CSS - Level 4 Selectors
css4.rocks
css4.rocks
The reason it hasn't been implemented is (probably) that it's a big perf footgun (not because of laziness). It essentially doubles the amount of work you need to do in applying the cascade. I suspect some browsers implement it internally anyway, but leave it off for web content.
I don't remember the exact circumstances, but a month ago we were discussing some optimizations in Servo (which has parallel styling, making `:has` even worse), and often my thoughts would be "thank god :has doesn't exist", because it would often destroy the premise of the optimization.
I'm sure that optimizations can be done so that pages without :has are unaffected and pages with :has aren't affected as much, but how much is enough?
So I'm skeptical if it will ever make it. I'm not involved in the discussions here so I don't know what the current status is.
I mean, I've often felt the need for :has. I wish we could have it. I'm not sure if it's a good idea taking perf into consideration.
It should be relatively trivial to isolate the elements targeted by :has and incur the performance penalty only for them instead of the whole dom.
No, that's the point, it isn't, because of various optimizations it turns off. I need to think about exactly what they were, but it's not as simple as isolating the has selectors.
One of the big changes here is that the :has selector is available in regular stylesheets. This is going to open up a wonderful array of interesting possibilities (virtual selectors like "parent of" or "previous sibling", for example).
When I last reviewed the spec [1], it was limited to use in JS querySelector*() calls only.
The :has selector would have wiped out all but about 2% of my JavaScript needs. Don't get me wrong. I don't mind JavaScript as much as other people. In fact, I kind of like it. But given the choice between declarative (CSS) and procedural (JavaScript) it's generally shorter to use declarative.
Some people seem to believe such a selector has always existed — at least I see some mentions of it on StackOverflow sometimes.
Now it looks like finally we will finally be able to do things like:
nav:has(>a.active){
background-colour: red
}
:lang seems a bit weird. Seems easier to use a lang= attribute on the root node or data-lang on any node, and then using an attribute selector like so:
[lang='jp']{
font-family: 'Noto Sans'
}
.box {
color: #111
}
[data-lang='c'].box {
color: #f44500
}The only thing new with :lang in Selectors 4 is wildcards (with "*"). Note that if you do want to use attribute selectors you likely want to use |= rather than just =. |= allows either the exact value or a string that starts with it followed by "-". :lang exists for similar reasons to :link—making selectors generic, so they can work with things except (X)HTML.
I don't get why you'd ever use data-lang rather than lang, though? Notably, data-lang wouldn't get passed through to the AT layer. You can use lang on any element, not just the root.
Taking CSS and splitting it into parts that can be in the stylesheet and parts that can't seems like it's only going to cause confusion, and won't really help anything.
The major reason you'd want something like :has is because you want to style a parent in CSS only. Without that being in the "dynamic profile" it leaves it to JS only, which (if i'm reading things correctly) would be able to do the same thing by doing a lookup on the parent, then doing a lookup in that node for the child which would be faster than how current CSS engines would find that node if they had to start making multiple passes.
One difference is that it should handle subtypes seamlessly - e.g. :lang(es) would match <div lang="es-mx"> without the developer having to remember to use [lang*=] or consider whether their expression could match other languages (e.g. did your attempt to select Canadian English (lang=en-ca) match Catalan (lang=ca) or vice versa?).
The main reason I use :lang, however, is for inheritance:
<p lang="zh">
We don't want <b>Chinese text to be displayed in bold</b>
</p>
I can't find :scope on caniuse.com? There's Scoped CSS there, but that's a largely unrelated (and, as you say, abandoned) HTML feature.
Why do you hate it in the first place? Because it's trendy to do so?
Over here, CSS class is given on the same level as the Programming 101 classes. The class you give to new students because it's easy.
If you feel even that's too complicated then just go with CSS Level 1.
And if not, use the old ones you know! Case closed :)
With Flexbox we're soon going to have _sort-of_ solved one painful issue in css - lack of vertical centring, but it's amazing it's taken this long and that the solution is still so ugly.
Larger issues with CSS can't really be solved without breaking backwards compatibility (which will never happen). For example, I wish CSS was more modular and perhaps didn't cascade so freely as it does. It's very rare to see an old site where it's possible to modify the CSS without risking breaking random pages.
Part of my work as a front-end dev. is taking pages from CMS softwares that are already done and add styles to them without changing any line of code on the markup.
I never, ever, had any issues.
You don't need to add extra divs to do anything.
In fact, when we learned to do CSS at college, the teacher teased the bad students. He would say that they had DIVitis. The great disease of our generation. Divs would keep popping up all over them and their work.
We currently support IE9+ without any issues. We used to support IE8+ without any issues.
The CSS spec was modularised so all the various parts (like selectors) are versioned independently of each other. So there's no longer one version of CSS but a combination of various specs that each might be at totally different versions.
Besides, no browser ever fully supported ALL of a particular version of a spec anyway.