7 ms·

What's new in CSS4

64 points by AndrewDucker 15y ago

dhx 15y ago
Does this accomplish anything above and beyond what XPath is capable of? I've always wondered why W3C has been pushing more than one standard for selecting elements in SGML and XML documents.
- masklinn 15y ago
  > Does this accomplish anything above and beyond what XPath is capable of? Nope. In terms of pure capabilities CSS selectors are still (mostly) a subset of XPath selectors (even XPath 1.0 I'd say) > I've always wondered why W3C has been pushing more than one standard for selecting elements in SGML and XML documents. I don't have an answer, but I see 4 reasons: * NIH, the W3C is not really a big coherent group, and technically CSS selectors predate XPath (CSS level 1 became a CR in December 1996, XPath 1.0 did not reach this status before November 1999) * CSS selectors are purpose-built for HTML and have efficient (and simple) shortcuts for a bunch of tasks: selecting on ids or classes has a 1-character overhead in CSS versus XPath having 5 for ids and classes... well you're looking at a good 50 characters in XPath 1 (w/o exslt) I'd say, there just isn't a convenient way to say "an element with this value in an attribute which is a space-separated list of names". Another one is XPath being built for parent/child relationships where CSS selectors default to ancestor/descendant relations, and makes it easier and shorter to broadly apply rules. The last one would be pseudo-classes and pseudo-elements, to handle these in XPath you'd have to add a bunch of functions to the core set (see point 4 for what I think of XPath functions) * For rendering-speed reasons, CSS are processed back-to-front, I'm not sure how good/easy it would be to process XPath that way (not too hard I'd guess, but it definitely wasn't standardized based on this thinking) * XPath is actually pretty complex, much more so than CSS selectors (even CSS3 or CSS4 selectors), I know I always a hard time with getting those fucking funcalls right, the syntax is fiddly and different XPath libraries tend to behave very differently on namespacing & al of funcalls. Also, the data-typing is complete shit. I like XPath 1.0 (though I think XPath 2.0 went full retard in backporting XQuery stuff and integrating a bunch of garbage relevant only to XSLT 2.0), but while I regularly pine for some specific XPath features in CSS selectors (usually more flexible axis modifiers) I really wouldn't enjoy having to use XPath instead of CSS in my style sheets.
hpaavola 15y ago
I don't need new selectors, I need a way to specify layouts. You know, to do the same things as tables did back in the days, but without all the ugliness.
- masklinn 15y ago
  http://www.w3.org/TR/css3-multicol/ http://www.w3.org/TR/css3-multicol/ http://www.w3.org/TR/css3-grid-layout/ http://www.w3.org/TR/css3-grid-layout/
  - StrawberryFrog 15y ago
    Are the ms-grids and the multicolumn layouts in CSS4? It doesn't look like it from that draft. Are they just free-floating proposals at this stage?
    - masklinn 15y ago
      The reality is that there's no such thing as CSS4, and no such thing as CSS3 either: starting with CSS3 the spec was "modularized", meaning it was broken up in a bunch of separate and mostly-independent "modules", which are grouped in a "level" but are specified on their own[0]. So the situation is that TFA talks not about CSS4 but about "Level 4 Selectors" (a draft), talking about "CSS4" is language abuse. The specs I linked are Level 3 specs, but independent of selectors and of one another (columns are a CR, grid is a working draft). To sum up, your question does not really make sense. Grids and columns are part of "CSS4" insofar as they are part of "CSS3" through being Level 3 specifications, but that's completely meaningless. Level 4 selectors could become recommandations before (level 3) grids reach that state, or not. There's no dependency. (columns are already supported by all modern browsers except MSIE). I'd recommend using (and abusing) http://caniuse.com/ http://caniuse.com/ to see the implementation state of each spec, it's become especially important with modular level 3 specs as implementors are free to add one level 3 spec and ignore an other. [0] You can see a list of specs at http://www.w3.org/TR/#tr_CSS http://www.w3.org/TR/#tr_CSS, note how some Level 3 specs are Recommendations, others are Candidate Recommandations, yet others are Last Calls or Drafts.
chime 15y ago
Parent selector is cool but I've needed it at most 2-3% of the time when designing a site. As of now, it doesn't appear to support things I really need in almost all mid-large site layouts: variables, mixins/functions, operations, and namespaces. This means even 5 years from now, I'll need http://lesscss.org/ http://lesscss.org/ because browsers with CSS4 won't support variables. How does one go about suggesting to W3C that they should support variables in CSS4?
- dhx 15y ago
  http://news.ycombinator.com/item?id=3162221 http://news.ycombinator.com/item?id=3162221 (which links to through to a www-style list discussion from October 24: http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.html http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.h...)
  - chime 15y ago
    That is quite elegant. That should take care of the variables requirement. Thanks!
  - romaniv 15y ago
    This is definitely better than no variables, but is it the best solution? I think most of the advantages of variables can be achieved through a technique that introduces no new syntax and a minimum of new keywords: .element { color: #06c; border-color: #006; } h1 { apply: .element; border-style: thick; border-width: solid; } This will make H1 "pretend" that it has .element class applied to it, even though in HTML source code it doesn't. I think it's a conceptually simple and orthogonal solution. True variables differ from the current metality of CSS way too much.
    - eljaco 15y ago
      +1 - I love this idea; some/most times it's easier to change the CSS instead of the HTML/template.
    - michaelchisari 15y ago
lukestevens 15y ago
Web Monkey calling this "CSS 4" seems a bit misleading -- it's a spec for Selectors Level 4; I don't think there is a monolithic "CSS 4" in the same way there isn't a monolithic "CSS 3". I assume the wide variety of CSS3 modules will be mostly unaffected.
- masklinn 15y ago
  Correct, as far as I know.
unfortunate 15y ago
I hope they introduce variables/mixins/functions (Akin to SASS or LESS)

64 points by AndrewDucker 15y ago

dhx 15y ago

Does this accomplish anything above and beyond what XPath is capable of? I've always wondered why W3C has been pushing more than one standard for selecting elements in SGML and XML documents.

masklinn 15y ago
> Does this accomplish anything above and beyond what XPath is capable of? Nope. In terms of pure capabilities CSS selectors are still (mostly) a subset of XPath selectors (even XPath 1.0 I'd say) > I've always wondered why W3C has been pushing more than one standard for selecting elements in SGML and XML documents. I don't have an answer, but I see 4 reasons: * NIH, the W3C is not really a big coherent group, and technically CSS selectors predate XPath (CSS level 1 became a CR in December 1996, XPath 1.0 did not reach this status before November 1999) * CSS selectors are purpose-built for HTML and have efficient (and simple) shortcuts for a bunch of tasks: selecting on ids or classes has a 1-character overhead in CSS versus XPath having 5 for ids and classes... well you're looking at a good 50 characters in XPath 1 (w/o exslt) I'd say, there just isn't a convenient way to say "an element with this value in an attribute which is a space-separated list of names". Another one is XPath being built for parent/child relationships where CSS selectors default to ancestor/descendant relations, and makes it easier and shorter to broadly apply rules. The last one would be pseudo-classes and pseudo-elements, to handle these in XPath you'd have to add a bunch of functions to the core set (see point 4 for what I think of XPath functions) * For rendering-speed reasons, CSS are processed back-to-front, I'm not sure how good/easy it would be to process XPath that way (not too hard I'd guess, but it definitely wasn't standardized based on this thinking) * XPath is actually pretty complex, much more so than CSS selectors (even CSS3 or CSS4 selectors), I know I always a hard time with getting those fucking funcalls right, the syntax is fiddly and different XPath libraries tend to behave very differently on namespacing & al of funcalls. Also, the data-typing is complete shit. I like XPath 1.0 (though I think XPath 2.0 went full retard in backporting XQuery stuff and integrating a bunch of garbage relevant only to XSLT 2.0), but while I regularly pine for some specific XPath features in CSS selectors (usually more flexible axis modifiers) I really wouldn't enjoy having to use XPath instead of CSS in my style sheets.

hpaavola 15y ago

I don't need new selectors, I need a way to specify layouts. You know, to do the same things as tables did back in the days, but without all the ugliness.

masklinn 15y ago
http://www.w3.org/TR/css3-multicol/ http://www.w3.org/TR/css3-multicol/ http://www.w3.org/TR/css3-grid-layout/ http://www.w3.org/TR/css3-grid-layout/
- StrawberryFrog 15y ago
  Are the ms-grids and the multicolumn layouts in CSS4? It doesn't look like it from that draft. Are they just free-floating proposals at this stage?
  - masklinn 15y ago
    The reality is that there's no such thing as CSS4, and no such thing as CSS3 either: starting with CSS3 the spec was "modularized", meaning it was broken up in a bunch of separate and mostly-independent "modules", which are grouped in a "level" but are specified on their own[0]. So the situation is that TFA talks not about CSS4 but about "Level 4 Selectors" (a draft), talking about "CSS4" is language abuse. The specs I linked are Level 3 specs, but independent of selectors and of one another (columns are a CR, grid is a working draft). To sum up, your question does not really make sense. Grids and columns are part of "CSS4" insofar as they are part of "CSS3" through being Level 3 specifications, but that's completely meaningless. Level 4 selectors could become recommandations before (level 3) grids reach that state, or not. There's no dependency. (columns are already supported by all modern browsers except MSIE). I'd recommend using (and abusing) http://caniuse.com/ http://caniuse.com/ to see the implementation state of each spec, it's become especially important with modular level 3 specs as implementors are free to add one level 3 spec and ignore an other. [0] You can see a list of specs at http://www.w3.org/TR/#tr_CSS http://www.w3.org/TR/#tr_CSS, note how some Level 3 specs are Recommendations, others are Candidate Recommandations, yet others are Last Calls or Drafts.

chime 15y ago

Parent selector is cool but I've needed it at most 2-3% of the time when designing a site. As of now, it doesn't appear to support things I really need in almost all mid-large site layouts: variables, mixins/functions, operations, and namespaces. This means even 5 years from now, I'll need http://lesscss.org/ http://lesscss.org/ because browsers with CSS4 won't support variables. How does one go about suggesting to W3C that they should support variables in CSS4?

dhx 15y ago
http://news.ycombinator.com/item?id=3162221 http://news.ycombinator.com/item?id=3162221 (which links to through to a www-style list discussion from October 24: http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.html http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.h...)
- chime 15y ago
  That is quite elegant. That should take care of the variables requirement. Thanks!
- romaniv 15y ago
  This is definitely better than no variables, but is it the best solution? I think most of the advantages of variables can be achieved through a technique that introduces no new syntax and a minimum of new keywords: .element { color: #06c; border-color: #006; } h1 { apply: .element; border-style: thick; border-width: solid; } This will make H1 "pretend" that it has .element class applied to it, even though in HTML source code it doesn't. I think it's a conceptually simple and orthogonal solution. True variables differ from the current metality of CSS way too much.
  - eljaco 15y ago
    +1 - I love this idea; some/most times it's easier to change the CSS instead of the HTML/template.
  - michaelchisari 15y ago

lukestevens 15y ago

Web Monkey calling this "CSS 4" seems a bit misleading -- it's a spec for Selectors Level 4; I don't think there is a monolithic "CSS 4" in the same way there isn't a monolithic "CSS 3". I assume the wide variety of CSS3 modules will be mostly unaffected.

masklinn 15y ago
Correct, as far as I know.

unfortunate 15y ago

I hope they introduce variables/mixins/functions (Akin to SASS or LESS)