I had to read through this twice, but I think I get it now (I’m not the sharpest knife in the drawer). Very useful if you’re doing theming in CSS.
Remember when I said that if we want to see CSS exclusions implemented in browsers, we need to make some noise?
Well, Rachel is taking names, so if you’ve got a use-case, let her know.
This just blew my mind! A fiendishly clever pattern that allows you to inline resources (like critical CSS) and cache that same content for later retrieval by a service worker.
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?
Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.
Some advice from Andy on creating a dark theme for your website. It’s not just about the colours—there are typography implications too.
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.
But despair not—Rachel points to a potential solution. I saw potential solution, because if we want to see this implemented in browsers, we need to make some noise.
‘Sfunny, this exact use-case (styling a profile component) came up on a project recently and I figured that CSS grid would be the right tool for the job.
Rachel gives us the run-down on what’s coming soon to Cascading Style Sheets near you, including an aspect-ratio unit and a
matches selector (as originally proposed by Lea).
The fascinating results of Brad’s survey.
Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.
That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.
The only thing I would add is that, in my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.
Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.
When a storm comes, some of the big news sites like CNN and NPR strip down to a zippy performant text-only version that delivers the content without the bells and whistles.
I’d argue though that in some aspects, they are actually better than the original.
The “full” NPR site in comparison takes ~114 requests and weighs close to 3MB on average. Time to first paint is around 20 seconds on slow connections. It includes ads, analytics, tracking scripts and social media widgets.
Meanwhile, the actual news content is roughly the same.
I quite like the idea of storm-driven development.
A very thoughtful post by Rachel…
It’ll never catch on.
How mucking about in HTML and CSS can lead to some happy accidents.
‘Sfunny, people often mention the constraints and limitations of “designing in the browser”, but don’t recognise that every tool—including Sketch and Photoshop—comes with constraints and limitations. It’s just that those are constraints and limitations that we’ve internalised; we no longer even realise they’re there.
As a community, we love to talk about meritocracy while perpetuating privilege.
This is playing out in full force in the front-end development community today.
Front-end development is a part of the field that has historically been at least slightly more accessible to women.
Shockingly, (not!) this also led to a salary and prestige gap, with back-end developers making on average almost $30,000 more than front-end.
(Don’t read the comments.)
font-feature-settings value demonstrated in one single page.