Web Standards

Oh wait, I was looking at production

Css Tricks - Wed, 06/07/2017 - 3:10am

Oh so true:

Why won't this CSS change?!

Restart server


rm -rf everything


rebuild dev env


Oh wait, I was looking at production

— Mike Coutermarsh (@mscccc) June 5, 2017

Not to ruin the joke, but I find it tremendously helpful to Give Your Development Domain a Different Favicon Than Production.

Read the comment thread on that post too, there are some other very clever ideas.

Direct Link to ArticlePermalink

Oh wait, I was looking at production is a post from CSS-Tricks

Creating Yin and Yang Loaders On the Web

Css Tricks - Tue, 06/06/2017 - 2:30am

I came across a couple such animations a while ago and this gave me the idea of creating my own versions with as little code as possible, no external libraries, using various methods, some of which take advantage of more recent features we can use these days, such as CSS variables. This article is going to guide you through the process of building these demos.

Before anything else, this is the animation we're trying to achieve here:

The desired result: a rotating ? symbol, with its two lobes increasing and decreasing in size.

No matter what method we choose to use to recreate the above animation, we always start from the static yin and yang shape which looks as illustrated below:

The static yin and yang symbol (live demo).

The structure of this starting shape is described by the following illustration:

The structure of the static symbol (live demo).

First off, we have a big circle of diameter d. Inside this circle, we tightly fit two smaller circles, each one of them having a diameter that's half the diameter of our initial big circle. This means that the diameter for each of these two smaller circles is equal to the big circle's radius r (or .5*d). Inside each of these circles of diameter r we have an even smaller concentric circle. If we are to draw a diameter for the big circle that passes through all the central points of all these circles - the line segment AB in the illustration above, the intersections between it and the inner circles split it into 6 equal smaller segments. This means that the diameter of one of the smallest circles is r/3 (or d/6) and its radius is r/6.

Knowing all of this, let's get started with the first method!

Plain old HTML + CSS

