

What's new in CSS4 - AndrewDucker
http://www.webmonkey.com/2011/10/discover-whats-new-in-css-4/

======
lukestevens
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
Correct, as far as I know.

------
hpaavola
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
<http://www.w3.org/TR/css3-multicol/> <http://www.w3.org/TR/css3-grid-layout/>

~~~
StrawberryFrog
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
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.

~~~
StrawberryFrog
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.

~~~
masklinn
> In summary: no, they're in CSS3

No. In summary, the question itself does not make sense, it's like asking if
the sun tastes better than communism.

~~~
StrawberryFrog
That's not quite right though; there is a CSS level 3 and these specs are in
it.

------
dhx
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
> 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.

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

------
chime
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?

~~~
dhx
<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.h...](http://lists.w3.org/Archives/Public/www-
style/2011Oct/0699.html))

~~~
romaniv
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.

~~~
huckfinnaafb
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.

~~~
sellandb
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.

~~~
huckfinnaafb
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?

    
    
        .data { 
            font-size:11px;
            font-family:Courier;
            color: #555;
        }
        .magic { 
            color: royalBlue;
        }
    
        <p class="data magic">Magical data</p>
        <p>Normal text with <span class="magic">magical <span class="data">data</span></span>.</p>
    

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.

