>> 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.
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).
For me personally, it's because I've been burned too many times by blog posts announcing that "feature X is here!", when in reality, it's only here in Chrome or behind a feature flag, or the exciting parts haven't been implemented yet. Even this blog post falls into the same trap. There isn't good cross-browser support for view transitions or anchor positioning, and yet they're listed as here now.
View transitions are the perfect candidate progressive enhancement. If the browser supports it, then the user will get the rich animations. If it doesn’t, then they get what they currently have.
And once other browsers starts supporting it, the experience will automatically work in those browsers too without you needing to touch a single line of code :)
> I can’t use [feature X], I need to support [old browser].
And that’s not necessarily a bad thing.
As I commented a few days ago, nowadays devs don’t seem to care too much about backwards compatibility. I like to hold onto my devices longer than most people and it’s a bit frustrating to see that most sites nowadays expect you to be in the latest and greatest. It didn’t use to be like this.
We recently had a user email us that our app stopped working for them. After we dug into it it was because their Chromebook was last updated in 2021 and didn't have Object.hasOwn (which a third-party library uses) and it's not even included in most common polyfills either. We fixed it, because I hate these sorts of compatibility issues.
Nevertheless, I left a bit concerned that they hadn't updated their Chrome in 3 years. Software decays much quicker than hardware in a real way, especially with the never ending list of security vulnerabilities found every year. Theres definitely a case to be made that forcing software upgrades is good for the end user too.
That is reasonable though if a missing feature is trivially obvious must-have. Browsers (and standards, and platforms) that are slow to add it must develop themselves better. It’s nice to respect compat if a new way is a redesign based on feedback, e.g. you used poll/select and now it’s epoll/kqueue/iocp with a fallback. But if it is a feature that was simply missing for years, e.g. UIKit adding random useful methods which existed since forever in Cocoa, no respect. Really, you don’t want to support a platform that takes years to wake up. Let their users know that it’s obsolete, they will update.
"I can’t use [feature X], I need to support [old browser]."
Any time someone says this it's important to add a caveat of "and I want my site to look the same everywhere". Using @supports means you can feature detect what CSS the user's browser supports and enhance where possible. A user with an older browser might see a less pretty, simpler design with somewhat worse UX, but that's often ok if it's a tiny minority and you can give the users on new browsers a much better experience. The two versions might look a bit different but that's fine.
In my team, we write software for TVs and set-top boxes, as well as modern browsers. TVs don’t get the ipdate support we’re used to on desktop and mobile. The same codebase has to support Safari 6-era webkit as well as contemporary Blink. We still can’t use some of the flex spec let alone the new hotness.
The real problem in my experience is that people who consider themselves to be "real" developers don't care about CSS. I do a ton of code reviews and consulting for companies of all sizes and their JavaScript and TypeScript is almost always at least in a borderline defensible state? But CSS is always one giant file that has been growing since 2002 and is treated as an append-only log of !important. Nobody even tries to fix their CSS because nobody can imagine the concept of "well written CSS". It's like JavaScript in the early 2000s, where the language has (in the minds of developers) to be worked around with stuff like tailwind.
Css scoping has been fixed for ages already by css modules, styled components, or/and (native) support for nested css declarations. If those all fail there’s namespace conventions like BEM.
If your css is a mess in 2024 (2016 really) it is all on the developer and not the language.
You are not wrong. But my god, the tech debt in any slightly older web app's CSS is bonkers. Even with really well thought out templates you still end up with ~5000 line css files that have all sorts of state and magic in them.
And like all tech debt, it's a triage.
What I'd really like is more intellisense for css so I could take a css file and get sensible code complete and class suggestions for elements.
Often I only use CSS if I have no choice. I really do try to fix it but I still cant imagine "well written CSS". I look at the 2000 lines of necessities and know some of it isn't even used and other things could be simpler. The process consumes lots of time without much to show for it or worse.
CSS needs a compiler with warnings, dead-code removal, type safety, modularization, standard structuring and "design patterns" - then software engineers will take it seriously.
The answer in my team's case is browser support and especially Safari on iOS. Our UI is quite complex and demanding regarding functionality, visual presentation and accessibility and would benefit greatly from most of these features, especially subgrid and container queries (and anchor positioning, but that feature doesn't exist outside of the latest version of Chrome).
Even though MDN lists most of these features as "baseline" supported, the reality is that a small but still meaningful share of our users are using old iOS devices – especially iPads – and they can't or won't update their operating system to update Safari. Our oldest supported browser is Safari 14 because of Flexbox gap support.
None of the other platforms are a problem, as basically everyone else is using an automatically updating evergreen browser.
I've read a few articles like this in the last few days and I don't understand why everyone is ignoring the elephant in the room. It's 2024 and Safari is still not evergreen.
When people say Safari is the new Internet Explorer, replies always mention how Safari just adopted such and such bleeding edge CSS feature (while ignoring much older features, though), but the truth is many Apple users won't see those features for years, until their devices break.
Apple is stopping both users and developers from enjoying these very same new features they so happily announce. The web is stuck in time, waiting for enough people to update their devices. Just like in the age of Internet Explorer. At least back then people had the option of installing a different browser. So maybe Safari and the apple ecosystem is actually worse than IE and Windows used to be.
Great article! CSS doesn’t get enough attention - not outside of Tailwind, which I don’t think is the way to go, but that’s another story.
:has() and :is() are awesome.
One issue I’ve had with any of the newer CSS features is that, most of the people I work with don’t know what they do, because nobody use them. So, I have to explain myself in each pull request - but I guess that’s ok, because then people learn.
> And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers.
Don't you know there are still a fuck ton of people that are still using the old iOS versions with their old phones?
I have plenty of them, and they are long term supporters that I just can't shut them off.
There are new css features that are almost harmless and do not affect the usability, some css features on the other hand...
Some comments here are framing CSS as getting too complex. Some folks are recommending the utility-class approach (e.g. Tailwind).
I don't want to argue for Tailwind, but as someone who's used it for ~4 years now, it strikes me that I've forgotten what it's like to have to think about sets of CSS rules and how they collide.
Utility class systems completely remove the need to even consider conflicting rules.
That doesn't mean CSS shouldn't continue to grow though, and I welcome these new features.
I dunno sir, do you just assume everyone knows what these list items are? I would link them to their appropriate mdn article. I think non of the readers know everything about all of the items.
This should be one of those articles one can click around in for considerable time.
Having to select and search made me wonder at what point in time we lost the ability to click on the bullet to select the list item text? Does anyone remember that feature?
> Quick question: how many of these have you actively used in production?
> Container Queries
I haven't used this, but it looks super useful.
> Style Queries
Eh, I'm sure this is useful for situations that don't come up very often.
> CSS Layers
Ugh, I'm not going to use this overly-complex silliness, and I'm not looking forward to debugging this when other people use this.
> Subgrid
Again, overly complex. Grid could already do everything this can do, more simply.
> Native Selector Nesting
I'm already using this.
> Anchor Positioning
Eh, I already had solutions to this problem, but this seems like it probably communicates intent a bit better. I guess I'll pick that up.
> :has, :is, :where
:has is useful
:is... okay, fine, syntactic sugar.
:where I don't believe in hell. If I did, I'd be against it because burning someone for eternity is inhumane. But I might be willing to make an exception for people who write CSS that requires you to read the MDN article on Specificity to understand it.
> Logical Properties
Perhaps useful for situations that don't come up very often. Seems complex, but that might be because the thing it's representing is inherently complex.
> Scroll-Linked Animations
Okay, someone who isn't me will probably do really cool things with this.
> View Transitions
Another thing that seems complex, but possibly because the thing it's representing is inherently complex.
There isn't a great way to make the <li> adhere to the grid template areas, because without subgrids only direct children (the ul) have coordinate attributes.
CSS layers are completely unintuitive to work with. I really don't see the use case for them. I hoped to isolate Telerik styling with it but it only made it harder to override styling.
Whats the eloquent javascript or think python equivalent for css? is it mdn docs or another? Does anyone know the best active, comprehensive online references?
How else do you really keep up on all the crazy new stuff
I simply need wide support. I made some websites for a client who receives many 1. older customers and 2. customers from all over the world. I was conscious of the possibility that these customers could have either ancient devices or some highly obscure foreign devices not reflected on caniuse.com.
Now, if your domain ends in .dev you can just assume that your users are up-to-date techies, but otherwise I avoid anything newer than flexbox (which is just so useful).
If one wants to replicate exact similar behavior in a webapp conpared to a native app we need the scroll/view animation to be available in all browsers. Right now animation is only possible with js and results in jittery animations.
CSS is becoming too complex. The syntax looks like it wants to be output by some compiler instead of being crafted by hand. Personally I also don't have any pleasure anymore writing CSS these days.
Sass and BEM methodology works fantastically well. Naming things isn't that hard, but Tailwind/utility approach is also extremely useful.
Those new features, besides container queries is just gibberish. Layer? WTF? The cascade is bad enough as it is, most devs can't even deal with the cascade it's why Tailwind become so popular. And we should dive even deeper into the cascade BS with layers and scoping and whatnpt? Again, this all looks like it was made to be output by some CSS compilers, not written by a developer.
Just because you don't understand it yet doesn't mean it isn't useful.
An ideal version of CSS would remove the need for SASS, BEM, and any non-thematic framework. That we have to use those right now is a problem to be fixed.
> Quick question: how many of these have you actively used in production?
> Container Queries
They aren't useful yet because:
1. Using them requires a wrapper element which can dirty up the HTML
2. While we were waiting for container queries to arrive, we also got new rules that made fluid layouts easier to implement which handle a chunk of container queries use cases.
Container queries will become more useful when elements can query their own size, rather than their size inside a designated parent.
> Style Queries
A solution in search of a problem. Current selectors are acceptable for most current use cases. May be useful for customizable widget/dashboard style layouts.
> CSS Layers
Nice, but they currently place too many demands on the developer to understand what layers currently exist. These will become more useful as browser dev tools make debugging them easier to reduce the burden on the developer to keep the layers in their mind while coding/debugging.
> Subgrid
Very useful when you need things aligned, especially in things like card layouts. The only thing holding this back is developers who are too reliant on 3rd party framework/libraries, e.g. bootstrap developers relying on grid column classes and tailwind developers building things with margin/padding everywhere. This will take time for developers to shift to, but those developer who limit themselves inside their own framework/library bubbles may never use them.
> Native Selector Nesting
Very nice quality-of-life improvement.
> Anchor Positioning
Only supported by one browser. I have no idea why this was even in the article to begin with. But it will completely remove the need for some JS placement/layout logic that keeps getting reimplemented all the time with pop-ups (pave the desire paths and all that). It also has the potential to make margin notes easier.
> :has, :is, :where
:has is super powerful as a parent selector
:where is great for simplifying repetitive css
> Logical Properties
If you maintain the discipline required to use these aliases over {top/left/down/right}, or if you have a linter to remind you, all of a sudden you're now able to support RTL languages without needing to spend time and money to make a different site for them.
> Scroll-Linked Animations
> View Transitions
Both will be abused by marketers and "designers" who don't understand accessibility, but both will also greatly simplify micro-interactions on proper websites that aren't trying to be a "marketing experience".
This article is interesting but when we’re talking about design elements I think it’s always a good idea to include some actual demos or examples showing the final result and not just the “code”. I might also not be the target audience but I still don’t understand what container queries are or what old paradigm they’re replacing. The author does a good job explaining the difference between border-radius and the old way of using photoshop, but fails to do that for the features that he’s trying to promote.
[+] [-] bruce511|1 year ago|reply
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.
[+] [-] Cyberdog|1 year ago|reply
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.
Good enough is good enough.
[+] [-] CM30|1 year ago|reply
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.
[+] [-] atoav|1 year ago|reply
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).
[+] [-] Flimm|1 year ago|reply
[+] [-] bramus|1 year ago|reply
And once other browsers starts supporting it, the experience will automatically work in those browsers too without you needing to touch a single line of code :)
[+] [-] leephillips|1 year ago|reply
“Granted some things are relatively new, and others might be sort of niche-y.”
[+] [-] rafark|1 year ago|reply
And that’s not necessarily a bad thing.
As I commented a few days ago, nowadays devs don’t seem to care too much about backwards compatibility. I like to hold onto my devices longer than most people and it’s a bit frustrating to see that most sites nowadays expect you to be in the latest and greatest. It didn’t use to be like this.
[+] [-] parhamn|1 year ago|reply
We recently had a user email us that our app stopped working for them. After we dug into it it was because their Chromebook was last updated in 2021 and didn't have Object.hasOwn (which a third-party library uses) and it's not even included in most common polyfills either. We fixed it, because I hate these sorts of compatibility issues.
Nevertheless, I left a bit concerned that they hadn't updated their Chrome in 3 years. Software decays much quicker than hardware in a real way, especially with the never ending list of security vulnerabilities found every year. Theres definitely a case to be made that forcing software upgrades is good for the end user too.
[+] [-] wruza|1 year ago|reply
[+] [-] onion2k|1 year ago|reply
Any time someone says this it's important to add a caveat of "and I want my site to look the same everywhere". Using @supports means you can feature detect what CSS the user's browser supports and enhance where possible. A user with an older browser might see a less pretty, simpler design with somewhat worse UX, but that's often ok if it's a tiny minority and you can give the users on new browsers a much better experience. The two versions might look a bit different but that's fine.
[+] [-] the_other|1 year ago|reply
[+] [-] sir_pepe|1 year ago|reply
[+] [-] graftak|1 year ago|reply
If your css is a mess in 2024 (2016 really) it is all on the developer and not the language.
[+] [-] gonzo41|1 year ago|reply
What I'd really like is more intellisense for css so I could take a css file and get sensible code complete and class suggestions for elements.
[+] [-] 6510|1 year ago|reply
[+] [-] lenkite|1 year ago|reply
[+] [-] paavohtl|1 year ago|reply
Even though MDN lists most of these features as "baseline" supported, the reality is that a small but still meaningful share of our users are using old iOS devices – especially iPads – and they can't or won't update their operating system to update Safari. Our oldest supported browser is Safari 14 because of Flexbox gap support.
None of the other platforms are a problem, as basically everyone else is using an automatically updating evergreen browser.
[+] [-] Unai|1 year ago|reply
When people say Safari is the new Internet Explorer, replies always mention how Safari just adopted such and such bleeding edge CSS feature (while ignoring much older features, though), but the truth is many Apple users won't see those features for years, until their devices break.
Apple is stopping both users and developers from enjoying these very same new features they so happily announce. The web is stuck in time, waiting for enough people to update their devices. Just like in the age of Internet Explorer. At least back then people had the option of installing a different browser. So maybe Safari and the apple ecosystem is actually worse than IE and Windows used to be.
[+] [-] skolind|1 year ago|reply
:has() and :is() are awesome.
One issue I’ve had with any of the newer CSS features is that, most of the people I work with don’t know what they do, because nobody use them. So, I have to explain myself in each pull request - but I guess that’s ok, because then people learn.
[+] [-] michaelnny|1 year ago|reply
[+] [-] npn|1 year ago|reply
> And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers.
Don't you know there are still a fuck ton of people that are still using the old iOS versions with their old phones? I have plenty of them, and they are long term supporters that I just can't shut them off.
There are new css features that are almost harmless and do not affect the usability, some css features on the other hand...
[+] [-] thoughtpalette|1 year ago|reply
[+] [-] PaulStatezny|1 year ago|reply
I don't want to argue for Tailwind, but as someone who's used it for ~4 years now, it strikes me that I've forgotten what it's like to have to think about sets of CSS rules and how they collide.
Utility class systems completely remove the need to even consider conflicting rules.
That doesn't mean CSS shouldn't continue to grow though, and I welcome these new features.
[+] [-] 6510|1 year ago|reply
This should be one of those articles one can click around in for considerable time.
Having to select and search made me wonder at what point in time we lost the ability to click on the bullet to select the list item text? Does anyone remember that feature?
[+] [-] kerkeslager|1 year ago|reply
> Container Queries
I haven't used this, but it looks super useful.
> Style Queries
Eh, I'm sure this is useful for situations that don't come up very often.
> CSS Layers
Ugh, I'm not going to use this overly-complex silliness, and I'm not looking forward to debugging this when other people use this.
> Subgrid
Again, overly complex. Grid could already do everything this can do, more simply.
> Native Selector Nesting
I'm already using this.
> Anchor Positioning
Eh, I already had solutions to this problem, but this seems like it probably communicates intent a bit better. I guess I'll pick that up.
> :has, :is, :where
:has is useful
:is... okay, fine, syntactic sugar.
:where I don't believe in hell. If I did, I'd be against it because burning someone for eternity is inhumane. But I might be willing to make an exception for people who write CSS that requires you to read the MDN article on Specificity to understand it.
> Logical Properties
Perhaps useful for situations that don't come up very often. Seems complex, but that might be because the thing it's representing is inherently complex.
> Scroll-Linked Animations
Okay, someone who isn't me will probably do really cool things with this.
> View Transitions
Another thing that seems complex, but possibly because the thing it's representing is inherently complex.
[+] [-] bobthepanda|1 year ago|reply
if you wanted to use grid template areas, and you had something that looked like
There isn't a great way to make the <li> adhere to the grid template areas, because without subgrids only direct children (the ul) have coordinate attributes.[+] [-] azangru|1 year ago|reply
May I ask you, are you a front-end developer?
[+] [-] sebazzz|1 year ago|reply
[+] [-] InMice|1 year ago|reply
How else do you really keep up on all the crazy new stuff
[+] [-] chrisweekly|1 year ago|reply
Pretty much everyone in the field knows about MDN (https://developer.mozilla.org/en-US/ )
and https://web.dev
and https://caniuse.com
but the Interop project is newer and maybe flying under the radar:
https://webkit.org/blog/14955/the-web-just-gets-better-with-...
Enjoy!
[+] [-] emmanueloga_|1 year ago|reply
--
1: https://stateofcss.com/en-US
[+] [-] sphars|1 year ago|reply
[+] [-] marcinreal|1 year ago|reply
Now, if your domain ends in .dev you can just assume that your users are up-to-date techies, but otherwise I avoid anything newer than flexbox (which is just so useful).
[+] [-] baggy_trough|1 year ago|reply
[+] [-] holoduke|1 year ago|reply
[+] [-] AltruisticGapHN|1 year ago|reply
Sass and BEM methodology works fantastically well. Naming things isn't that hard, but Tailwind/utility approach is also extremely useful.
Those new features, besides container queries is just gibberish. Layer? WTF? The cascade is bad enough as it is, most devs can't even deal with the cascade it's why Tailwind become so popular. And we should dive even deeper into the cascade BS with layers and scoping and whatnpt? Again, this all looks like it was made to be output by some CSS compilers, not written by a developer.
[+] [-] willio58|1 year ago|reply
At the end of the day these are all more tools in our toolbelt. If you want you can keep writing CSS the same way you always have.
[+] [-] JimDabell|1 year ago|reply
[+] [-] paulddraper|1 year ago|reply
I think the syntax is good (getting better with nested selectors)
[+] [-] notRobot|1 year ago|reply
[+] [-] cthor|1 year ago|reply
An ideal version of CSS would remove the need for SASS, BEM, and any non-thematic framework. That we have to use those right now is a problem to be fixed.
[+] [-] andrecarini|1 year ago|reply
Are there selectors for this anchor relationship? e.g. style anchored element when anchor is on :hover
[+] [-] tbm57|1 year ago|reply
[+] [-] spartanatreyu|1 year ago|reply
> Container Queries
They aren't useful yet because:
1. Using them requires a wrapper element which can dirty up the HTML
2. While we were waiting for container queries to arrive, we also got new rules that made fluid layouts easier to implement which handle a chunk of container queries use cases.
Container queries will become more useful when elements can query their own size, rather than their size inside a designated parent.
> Style Queries
A solution in search of a problem. Current selectors are acceptable for most current use cases. May be useful for customizable widget/dashboard style layouts.
> CSS Layers
Nice, but they currently place too many demands on the developer to understand what layers currently exist. These will become more useful as browser dev tools make debugging them easier to reduce the burden on the developer to keep the layers in their mind while coding/debugging.
> Subgrid
Very useful when you need things aligned, especially in things like card layouts. The only thing holding this back is developers who are too reliant on 3rd party framework/libraries, e.g. bootstrap developers relying on grid column classes and tailwind developers building things with margin/padding everywhere. This will take time for developers to shift to, but those developer who limit themselves inside their own framework/library bubbles may never use them.
> Native Selector Nesting
Very nice quality-of-life improvement.
> Anchor Positioning
Only supported by one browser. I have no idea why this was even in the article to begin with. But it will completely remove the need for some JS placement/layout logic that keeps getting reimplemented all the time with pop-ups (pave the desire paths and all that). It also has the potential to make margin notes easier.
> :has, :is, :where
:has is super powerful as a parent selector
:where is great for simplifying repetitive css
> Logical Properties
If you maintain the discipline required to use these aliases over {top/left/down/right}, or if you have a linter to remind you, all of a sudden you're now able to support RTL languages without needing to spend time and money to make a different site for them.
> Scroll-Linked Animations > View Transitions
Both will be abused by marketers and "designers" who don't understand accessibility, but both will also greatly simplify micro-interactions on proper websites that aren't trying to be a "marketing experience".
[+] [-] nolongerthere|1 year ago|reply