Slashdot Mirror
HTML5 Splits Into Two Standards
mikejuk writes "Until now the two standards bodies working on HTML5 (WHATWG and W3C) have cooperated. An announcement by WHATWG makes it clear that this is no longer true. WHATWG is going to work on a living standard for HTML which will continue to evolve as more technologies are added. W3C is going the traditional and much more time consuming route of creating a traditional standard which WHATWG refers to as a 'snapshot' of their living standard. Of course now being free of W3C's slower methods WHATWG can accelerate the pace of introducing new technologies to HTML5. Whatever happens, the future has just become more complicated — now you have to ask yourself 'Which HTML5?'"
So when browsers claim to be fully HTML5 compliant, will that even have any meaning anymore?
The one supported by by Webkit and Gecko?
and I wanted to moderate this story down for its appalling failure to call W3C "W3C" two times out of three.
"Living standard" is kind of an oxymoron. The whole point of having a standard is so that authors have something to target, and developers know what is necessary to be standards compliant. A constantly evolving standard creates a moving target, which I believe is actually counter-productive.
The whole world should slow down. Stick with a stable standard for a while. And relax.
What better way for Google to control the web than to keep pushing the standard foward so it turns out Chrome has the best support for everything first.
Microsoft failed to try and conquer the web by creating their own standard and my fear is google just figured out how to do it out in the open by always changing it.
A standard is a standard. It is not a moving target. That is its whole point.
Other things that are mandatory for a standard:
- simple (or as simple as possible)
- clear
- easy to implement
I think this just killed HTML5, because now it will become a complex monster that basically is never ever compatible with anything. Funny how history repeats itelf because people are too stupid to learn its lessons.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And with HTML 5 it is bad enough already. The standard is so amazingly complex that none of the browsers seem to have the same idea of how to support it. Things that will work in one don't in another, or they work less well and so on.
My favourite example is the HTML 5 Angry Birds game. In Chrome, it's "recommended browser" (something that shouldn't ever be necessary) it runs fast, and full featured, but Chrome seems to 'asplode on it randomly. Firefox is stable with it, but no sound/music, just visuals. IE is stable and has sound, but runs a bit slower than the others, it can't maintain 60 fps. This is even given that they've done work to make it work on all platforms.
So how about let's fuck off with new HTML standards until we have non-fucked up 5 implementations in at least most of the browsers. Then maybe we can worry about something new.
"Today we have phones like my Andriod as well as IPhones that give a much better browsing experience than my desktop?!"
Are you having a laugh? The browsing "experience" on a smartphone doesn't come anywhere close the what I have on my dual 22 inch desktop monitors. If you seriously think that can be replicated on some rinky dink 3 inch screen then you must have problems with your eyesight..
"On my computer it flickers unless I use IE 9"
Then your computer is a piece of junk. Go and buy one built in the 21st century.
"Why should the best experiences be only for phone based applets?"
Errm , you do realise that applets are programs, not web pages?
"HTML5" is a marketing buzzword, just like "Web 2.0". HTML 5 is a loose coupling of emergent technologies which is in a constant state of flux as new shiny stuff is added by the competing browsers (Internet Explorer is not one of these). 'Twas ever thus that new things appeared hoping to be part of the standard - either by saturation or by conscious decision - before the standard is declared. This is nothing new.
"Wait. Something's happening. It's opening up! My God, it's full of apricots!"
I agree with you, but that is not what everyone seems to want. They all talk about local storage, and web cam access and this that and the other thing that they get access to from the OS.
To me, it just seems like they want the browser to be an application, not just a way to display information. This is just going to create a number of new viruses as we give the web more and more access to our actual OSs.
This is just stupid, and a terrible idea.
Fun fact: modern graphics cards don't support pre-emptive multitasking. This is why Bitcoin miners have a setting which controls how long the app holds the card before yielding. Set it too high and your desktop basically hangs. Now imagine every web "designer" out there being able to do the same thing.
Also... why would web apps need 3D? Very few desktop apps have any use for 3D. Almost all applications deal with things that simply don't map to spatial relationships at all, much less to 3D space specifically. Add the increased resource consumption per page (which makes it harder to do heavy multi-tab browsing) and harder navigation (because 45 degree field of view to 3D space is simply inferior to a flat page that scrolls down in almost all situations), and I for one hope that 3D stays out of HTML for years to come.
But, even in the case that someone could come up with a compelling case for 3D, why would the web pages need direct access to the underlaying API when even game developers use middleware engines nowadays?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
This should have been the method from the beginning.
I'm sick of you people moaning that a "moving standard" is backwards.
You should be detecting working features before you even use the damn things in the first place. It is standard practice to prevent any damn errors from happening.
Anyone against this is showing their true colors as a developer. (and I don't even do it all the time myself! So, yes, I am a hypocrite at times!)
Every browser is different. It is the fault of the W3C and their terrible system of MUSTs and MAYs or whatever the hell they use now.
They weren't strict enough and now that has left us with every single browser working differently with CSS rules for JavaScript, it has given us HORRIBLE input management, it has given us quite inconsistent DOMs across every browser at the lowest levels, and many others.
Don't even mention library or your monitor will become a fist.
Libraries to cover up W3Cs mistakes should never have been tolerated! EVER!
So don't even dare sit there and say "we need solid standards!", I don't think there is a single browser out there that is 100% complete and actually accurate with every standard. Not even Opera.
WHATWG are giving people who actually give a damn about web development what we want.
W3C are old farts sitting on their rocking chair listening to a radio and shouting out the window at the kids.
They are the ones who use the scroll bar to scroll things instead of using a scrollwheel.
They are the ones who take about half a century to read the damn start menu.
Everybody already doesn't care about the limited crap setup by W3C. Well, those of any worth.
W3C ruined the web tech front. Absolutely ruined it.
They can keep their limited crap. No other industry in computing does this. It is either feature versions or a free-for-all. HTML, JS and even CSS are improperly labeled in one group all the time.
Speaking of that, where are the CSS versions? Why is nobody complaining at that? Eh? Where are your words now?
CSS already is this. It is literally a cascading standard, to use its own name. Its use, the use of attributes, they grow and die as the web evolves.
This works well, there are no problems with this. (except IE as always)
So why the complaints now? You can't select your CSS version. I don't think any browser even supports selecting JS versions anymore since nobody cares about it.
Why does a bloody markup language have to be any different? Why do features that have pretty much no relation to each other have to be slapped in with each other under some global header as "HTML5"?
I don't think it's that simple, part the problem is browser manufacturers vs. everyone else. The fact is whilst mainstream browser manufacturers often seem like the only entities who should care about HTML, there's actually more to it than that.
The impact of HTML standards development has relevance to other developers too, think how many applications export to HTML, do not underestimate how many business systems scrape websites and import HTML. Think of all the people who have to author and develop with and for HTML.
Effectively WHATWG was a coup, it was a hijacking of the standards process by the browser manufacturers. Presumably they got tired of having to deal with everyone else having a say as they do in the W3C and just decided to try and go their own way. Their criticism of W3C was that it was slow in the creation of new web standards, but who exactly was behind the failure to implement many existing standards properly, and newer W3C standards at all which was in part a major factor in that? Er, the browser manufacturers.
I'm not at all convinced it's a good thing so far, the HTML5 process seems to have been a bit of a shambles and some important areas have been overlooked and grossly neglected in the new standard (e.g. accessibility).
Sory to post this here, but it seems that SLASHCODE'S CSS HAS CHANGED IN A WAY THAT IT NO LONGER OBEYS CHROMIUM'S MAGNIFICATION COMMAND.
I am sight impaired and CANNOT READ unles with high magnification.
Please fix this!
You should probably email feedback at slashdot.org (see the footer of this page) instead of posting this in a random thread; maybe they can fix it for you.
Part of the reason we've had a good level of interop on the web in the last ten years is because HTML4 didn't evolve. We need to do the same with HTML5, have a document that can remain unchanged for ten years at least, so that the web as a whole can sync up to the same document.
However, IE 6's box model that people hate started because the W3C finalized version was different than the one the IE team started implementing just weeks before its release.
I'd just like to point out that the IE6 box model is fucking awesome. What people hate is the W3C box model, because it's utterly moronic and illogical.
W3C: element width = content width; border and padding not included
IE6: element width = border + padding + content width
Imagine a real, physical box. Put something in it. W3C says the dimensions of that box are the dimensions of your object. IE6 says the dimensions of that box are the dimensions of that box.
With the crazy W3C box model, if you want to do something as simple as floating two elements with 50% width, you *have* to make them containers and include extra markup. You have to do that even if you don't have borders and padding right now, because eventually you might have.
Basically, you'll have containerLeft and containerRight, both float: x, width: 50%, and both of them will have to include containerLeftContent or containerRightContent, which will then have border and padding set, so your layout doesn't blow up... But it'll be harder to read and maintain, because you'll have "divitis" all around and your CSS will be more complicated than it needs to be.
Enter the "box-sizing: border-box" CSS3 property+value, implemented in all browsers since quite some time ago, which reverts the internal rendering processes to IE6 emulation -- in other words, sanity. Many people even go so far to include this at the beginning of their CSS:
* { box-sizing: border-box }
There are many things that IE6 did wrong, but the box model just isn't one of them.
The web browser interoperability in the last few years (after IE6) is a product of the WHATWG standard, that started in 2004 (it wasn't called HTML back then). Just an example: HTML 4.01 doesn't specify a way to parse HTML that actually works and doesn't specify at all how to handle errors. The result is that every browser had a slightly different and incompatible parsing algorithm. Let me make this clear: no browser ever implemented HTML 4.01. Not a single one of them. Because HTML 4.01 was extremely buggy and unmaintained. It caused the IE6 era. The HTML5 draft on W3C is less buggy but still severely incomplete, stopping making major changes just means that all browsers vendors are completely ignoring the HTML5 from W3C and going instead for the HTML standard that's actively maintained and updated.
There's a hidden treasure in Python 3.x: __prepare__()
> but in reality they were merely failures by the browser
> vendors to properly implement the spec.
They were failures caused by the spec being deliberately written to not match behavior of already existing and deployed systems.
The point of standardization is generally to take a bunch of stuff that's going on already and reconcile it so that people all do it the same way. What that _usually_ means is that if they're all doing it the same way already, you just spec it that way unless there are incredibly important reasons not to (e.g. it's a security flaw, in the browser space). It doesn't really work for the spec to forbid behavior X if there are already lots of existing deployments that depend on behavior X.
But development of HTML at the W3C had a tendency to see the spec as a club, not as a way to get everyone to agree on the same thing. Which is slightly backwards.
> There's nothing in the HTML4 spec that couldn't
> be implemented properly
If you actually implemented parsing of HTML4 the way the spec required at the time it was written, you would fail to parse many web pages of the time "correctly" (as in, in a way that would actually render them the way they were expected to be rendered by their authors).
That's not to mention that the spec didn't actually define the parsing of many other web pages (indeed, most of them). Which is a bit of a problem if the point is to actually achieve interoperable behavior.
This was the usual problem with HTML4, in fact: it was written in a way that was impossible to implement interoperably without reverse-engineering another browser, because it left so many critical things undefined.
> Why is this a problem?
Why is it a problem that a single program can't implement both HTML4/XHTML1 (which are basically the same except for the XML syntax for the latter) and XHTML2? It's a problem because it meant that there was no deployment path for XHTML2: no browser could actually implement it correctly without breaking their HTML4/XHTML1 support. And they had absolutely no incentive to do that.
> I believe most browsers have implemented XML
> rendering now anyway?
Sure, but the "XML" bit wasn't the problem with XHTML2. Things like "assign different semantics than XHTML1 to the same namespace+localname pair" were a bit more of a problem.
> simply writing off those interested in true
> separation of concerns as pie-in-the-sky projects
No, I'm writing off the particular _approach_ they took to that goal as a pie-in-the-sky project.
In particular, the project was structured as follows:
1) Create a new version of HTML that no existing browser can implement without dropping support for the old version of HTML, the one that lots of sites already use.
2) ???
3) New version of HTML replaces old version on the web and life is good.
Step 2 was never really addressed, which was the problem. There were lots of good ideas in XHTML2, but the particular way they were being put into practice was completely unrealistic.
But maybe I'm missing something. If you were involved in the standards process at the time, perhaps you happen to know what the actual deployment plan for XHTML2 was? I certainly never heard one.