This is a great explanation of the difference between the [lang] and :lang CSS selectors. I wouldn’t even have thought’ve the differences so this is really valuable to me.
Jonathan shares his notes on that great flexbox container queries article from Heydon that I linked to.
Er …I think Heydon might’ve cracked it. And by “it”, I mean container queries.
This is some seriously clever thinking involving CSS custom properties, calc, and flexbox. The end result is a component that can respond to its container …and nary a media query in sight!
One facet of this whole CSS debate involves one side saying, “Just learn CSS” and the other side responding, “That’s what I’ve been trying to do!”
I think it’s high time we the teachers of CSS start discussing how exactly we can teach a correct mental model. How do we, in specific and practical ways, help developers get past this point of frustration. Because we have not figured out how to properly teach a mental model of CSS.
How did I miss this great post from 2016 by one of my favourite people‽ It’s even more more relevant today.
To me it doesn’t matter whether you write your HTML and CSS by hand or use JavaScript to generate it for you. What matters is the output, how it is structured, and how it is served to the client. When we allow our tools to take precedent over the quality of our output the entire web suffers. Sites are likely to be less accessible, less performant, and suffer from poor semantics.
I think Cathy might’ve buried the lede:
The knock on effect of this was removing media queries. As I moved towards some of the more modern features of CSS the need to target specific screen sizes with unique code was removed.
But on the topic of Sass, layout is now taken care of with CSS grid, variables are taken care of with CSS custom properties, and mixins for typography are taken care of with calc().
Personally, I’ve always found the most useful feature of Sass to simply be that you can have lots of separate Sass files that get combined into one CSS file—very handy for component libraries.
It’s getting exhausting spending so much of my time defending one of the three pillars of the web: CSS. It should sit equal with HTML and JavaScript to produce accessible, progressively enhanced websites and web apps that help everyone achieve what they need to achieve.
In which Matthew disects a multiple choice quiz that uses CSS to do some clever logic, using the :checked pseudo-class and counter-increment.
Oh, and this is how he realised it wasn’t using JavaScript:
I have JavaScript disabled on my phone because a) it cuts out most of the ads, b) it cuts out lots of bandwidth and I have a limited data plan, and c) my battery lasts longer because it’s not processing tons of code to show me some text (cough, Medium).
Andy’s slides:
We dive into why progressive enhancement is important and how we can leverage the power of Vanilla JavaScript, Web Components and modern CSS to deliver a hack-free, lightweight and progressive experience for our users.
I reckon it’s time for distressed type to make a comeback—CSS is ready for it.
The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.
Absolutely spot on! And it cuts both ways:
Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.
Telling other people working on the web and doing a great job building web sites that they are useless because they focus on HTML and CSS is very wrong.
The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right?
Well, no, actually. I certainly don’t think that front-end development is a problem at all.
What Robin said.
I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.
Chris Ferdinandi has a good rule of thumb:
If something I want to do with JavaScript can be done with CSS instead, use CSS.
Makes sense, given their differing error-handling models:
A JavaScript error can bring all of the JS on a page to screeching halt. Mistype a CSS property or miss a semicolon? The browser just skips the property and moves on. Use an unsupported feature? Same thing.
But he also cautions against going too far with CSS. Anything to do with state should be done with JavaScript:
If the item requires interaction from the user, use JavaScript (things like hovering, focusing, clicking, etc.).
‘Sfunny; I remember when we got pseudo-classes, I wrote a somewhat tongue-in-cheek post called :hover Considered Harmful:
Presentation and behaviour… the twain have met, the waters are muddied, the issues are confused.
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.
Crazy clever!
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
It turns out there are plenty of reasons that people give for using frameworks—whether it’s CSS or JavaScript—but Rachel shares some of my misgivings on this:
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.