A Word About CSS4(xanthir.com)
xanthir.com
A Word About CSS4
http://www.xanthir.com/b4Ko0
33 comments
Using an example from the article:
> Others start out at level 1, if they're something new (for example, Flexbox
"CSS Flexbox level 1" is a fair bit less confusing than "CSS1 Flexbox model". It would get even worse if a module moved to level 2.1!
> Others start out at level 1, if they're something new (for example, Flexbox
"CSS Flexbox level 1" is a fair bit less confusing than "CSS1 Flexbox model". It would get even worse if a module moved to level 2.1!
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.
But that’s always how it was. They just decided to make the standards process officially fit what happens in the real world.
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).
HTML -> DHTML -> HTML5
JavaScript -> AJAX
CSS -> CSS2 -> CSS3 -> ____ -> Profit?
HTML -> DHTML -> HTML5
JavaScript -> AJAX
CSS -> CSS2 -> CSS3 -> ____ -> Profit?
Oh god how does Javascript become AJAX?
AJAX is largely part of DOM, it's just some http callbacks your browser provide to Javascript.
AJAX is largely part of DOM, it's just some http callbacks your browser provide to Javascript.
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.
Also, wasn't DHTML just HTML+JS?
DHTML was just a way to sell books with 'DHTML' in the title.
I just wanted to point out that this guys site is all messed up on my iPhone. CSS problems basically. But I'm sure he's really good as CSS...
And what's with all the troll comments on his page? Looked like reddit got there first. I laughed.
And what's with all the troll comments on his page? Looked like reddit got there first. I laughed.
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.
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.
Yup my 4S sure feels old. Sure wish I had a modern browser like IE9 on there. Blast!!
CSS3 will inevitably reach some kind of EOL eventually. If there will never be a CSS4, what will take CSS's place?
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.
>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.
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.
But hey, nice attempt at trolling.
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.
But hey, nice attempt at trolling.
This post exhibits everything that is wrong with standards bodies.
Why?
Nothing of the sort actually.
On the contrary, it shows how by breaking things into smaller modules instead of a monolithic one, they got things moving along faster.
On the contrary, it shows how by breaking things into smaller modules instead of a monolithic one, they got things moving along faster.
>they got things moving along faster //
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?!
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?!
>We can't really be sure of that can we.
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).
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).
>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. //
In CSS2 there are about 500 or so different things that you'd need to list (http://www.w3.org/TR/CSS2/indexlist.html).
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.
In CSS2 there are about 500 or so different things that you'd need to list (http://www.w3.org/TR/CSS2/indexlist.html).
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.
Who's involved in the CSSWG? How does one become a contributor? Who are our CSS overlords?
Seriously? I'll even skip the lmgtfy:
http://www.w3.org/Style/CSS/members
The mailing list is open to the public. If you do decide to participate, please treat it as you would when joining any long-standing forum.
http://www.w3.org/Style/CSS/members
The mailing list is open to the public. If you do decide to participate, please treat it as you would when joining any long-standing forum.
Lets call it CSS ∞ then!
Good because I am sick of hearing about it anyway - almost as sick as hearing about the glorious "someday soon" of HTML5.
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.
Thinking about going that route myself. Do you use html5shiv?
No.
Also, you mean shim I think.
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.
Also, you mean shim I think.
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.
No.
The name is html5shiv, and it is something you fashion out of javascript and shove into the guts of IE.
The name is html5shiv, and it is something you fashion out of javascript and shove into the guts of IE.
What difference does it make if someone uses the term "CSS4 Selectors" instead of "CSS Selectors Level 4"???