An excellent and clear explanation of specificity in CSS.
This is a wonderful interactive explanation of the way CSS hierarchy works—beautiful!
Facebook and even Instagram are at odds with the principles of the open web.
This is very handy! Export your data from Ev’s blog and then import it into a static site generator of your choice.
You may have noticed the recent movement of people looking to get off Medium. Most of us are motivated by a desire to own our content, have data portability and get more control over how/where our content is displayed and monetized. Most importantly many of us consider our blog/site to be a core part of our online identity and while Medium offers a fantastic writing experience it sacrifices other important values. Luckily there’s a modern approach to running your blog which aligns with these ideals, its called the JAMstack and its all around us.
This is yet another great explainer from Ire. Tree shaking is one of those things that I thought I understood, but always had the nagging doubt that I was missing something. This article really helped clear things up for me.
Harry takes a look at the performance implications of loading CSS. To be clear, this is not about the performance of CSS selectors or ordering (which really doesn’t make any difference at this point), but rather it’s about the different ways of getting rid of as much render-blocking CSS as possible.
…a good rule of thumb to remember is that your page will only render as quickly as your slowest stylesheet.
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
A really great introduction to web components by Monica. But I couldn’t help but be disheartened by this:
Web components tend to have dependencies on other web components, so you need a package manager to herd all them cats.
For me, this kind of interdependence lessens the standalone nature of web components—it just doesn’t feel quite so encapsulated to me. I know that this can be solved with build tools, but now you’ve got two problems (and one more dependency).
The new style guide and pattern library for Buzzfeed.
It all looks pretty reasonable on the surface but if you poke around in the CSS, you’ll find 1157 uses of
The whole point of having an agreed-upon codebase in a pattern library is so that developers need never reach for nuclear options like
!important, so I’m afraid, for me, this is a demonstration of what not to do (in terms of CSS—the output of the HTML in the styleguide looks perfectly fine).
Solid uses immutable, atomic CSS classes…
CSS is “mutable”. By design. I don’t think we should be working against that.
Now this is how to do the "find your friends" trick. For GMail, Yahoo Mail, and Hotmail, Flickr never once asks for your password. Bravo!
Another sign up form that features hCard input (like Satisfaction). Choose a service (e.g. Flickr, Last.fm, Twitter) or enter your own URL.
Portable social networks are no longer just theory: Dopplr makes it a reality.