Re #24: You are right saying there is no such thing as CSS3. I was going to say exactly that until I saw your comment.

There is, however, a thing called "Modular CSS", which is made of modules, and those modules have a "level". And the level of most (although not all) of those modules starts at 3. And that merely reflects the fact that the earlier levels of those modules were just parts of the monolithic specs.

There is a thing worth calling CSS3. And also something that deserves the name "CSS4".

CSS3 can be understood as the CSS modularization effort. Let's look back a bit:

CSS1 was the "font-killer" (it'd allow us to kill the font tag). It was also the first attempt at separating structure from presentation. If you look deeply at it, its feature cover pretty much the same ground as HTML3.2's presentational elements.

CSS2 (2.0 to be exact) was an epic fail. Not of the spec on itself, but on the W3C process that was being followed then. There are more aspects of CSS2.0 (essentially, it was aimed at replacing not the purely presentational elements, but the presentational use of structural elements), but in the end it became the nonimplemented, unimplementable CSS spec. CSS2.0 achieved something: it highlighted issues on the W3C process that are now fixed (and those fixes brought some of the modern issues, but more on that later).

CSS2.1 was the ammendment to the disaster. It could have been called "Implementable CSS2", but that would have sounded awful. Its grounds were the same as for CSS 2.0, essentially a tool to erradicate the need of presentational use of HTML tags. In that regard, it was a partial success.

success. CSS3 is a realization that the presentation needs for the modern web are simply too much to be covered by a single spec.

CSS4 is... well, I'm not sure what exactly what CSS4 would be. When we look at the "level-4 generation of modules", there seems to be a trend. Once we see what is that trend exactly, we will be able to describe what CSS4 is.

The bottom line is that, while from CSS3 onwards the number no longer refer to a specific version of a specific specification, the numbers still have a meaning.

Maybe something like CSS 2007, CSS 2010, CSS 2013, etc could work better. But it doesn't :(

Now, addressing your question: when will "JUST CSS" be available? Short answer is: it's already available. We have been using CSS for over a decade! But I'll try to answer to what you wanted to know rather than to what you asked.

An attempt was started, back in 2007, to document the current implementation status of CSS features in a "snapshot" spec. The document was titled "CSS Snapshot 2007". I'm sure you know about that document, and about the similar "CSS Snapshot 2010". Actually, those are more than similar. They gather exactly the same features, by virtue of referencing the same list of specs in their definition of "what is CSS as of year". The 2010 note is just a bit longer because it includes a couple of indexes (for properties and selectors), but other than that they are identical.

And here goes a painful fact: that effort, started in 2007, didn't become stable until 2011. CSS 2.0 is the culprit of that. Because of the disaster 2.0 was, the W3C process was updated to include strict interoperability testing. Going into the fine letter, the process requires "at least 2 independent interoperable implementations" before it can become a Rec. Getting a couple of major browsers to implement some stuff ain't that hard (actually, they implement some stuff even before it gets spec'd!). Testing that those implementations abide to the spec... well, that is tough work.

Before a spec (be it a "snapshot" or a new module) can get the "Rec" stamped on it, implementations need to exist and be tested. Which means that a mechanism to test implementations has to be available. That mechanism is a comprehensive test suite and it is the biggest slowdown within the W3C process.

Hence we are now at a crossroads: a mechanism to test implementations is needed to avoid repeating the CSS 2.0 disaster. But the mechanism currently in place is so expensive (in terms of development effort) that is making the W3C lag behind actual browser support for new features.

If you have any contribution on how to speed up that process, I'm sure the folks at the W3C will be glad to hear it.