In this case, we can do it with one element and its two pseudo-elements. The how behind building the symbol is illustrated by the following animation (since the whole thing is going to rotate, it doesn't matter if we switch axes):

See the Pen by thebabydino (@thebabydino) on CodePen.

The actual element is the big circle and it has a top to bottom gradient with a sharp transition right in the middle. The pseudo-elements are the smaller circles we place over it. The diameter of one of the smaller circles is half the diameter of the big circle. Both smaller circles are vertically middle-aligned with the big circle.

So let's start writing the code that can achieve this!

First of all, we decide upon a diameter $d for the big circle. We use viewport units so that everything scales nicely on resize. We set this diameter value as its width and height, we make the element round with border-radius and we give it a top to bottom gradient background with a sharp transition from black to white in the middle.

$d: 80vmin; .? { width: $d; height: $d; border-radius: 50%; background: linear-gradient(black 50%, white 0); }

So far, so good:

See the Pen by thebabydino (@thebabydino) on CodePen.

Now let's move on to the smaller circles which we create with pseudo-elements. We give our element display: flex and make its children (or pseudo-elements in our case) middle aligned with it vertically by setting align-items: center. We make these pseudo-elements have half the height (50%) of their parent element and make sure that, horizontally, they each cover half of the big circle. Finally, we make them round with border-radius, give them a dummy background and set the content property just so that we can see them:

.? { display: flex; align-items: center; /* same styles as before */ &:before, &:after { flex: 1; height: 50%; border-radius: 50%; background: #f90; content: ''; } }

See the Pen by thebabydino (@thebabydino) on CodePen.

Next, we need to give them different backgrounds:

.? { /* same styles as before */ &:before, &:after { /* same styles as before */ background: black; } &:after { background: white } }

Now we're getting somewhere!

See the Pen by thebabydino (@thebabydino) on CodePen.

All that's left to do before we get the static symbol is to give these two pseudo-elements borders. The black one should get a white border, while the white one should get a black border. These borders should be a third of the pseudo-element's diameter, which is a third of half the diameter of the big circle - that gives us $d/6.

.? { /* same styles as before */ &:before, &:after { /* same styles as before */ border: solid $d/6 white; } &:after { /* same styles as before */ border-color: black; } }

However, the result doesn't look quite right:

See the Pen by thebabydino (@thebabydino) on CodePen.

This is because, vertically, the border adds up to the height instead of being subtracted out of it. Horizontally, we haven't set a width, so it gets subracted from the available space. We have two fixes possible here. One would be to set box-sizing: border-box on the pseudo-elements. The second one would be to change the height of the pseudo-elements to $d/6 - we'll go with this one:

See the Pen by thebabydino (@thebabydino) on CodePen.

We now have the basic shape, so let's move on to the animation! This animation involves going from the state where the first pseudo-element has shrunk to let's say half its original size (which would mean a scaling factor $f of .5) while the second pseudo-element has expanded to take up all available space left - meaning to the diameter of the big circle (which is twice its original size) minus the diameter of the first circle (which is $f of its original size) to the state where the second pseudo-element has shrunk to $f of its original size and the first pseudo-element has expanded to 2 - $f of its original size. The first pseudo-element circle scales relative to its leftmost point (so we need to set a transform-origin of 0 50%), while the second one scales relative to its rightmost point (100% 50%).

$f: .5; $t: 1s; .? { /* same styles as before */ &:before, &:after { /* same styles as before */ transform-origin: 0 50%; transform: scale($f); animation: s $t ease-in-out infinite alternate; } &:after { /* same styles as before */ transform-origin: 100% 50%; animation-delay: -$t; } } @keyframes s { to { transform: scale(2 - $f) } }

We now have the shape changing animation we've been after:

See the Pen by thebabydino (@thebabydino) on CodePen.

The last step is to make the whole symbol rotate:

$t: 1s; .? { /* same styles as before */ animation: r 2*$t linear infinite; } @keyframes r { to { transform: rotate(1turn) } }

And we got the final result!

However, there's still one more thing we can do to make the compiled CSS more efficient: eliminate redundancy with CSS variables!

white can be written in HSL format as hsl(0, 0%, 100%). The hue and the saturation don't matter, any value that has the lightness 100% is white, so we just set them both to 0 to make our life easier. Similarly, black can be written as hsl(0, 0%, 0%). Again, the hue and saturation don't matter, any value that has the lightness 0% is black. Given this, our code becomes:

.? { /* same styles as before */ &:before, &:after { /* same styles as before */ border: solid $d/6 hsl(0, 0%, 100% /* = 1*100% = (1 - 0)*100% */); transform-origin: 0 /* = 0*100% */ 50%; background: hsl(0, 0%, 0% /* 0*100% */); animation: s $t ease-in-out infinite alternate; animation-delay: 0 /* = 0*-$t */; } &:after { /* same styles as before */ border-color: hsl(0, 0%, 0% /* = 0*100% = (1 - 1)*100% */); transform-origin: 100% /* = 1*100% */ 50%; background: hsl(0, 0%, 100% /* = 1*100% */); animation-delay: -$t /* = 1*-$t */; } }

From the above, it results that:

  • the x component of our transform-origin is calc(0*100%) for the first pseudo-element and calc(1*100%) for the second one
  • our border-color is hsl(0, 0%, calc((1 - 0)*100%)) for the first pseudo-element and hsl(0, 0%, calc((1 - 1)*100%)) for the second one
  • our background is hsl(0, 0%, calc(0*100%)) for the first pseudo-element and hsl(0, 0%, calc(1*100%)) for the second one
  • our animation-delay is calc(0*#{-$t}) for the first pseudo-element and calc(1*#{-$t}) for the second one

This means we can use a custom property that acts as a switch and is 0 for the first pseudo-element and 1 for the second:

.? { /* same styles as before */ &:before, &:after { /* same styles as before */ --i: 0; border: solid $d/6 hsl(0, 0%, calc((1 - var(--i))*100%)); transform-origin: calc(var(--i)*100%) 50%; background: hsl(0, 0%, calc(var(--i)*100%)); animation: s $t ease-in-out calc(var(--i)*#{-$t}) infinite alternate; } &:after { --i: 1 } }

This eliminates the need for witing all these rules twice: all we need to do now is flip the switch! Sadly, this only works in WebKit browsers for now because Firefox and Edge don't support using calc() as an animation-delay value and Firefox doesn't support using it inside hsl() either.

Canvas + JavaScript

While some people might think this method is overkill, I really like it because it requires about the same amount of code as the CSS one, it has good support and good performance.

We start with a canvas element and some basic styles just to put it in the middle of its container (which is the body element in our case) and make it visible. We also make it circular with border-radius so that we simplify our job when drawing on the canvas.

$d: 80vmin; body { display: flex; justify-content: center; align-items: center; height: 100vh; background: lightslategray; } canvas { width: $d; height: $d; border-radius: 50%; background: white; }

So far, so good - we have a white disc:

See the Pen by thebabydino (@thebabydino) on CodePen.

Alright, now let's move on to the JavaScript part! Before anything else, we need to get the canvas element, the 2D context and set the canvas element's width and height attributes (things we draw on the canvas would appear stretched otherwise). Then, we're going to need to have a radius for our big circle. We get this radius to be half the computed size of the canvas element and, after we do that, we translate our context such that we bring the 0,0 point of our canvas dead in the middle (it's originally in the top left corner). We make sure we recompute the radius and the width and height attributes on each resize because, in the CSS, we made the canvas dimensions depend on the viewport.

const _C = document.querySelector('canvas'), CT = _C.getContext('2d'); let r; function size() { _C.width = _C.height = Math.round(_C.getBoundingClientRect().width); r = .5*_C.width; CT.translate(r, r); }; size(); addEventListener('resize', size, false);

After we've done this, we can move on to drawing on the canvas. Draw what? Well, a shape made out of three arcs, as shown in the illustration below:

The structure of the three arc shape (live demo).

In order to draw an arc on a 2D canvas, we need to know a few things. First off, it's the coordinates of the central point of the circle this arc belongs to. Then we need to know the radius of this circle and the angles (relative to the x axis of the local coordinate system of the circle) at which the start and end points of the arc are located. Finally, we need to know if we go from the start point to the end point clockwise or not (if we don't specify this, the default is clockwise).

The first arc is on the big circle whose diameter is equal to the canvas dimensions and, since we've placed the 0,0 point of the canvas right in the middle of this circle, this means we know both the first set of coordinates (it's 0,0) and the circle radius (it's r). The start point of this arc is the leftmost point of this circle - this point is at -180° (or -?). The end point is the rightmost point of the circle, which is at 0° (also 0 in radians). If you need a refresher of angles on a circle, check out this helper demo.

This means we can create a path and add this arc to it and, in order to see what we have so far, we can close this path (which in this case means connecting the end point of our arc to the start point with a straight line) and fill it (using the default fill, which is black):

CT.beginPath(); CT.arc(0, 0, r, -Math.PI, 0); CT.closePath(); CT.fill();

The result can be seen in the following Pen:

See the Pen by thebabydino (@thebabydino) on CodePen.

Now let's move on to the second arc. The coordinates of the central point of the circle it's on are .5*r,0 and its radius is .5*r (half the radius of the big circle). It goes from 0 to ?, moving clockwise in doing so. So the arc we add to out path before closing it is:

CT.arc(.5*r, 0, .5*r, 0, Math.PI);

After adding this arc, our shape becomes:

See the Pen by thebabydino (@thebabydino) on CodePen.

Now we have one more arc left to add. The radius is the same as for the previous one (.5*r) and the first set of coordinates is -.5*r,0. This arc goes from 0 to -? and it's the first arc not to go clockwise, so we need to change that flag:

CT.arc(-.5*r, 0, .5*r, 0, -Math.PI, true);

We now have the shape we wanted:

See the Pen by thebabydino (@thebabydino) on CodePen.

Next, we're going to add the black circle to this path. We're not going to create another path because the aim is to group all shapes with the same fill into the same path for better performance. Calling fill() is expensive, so we don't want to do it more often than we really need to.

A circle is just an arc from 0° to 360° (or from 0 to 2*?). The central point of this circle coincides to that for the last arc we've drawn (-.5*r, 0) and its radius is a third of that of the previous two arcs.

CT.arc(-.5*r, 0, .5*r/3, 0, 2*Math.PI);

Now we're getting really close to having the full symbol:

See the Pen by thebabydino (@thebabydino) on CodePen.

All that's left to do is create a white circle, symmetrical to the black one with respect to the y axis. This means need to switch to a white fill, start a new path and then add an arc to it using almost the same command we used to add the black circle shape - the only difference is that we reverse the sign of the x coordinate (this time, it's +, not -). After that, we close that path and fill it.

CT.fillStyle = 'white'; CT.beginPath(); CT.arc(.5*r, 0, .5*r/3, 0, 2*Math.PI); CT.closePath(); CT.fill();

We now have the static symbol!

See the Pen by thebabydino (@thebabydino) on CodePen.

For the animation, we want to go from the state where the first of the smaller arcs has shrunk to half is original radius (so we use a scaling factor F of .5) and the other one has expanded accordingly to the state where these initial radii are reversed.

In the initial state, given that the radius of the smaller arcs is initially .5*r, then the radius of the first of them after being scaled down by a factor F is r1 = F*.5*r. Since the radii of the smaller circles need to add up to the radius of the big circle r, we have that the radius of the second one of the smaller circles is r2 = r - r1 = r - F*.5*r.

In order to get the x coordinate of the origin of the first smaller arc for the initial state, we need to subtract its radius from the x coordinate of the point it starts at. This way, we get that this coordinate is r - r1 = r2. Similarly, in order to get the x coordinate of the origin of the second smaller arc, we need to add up its radius to the coordinate of the point it ends at. This way, we get that this coordinate is -r + r2 = -(r - r2) = -r1.

The initial vs. the final state of the animation (live demo).

For the final state, the values of the two radii are reversed. The second one is F*.5*r, while the first one is r - F*.5*r.

With every frame of our animation, we increase the current radius of the first smaller arc from the minimum value (F*.5*r) to the maximum value (r - F*.5*r) and then we start decreasing it to the minimum value and then the cycle repeats while also scaling the radius of the other smaller arc accordingly.

In order to do this, we first set the minimum and maximum radius in the size() function:

const F = .5; let rmin, rmax; function size() { /* same as before */ rmin = F*.5*r; rmax = r - rmin; };

At any moment in time, the current radius of the first of the smaller arcs is k*rmin + (1 - k)*rmax, where this k factor keeps going from 1 to 0 and then back up to 1. This sounds similar to the cosine function on the [0, 360°] interval. At 0°, the value of the cosine is 1. Then it starts decreasing and it keeps doing so until it gets to 180°, when it reaches its minimum value of -1, after which the value of the function starts increasing again until it gets to 360°, where it's again 1:

See the Pen by thebabydino (@thebabydino) on CodePen.

Alright, but the values of the cosine function are in the [-1, 1] interval and we need a function that gives us values in the [0, 1] interval. Well, if we add 1 to the cosine, then we shift the whole graph up and the values are now in the [0, 2] interval:

See the Pen by thebabydino (@thebabydino) on CodePen.

[0, 2] isn't [0, 1], so what we still need to do here is divide the whole thing by 2 (or multiply it with .5, same thing). This squishes our graph to the desired interval.

See the Pen by thebabydino (@thebabydino) on CodePen.

Good, but what's up with that angle? We don't have an angle going from 0° to 360°. If we're going to use requestAnimationFrame, we just have the number of the current frame, which starts at 0 and then keeps going up. Well, at the beginning, we set a total number of frames T for one animation cycle (the first arc going from the minimum radius value to the maximum radius value and then back again).

For every frame, we compute the ratio between the number of the current frame (t) and the total numeber of frames. For one cycle, this ratio goes from 0 to 1. If we multiply this ratio with 2*Math.PI (which is the same as 360°), then the result goes from 0 to 2*Math.PI over the course of a cycle. So this is going to be our angle.

const T = 120; (function ani(t = 0) { let k = .5*(1 + Math.cos(t/T*2*Math.PI)), cr1 = k*rmin + (1 - k)*rmax, cr2 = r - cr1; })();

The next step is to put inside this function the code that actually draws our symbol. The code for beginning, closing, filling paths, changing fills stays the same, as does the code needed for creating the big arc. The things that change are:

  • the radii of the smaller arcs - they're cr1 and cr2 respectively
  • the x coordinates of the central points for the smaller arcs - they're at cr2 and -cr1 respectively
  • the radii of the black and white circles - they're cr2/3 and cr1/3 respectively
  • the x coordinates of the central points of these circles - they're at -cr1 and cr2 respectively

So our animation function becomes:

const T = 120; (function ani(t = 0) { let k = .5*(1 + Math.cos(t/T*2*Math.PI)), cr1 = k*rmin + (1 - k)*rmax, cr2 = r - cr1; CT.beginPath(); CT.arc(0, 0, r, -Math.PI, 0); CT.arc(cr2, 0, cr1, 0, Math.PI); CT.arc(-cr1, 0, cr2, 0, -Math.PI, true); CT.arc(-cr1, 0, cr2/3, 0, 2*Math.PI); CT.closePath(); CT.fill(); CT.fillStyle = 'white'; CT.beginPath(); CT.arc(cr2, 0, cr1/3, 0, 2*Math.PI); CT.closePath(); CT.fill(); })();

This gives us the initial state of the animation:

See the Pen by thebabydino (@thebabydino) on CodePen.

Before we actually start animating the radii of the arcs, we still need to take care of a couple more things. First of all, if we start the animation right now, we're just going to be drawing how the shape looks for each frame over what we've drawn for the previous frames, which is going to create one big mess. In order to avoid this, we need to clear the canvas for each frame, before drawing anything on it. What we clear is the visible part, which is inside the rectangle of canvas dimensions whose top left corner is at -r,-r:

CT.clearRect(-r, -r, _C.width, _C.width);

The second little problem we need to fix is that we're switching to a white fill, but at the start of the next frame, we need a black one. So we need to make this switch for each frame before the beginning of the first path:

CT.fillStyle = 'black';

Now we can actually start the animation:

requestAnimationFrame(ani.bind(this, ++t));

This gives us the morphing animation, but we still need to rotate the whole thing. Before tackling that, let's look at the formula for k once more:

let k = .5*(1 + Math.cos(t/T*2*Math.PI))

T and 2*Math.PI are constant throughout the animation, so we can just take that part out and store it as a constant angle A:

const T = 120, A = 2*Math.PI/T; (function ani(t = 0) { let k = .5*(1 + Math.cos(t*A)); /* same as before */ })();

Now for every frame, we can also rotate the context by A after clearing the canvas.


This rotation keeps adding up with every frame and we now have the rotating and morphing animation we've been after.

SVG + JavaScript

We start with an SVG element and pretty much the same CSS as in the canvas case:

$d: 80vmin; body { display: flex; justify-content: center; align-items: center; height: 100vh; background: lightslategray; } svg { width: $d; height: $d; border-radius: 50%; background: white; }

This gives us a white disc:

See the Pen by thebabydino (@thebabydino) on CodePen.

Not too exciting, so let's move on to drawing something on the SVG canvas. Just like in the canvas case, we'll be drawing a path made up of the same three arcs (the big one with a radius that's half the size of the SVG viewBox and the two smaller ones with a radius that's half of that of the big arc in the static case) and two small circles (with a radius that's a third of that of the smaller arc they share their central point with).

So we start by picking a radius r value and using it to set the viewBox on the svg element:

- var r = 1500; svg(viewBox=[-r, -r, 2*r, 2*r].join(' '))

The next step is to add the path made up of the three arcs. Creating a path in SVG is a bit different from canvas. Here, the shape is described by the path data d attribute, which, in our case, is made up of:

  • a "move to" (M) command after which we specify the coordinates of the start point of our path (also the start point of the big arc in this case)
  • an "arc to" (A) command for each of our arcs after which we describe our arcs; each of these arcs starts from the end point of the previous arc or, in the case of the first arc, from the start point of our path

Let's take a closer look at the components of an "arc to" (A) command:

  • the radius of our arc along the x axis of its system of coordinates - this is equal to r in the case of the big arc and to .5*r in the case of the two smaller ones
  • the radius of our arc along the y axis of its system of coordinates - this is equal to the one along the x axis in the case of circular arcs as we have here (it's only different for elliptical arcs, but that's beyond the scope of this article)
  • the rotation of our arc's system of coordinates - this only influences the arc's shape in the case of elliptical arcs, so we can safely always take it 0 to simplify things for circular arcs
  • the large arc flag - this is 1 if our arc is greater than half a circle and 0 otherwise; since our arcs are exactly half a circle, they're not greater than haf a circle, so this is always 0 in our case
  • the sweep flag - this is 1 if the arc goes clockwise between its start and its end point and 0 otherwise; in our case, the first two arcs go clockwise, while the third doesn't, so the values we use for the three arcs are 1, 1 and 0
  • the x coordinate of the arc's end point - this is something we need to determine for each arc
  • the y coordinate of the arc's end point - also something we need to determine for each arc

At this point, we already know most of what we need. All we still have to figure out are the coordinates of the arcs' endpoints. So let's consider the following illustration:

The structure of the three arc shape with coordinates of arc endpoints (live demo).

From the illustration above we can see that the first arc (the big one) starts at (-r,0) and ends at (r,0), the second one ends at 0,0 and the third one ends at (-r,0) (also the start point of our path). Note that the y coordinates of all these points remain 0 even if the smaller arcs' radii change, but the x coordinate of the second arc's endpoint only happens to be 0 in this case when the radii of the smaller arcs are exactly half of the big one. In the general case, it's r - 2*r1, where r1 is the radius of the second arc (the first of the smaller ones). This means we can now create our path:

- var r1 = .5*r, r2 = r - r1; path(d=`M${-r} 0 A${r} ${r} 0 0 1 ${r} 0 A${r1} ${r1} 0 0 1 ${r - 2*r1} 0 A${r2} ${r2} 0 0 0 ${-r} 0`)

This gives us the three arc shape we've been after:

See the Pen by thebabydino (@thebabydino) on CodePen.

Now let's move on to the small circles. We already know the coordinates of their central points and their radii from the canvas method.

circle(r=r1/3 cx=r2) circle(r=r2/3 cx=-r1)

By default, all these shapes have a black fill so we need to explicitly set a white one on the circle at (r2,0):

circle:nth-child(2) { fill: white }

We now have the static shape!

See the Pen by thebabydino (@thebabydino) on CodePen.

Next, we're going to animate the shape of our path and the size and position of our two small circles using JavaScript. This means that the first thing we do is get these elements, get the radius R of the big circle and set a scaling factor F that gives us the minimum radius (RMIN) down to which the arcs can be scaled. We also set a total number of frames (T) and a unit angle (A).

const _P = document.querySelector('path'), _C = document.querySelectorAll('circle'), _SVG = document.querySelector('svg'), R = -1*_SVG.getAttribute('viewBox').split(' ')[0], F = .25, RMIN = F*R, RMAX = R - RMIN, T = 120, A = 2*Math.PI/T;

The animation function is pretty much the same as in the canvas case. The only thing that's different is the fact that now, in order to change the path shape, we change its d attribute and, in order to change the small circles' radii and positions, we change their r and cx attributes. But everything else works exactly the same way:

(function ani(t = 0) { let k = .5*(1 + Math.cos(t*A)), cr1 = k*RMIN + (1 - k)*RMAX, cr2 = R - cr1; _P.setAttribute('d', `M${-R} 0 A${R} ${R} 0 0 1 ${R} 0 A${cr1} ${cr1} 0 0 1 ${R - 2*cr1} 0 A${cr2} ${cr2} 0 0 0 ${-R} 0`); _C[0].setAttribute('r', cr1/3); _C[0].setAttribute('cx', cr2); _C[1].setAttribute('r', cr2/3); _C[1].setAttribute('cx', -cr1); requestAnimationFrame(ani.bind(this, ++t)); })();

This gives us the morphing shape:

See the Pen by thebabydino (@thebabydino) on CodePen.

There's just one more thing to take care of and that's the rotation of the whole symbol, which we set on the _SVG element:

let ca = t*A; _SVG.style.transform = `rotate(${+ca.toFixed(2)}rad)`;

And we now have the desired result with SVG and JavaScript as well!


There's one more method of doing this, although it involves changing things like the path data from CSS, which is something only Blink browsers support at this point (and they're not even matching the latest spec).

It's also a bit breakable because we need to have the same radius value both in the SVG viewBox attribute and as a Sass variable.

- var r = 1500; svg(viewBox=[-r, -r, 2*r, 2*r].join(' ')) path circle circle $d: 65vmin; $r: 1500; $r1: .5*$r; $r2: $r - $r1; $rmin: .25*$r; $rmax: $r - $rmax;

We could access the value of this radius from the CSS, but only as a custom property, if we were to do something like this:

- var r = 1500; svg(viewBox=[-r, -r, 2*r, 2*r].join(' ')) style :root { --r: #{r} }

However, while this may be very helpful in some cases, it is useless here, as we currently have no way of putting CSS variables into the path data string we build with Sass. So we're stuck with having to set the same value both in the viewBox attribute and in the Sass code.

The basic styles are the same and we can create the path data with Sass in a way that's similar to the Pug method:

$r: 1500; $r1: .5*$r; $r2: $r - $r1; path { $data: 'M#{-$r} 0' + 'A#{$r} #{$r} 0 0 1 #{$r} 0' + 'A#{$r1} #{$r1} 0 0 1 #{$r - 2*$r1} 0' + 'A#{$r2} #{$r2} 0 0 0 #{-$r} 0'; d: path($data); }

This gives us our three arcs shape:

The three arcs shape (live demo, Blink only).

For the two small circles, we set their radii and positions along the x axis. We also need to make sure one of them is white:

circle { r: $r1/3; cx: $r2; &:nth-child(2) { fill: white } &:nth-child(3) { r: $r2/3; cx: -$r1 } }

We now have the static shape:

The static yin and yang shape (live demo, Blink only).

In order to get the effect we're after, we need the following animations:

  • a morphing animation of the path shape, where the radius of the first of the smaller arcs goes from the minimum possible radius ($rmin: .25*$r) to the maximum possible one ($rmax: $r - $rmin) and then back, while the radius of the last arc goes from $rmax to $rmin and back again; this can be done with a keyframe animation from one extreme to the other and then using the alternate value for animation-direction
  • another alternating animation that scales the radius of the first small circle from $rmin/3 up to $rmax/3 and then back down to $rmin/3 again; the second small circle uses the same animation only delayed by the value of a normal animation-duration
  • a third alternating animation that moves the central points of the two small circles back and forth; in the case of the first (white) small circle, it moves from $rmax down to $rmin; in the case of the second (black) circle, it goes from -$rmin down to -$rmax; what we can do here to unify them is use a CSS variable as a switch (it only works in WebKit browsers, but setting the path data or the circle radii or offsets from the CSS doesn't have better support either)

So let's first see the morphing @keyframes. These are created by setting pretty much the same path data as before, only replacing $r1 with $rmin and $r2 with $rmax for the 0% keyframe and the other way around for the 100% one:

@keyframes m { 0% { $data: 'M#{-$r} 0' + 'A#{$r} #{$r} 0 0 1 #{$r} 0' + 'A#{$rmin} #{$rmin} 0 0 1 #{$r - 2*$rmin} 0' + 'A#{$rmax} #{$rmax} 0 0 0 #{-$r} 0'; d: path($data); } 100% { $data: 'M#{-$r} 0' + 'A#{$r} #{$r} 0 0 1 #{$r} 0' + 'A#{$rmax} #{$rmax} 0 0 1 #{$r - 2*$rmax} 0' + 'A#{$rmin} #{$rmin} 0 0 0 #{-$r} 0'; d: path($data); } }

Now we just need to set this animation on the path element:

$t: 1s; path { animation: m $t ease-in-out infinite alternate }

And the shape morphing part works!

The three arcs shape morphing (live demo, Blink only).

Next step is to move on to scaling and moving the two small circles. The scaling @keyframes follow the same pattern as the morphing ones. The radius value is $rmin/3 at 0% and $rmax/3 at 100%:

@keyframes s { 0% { r: $rmin/3 } 100% { r: $rmax/3 } }

We set this animation on the circle elements:

circle { animation: s $t ease-in-out infinite alternate }

And now the radii of the two small circles are animated:

The three arcs shape morphing and the small circles scaling (live demo, Blink only).

It's a start, but we have a number of problems here. First of all, the second small circle should decrease in size when the first one is growing bigger and the other way around. We fix this by setting an animation-delay that depends on a CSS variable we initially set to 0 and then switch to 1 on the second small circle:

circle { --i: 0; animation: s $t ease-in-out calc(var(--i)*#{$t}) infinite alternate &:nth-child(3) { --i: 1 } }

As mentioned before, using calc() as an animation-delay value only works in WebKit browsers, but setting r from the CSS has even poorer support, so the animation-delay is not the biggest problem we have here. The result can be seen below:

The three arcs shape morphing and the small circles scaling (live demo, Blink only).

This is much better, but we still nedd to animate the positions of the small circles along the x axis. The way we do this is with a set of @keyframes that make cx go from $rmax to $rmin and back again for the first small circle and from -$rmin to -$rmax and back for the second one. In these two cases, we have both a different order and a different sign, so we need to come up with a keyframe animation that satisfies both.

Getting around the order problem is the easy part - we use the same animation-delay as we did for the scaling radii animation.

But what about the sign? Well, we use our custom property --i again. This is 0 for the first small circle and 1 for the second one, so we need a function that takes in --i and gives us 1 when this variable's value is 0 and -1 for a value of 1. The simplest one that comes to mind is raising -1 to the power --i. Sadly, that's not possible with CSS - we can only have arithmetic operations inside calc(). However, calc(1 - 2*var(--i)) is another solution that works and it's not much more complicated. Using this, our code becomes:

circle { --i: 0; --j: calc(1 - 2*var(--i)); animation: s $t ease-in-out calc(var(--i)*#{-$t}) infinite alternate; animation-name: s, x; &:nth-child(3) { --i: 1 } } @keyframes x { 0% { cx: calc(var(--j)*#{$rmax}) } 100% { cx: calc(var(--j)*#{$rmin}) } }

The result can be seen below... and it's not quite as expected:

Result (live demo, Blink only).

What we have looks like a sudden flip at 50% in between the two end values, not a smooth animation. This is not what we wanted, so it looks like we need to abandon this tactic.

We have another option here though: combining cx with transform. The two small circles are always positioned such that the distance between their central points is $r. So what we can do is position the second of the small circles at -$r, then translate them both by a distance that's between $rmax and $rmin:

circle { transform: translate($r2*1px); animation: s $t ease-in-out infinite alternate; animation-name: s, x; &:nth-child(3) { cx: -$r; animation-delay: -$t, 0s } } @keyframes x { 0% { transform: translate($rmax*1px) } 100% { transform: translate($rmin*1px) } }

This finally behaves as we wanted it to!

Correct animation (live demo, Blink only)

One more thing we can do here to simplify the code is get rid of the initial $r1 and $r2 values and replace them with those in the 0% keyframe of each animation:

path { d: path('M#{-$r} 0A#{$r} #{$r} 0 0 1 #{$r} 0' + 'A#{$rmin} #{$rmin} 0 0 1 #{$r - 2*$rmin} 0' + 'A#{$rmax} #{$rmax} 0 0 0 #{-$r} 0'); animation: m $t ease-in-out infinite alternate } circle { r: $rmin/3; transform: translate($rmax*1px); animation: s $t ease-in-out infinite alternate; animation-name: s, x; &:nth-child(3) { cx: -$r; animation-delay: -$t, 0s } } @keyframes m { to { d: path('M#{-$r} 0A#{$r} #{$r} 0 0 1 #{$r} 0' + 'A#{$rmax} #{$rmax} 0 0 1 #{$r - 2*$rmax} 0' + 'A#{$rmin} #{$rmin} 0 0 0 #{-$r} 0'); } } @keyframes s { to { r: $rmax/3 } } @keyframes x { to { transform: translate($rmin*1px) } }

The visual result is exactly the same, we just have less code.

The final step is to make the SVG element itself rotate infinitely:

svg { animation: r 2*$t linear infinite } @keyframes r { to { transform: rotate(1turn) } }

The finished loading animation can be seen in this Pen.

So there you have it - one loading animation, four different methods of recreating it from scratch for the web. Not everything we've explored in here is usable in practice today. For example, the support for the last method is really poor and the performance is awful. However, exploring the limits of what's becoming possible these days was a fun exercise and a great learning opportunity.

Creating Yin and Yang Loaders On the Web is a post from CSS-Tricks

Breaking Out with CSS Grid Explained

Css Tricks - Tue, 06/06/2017 - 2:26am

Tyler Sticka shared a slick technique for breaking out content in a CSS Grid layout, but Rachel Andrew goes the extra mile to explain why the technique works:

When you name lines, you can optionally name them as *-start and *-end and this gives you a little more grid magic. We get a named grid area of the main name used. Sounds odd? Take a look at the diagram below, it shows 4 named grid lines, main-start and main-end both for columns and rows. The area marked out by the intersection of these lines can now be referenced by the name main. If we had named the lines foo-start and foo-end then we would have a named area called foo.

Rachel's post stood out to me for a number of reasons. First, I love blog posts as responses to other blog posts. Second, it's an excellent reminder that sharing how a concept works is equally as important as showing that it works. Lastly, the concept of implicitly named grid areas based on named grid lines is as good a reason as any to roll up our sleeves and get cozy with the spec. In fact, following Rachel's series on the CSS Grid spec is a good starting point.

As a side note, Tyler's clever use of named Grid lines reminded me of Dave Rupert's equally crafty use of :not to achieve a similar full bleed effect.

Direct Link to ArticlePermalink

Breaking Out with CSS Grid Explained is a post from CSS-Tricks

Fun with Viewport Units

Css Tricks - Mon, 06/05/2017 - 2:50am

Viewport units have been around for several years now, with near-perfect support in the major browsers, but I keep finding new and exciting ways to use them. I thought it would be fun to review the basics, and then round-up some of my favorite use-cases.

What are viewport units?

Four new "viewport-relative" units appeared in the CSS specifications between 2011 and 2015, as part of the W3C's CSS Values and Units Module Level 3. The new units – vw, vh, vmin, and vmax - work similarly to existing length units like px or em, but represent a percentage of the current browser viewport.

  • Viewport Width (vw) – A percentage of the full viewport width. 10vw will resolve to 10% of the current viewport width, or 48px on a phone that is 480px wide. The difference between % and vw is most similar to the difference between em and rem. A % length is relative to local context (containing element) width, while a vw length is relative to the full width of the browser window.
  • Viewport Height (vh) – A percentage of the full viewport height. 10vh will resolve to 10% of the current viewport height.
  • Viewport Minimum (vmin) – A percentage of the viewport width or height, whichever is smaller. 10vmin will resolve to 10% of the current viewport width in portrait orientations, and 10% of the viewport height on landscape orientations.
  • Viewport Maximum (vmax) – A percentage of the viewport width or height, whichever is larger. 10vmin will resolve to 10% of the current viewport height in portrait orientations, and 10% of the viewport width on landscape orientations. Sadly, and strangely, vmax units are not yet available on Internet Explorer or Edge.

While these units are derived from viewport height or width, they can all be used everywhere lengths are accepted – from font-size to positioning, margins, padding, shadows, borders, and so on. Let's see what we can do!

Responsive Typography

It's become very popular to use viewport units for responsive typography – establishing font-sizes that grow and shrink depending on the current viewport size. Using simple viewport units for font-size has an interesting (dangerous) effect. As you can see, fonts scale very quickly – adjusting from unreadably small to extra large in a very small range.

This direct scaling is clearly too dramatic for daily use. We need something more subtle, with minimums and maximums, and more control of the growth rate. That's where calc() becomes useful. We can combine a base size in more steady units (say 16px) with a smaller viewport-relative adjustment (0.5vw), and let the browser do the math: calc(16px + 0.5vw)

See the Pen partially-Responsive Type by Miriam Suzanne (@mirisuzanne) on CodePen.

By changing the relationship between your base-size and viewport-relative adjustment, you can change how dramatic the growth-rate is. Use higher viewport values on headings, and watch them grow more quickly than the surrounding text. This allows for a more dynamic typographic scale on larger screens, while keeping fonts constrained on a mobile device - no media-queries required. You can also apply this technique to your line-height, allowing you to adjust leading at a different rate than the font-size.

body { // font grows 1px for every 100px of viewport width font-size: calc(16px + 1vw); // leading grows along with font, // with an additional 0.1em + 0.5px per 100px of the viewport line-height: calc(1.1em + 0.5vw); }

For me, this is enough complexity. If I need to constrain the top-end for rapid-growth headings, I can do that with one single media-query wherever the text becomes too large:

h1 { font-size: calc(1.2em + 3vw); } @media (min-width: 50em) { h1 { font-size: 50px; } }

Suddenly I wish there was a max-font-size property.

Others have developed more complex calculations and Sass mixins to specify the exact text-size ranges at specific media-queries. There are several existing CSS-Tricks articles that explain the technique and provide snippets to help you get started:

I think that's overkill in most cases, but your milage will absolutely vary.

Full-Height Layouts, Hero Images, and Sticky Footers

There are many variations on full-height (or height-constrained) layouts – from desktop-style interfaces to hero images, spacious designs, and sticky footers. Viewport-units can help with all of these.

In a desktop-style full-height interface, the page is often broken into sections that scroll individually – with elements like headers, footers, and sidebars that remains in place at any size. This is common practice for many web-apps these days, and vh units make it much simpler. Here's an example using the new CSS Grid syntax:

See the Pen Full-height CSS Grid by Miriam Suzanne (@mirisuzanne) on CodePen.

A single declaration on the body element, height: 100vh, constrains your application to the height of the viewport. Make sure you apply overflow values on internal elements, so your content isn't cut off. You can also achieve this layout using flexbox or floats.Note that full-height layouts can cause problems on some mobile browsers. There's a clever fix for iOs Safari, that we use to handle one of the most noticeable edge-cases.

Sticky-footers can be created with a similar technique. Change your body height: 100vh to min-height: 100vh and the footer will stay in place at the bottom of your screen until it's pushed down by content.

See the Pen Sticky-Footer with CSS Grid by Miriam Suzanne (@mirisuzanne) on CodePen.

Apply vh units to the height, min-height, or max-height of various elements to create full-screen sections, hero images, and more. In the new OddBird redesign, we constrained our hero images with max-height: 55vh so they never push headlines off the page. On my personal website, I went with max-height: 85vh for a more image-dominated look. On other sites, I've applied min-height: 90vh to sections.

Here's an example showing both a max-height heroic kitten, and a min-height section. Combining all these tricks can give you some powerful control around how your content fills a browser window, and responds to different viewports.

Fluid Aspect Ratios

It can also be useful to constrain the height-to-width ratio of an element. This is especially useful for embeded content, like videos. Chris has written about this before. In the good-old-days, we would do that with %-based padding on a container element, and absolute positioning on the inner element. Now we can sometimes use viewport units to achieve that effect without the extra markup.

If we can count on the video being full-screen, we can set our height relative to the full viewport width:

/* full-width * aspect-ratio */ .full-width { width: 100vw; height: calc(100vw * (9/16)); }

That math doesn't have to happen in the browser with calc. If you are using a pre-processor like Sass, it will work just as well to do the math there: height: 100vw * (9/16). If you need to constrain the max-width, you can constrain the max-height as well:

/* max-width * aspect-ratio */ .full-width { width: 100vw; max-width: 30em; height: calc(100vw * (9/16)); max-height: calc(30em * (9/16)); }

Here's a demonstration showing both options, with CSS custom properties (variables) to make the math more semantic. Play with the numbers to see how things move, keeping the proper ratio at all times:

See the Pen Fluid Ratios with Viewport Units by Miriam Suzanne (@mirisuzanne) on CodePen.

Chris takes this one step farther in his pre-viewport-units article, so we will too. What if we need actual HTML content to scale inside a set ratio - like presentation slides often do?

We can set all our internal fonts and sizes using the same viewport units as the container. In this case I used vmin for everything, so the content would scale with changes in both container height and width:

See the Pen Fluid Slide Ratios with Viewport Units by Miriam Suzanne (@mirisuzanne) on CodePen.

Breaking the Container

For years now, it's been popular to mix constrained text with full-width backgrounds. Depending on your markup or CMS, that can become difficult. How do you break content outside of a restricted container, so that it fills the viewport exactly?

Again, viewport units can come in handy. This is another trick we've used on the new OddBird site, where a static-site generator sometimes limits our control of the markup. It only takes a few lines of code to make this work.

.full-width { margin-left: calc(50% - 50vw); margin-right: calc(50% - 50vw); }

There are more in-depth articles about the technique, both at Cloud Four and here on CSS Tricks.

Getting Weird

Of course, there's much more you can do with viewport units, if you start experimenting. Check out this pure CSS scroll-indicator (made by someone named Mike) using viewport units on a background image:

See the Pen CSS only scroll indicator by Mike (@MadeByMike) on CodePen.

What else have you seen, or done with viewport units? Get creative, and show us the results!

Fun with Viewport Units is a post from CSS-Tricks

Using Filters in Vue.js

Css Tricks - Sat, 06/03/2017 - 1:06am

Filters are an interesting way to deal with data rendering in Vue but are only useful in a small amount of cases. The first thing to understand about filters is that they aren't replacements for methods, computed values, or watchers, because filters don't transform the data, just the output that the user sees. As of Vue 2.0, there are no built-in filters, we need to construct them ourselves.

We can use filters locally or globally, but it's worth mentioning that if you declare a Vue filter globally it should come before the Vue instance. In both cases, we would pass the value in as a parameter.

//global Vue.filter('filterName', function(value) { return // thing to transform }); //locally, like methods or computed filters: { filterName(value) { return // thing to transform } }

Filters are used with a pipe, following the piece of data you'd like to be altered upon render. So we would show the piece of data we want to alter, followed by the filter

{{ data | filter }}

Here's a small example, with a tip calculator:

See the Pen Filters by Sarah Drasner (@sdras) on CodePen.

new Vue({ el: '#app', data() { return { customer1total: 35.43 } }, filters: { tip15(value) { return (value*.15).toFixed(2) }, tip20(value) { return (value*.2).toFixed(2) }, tip25(value) { return (value*.25).toFixed(2) } } }); <div id="app"> <h2>Tip Calculator</h2> <p><strong>Total: {{ customer1total }}</strong></p> <p>15%: {{ customer1total | tip15 }}</p> <p>20%: {{ customer1total | tip20 }}</p> <p>25%: {{ customer1total | tip25 }}</p> </div>

You can also use filters in v-bind directives rather than just the mustache template. Filters can also be chained. Keep in mind if you're going to chain filters: ordering matters. The first filter will be applied first, the second will be applied to the completed first, and so on.

{{ data | filterA | filterB }}

We can also pass additional arguments into filters like so:

{{ data | filterName(arg1, arg2) }} // locally, like methods or computed filters: { filterName(value, arg1, arg2) { return //thing to transform } }

Now, you might think, based on the name, that filters would be great for forms when we want to show only some bits of data and not others. However, filters need to rerun on every single update, so if you have something like an input that updates every time you type, it's not very performant. Better to use computed for something like this as it's less overhead. The results will be cached based on their dependencies and won't be rerun on every update. Computed properties will only be reevaluated when those dependencies change, but can also handle complex logic. This makes them excellent candidates for filtering information based on input. There are, however, circumstances where you do need to update based on changes in time, and for these instances, better to use a method.

Using Filters in Vue.js is a post from CSS-Tricks

Intro to Firebase and React

Css Tricks - Fri, 06/02/2017 - 3:16am

Let's take a look at building something using Firebase and React. We'll be building something called Fun Food Friends, a web application for planning your next potluck, which hopefully feels like something rather "real world", in that you can imagine using these technologies in your own production projects. The big idea in this app is that you and your friends will be able to log in and be able to see and post information about what you're planning to bring to the potlock.

When we're finished, it will look like this:

Our example app: Fun Food Friends

This article assumes you already have some basic knowledge of how React works and maybe built a few small apps with React. If you haven't, I would recommend checking out a series like Wes Bos' React for Beginners first before continuing on.

What is Firebase?

Google's Firebase is a cloud-based database hosting service that will set up a database for you and host it, as well as offer you the tools to interact with it. You can use it to store and retrieve data in real time. That's not all Firebase does, it can do more things like handle user authentication and store files, but we'll be mainly focusing on data storage.

The data storage ability of Firebase make it a perfect fit for React. A persistent, real-time backend for your application to plug in to!

How does Firebase store data?

Firebase stores data as a giant object with key-value pairs. Unlike JSON or JavaScript objects, there are no arrays in Firebase.

A Firebase database might look something like this:

{ "groceries": { "-KjQTqG3R2dPT8s2jylW": "tomato", "-KjQTrds1feHT3GH_29o": "pasta", "-KjQTsmfBR8zN1SwPPT8": "milk", "-KjQTtnzt_jJZPoCHWUM": "sugar" }, "users": { "name": { "-KjQTyIfKFEVMYJRZ09X": "simon", "-KjQU-Xuy5s7I-On9rYP": "ryan", "-KjQU0MYVeKRsLuIQCYX": "sylvia" } } }

For more information on the nuances of structuring data in Firebase, you can read the amazing Firebase documentation.

Ready to start? Let's dig in!

Getting Started: Setting up Our App

We'll start by using the incredibly handy `create-react-app` package in order to quickly set up a new React project without having to worry about any build configuration. Open up your command line, and type the following:

npm install -g create-react-app create-react-app fun-food-friends cd fun-food-friends yarn add firebase --dev yarn start

This will boot up your app in the browser, and start a watch task in your terminal so that we can begin hacking away at the project. We're also installing the `firebase` package here as we'll need it for the next step.

Creating our Firebase Database

Now that our app is set up, we'll need to create an account and database on Firebase so that we can link up our application to it.

Head on over to Firebase's website, and click Get Started.

This will take you to a page where you’ll be asked to authenticate with your Google account. Select the account that you’d like this project to be affiliated with, and press OK.

This should take you to the Firebase console, which looks something like this:

Now let's create our project's database. Click Add Project. Let's call it "fun-food-friends" and press OK.

This will take you to your app's dashboard, which looks like this:

Since we'll be building a web app, select Add Firebase to your web app. This will trigger a popup with some code that looks like this:

<script src="https://www.gstatic.com/firebasejs/3.9.0/firebase.js"></script> <script> // Initialize Firebase var config = { apiKey: "AIzaSyDblTESEB1SbAVkpy2q39DI2OHphL2-Jxw", authDomain: "fun-food-friends-eeec7.firebaseapp.com", databaseURL: "https://fun-food-friends-eeec7.firebaseio.com", projectId: "fun-food-friends-eeec7", storageBucket: "fun-food-friends-eeec7.appspot.com", messagingSenderId: "144750278413" }; firebase.initializeApp(config); </script>

Since we'll be importing Firebase into our project using ES6 modules, we won't need those script tags. That config object is important though: it's how we authenticate our React application with our Firebase database.

Hooking up our App to Firebase

Copy that whole config object, and head back over to your React project. Find your `src` folder, and create a file called `firebase.js`. Inside of it, let's import firebase, our config, and initialize our app:

// src/firebase.js import firebase from 'firebase' const config = { apiKey: "AIzaSyDblTESEB1SbAVkpy2q39DI2OHphL2-Jxw", authDomain: "fun-food-friends-eeec7.firebaseapp.com", databaseURL: "https://fun-food-friends-eeec7.firebaseio.com", projectId: "fun-food-friends-eeec7", storageBucket: "fun-food-friends-eeec7.appspot.com", messagingSenderId: "144750278413" }; firebase.initializeApp(config); export default firebase;

One last thing we'll need to do before we can dive into roughing out our App. We need to temporarily disable authentication requirements on our app so that we can add and remove items without needing to have any kind of user authentication flow.

From the Firebase Dashboard, on the left-hand side of the screen, you'll notice that there is a Database tab. Click on it. Then, on the right-hand side, under the subheading Realtime Database, you'll see a Rules tab. This will cause an object to appear that looks something like this:

{ "rules": { ".read": "auth != null", ".write": "auth != null" } }

We need to set .read and .write to both be equal to true, otherwise later, when we try to add data to our database from our application, Firebase won't let us. When you're finished, it should look something like this:

Make sure to click the Publish button.

And that's all there is to hooking up our database! Anytime we need a component of our application to connect with our Firebase database, we simply need to import our firebase module and we'll have direct reference to it.

Building out our App's Rough Skeleton

Let's build out a rough HTML skeleton for our application. We'll build a simple form with two inputs:

  1. A field where the user can submit their name
  2. A field where the user can enter what food they're bringing to the potluck.

Since our app is quite simple, we'll keep everything inside of one main component, `App.js`. Open up `src/App.js`, and remove the `App` component, replacing it with this basic skeleton:

import React, { Component } from 'react'; import logo from './logo.svg'; import './App.css'; class App extends Component { render() { return ( <div className='app'> <header> <div className='wrapper'> <h1>Fun Food Friends</h1> </div> </header> <div className='container'> <section className='add-item'> <form> <input type="text" name="username" placeholder="What's your name?" /> <input type="text" name="currentItem" placeholder="What are you bringing?" /> <button>Add Item</button> </form> </section> <section className='display-item'> <div className='wrapper'> <ul> </ul> </div> </section> </div> </div> ); } } export default App; Get the CSS

I've prepared a little bit of CSS for you to paste into the `App.css` file, just so that our app doesn't look totally bland. If you want to grab it, just go here and copy and paste the raw contents you find there into your `src/App.css` file!

We'll also need to embed a link to Google Fonts and Font Awesome, so go ahead and open up `public/index.html` and add the following lines below the favicon:

<link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico"> <!-- add the lines below --> <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans"> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css">

At this point, your app should look like this:

Connecting our Form to Component State

Before we can start adding data into our Firebase database, we need to connect our inputs to our component’s state, so that React can keep track of them.

First, let's carve out some space in our component's state - a space to keep track of the user using our app (username) and the item they intend to bring (currentItem). We'll do this by creating a constructor() hook for our app and setting a default value for our input's state there:

class App extends Component { constructor() { super(); this.state = { currentItem: '', username: '' } } // ....

We'll add a onChange event handlers to our inputs, as well as providing them with a value derived from our state (this is called a "controlled input"), like this:

<section className="add-item"> <form> <input type="text" name="username" placeholder="What's your name?" onChange={this.handleChange} value={this.state.username} /> <input type="text" name="currentItem" placeholder="What are you bringing?" onChange={this.handleChange} value={this.state.currentItem} /> <button>Add Item</button> </form> </section>

And finally, we'll create a catch-all handleChange method that receives the event from our inputs, and updates that input's corresponding piece of state:

handleChange(e) { this.setState({ [e.target.name]: e.target.value }); }

If you aren't familiar with using brackets to dynamically determine key name in an object literal, check out the MDN docs on computed properties.

Since we're using ES6 classes and need access to this in our handleChange method, we'll also need to bind it back in our constructor() component like this:

constructor() { super(); this.state = { username: '', currentItem: '' } this.handleChange = this.handleChange.bind(this); }

If you now use the React DevTools to inspect your App component's state, you'll see that both of your inputs are now successfully hooked up and being tracked in your component's state:

Adding a new Potluck Item to your Database

Now that we're tracking our inputs, let's make it so that we can add a new item to our database so that Firebase can keep track of it.

First we'll need to connect to Firebase in order to do this, we'll start by importing our firebase module that we created earlier. We'll also delete the logo.svg import, since it's just an unneeded part of the create-react-app boiler plate and will cause warnings if we don't:

import React, { Component } from 'react'; import logo from './logo.svg'; // <--- remove this line import './App.css'; import firebase from './firebase.js'; // <--- add this line

Once that's done, we'll need to make our 'Add Item' button let Firebase know what we'd like to add to our database and where we'd like to put it.

First we'll attach a submit event listener for our form, and have it call a handleSubmit method we'll write in a minute:

<form onSubmit={this.handleSubmit}> <input type="text" name="username" placeholder="What's your name?" onChange={this.handleChange} value={this.state.username} /> <input type="text" name="currentItem" placeholder="What are you bringing ?" onChange={this.handleChange} value={this.state.currentItem} /> <button>Add Item</button> </form>

Don't forget to bind it in the constructor!

constructor() { super(); this.state = { currentItem: '', username: '' } this.handleChange = this.handleChange.bind(this); this.handleSubmit = this.handleSubmit.bind(this); // <-- add this line }

And now add the handleSubmit method to your component:

handleSubmit(e) { e.preventDefault(); const itemsRef = firebase.database().ref('items'); const item = { title: this.state.currentItem, user: this.state.username } itemsRef.push(item); this.setState({ currentItem: '', username: '' }); }

Let's break down what's going here:

  • e.preventDefault() - we need to prevent the default behavior of the form, which if we don't will cause the page to refresh when you hit the submit button.
  • const itemsRef = firebase.database().ref('items'); - we need to carve out a space in our Firebase database where we'd like to store all of the items that people are bringing to the potluck. We do this by calling the ref method and passing in the destination we'd like them to be stored (items).
  • const item = { /* .. */ } here we grab the item the user typed in (as well as their username) from the state, and package it into an object so we ship it off to our Firebase database.
  • itemsRef.push(item) similar to the Array.push method, this sends a copy of our object so that it can be stored in Firebase.
  • Finally this.setState({ currentItem: '', username: '' }); is just so that we can clear out the inputs so that an additional item can be added.

Now try adding a new item, and hitting submit! If you don't have any errors in your console, you should be able to head on over to the Firebase dashboard, where you'll see something like this inside your Database tab:

If you click the little + next to items you'll be able to look inside, like this:

That strange looking -Kk8lHSMqC5oP6Qai0Vx key you see is a programmatically generated key created by Firebase when we called the push method, but inside you'll find whatever item you added to the Potluck.

You'll notice that all of our records are stored as objects with properties that have the generated names you see above - just another quick reminder that there are no arrays in Firebase!

Try adding more items and see what happens.

Way to go! We're almost there, but we still have one more step: getting our potluck items to appear on the page.

Retrieving our Potluck Items from the database

Just like in a traditional React app, we need to find some way to keep track of all of the potluck dishes so that we can display what people are planning to bring on to the page.

Without a database, this poses an issue, since every time we refresh the page any new dishes that were added to the potluck would get lost. But with Firebase, this is a snap to fix!

First, let's create a variable called items inside of default state. This will eventually hold all of the potluck items that are currently being tracked inside of our Firebase database.

constructor() { super(); this.state = { currentItem: '', username: '', items: [] } this.handleChange = this.handleChange.bind(this); this.handleSubmit = this.handleSubmit.bind(this); }

Next, we need to actually grab those items from our Firebase database so that we can store them into our state.

The Firebase API offers us an incredibly easy way to not only grab this kind information from our database, but also to update us when new values get added to our database. It accomplishes this using the value custom event listener.

It looks like this:

itemsRef.on('value', (snapshot) => { console.log(snapshot.val()); });

The callback here, which we've called snapshot, provides you with a bird's eye overview of the items ref inside of your database. From here, you can easily grab a list of all of the properties inside of that items ref, using the .val() method which you can call on the snapshot.

This value automatically fires on two occassions:

  1. Any time a new item is added or removed from our items reference inside of our database
  2. The first time the event listener is attached

This makes it especially useful for initially grabbing a list of all of the items inside of our database, and then subsequently tracking when new items get added and removed.

We'll attach this event listener inside of our componentDidMount, so that we start tracking our Potluck items as soon as our component loads on to the page:

componentDidMount() { const itemsRef = firebase.database().ref('items'); itemsRef.on('value', (snapshot) => { let items = snapshot.val(); let newState = []; for (let item in items) { newState.push({ id: item, title: items[item].title, user: items[item].user }); } this.setState({ items: newState }); }); }

Here, we instantiate a new array and populate it with the results that come back from our value listener. We for…in over each key, and push the result into an object inside our newState array. Finally, once all the keys are iterated over (and therefore all items are grabbed from our database), we update the state with this list of items from our database.

Inspect your App using the React Dev Tools - you'll notice that you now have an items property inside of your state with all of the items people have submitted for your potluck!

Displaying Potluck Items on the Page

Now let's get these potluck items to actually display on the page. This is relatively easy, now that we have a list of all of our items being grabbed from Firebase and stored inside of our state. We just map over it and print the results on to the page, like so:

<section className='display-item'> <div className="wrapper"> <ul> {this.state.items.map((item) => { return ( <li key={item.id}> <h3>{item.title}</h3> <p>brought by: {item.user}</p> </li> ) })} </ul> </div> </section>

Try adding a new item through your form. You'll notice that it automatically causes a new list item to appear on the page!

It's not magic, Firebase's value event is firing when you push the new item into your database, and sending back a new snapshot with a list of all of the items currently in your database, which ultimate updates your component through a setState which triggers a re-render and displays the new item on the page.

But we digress. There's still one more step! We need to make it so that we can remove an item from the page.

Removing Items from the Page

We'll need to create a new method on our component for this: removeItem. This method will need to be passed that unique key which serves as the identifier for each one of the items inside of our Firebase database.

It's very simple, and looks like this:

removeItem(itemId) { const itemRef = firebase.database().ref(`/items/${itemId}`); itemRef.remove(); }

Here, instead of grabbing all of the items as we did before when adding a new item, we instead look up a specific item by its key (that strange -Kk8lHSMqC5oP6Qai0Vx key from before). We can then call firebase.database()'s remove method, which strips it from the page.

Finally, we'll need to add a button to our UI with an onClick that calls our removeItem method and passes it the item's key, like follows:

{this.state.items.map((item) => { return ( <li key={item.id}> <h3>{item.title}</h3> <p>brought by: {item.user}</p> <button onClick={() => this.removeItem(item.id)}>Remove Item</button> </li> ) }) }

And that's all there is to it! Just like our addItem method, our UI and component state automatically update when an item is removed from the database.

Here's what our completed `App.js` should look like:

import React, { Component } from 'react'; import logo from './logo.svg'; import './App.css'; import firebase from './firebase.js'; class App extends Component { constructor() { super(); this.state = { currentItem: '', username: '', items: [] } this.handleChange = this.handleChange.bind(this); this.handleSubmit = this.handleSubmit.bind(this); } handleChange(e) { this.setState({ [e.target.name]: e.target.value }); } handleSubmit(e) { e.preventDefault(); const itemsRef = firebase.database().ref('items'); const item = { title: this.state.currentItem, user: this.state.username } itemsRef.push(item); this.setState({ currentItem: '', username: '' }); } componentDidMount() { const itemsRef = firebase.database().ref('items'); itemsRef.on('value', (snapshot) => { let items = snapshot.val(); let newState = []; for (let item in items) { newState.push({ id: item, title: items[item].title, user: items[item].user }); } this.setState({ items: newState }); }); } removeItem(itemId) { const itemRef = firebase.database().ref(`/items/${itemId}`); itemRef.remove(); } render() { return ( <div className='app'> <header> <div className="wrapper"> <h1>Fun Food Friends</h1> </div> </header> <div className='container'> <section className='add-item'> <form onSubmit={this.handleSubmit}> <input type="text" name="username" placeholder="What's your name?" onChange={this.handleChange} value={this.state.username} /> <input type="text" name="currentItem" placeholder="What are you bringing?" onChange={this.handleChange} value={this.state.currentItem} /> <button>Add Item</button> </form> </section> <section className='display-item'> <div className="wrapper"> <ul> {this.state.items.map((item) => { return ( <li key={item.id}> <h3>{item.title}</h3> <p>brought by: {item.user} <button onClick={() => this.removeItem(item.id)}>Remove Item</button> </p> </li> ) })} </ul> </div> </section> </div> </div> ); } } export default App; Conclusion

Now you can truly see how Firebase and React play beautifully together. Firebase's ability to persist data on the fly, coupled with React's component lifecycle, makes for an incredibly simple and powerful way to quickly build up simple applications.

This article just scratches the surface of what the Firebase API can provide us. For example, with just a few more steps (and perhaps we will go over this in a future article), it would be incredibly easy to expand this application so that users could log in and out, be able to have a display photo next to the item that they are bringing, and only be able to remove their own items.

Happy Firebasing!

Intro to Firebase and React is a post from CSS-Tricks

Componentizing a Framework

Css Tricks - Fri, 06/02/2017 - 3:10am

I'm sure most of you understand how you work with a framework like Bootstrap, Foundation, or Materialize. You use their CSS and JavaScript. You also use their chunks of HTML, piecing together and applying classes as needed to do what you need to do.

You're on your own piecing the HTML together. That's good, because it's flexible. People use frameworks like this in all kinds of CMS's and backend systems. But what if you want to apply some structure to this, making actual components out of the components given to you in the framework?

That's exactly what Morgan Feeney did in Component-Led Design Patterns with Nunjucks & Grunt last year.

For example, Bootstrap gives you some HTML for alert messages, that are like this:"

<div class="alert alert-success" role="alert">...</div> <div class="alert alert-info" role="alert">...</div> <div class="alert alert-warning" role="alert">...</div> <div class="alert alert-danger" role="alert">...</div>

We could abstract that into a reusable component by:

  1. Pass in the type of alert (second half of the second class)
  2. Pass in the content inside the alert

I'm sure you could imagine doing that in the backend or templating language of your choice. A single PHP file in which you set variables representing those things before you include it. A Rails partial in which you pass locals to it. A literal React component in JSX where you pass the stuff as props. This kind of thing makes these patterns a lot easier to reuse.

Morgan did this with Nunjucks:

{% macro alert(class="success", text="<strong>Well done!</strong> You successfully read this important alert message.") %} <div class="alert alert-{{ class }}" role="alert"> {{ text | safe }} </div> {% endmacro %}

I think this is super compelling and the kind of thing we'll be doing more and more as design systems are becoming more of a standard practice.

I also think Nunjucks is pretty darn cool.

I ported Morgan's idea (which is already a repo) over to a CodePen Project if you'd like to have a play there.

Componentizing a Framework is a post from CSS-Tricks

HelloSign: The Industry’s Fastest eSignature API Integration

Css Tricks - Thu, 06/01/2017 - 1:57am

My favorite kind of software products are the ones that very clearly make life simpler. Being able to legally sign a document by clicking a button in an email and squiggling my mouse to make my signature is definitely one of those things.

You can provide that to your users with HelloSign! You can set up your documents there (it supports all the formats you'd need, like PDF, Microsoft Word, Powerpoint, etc) and start collecting the signatures you need very easily. Set up templates of your commonly used documents. Make sure your branding is present during the signing process. Get notifications when documents are reviewed and signed.

There are a bunch more killer features you should be aware of. For example, like I mentioned, you can sign documents without ever leaving your email with their Chrome browser extension for Gmail. Same with Google Docs and Salesforce!

Perhaps most importantly, you can use HelloSign right from your own interface through their API. That's great for all us developers interested in building seamless useful experiences right in our own products. You can embed documents directly on your website with just a few lines of code!

Direct Link to ArticlePermalink

HelloSign: The Industry’s Fastest eSignature API Integration is a post from CSS-Tricks


Css Tricks - Thu, 06/01/2017 - 1:53am

Kelly Sutton has written a post called Deletability and I've been thinking about it all day and how his ideas relate to writing CSS:

By working with code, we see that modularity and deletability are closely related. Properly modularized code is easy to delete.

Writing deletable code is writing good code.

Apparently, this is a common approach to writing software although I've never heard of this concept when taken to the front-end side of things. But! I think it should be a goal for us to have in mind when we’re naming classes or building complex layouts. And after mulling over this idea all day I think that questions like "can I throw this code away easily?" should be a measuring stick for whether we're doing a good job at writing CSS.

For example, a while back I was working on a project where the style of one checkbox element impacted the styling of another, completely unrelated checkbox. The code for each was splintered across multiple files and directories so designers on the team would constantly push back and forth, undoing each other's work in a mad attempt to solve their own problem without thinking about the much larger problems of inheritance and CSS design. They'd notice an issue in their own part of the app, change the CSS and move on with their lives. And I'm not trying to be a jerk here – some applications have tens of thousands of lines of CSS and apps can be devilishly complex so it's no wonder that they didn't see this problem coming up.

But if the original design of those checkboxes had been built with the concept of deletability in mind I think we'd have avoided this problem altogether. The line-height and font-size, color and background-color properties would've been isolated in the correct files. And so looking at one file we'd be able to see all of the code for this one specific element. In other words, the system would have made itself clear to us in an instant.

If in the future, we can begin to ditch large portions of our codebase without impacting unrelated components, then we deserve to raise a glass to ourselves for being so gosh darn smart this whole time.

Direct Link to ArticlePermalink

Deletability is a post from CSS-Tricks

Build a Style Guide Straight from Sass

Css Tricks - Thu, 06/01/2017 - 1:43am

Last fall, our dev team wanted to get started with style guides. We had added a new member to the team, and as he was getting up to speed, we realized how lacking our project documentation was. If you've ever been a new developer on a team with weak documentation, you know how confusing it can be to try to familiarize yourself with a dozen projects without documentation.

In deciding on a style guide method, we came up with two main requirements:

  1. Low Friction

    The style guide should be easy to find, easy to read, and easy to maintain.

    Something that fit into our existing development workflow would be awesome. Adding new directories for sample markup and documentation files would not be awesome.

  2. Platform Agnostic

    We work in WordPress, Drupal, and CakePHP most often, and we wanted something that would work the same way across all three platforms.

    We wanted this to be easily maintainable, and for us that meant keeping the documentation alongside the CSS.

The Basics of Node-KSS

To achieve our goals of a platform agnostic, low-friction style guide, we landed on kss-node, which is itself a Node.js implementation of Knyle Style Sheets (KSS), a Ruby library that:

... provides a methodology for writing maintainable, documented CSS within a team. Specifically, KSS is a documentation specification and styleguide format.

The basic principle is that your style guide is generated via comments you create in your CSS, SCSS, Sass, LESS, etc.

You write some CSS like this:

// Bold Button // // Use this class for a bolder, stronger looking button. // // Markup: // <button class="btn btn-bold">Click Me</button> // // Styleguide Components.Buttons.bold .btn.btn-bold { position: relative; font-weight: bold; text-transform: uppercase; }

And get this lovely output:

Screenshot of the generated documentation for the bold button

You are able to organize your documentation however you like and it generates a nice little navigation and document structure for you as well:

Because it lives inside your CSS, updating it fits naturally in existing development workflows. If you update some CSS properties, the style guide is automatically updated. If you need to update the documentation, the documentation text is sitting right on top of the component you are working on. Even if you never visit the generated style guide, you will see the style guide any time you open a CSS file. Low friction? Check.

Additionally, since we use CSS and build processes in all our web projects, it's as platform agnostic as we need it to be.

Let's get started!

Initial Setup

In your project directory, you want to install kss-node as a project dependency. We're also going to install michelangelo, a nice theme for the style guide:

$ npm install --save-dev kss michelangelo

You can verify that it was installed by running

$ ./node_modules/.bin/kss --version

We'll create a file named kss-config.json to configure our KSS settings.

Inside your file, create an object like this:

{ "title": "Title of the Style Guide", // Source tells KSS where the CSS, Sass, or SCSS is that it should parse for documentation comments. // Here we are assuming your sass is in a directory at the root level of your project. "source": "sass/", // Destination tells KSS where to compile your style guide to. "destination": "styleguide/", // Builder tells KSS where to look for a theme. // If you aren't using michelangelo, you don't need this. "builder": "node_modules/michelangelo/kss_styleguide/custom-template/", // CSS gives KSS the path to your CSS, so it can pull your styles into the style guide. // The path needs to be relative to your style guide destination. // Here, our style guide is in /styleguide and our compiled css is at our project root. "css": [ "../main.css" ] // If you want to include any javascript files, add this block, with the path to your javascript file. // Also relative to your style guide destination. // Optional. "js" : [ "../bundle.js" ] }

This assumes a simple project directory tree that looks like this:

js/ sass/ bundle.js index.html main.css

You can try compiling your style guide by running:

$ ./node_modules/.bin/kss --config kss-config.json

If you want a cleaner command to run, add a script to the scripts block in your package.json:

"scripts": { "kss": "kss --config kss-config.json" },

Now you can run $ npm run kss to compile your style guide. (I'll use this method going forward, but you can use $ ./node_modules/.bin/kss --config kss-config.json if you want).

Since we haven't written any documentation yet though, you will likely receive a message like:

Error: No KSS documentation discovered in source files.

Let's fix that by documenting our first component!

Create and Document a Simple Component

We'll create a sample post title component.

Here's our CSS:

.post-title { font-size: 3em; text-align: center; font-family: fantasy; }

To create our documentation, we'll create a comment:

// Post Title (this will be the title of your component) // // Large, **in charge**, and centered. (this is the description of your component. you can use markdown in here.) // // Markup (define the markup to be used in your styleguide): // // <h1 class="post-title">A Post Title</h1> // // Styleguide Components.article.post-title // (? this controls the organization of your style guide. Here, I'm filing this component inside Components / Article / Post Title) .post-title { font-size: 3em; text-align: center; font-family: fantasy; }

Run $ npm run kss and your style guide should compile! You can access it based on the destination path you gave it. In this example, we have a static site and I compiled it in /styleguide, so that's the url I will use to find it. Here's what it should look like if you are using the michelangelo theme (I've removed the comments in parentheses):

Post Title Documentation

Here's what happened:

  1. KSS created a documentation section for our post title, complete with the title, description, markup, and CSS that we provided. You can see the rendered HTML and CSS as well as the raw HTML.
  2. KSS saw that we nested our post title underneath Components / Article, so it created a Components top-level section and a Components.article section. Our post title is nested underneath both of these.
  3. KSS generated a navigation based on this hierarchy.

If you wanted to provide more information about Components, you could provide a documentation block (anywhere in your CSS, really) like this:

// Components // // Components are ingredients of our design system. They may be made up of smaller groups of styles. // // Styleguide Components

Likewise, you could provide more information about the article component by defining a documentation block that targets that item via the Styleguide Components.article method:

// Article // // An article is made up of a title, featured image, and some default // typographic settings for links, italics, bold, and blockquotes. // // Styleguide Components.article

With those new documentation blocks, compile your style guide again ($ npm run kss) and you will see your outline filled out a little more:

Components and article documentation Documenting Component States and Variations

Our post title component is very simple, but we'll need to display more complex information in our style guide. KSS can easily handle variations on components as well as interactive states like :hover or :focus. We'll document a button to show this.

Our button will have different styles for :focus and :hover, as well as a small variation and a large variation. Here is the CSS we'll start with:

.button { padding: 1em 2em; margin: .5em; display: inline-block; font-size: .9em; font-family: Helvetica, sans-serif; font-weight: bold; text-transform: uppercase; color: #f56476; background-color: #fff; border: 2px solid #f56476; transition: .2s color, .2s background-color, .2s border-color; } .button:hover { color: #fff; background-color: #f56476; } .button:focus { color: #3ddc97; border-color: currentColor; } .button--small { font-size: .5em; } .button--large { font-size: 1.5em; }

We'll format our documentation the same as we did for our post title with 2 additions: we're going to add a placeholder class of {{modifier_class}} to all of our elements that will get the modifier, and we'll define our states / variations directly underneath our markup. Our comment block will look like this (I've added some notes in parentheses):

// Buttons (title, same as before) // // Various button styles. (description, just as before) // // Markup: (we add the `{{modifier_class}}` to every element that has a modifier) // <a class="button {{modifier_class}}">Link Button</a> // <button class="button {{modifier_class}}">Button Element</button> // <input class="button {{modifier_class}}" type="button" value="Input Button" /> // // (a new modifiers section) // :hover - When user hovers over button. // :focus - When button is focused. // .button--small - A small button. // .button--large - A large button. // // Styleguide Components.button (organization, just as before)

You can see that I've added a variation for each of the variations I declared in my CSS. The format is:

// .class-name - Description


// :state - Description

When the styleguide is compiled, you get this new documentation:

Generated documentation for buttons

You can see that you now have an example of each of the states and variations that you described in the modifiers section, with the appropriate CSS applied.

This technique also works for more complex components than this button. Say you have a .card component with children elements inside that need to change when a user hovers over the card. To document that, you would add the {{modifier_class}} only to the .card element and specify the hover state just as we did above.


By default, sections will be organized alphabetically by their title. For instance, our button component will come after our article component in the examples above. However, if you want to change the order of components or other sections, you can provide a weight to the component. A higher weight will bring the component lower in its section. A lower weight will move the component higher in the section.

When using Sass or SCSS, I put my organizational comments inside my main.sass or wherever I am importing my partials. For example, on a recent project, I had a Typography section and Elements section both filed underneath a Base top-level section. Naturally, KSS would organize these sections alphabetically, but I wanted Typography to come first. Here's how I changed the weight in my main.sass file:

// Typography // // Weight: 1 // // Styleguide base.typography @import "base/typography" // Elements // // Weight: 2 // // Styleguide base.elements @import "base/elements" Color Palettes

The Michelangelo theme that we are using provides a cool color palette generator. If you are using Sass or SCSS, you can document your color variable names and KSS will format a little color palette block.

With a comment like this:

// Highlight Colors // // Colors we use for higlighting states. // // $highlight-blue - #1460aa, primary blue // $highlight-purple - #674172, secondary purple // $highlight-red - #d50000, danger red // // Styleguide Base.colors

KSS will create a color palette for easy reference like this:

Auto Compiling the Style Guide

Instead of running $ npm run kss every time we make a change to the CSS, we can add a watch task to regenerate the style guide every time our CSS files change. I'll document how to do it with npm Scripts and via Grunt next.

npm Scripts

We are already using npm scripts to build the style guide, we just need to add a script that will watch our style guide.

We'll use the onchange package. First install it:

$ npm install onchange --save-dev

Then add a new script in our scripts object:

"scripts": { "watch": "onchange 'sass/**/*.sass' -- npm run kss", "kss": "kss --config kss-config.json" },

The watch task tells onchange to watch the files we specified in our glob pattern ('sass/**/*.sass') and when it detects a change, run the command we specify after the --: npm run kss.

Now running $ npm run watch will watch our .sass files and regenerate our style guide every time it detects a change in our Sass.


There is an official Grunt plugin for KSS, grunt-kss. You can configure it to watch your .sass or .scss files for changes and recompile the style guide as you develop it.

Here's a sample Grunt configuration. With this setup, you don't need a separate kss-config.json file, all the configuration can happen in your Gruntfile.

module.exports = function(grunt) { grunt.initConfig({ kss: { options: { title: 'Title of the Style Guide', builder: "./node_modules/michelangelo/kss_styleguide/custom-template/", css: [ "../path/to/compiled/css.css", ], js: [ "../path/to/compiled/javascript.js", ] }, dist: { src: "path/to/css/src", dest: "styleguide/", } }, watch: { sass: { files: [ './path/to/**/*.sass' ], tasks: ['kss'] }, } }); grunt.loadNpmTasks('grunt-kss'); grunt.loadNpmTasks('grunt-contrib-watch'); grunt.registerTask('dev', ['kss', 'watch']); }

Running $ grunt dev will first generate the style guide, and then watch our .sass for changes and regenerate the style guide when it detects a change.

Wrap Up

There are more details regarding the comment parsing and other features I haven't mentioned here at the official KSS repo. You have more than enough to get started here but there are some things I didn't go into, including a custom home page, experimental/deprecation flags and helpers for preprocessors.

If you want to go even further, you can develop your own style guide in place of the Michelangelo theme we used. Check out the docs on using custom templates for more information.

Build a Style Guide Straight from Sass is a post from CSS-Tricks

Why the political hackers and algorithm stories are bullshit

QuirksBlog - Mon, 05/08/2017 - 5:16am

Now that the fascists singularly failed to carry France despite a last-minute attempt at one of those terrifying, democracy-destroying “hacker” jobs against Macron it’s time to call out the hacker and algorithm stories for the bullshit they are.

It was clear from the outset that the Macron leak contained many false documents. What I didn’t find out until today was that many (all?) of those false documents were planted by the Macron campaign itself (scroll down to last paragraphs) in an apparent counter-phishing attempt. That proves the hackers aren’t terribly clever (and didn’t read French).

Let’s look at what those terrifying hackers actually achieved:

  1. Clinton. The Clinton email revelations likely did have some influence on the US election outcome, but it is important to realise that it merely reinforced an already-existing story and was powerfully supported by the US press and the FBI director. In the absence of these occurrences, would the hackers have had the same success? I’m not sure they would have.
  2. Fillon. The Fillon corruption revelations clearly did influence the French elections, and, as far as I know, the data was new and genuine.
    Point is: if we assume the hackers are in Putin’s pay and advance his political agenda, they did a thoroughly lousy job. Fillon is a typical example of a “moderate right-wing” politician who can be made to coopt fascism, and who was genuinely pro-Russian (or, at least, anti-sanctions). The revelations destroyed his chance to win the presidency, and with Le Pen never a serious contender Fillon was exactly what Russia should have hoped for.
    So despite their apparent success the hackers failed in France.

And this, as far as I can see, is the total roster of successes for the hackers. One success thanks to powerful support from within US politics, and one apparent success that was a serious strategic error. To me, that doesn’t seem like evidence of a serious threat to democracy.

There are murky rumours surrounding the Brexit vote, but nothing has been conclusively proven, and I tend to look at the polls themselves as the main culprits. Though the vote was expected to be close, poll after poll after poll showed the Remain camp squeaking in a narrow victory. Thus, if you’re a moderate Remain supporter but are angry at the political caste, you could easily be led to believe that you can cast a protest vote with impunity because Remain is going to win anyway. Except that too many people made this decision, and the tables were turned and Brexit won.

To me, this is a MUCH more convincing explanation than shady conspiracy theories featuring billionaires, tech geniuses, and algorithms — especially when techies and moderate right-wing voters have a vested interest in pushing these stories.

Why do we believe it?

This leads to the question why we so desperately want to believe these stories of high-tech voter manipulation. As far as I can see there are two reasons.

First, it strokes our ego as technologists.

The tech sector is on the defense nowadays, with Facebook and Twitter refusing to do anything about fake news (except for “algorithms” and flags that aren’t going to solve anything — hire human editors, guys!), and with especially Uber under fire for extorting its employees who aren’t really employees. It is becoming clear that technology is not the instrument for salvation we’ve believed it to be for the past twenty years.

It may be that Silicon Valley’s dominance is coming to an end, and even if it isn’t the Valley needs to convince the rest of the world it’s worth keeping around. It needs to restore its magical appeal.

In that light, dark mutterings about hackers and genius algorithms that can throw entire elections are a gift from heaven. They prove tech’s continuing vital role in the world, and prove technology can do anything it sets its mind to. And we as techies have every reason in the world to reinforce this narrative, since it enhances our position as grand imperial wizards of the most important force in the universe.

Bull. Shit. But it strokes our egos and fills our wallets, so we fall for it.

Also, the evil geniuses with their algorithms are supposed work with Big Data, and if there’s anything that’s overrated right now in the tech scene it’s Big Data. But hey, these people can throw entire elections, so you’d better invest in that Big Data company, right? So the Big Data people have a vested interest in hyping these stories.

Second, it serves to absolve voters from responsibility.

Remember: fascism can only win if it is supported by the moderate right wing. This happened in the US back in November, and it will likely happen in the UK next month. But if you can say that you’re a soulless slave of genius algorithms, hey, then the responsibility is not yours. (Also, if you’re a soulless slave, should you have the vote?)

Bull. Shit. If you vote for a fascist party it’s your responsibility, and no one else’s.

The hacks are unimportant

So let’s pierce the bullshit and clearly state that these vaunted “hackers” are a relatively unimportant force that can only strengthen genuine trends that already exist in the political realm. The rest is all smoke and mirrors aimed at reinforcing the societal status of technologists, and of protecting the sensivities of “moderate” right-wing voters.

Also, these categories overlap in the upper reaches of Silicon Valley. I mean, libertarianism is also a part of fascism, though only for the upper classes who have achieved success and can therefore do anything they like. Triumph of the Will and all that. (The commoners should serve and obey, and combat the immigrants. Libertarianism is not for them; only for us.)

So there. Smoke and mirrors, nothing more. The current fascist crisis is not caused by tech geniuses, hackers, and algorithms, but by moderate right-wing voters in the US and the UK, where the outdated and silly political system forces them to vote either extreme right or moderate left. And they pick extreme right of their own free will.

Keep calm and perform historical analysis.

We techies should stop hyping and supporting bullshit articles about dangerous hackers and genius algorithms. Also, we should consider the possibility that the modern tech gospel has some fascist components at its heart — especially the myth of the genius innovator.

Wed, 12/31/1969 - 2:00pm
Syndicate content
©2003 - Present Akamai Design & Development.