5 ms·

CSS - Level 4 Selectors

59 points by smaili 10y ago

sdegutis 10y ago
Looks like this is a bunch of links to what's basically CSS4? (Not sure why all 4 links on the landing page go to the exact same page, but whatever.) If this really is the future of CSS, then I now hate CSS even more than I already did.
- Raphmedia 10y ago
  Why would those handy extra selectors make you hate CSS more that you do? Why do you hate it in the first place? Because it's trendy to do so?
  - sdegutis 10y ago
    Because it's getting exponentially and disproportionately more complicated to just make what ought to be a pretty simple e-store. At this rate I'll soon need to know how to do advanced calculus just to figure out how to make an interface that supports both mobile and desktop.
    - Raphmedia 10y ago
      If you find CSS hard to grasp you should seriously consider actually learning it instead of randomly writing words in the hope that things will stick. 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.
      - sdegutis 10y ago
        Everything I've said in this thread has been misinterpreted and/or misunderstood and I just don't have the time to clarify, gotta get back to work.
        Raphmedia 10y ago
        No hard feelings. :-)
    - talmand 10y ago
      Just because a feature was added doesn't mean you need to make use of it. You can still style a website using well-documented and easy-to-use CSS Level 2.1 if you really want to, it'll still work. If you feel even that's too complicated then just go with CSS Level 1.
    - angry-hacker 10y ago
      It's getting easier with new selectors, no? And if not, use the old ones you know! Case closed :)
  - Ellipsis753 10y ago
    Not sure this is what OP is getting at, but CSS is getting a bit bloated and yet is still unable to fulfill many simple tasks without extra divs and/or JavaScript. 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.
    - Raphmedia 10y ago
      > Not sure this is what OP is getting at, but CSS is getting a bit bloated and yet is still unable to fulfill many simple tasks without extra divs and/or JavaScript. 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.
- pluma 10y ago
  "CSS4" is a bit of a misnomer. 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.
