This is not a joke.
This is the same reason why there will be no HTML6. There will just be HTML moving forward. The 'level N' stuff is just for the W3C to keep track of which 'code sprint' (if you will) they are on. The the end-dev, he can just think of it as CSS moving forward.
We know that most browsers couldn't hit a single standing target of a spec. So in order to fix the problem we've made multiple specs that move independently, and at various speeds.
There's no CSS4 right now, but eventually it will get a version bump or they'll draw a line in the sand or the community will select a new term that will come to mean the new set of functionality (even if it's not an official spec).
I'm not saying that I think that those are the technically accurate terms (they're not). But that's what they're called. It's what sells books and causes articles to trend.
If there are any problems, it's because you're using an old browser. (As far as I know.) The iPhone browser definitely counts as "old". ^_^
In particular, a bunch of browsers don't support specifying background-size in the background shorthand yet. It's in modern WebKit, but that hasn't trickled down to mobile versions yet.
It's just nomenclature; CSS3 will eventually just become "CSS" and each module will move forward on its own. And they're really just codifying what was already happening: browsers never jumped from CSS1 to CSS2 or CSS2 to CSS3; they just added support bit by bit.
I imagine that, in part at least, is because the standards have taken so long to be codified.
We've been calling it CSS3 and it's been implemented gradually in browsers but it's still a working document and not a finished standard (and now it seems never will be).
The pace of required changed for the needs of web page production and rendering is faster than the pace of the standards confirmation.
If this is just to address this issue then why not have "selectors 3", or whatever, as a part of a point release.
Despite there being obvious confusion over the css4 selectors, I'd bet they make zero effort to rename, thus clearing up confusion for all the folks who don't follow up with CSSWG.
You, um, know that Selectors is one of the few specs without naming problems, right? Its url is "selectors4".
As well (partially as a result of me writing this blog post), we're looking into changing our URL structure, which was originally settled on a decade ago, before we knew how we were going to do this "module" thing.
We can't really be sure of that can we. What we can be sure of is that there's no way to summarise the CSS standards compliance of a browser or to indicate concisely the browser level requirements of a website for a human. This I fear makes designing for the web a case of breaking down and designing for lots of individual UA that meet a list of hundreds of different point versions for different abilities instead of being able to simply design to a standard HTML5+CSS3 and readily see that the top X browsers will support (with some issues of course) the elements of those standards.
Instead of one current standard there are now hundreds of standards?!
No, but we can be sure that conceptually it's far better than the monolithic practice, which has been shown in the past to slow down the standardising process.
>What we can be sure of is that there's no way to summarise the CSS standards compliance of a browser or to indicate concisely the browser level requirements of a website for a human.
That was always true. I mean, we might have had a "way to summarise the CSS standard compliance", as in "this browser is CSS 2 compatible", but we never had a 100% compatible browser for any previous version. I doubt we still have a full CSS2 compatible browser engine, so so much for summarizing.
Now, it could be easier: we could have a browser that is 100% compatible with A, B, C, D CSS modules and lacks in X, Y, Z.
It's not like developers care about the overall compatibility. What they do care is "can I use this or that feature?". To say "this engine is 90% CSS3 compatible doesn't answer that". Only 100% compatibility would answer those kinds of questions ("yes, you can use ANY feature").
So, they way to summarise compliance will be, as it is the practice anyway, with some list of CSS features and Yes/No tick marks. And for some things, with the knowledge that for that module the engine has 100% compliance (easier to achieve than the ellusive 100% compliance over ALL modules).
I dispute that people care about 100% compatibility.
>So, they way to summarise compliance will be [...] some list of CSS features and Yes/No tick marks. //
I think you misunderstand the meaning of "summarise", "this engine is 90% CSS3 compatible" is a summary. Quirksmodes tables - http://www.quirksmode.org/css/contents.html - whilst useful during development aren't really something you can put before a user as an equivalent to an "HTML5" badge.
We use HTML5 prolifically. It's a calculated decision, precious few of the people who visit our site/use our apps use anything that doesn't support core HTML5.
A shiv is something you fashion out of a toothbrush and shove into the guts of somebody that mouthed off to you in the cafeteria in cell block A last week.
What difference does it make if someone uses the term "CSS4 Selectors" instead of "CSS Selectors Level 4"???