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.
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.
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/ 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, note how some Level 3 specs are Recommendations, others are Candidate Recommandations, yet others are Last Calls or Drafts.
In summary: no, they're in CSS3; but it's all modular and might not be implemented at the same time.
There is incentive for MS Grids to go forward soon, they're important to MS for use in Windows 8.
Also, they're cool, or rather they're a sane layout scheme and it's awful that CSS hasn't had one up to now.
The irony is that Firefox and Chrome will implement them at about the same time that they become official. But we won't be able to use them widely until IE7,8 and 9 have faded from the web. MS giveth, MS taketh away.
One problem with that idea is that tools like CSS tables still have some dependency on the source order in the HTML. So do certain other popular tools, notably various aspects of float positioning.
If we're going to have a proper separation of content from presentation, such that we can do things like alternative layouts for responsive design or A/B testing using only the presentation layer, there has to be a viable mechanism for overriding that sort of source-order dependency.
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.
> 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.
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/ because browsers with CSS4 won't support variables. How does one go about suggesting to W3C that they should support variables in CSS4?
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:
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.
I'm torn on this. Inheritance already exists through assigning multiple classes and the cascade, and now it's impossible to use a "child" class without dragging its parent along with it unless you override "apply" inline.
Not terribly clear as to why we need specific functionality for inheritance when we already have an expressive way of defining it.
The above comment was addressing the lack of variables, not the lack of true inheritance (a single level of inheritance is not really inheritance at all, simply applying attributes en masse). What the comment does address is the lack of variables and the need/want to set a color (or anything else) once and then use that through an assortment of other definitions. This is something that is only currently possible through CSS preprocessors.
It really doesn't look like variables to me. A variable would be a reference to a singularly defined property, such as a color or border style, not a hook to an entire list of properties. Certainly it could be used as a variable: that is, defining a class with a single property and hooking to that. But let's assume it's being used as a variable, why not write something like this?
I've inherited .magic into .data without sacrificing the ability to use .magic and .data by itself. As long as you keep your CSS classes semantic and disperse them intelligently into the markup, it's really not an issue of making large scale changes with minimal effort. Of course, in practice, this isn't always the case, but I think adding more ways to inherit properties will increase complexity more than help write good styles.
I think the outcry for these features is a symptom of a poor understanding of the cascade and the language. There are much larger issues I'd like to see addressed, like the wide adoption of layout definitions which has better rules for defining vertical positioning and more fluid widths, both of which are pretty nightmarish without resorting to tables.
CSS cascading allows you to apply styles based on the structure of your HTML document. It does nothing for structuring CSS itself. The point of variables (and my suggestion above) is to have a tool for ogranizing and reusing CSS regardless of your HTML structure.
Why require adding a fiddly and complex toolchain making ramp up and usage of these features more complex than it has to be, and harder to troubleshoot, when it's something making production easier to maintain in the long run?
Because unless you suggest adding source maps to CSS (even though they still are not in JS), a preprocessor generating CSS makes CSS far more annoying to debug or play around with than native constants support would (and even with source maps, the usability of devtools style inspectors and editors would be significantly inferior to native support)
I wouldn't mind a Chrome/Firefox extension to play around with extended CSS, but in production, I'm on the side of higher performance in Web Browser, which comes from simple style syntax.