andrewmcwatters 10y ago
Thank you for not titling this CSS4. Although in the long run, this misnomer will probably still carry on.
wanda 10y ago
Nice to see a parent selector in the form of :has. 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 } if you wanted to change a navigation bar's background color without JavaScript. :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' } or perhaps: .box { color: #111 } [data-lang='c'].box { color: #f44500 }
- gsnedders 10y ago
  Note however the different profiles (see https://drafts.csswg.org/selectors-4/#profiles https://drafts.csswg.org/selectors-4/#profiles). Notably, the dynamic profile excludes :has, and that's what's expected to be used for selector matching in CSS in browsers. (:has can't be matched in a single-pass of the document with a single-node lookahead, which is something no browser vendor wants to give up.) The static profile is likely to be used by querySelector and similar. 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.
  - Klathmon 10y ago
    Does the profiles thing feel like a really really bad idea to anyone else? 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.
gkilmain 10y ago
I see conflicts with caniuse.com. For instance :scope. CSS4Rocks says supported in all browsers but IE. caniuse.com says its only supported in FF and mentions it has been removed from the current specification.
- gsnedders 10y ago
  > For instance :scope. CSS4Rocks says supported in all browsers but IE. caniuse.com says its only supported in FF and mentions it has been removed from the current specification. 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.
  - gkilmain 10y ago
    I think you're right. One looks like an attribute (caniuse.com), cssrocks is :scoped, a pseudo.
mmastrac 10y ago
EDIT: I'm wrong, see [2] 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. [1] https://grack.com/blog/2015/01/11/css-selectors-4/ https://grack.com/blog/2015/01/11/css-selectors-4/ [2] https://drafts.csswg.org/selectors-4/#profiles https://drafts.csswg.org/selectors-4/#profiles
- combatentropy 10y ago
  It's a little disappointing if the :has selector never makes it into stylesheets, just JavaScript's querySelector. Then again I'm thankful for what we already have. For example, even the old :hover selector seems to me like it would have been slow, but it's not. Others like :checked, :disabled, and :target further eliminate some JavaScript. HTML 5 eliminates more, like autofocus, datepickers, and most form checking (I think? I haven't used it much.) 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.
Manishearth 10y ago
A lot of the comments on the post about :has complain that browsers haven't implemented it yet. 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.
- Senji 10y ago
  I've used :has in uBlock filter declarations and it's perfect.(uBlock implements its own :has for its filters) 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.
  - Manishearth 10y ago
    > relatively trivial 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.

59 points by smaili 10y ago

Looks like this is a bunch of links to what's basically CSS4? (Not sure why all 4 links on the landing page go to the exact same page, but whatever.) If this really is the future of CSS, then I now hate CSS even more than I already did.

Raphmedia 10y ago
Why would those handy extra selectors make you hate CSS more that you do? Why do you hate it in the first place? Because it's trendy to do so?
- sdegutis 10y ago
  Because it's getting exponentially and disproportionately more complicated to just make what ought to be a pretty simple e-store. At this rate I'll soon need to know how to do advanced calculus just to figure out how to make an interface that supports both mobile and desktop.
  - Raphmedia 10y ago
    If you find CSS hard to grasp you should seriously consider actually learning it instead of randomly writing words in the hope that things will stick. 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.
    - sdegutis 10y ago
      Everything I've said in this thread has been misinterpreted and/or misunderstood and I just don't have the time to clarify, gotta get back to work.
      - Raphmedia 10y ago
        No hard feelings. :-)
  - talmand 10y ago
    Just because a feature was added doesn't mean you need to make use of it. You can still style a website using well-documented and easy-to-use CSS Level 2.1 if you really want to, it'll still work. If you feel even that's too complicated then just go with CSS Level 1.
  - angry-hacker 10y ago
    It's getting easier with new selectors, no? And if not, use the old ones you know! Case closed :)
- Ellipsis753 10y ago
  Not sure this is what OP is getting at, but CSS is getting a bit bloated and yet is still unable to fulfill many simple tasks without extra divs and/or JavaScript. 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.
  - Raphmedia 10y ago
    > Not sure this is what OP is getting at, but CSS is getting a bit bloated and yet is still unable to fulfill many simple tasks without extra divs and/or JavaScript. 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.
pluma 10y ago
"CSS4" is a bit of a misnomer. 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.

andrewmcwatters 10y ago

Thank you for not titling this CSS4. Although in the long run, this misnomer will probably still carry on.

wanda 10y ago

Nice to see a parent selector in the form of :has. 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 } if you wanted to change a navigation bar's background color without JavaScript. :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' } or perhaps: .box { color: #111 } [data-lang='c'].box { color: #f44500 }

gsnedders 10y ago
Note however the different profiles (see https://drafts.csswg.org/selectors-4/#profiles https://drafts.csswg.org/selectors-4/#profiles). Notably, the dynamic profile excludes :has, and that's what's expected to be used for selector matching in CSS in browsers. (:has can't be matched in a single-pass of the document with a single-node lookahead, which is something no browser vendor wants to give up.) The static profile is likely to be used by querySelector and similar. 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.
- Klathmon 10y ago
  Does the profiles thing feel like a really really bad idea to anyone else? 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.

gkilmain 10y ago

I see conflicts with caniuse.com. For instance :scope. CSS4Rocks says supported in all browsers but IE. caniuse.com says its only supported in FF and mentions it has been removed from the current specification.

gsnedders 10y ago
> For instance :scope. CSS4Rocks says supported in all browsers but IE. caniuse.com says its only supported in FF and mentions it has been removed from the current specification. 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.
- gkilmain 10y ago
  I think you're right. One looks like an attribute (caniuse.com), cssrocks is :scoped, a pseudo.

mmastrac 10y ago

EDIT: I'm wrong, see [2] 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. [1] https://grack.com/blog/2015/01/11/css-selectors-4/ https://grack.com/blog/2015/01/11/css-selectors-4/ [2] https://drafts.csswg.org/selectors-4/#profiles https://drafts.csswg.org/selectors-4/#profiles

combatentropy 10y ago
It's a little disappointing if the :has selector never makes it into stylesheets, just JavaScript's querySelector. Then again I'm thankful for what we already have. For example, even the old :hover selector seems to me like it would have been slow, but it's not. Others like :checked, :disabled, and :target further eliminate some JavaScript. HTML 5 eliminates more, like autofocus, datepickers, and most form checking (I think? I haven't used it much.) 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.

Manishearth 10y ago

A lot of the comments on the post about :has complain that browsers haven't implemented it yet. 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.

Senji 10y ago
I've used :has in uBlock filter declarations and it's perfect.(uBlock implements its own :has for its filters) 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.
- Manishearth 10y ago
  > relatively trivial 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.