Some of those properties are new-ish. If you follow the events, you will have known of them for a while but I agree most people may not be aware of them.
The :has selector is huge if you like customizing sites with grease monkey. You can now modify parents based on their children with pure css. Saves you having to use mutation observers in those cases (assuming the site is built with a React-like thing).
I just checked and Firefox finally supports it (added Dec 2023). I have a javascript workaround still in place for Firefox and it looks like I can remove that. ;) All the other mainstream browsers added :has in 2022 and it was an excellent fit for some layout optimizations.
If you don't require pure CSS, nested `querySelector` calls are also great for this -- you can use it to segment out smaller slices of a DOM with more generalized queries, that don't rely on detailed selector logic. I'm a fan of this for its composability, but nesting -- also referenced in the OP -- could be used to achieve a similar result.
You can also create new DOMs out of arbitrary HTML trees with a `DOMParser`, and can then run queries against those. Really useful when run against the responses from `fetch` requests.
I don't really see how that helps you when you're trying to modify a SPA. As soon as you try to use JavaScript to modify anything, you need to figure out how to run that JS after whatever framework has finished rendering.
Usually that's using mutation observers or by adding super short animations and listening for animation end events. Both are annoying to use _and_ result in a slight jank where the wrong thing flashes for a split second if you're doing large layout changes.
The advantage of using CSS is that after you inject it, everything happens synchronously, so there are no rendering glitches.
It doesn't, the use case I had picked up a userscript manager for was to experiment with Web scraping.
I was more saying that if someone reading this thread doesn't need pure CSS for this -- like if you have other needs but a similar problem -- there are additional options.
Do you have an examples you can share where you use what you're describing? I love learning "weird tricks", but I'm struggling to understand yours without a code sample.
My experiments with scraping have been running headless chrome, grabbing all the HTML after stuff renders, dumping that to BeautifulSoup in Python and processing it there. I'm really curious how you do it in a user script.
Basically I went from screwing around in a console to reimplementing the same thing using Violentmonkey[0] to eventually using `astral` (a Deno-based browser automation lib)
For a simple example, to walk through a paginated list: check the first page's DOM for a "next page" link. Make a `fetch` request against its href, get the response's HTML content using `res.text()`, and then pass it into a `DOMParser`. Then, check that DOM for another "next" button. And so on. (Obviously running whatever page scraping logic you might need each time you run the loop.)
Another example of why you might do this is, say, to replace sections of a comment history while you overwrite them. (Though, to your point, when I did that to my Reddit account I had to use old reddit for this part in particular. I was trying to do the whole thing within the browser, and that turned out to not be possible in New Reddit bc client-side routing kept spawning new console instances.)
Browser automation libs come with handlers for stuff like selection anyway, but it's still there if you need client-side logic -- you can use `page.evaluate()` to execute code within the browser context and pass data back out.
Some additions are nice, but I have my doubts about where this is going. As usual, Google throws in tons of extra stuff. To compute the size, position and appearance of anything, engines have to deal with a growing list of instructions, that all brings conflict. We had floats, flex, grids, position, and now anchor positioning as well.
It strikes me that the more useful additions are implemented by Firefox, and the lesser ones not.
I had expected that by now we would have a super light (kernel) spec for SPAs, and the heavier spec for design heavy documents. Chrome cannot keep up with Firefox wrt CSS performance.
I don't understand why Google is overloading its own camel; the web is not going to render faster with more added complexity.
I mean would you rather the browser handle this at a lower level where it can do so efficiently or libraries continue to solve these things on the main thread with pure javascript? The defacto way to handle anchoring views today is with something like Floating UI [1] and that doesn't even handle portaling content to root of the DOM except for in React.
Some of the additions are nice but I also think some of them just add unnecessary complexity. Some of them (e.g. the @layer feature) diverge from CSS fundamentals in a radical way and don't let you achieve anything new (just gives you more ways to get to the same place). My feeling is that Google is trying hard to lock developers into Chrome. I wish they had come up with a new standard and just invented a new simpler CSS alternative instead of adding more stuff on top of the existing standard.
Seems like some good stuff there. Personally I really like container queries, cascade layers, nesting and the has selector, all of which feel like they solve some very common design problems in incredibly easy to understand, logical ways.
Like cascade layers, nesting and scoped CSS are basically built for component systems, and are going to be so handy for implementing styles for those going forward.
Didn't know about margin trim either... that sounds like it'll be a godsend when it's fully implemented. So much extra CSS required to overwrite the margin on the last element in a container almost every time the situation comes up...
23 comments
[ 3.0 ms ] story [ 62.9 ms ] threadThat should be the real title of the article.
Some of those properties are new-ish. If you follow the events, you will have known of them for a while but I agree most people may not be aware of them.
https://caniuse.com/?search=%3Ahas
You can also create new DOMs out of arbitrary HTML trees with a `DOMParser`, and can then run queries against those. Really useful when run against the responses from `fetch` requests.
Usually that's using mutation observers or by adding super short animations and listening for animation end events. Both are annoying to use _and_ result in a slight jank where the wrong thing flashes for a split second if you're doing large layout changes.
The advantage of using CSS is that after you inject it, everything happens synchronously, so there are no rendering glitches.
I was more saying that if someone reading this thread doesn't need pure CSS for this -- like if you have other needs but a similar problem -- there are additional options.
My experiments with scraping have been running headless chrome, grabbing all the HTML after stuff renders, dumping that to BeautifulSoup in Python and processing it there. I'm really curious how you do it in a user script.
Basically I went from screwing around in a console to reimplementing the same thing using Violentmonkey[0] to eventually using `astral` (a Deno-based browser automation lib)
For a simple example, to walk through a paginated list: check the first page's DOM for a "next page" link. Make a `fetch` request against its href, get the response's HTML content using `res.text()`, and then pass it into a `DOMParser`. Then, check that DOM for another "next" button. And so on. (Obviously running whatever page scraping logic you might need each time you run the loop.)
Another example of why you might do this is, say, to replace sections of a comment history while you overwrite them. (Though, to your point, when I did that to my Reddit account I had to use old reddit for this part in particular. I was trying to do the whole thing within the browser, and that turned out to not be possible in New Reddit bc client-side routing kept spawning new console instances.)
Browser automation libs come with handlers for stuff like selection anyway, but it's still there if you need client-side logic -- you can use `page.evaluate()` to execute code within the browser context and pass data back out.
[0] https://violentmonkey.github.io/
CSS nesting looks like a nice quality-of-life improvement in some cases.
I'm not CSS-ninja enough for any of the other items to catch my eye, though the "stylable select element" tease at the end looks interesting.
It strikes me that the more useful additions are implemented by Firefox, and the lesser ones not.
I had expected that by now we would have a super light (kernel) spec for SPAs, and the heavier spec for design heavy documents. Chrome cannot keep up with Firefox wrt CSS performance. I don't understand why Google is overloading its own camel; the web is not going to render faster with more added complexity.
[1] https://floating-ui.com/
Like cascade layers, nesting and scoped CSS are basically built for component systems, and are going to be so handy for implementing styles for those going forward.
Didn't know about margin trim either... that sounds like it'll be a godsend when it's fully implemented. So much extra CSS required to overwrite the margin on the last element in a container almost every time the situation comes up...
There's some good stuff here for sure.