>> But take container queries, for example. They were the number one feature requested by front-end devs for a looong time. So why don’t we use them more, now that they’re finally here?
A number of things are in play here.
1) when people ask for something it's because they need it now. The client wants it to look like x. Providing it a year later doesn't mean I'll retro-fit it, I'm working for another client now.
2) the new features on offer are (mostly) not low-hanging fruit. 20 years ago we were asking for the basics - not-table layout (flex, grid), variables (var --), conditionals (@media) and so on. The low hanging fruit stuff. Now "most people" aren't really asking for anything. (The sliver of a minority attending css conferences naturally are dreaming up new edge cases.)
3) most of the websites that exist (aka have been styled) are older than these features. Since redesigns are typically multiple years apart it takes years for them to filter in. As a proportion the number of sites built, or updated, in the last year is small. And the proportion of those needing these features is smaller.
4) most sites are not styled from an empty notepad. Most use (reuse) a framework - either personal or public.
CSS is starting to move from mid-stage to late-stage development. We're well passed the "terrible to work with" stage, well passed the "good enough" stage, and now into the "what can we dream up stage".
That said I can see myself using some of these things - sub-grid and :has being the obvious ones for me.
Very good take. CSS is at a point of complexity now where you can't really blame anyone for not knowing everything you can do with it or every new feature that's been adopted in the last couple years, especially for full-stackers like me. I know a lot, including more than enough to get my job done, and though I will still learn new things now and then (I didn't know container queries existed before this article and now that I do I may use them in the future), I'm not in a hurry to learn every new bleeding-edge feature which are probably just going to cause compatibility issues for some non-insignificant number of my clients' browsers (or my clients' clients' browsers) anyway.
Also, as someone who started doing web dev professionally nearly 20 years ago where if it didn't work in IE 6 then you just couldn't use it at all, I just instinctually don't even bother with new (as in 3-4 years old) CSS or JS features most of the time. It's pretty deeply ingrained in me and I suspect many other devs who were around in that time. That said, 5-year-old CSS and JS specs at this point are pretty damn good and you can do a whole lot of cool stuff with them, so this is not nearly as painful now as it was back then.
> I just instinctually don't even bother with new (as in 3-4 years old) CSS or JS features most of the time. It's pretty deeply ingrained in me and I suspect many other devs who were around in that time.
I'm also a web dev with nearly 20 years and do exactly this as well. Old versions (or any version of) IE crushed our dreams too many times to feel comfortable delivering anything modern, let alone cutting edge.
As a developer of a similar vintage, I can relate to this mindset, but I think we should be careful about it. We learned in an era when differences in browser behaviour were a big deal and new versions of browsers sometimes came along years apart. But those days are long gone — even Safari now gets several updates each year — and we should let the habits they created go with them.
Should we be cautious about relying on non-standard features or trusting the perma-beta culture that Google never seems to have grown out of? Of course. But there have been many recent developments that are useful and already widely supported, and not using those when they provide a good solution to an immediate problem seems counterproductive.
Same here (>20 years at this point)—I just know how to do nearly everything with existing CSS features, or else I’m already using a framework like MUI that eliminates a lot of the issues the new CSS features aim to solve. For example, the unique class names and low specificity offered by MUI negates the need for the new container functionality.
I’ve definitely used :has() though to replace the need for certain CSS combinators—for example, being able to style a label that wraps a checkbox based on the checkbox being checked, rather than relying on the next-sibling combinator while placing the label after the checkbox input. That’s pretty cool and solves some limitations that existed previously.
Yeah, I think the first factor is probably the biggest one here. Devs tend not to rebuild existing sites on a whim, especially not to integrate new technology for the hell of it.
We'll almost certainly see more container queries used on new website/app development projects going forward, but any that started prior to their integration into most browsers are likely going to remain using the old design philosophy with media queries instead.
Yeah, I still remember a site where I really would have needed the :has selector, but I have written a workaround in JS and now I would rather so the whole thing new than fix that tiny aspect.
I will however definitely rely on the has: selector next time I encounter that situation (it had to do with markdown output putting img tags inside paragraphs, so I needed css that treats a paragraph that has a img inside differently than other paragraphs).
Does :has function as a parent selector? That's probably the only thing I ever really wanted from CSS and I assumed it would never happen because of the (back propagating) implications for the order the DOM is rendered in.
A number of things are in play here.
1) when people ask for something it's because they need it now. The client wants it to look like x. Providing it a year later doesn't mean I'll retro-fit it, I'm working for another client now.
2) the new features on offer are (mostly) not low-hanging fruit. 20 years ago we were asking for the basics - not-table layout (flex, grid), variables (var --), conditionals (@media) and so on. The low hanging fruit stuff. Now "most people" aren't really asking for anything. (The sliver of a minority attending css conferences naturally are dreaming up new edge cases.)
3) most of the websites that exist (aka have been styled) are older than these features. Since redesigns are typically multiple years apart it takes years for them to filter in. As a proportion the number of sites built, or updated, in the last year is small. And the proportion of those needing these features is smaller.
4) most sites are not styled from an empty notepad. Most use (reuse) a framework - either personal or public.
CSS is starting to move from mid-stage to late-stage development. We're well passed the "terrible to work with" stage, well passed the "good enough" stage, and now into the "what can we dream up stage".
That said I can see myself using some of these things - sub-grid and :has being the obvious ones for me.