HTML5 Splits Into Two Standards 395
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?'"
The great thing about standards (Score:4, Funny)
There's so many to choose from.
Re: (Score:3, Funny)
I like how the first post is redundant.
Back on topic, the editor of both docs wrote this: (Score:5, Informative)
Ian Hickson is the editor of both docs (he's actually the editor of the main HTML standard, the WHATWG one; the draft hosted by the W3C is really nothing more that an old and incomplete copy that nobody among browser vendors takes seriously).
He explained very clearly the past and current situation: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0119.html [w3.org]
And, yes, the WHATWG has done an excellent job so far, bringing much needed features to the web and creating an era of faster and more interoperable browsers. If they had just waited for the W3C we would still be stuck with HTML 4.01, IE6, Flash and other plugins.
Also this is not a new development, HTML (from WHATWG) has started gradually leaving the HTML5 (from W3C) behind a long time ago. Where the two differ, all major browsers (including IE) either already follow HTML or plan to. See this post from more than a year ago: http://blog.whatwg.org/html-is-the-new-html5 [whatwg.org]
When people talk about HTML5 features in browsers and websites, they actually refer to the HTML standard. The HTML5 "working draft" on the W3C website doesn't even support the old 2D canvas API, which is implemented by all browsers!
Re: (Score:3)
* - Backward compatibility is what users need, forward compatibiliy is what users want, and they will get it when the first software dev g
Re:Back on topic, the editor of both docs wrote th (Score:5, Insightful)
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.
Quite the opposite (Score:5, Insightful)
Re:The great thing about first posts (Score:5, Funny)
In Soviet Russia, here's you.
Re:The great thing about first posts (Score:5, Funny)
In soviet Russia, the standard chooses you!
In soviet Russia, the standard forks you!
Re:The great thing about standards (Score:5, Funny)
I'm sure this was not intentional, but your message reminded me of one of my favorite Trek episodes in the alternate "evil Kirk" universe (quoting from memory):
Miles O'Brien says: "Great. Captain Sisko, Captain Bashir, Captain Kira..... we've got plenty of captains to choose from, but no damn ships!"
.
And in about two years we'll be saying : Browser Explorer, browser Chrome, browser Firefox, browser Opera..... I've got plenty of browsers to choose from, but not a damn one works! Stupid "living" HTML standard!
Re:The great thing about standards (Score:5, Interesting)
Obligatory xkcd (I can't believe it's not linked yet): http://xkcd.com/927/ [xkcd.com]
Re:CANT READ SLASHDOT ANYMORE (Score:4, Insightful)
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.
Re:CANT READ SLASHDOT ANYMORE (Score:5, Funny)
He would... if he could see where he was..
Dumb idea. (Score:5, Insightful)
So when browsers claim to be fully HTML5 compliant, will that even have any meaning anymore?
Re:Dumb idea. (Score:4, Insightful)
We will have a full description for each standard - only 5a & 5b at first, but then those will both fork to make HTML5aa, HTML5ab, and HTML5ba, 5bb. Won't that be a wonderful time to develop web pages?
BUT WAIT, it gets even better. Each of the teams who develop those standards will fork, and we'll get 8 new GLORIOUS standards. Already, I'm drooling at the prospect of the return to the IE6-like era where we can develop for multiple HTML flavours again. It will create so many new jobs and so much specialist knowledge, it can't fail to improve the economy!
Re:Dumb idea. (Score:5, Insightful)
It will create so many new jobs and so much specialist knowledge, it can't fail to improve the economy!
Ah, yes, that's it, they are trying to institutionalize the Broken Window Falacy [wikipedia.org].
Personally, I suspect the term "Living standard" is code for we don't want any standards we can't subvert, and we want the freedom to pack in as much
proprietary crap as we can and go after patent license fees down the road.
This can't help but lead to IE6 all over again.
Re:Dumb idea. (Score:5, Insightful)
Is Microsoft, by chance, involved in WHATWG?
Not really. This sort of madness is driven by the same fools at places like Google and Mozilla who think pushing a new update every six weeks is a good idea.
One day, they will notice that most real developers on real projects can't and don't want to keep up with that kind of unstable foundation.
One day, they will notice that most users don't like being hassled every few weeks by their browser update mechanism or their UIs forever moving around in subtle (or occasionally not-so-subtle) ways.
One day, they will notice that the only people in the industry who actually like the rapid releases are people making cute demos on blogs, people at the aforementioned Google and Chrome who are comparing anatomical measurements, and people who want to be one of the above.
One day, they will acknowledge that their quality control processes are demonstrably not up to the job of supporting such rapid releases, and they do keep breaking things, and those things aren't always minor details you can get away with for another six weeks.
One day, they will acknowledge that quite a few of the minor things that break are actually their prototype implementations of whizzy new features, which means developers of real production projects can't use those whizzy new features even on browsers that support them, which entirely defeats the purpose of pushing out new features at such a breakneck pace in the first place.
Until then, most of the projects I work on will continue to recommend that our professional customers use IE, and IE will remain the only platform that we will contractually support, because unlike nonsense like "living standards", it is a reasonably stable platform that we can test against to a professional standard. And that matters a lot more to both us and our clients than supporting this week's proposal for a multi-resolution-friendly <img> tag that only works on Chrome cloud cuckoo channel.
Re:Dumb idea. (Score:5, Insightful)
Six weeks is not really an unreasonably short release cadence, unless you work for a defense contractor or something.
Re:Dumb idea. (Score:5, Interesting)
One of the biggest challenges we have is trying to deal with the slew of constant updates to dozens of applications, all of which seem to break in subtle ways. Testing a large application for browser compatibility is a royal PITA, and every time one goes through you end up having to come up with a new set of workarounds for small bugs and explaining why the old set of workarounds isn't needed anymore.
Or you can just do what we do, which is freeze all your applications for a specific build every semester or year, then carefully turn off every farking updater to stop the blizzard of login messages you otherwise get socked with. But then you get people wondering why you still have machines running Firefox 3.6
Re:Dumb idea. (Score:5, Insightful)
But it is an unreasonably short update cadence for the user. You have totally missed the parent's point - people don't want to be updating their software every six weeks. For the home user, this is an annoyance. For the SMB or enterprise, this is a nightmare.
Just because you can release new features every six weeks doesn't mean that you should. As the parent said, this seems to be more for the "gee-whiz" factor than anything else. That, or some well intentioned soul doesn't understand that flooding the user base with software updates doesn't really equate to a good experience.
Re:Dumb idea. (Score:5, Insightful)
It doesn't help that they don't even seem to know what's in each release themselves. Case in point, I loaded up Firefox yesterday and it asked me if I wanted to install a security and stability update, so I clicked yes and it installed... ...but if it's just a security and stability update, why the fuck has my user interface changed? Were the old back/forward and home buttons a security risk then? Thanks Mozilla, for lying to me about what was in the update.
Honestly, if they can't even tell what they're putting into each patch there's really little hope for the process.
Re:Dumb idea. (Score:4, Insightful)
But your entire argument is undermined by how buggy IE has historically been. Despite all of that QA, they've never managed to fix some quite serious bugs.
While there's truth to your argument that updates should be less frequent, I don't think IE should be the standard you're using for quality.
Re:Dumb idea. (Score:4, Insightful)
The thing is, if you take a step back and look at the facts objectively, recent versions of IE actually have a pretty good track record for quality (and security, for that matter). Sure, you can go back to the IE6 era and point plenty of fingers, but then again you have to remember that some "bugs" in IE6 are really behaviours that hadn't been effectively standardised yet when IE6 was released; it predates CSS 2.1 by several years, for example. And of course, IE6 is more than a decade old. Criticising Microsoft's track record for having bugs or security vulnerabilities in IE6 is like criticising Mozilla because Netscape 6 wasn't their finest hour or condemning Apple for having weak support for the Web in MacOS 9 before Safari even existed.
Meanwhile, if we're looking at the situation today rather than historically, Firefox and Chrome both have appalling quality control. Since the six-week-release era, they've broken basic rendering and they've broken popular new CSS3 features like rounded corners and shadows. They've broken major third party integrations with Flash and Java, and they've broken the new HTML5 shinies that are supposed to replace them like the <video> and <canvas> elements. In several cases, they have compromised their design or don't even respect the basic architecture of the Internet in their never-ending quest to squeeze every last millisecond of performance out of your system, which is fine right up to the point where their caching just plain gets it wrong and what you see isn't the content you were supposed to see, or their direct integration with plug-ins allows something to block their application UI thread and the whole damn browser locks up because someone's AJAX request blocked one of the tabs.
So as surprising as it may seem to those of us who have been around for a while, looking at the issue today, based on the empirical data we have for bugs and effort spent fixing/working around them on various projects I'm involved with, I do currently use IE as my benchmark for browser quality. Moreover, I am 100% confident that for the features we're actually using, even recent trends around CSS3 and HTML5, IE clearly has superior quality to either Firefox or Chrome. Of course it's always possible that the selection of projects I'm talking about has been exceptionally unlucky and hit a huge number of corner cases, and I certainly won't presume to speak for every other project I don't work on...
Re:Dumb idea. (Score:4, Interesting)
We routinely test all of those projects I mentioned with all of the major browsers.
IE9 is actually the only big hitter that has never crashed on us.
YMMV, plurals and anecdotes and data, etc.
Re:Dumb idea. (Score:5, Interesting)
Here's the thing: For years now, the rest of the industry's been held back by the "Business environment". Blackberry, IE6, Windows Servers and the like... Stable features, rarely updated (say, every couple of years or so if you're lucky), and a concrete environment for multi-year projects to target.
Now, we have an entirely different ethos trying to compete - the rapid-fire consumer-oriented model of iOS, Android, Chrome and the rest. This is all about eyeballs, because they're not pitching to Joe CTO who needs 2 years to complete his project, which should run for another 20. The audience in this case is the man or woman on the street, who will jump to the next shiny thing in a heartbeat, because the investment is really not that high.
The first method leads to stagnation - we've lived through that... The second leads to instability. That too, we've seen. It remains to be seen, how this will be balanced out as time goes on. Because this isn't going away anymore.
Re: (Score:3)
No no no, you misunderstand. The whole idea of a "living standard" is that you have no way to refer to revisions b, ba or bb, but rather just have to hope that the browser will guess the intended meaning of your markup correctly. Which it probably won't, being roughly as intelligent as a particularly retarded earthworm. But I guess failure is part of being
Re:Dumb idea. (Score:5, Funny)
I think the specific definition of "Living Standard" in this context represents a standard that can effectively duck and weave as they throw assorted crap at it. The idea of a more passive "Dead" standard just taking it in the face (as it were) seems unsportsman-like and vaguely cruel (certainly less entertaining!)
Re: (Score:2)
Since the dawn of the web, from the perspective of a user, it's been somewhat hit or miss whether any given website would work with the browser the user was using at the moment. Now we're just codifying it in terms of an un-standard. I'm not sure why it's a good idea to split with the standards group "because they're too slow" when it takes years to get full support in all browsers as it is.
3D? Cameras? Microphones? (Score:2)
There are huge areas for improvement in web apps. There is no good way to do 3D. A web app should have direct access to an OpenGL. HTML5 can play audio (usually poorly) but there is no API for recording it. There should be a way to interface with cameras, etc. But all of this belongs in HTML6.
Re: (Score:2)
It sounds like you want HTML 6 to replace the desktop. Considering the different OSes out there this may be an unrealistic goal. In general a web browser is designed to retrieve and display information from other computers. It is not designed to record information on one's own computer. We have much better applications for that and it does not require stuffing everything into one box.
Re: (Score:3, Insightful)
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.
Re:3D? Cameras? Microphones? (Score:5, Interesting)
PLEASE take everything media related OUT of my browser. Text, links, thumbnails and CSS for basic layout management is ALL we really need. In fact, I'd like to go even 1 step further and take layout management away from webmasters as well. Why should THEY get to decide how the menus work and the site navigation is layed out. This is one of the reasons why RSS readers are so nice, every website's feed uses the EXACT same interface and you NEVER have to try to figure out where they hid the menu or the contact page.
Webmasters should compile the data into a basic heirarchy of XML with some predefined fields for contact information, navigation menus and search features. Leave the layout management to the user because THEY know what they want, you don't.
Re: (Score:3, Insightful)
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 sim
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
Re:3D? Cameras? Microphones? (Score:4)
A trivial Google search would have found the information before you posted (sorry to point this out, but damn, I had to revert mod points to make this post).
Re: (Score:3)
In HTML23 you'll have tags for elective genital origami or macrame! Oh, the unadulterated power!
Re: (Score:2)
Well, the HTML5 standard is so big that I have my doubts that any browser will comply to the entire thing. And nothing will even come close for something approaching a decade I hear.
Re: (Score:3)
Re:Dumb idea. (Score:5, Informative)
However, HTTP requests include a mime-type header that describes the type of document being requested. Currently all HTML uses the same mime-type of "text/html", but there's no reason a HTML5 "text/html5" mime-type couldn't be agreed on.
Re: (Score:2)
Re: (Score:3)
Ouch, you're absolutely correct. What a silly mistake to make :(
Newsflash! HTML5 fork now an official Google BETA (Score:5, Interesting)
"Living standard"? Perpetually unfinished with no accountability for stability, is more like it. Didn't Google patent that?
What a monumentally bad idea ...
Re: (Score:3)
It's how the human mind & language work... Just sayin'.
...now you have to ask yourself 'Which HTML5?'" (Score:5, Insightful)
Re: (Score:2)
Judging by the spelling error up there we'll need to use one of the Wing Commander games to view the content.
Re: (Score:3)
Those F'in bastards. Yet ANOTHER reason why google is on my boycott list. There's absolutely no reason Opera 11.6 can't render this website..... too bad they don't have a "mask as chrome" option like they do with IE and FF.
http://www.exquisiteforest.com/ [exquisiteforest.com]
"Your browser does not support this site. Try Google Chrome." Oh go shove it up your ass Microsoft clone.
I have mod points (Score:5, Insightful)
and I wanted to moderate this story down for its appalling failure to call W3C "W3C" two times out of three.
Re: (Score:2)
How can a standard be "living"? (Score:5, Insightful)
"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.
No shit (Score:5, Insightful)
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.
Re:No shit (Score:4, Informative)
It's because WHATWG has shown nothing but complete ineptitude throughout the standards process and he is simply not fit to be writing any kind of standard, the simple fact is that they (or at least grand dicator Ian Hickson) just doesn't understand what standards are meant to achieve, and how they should reasonably achieve them, let alone the merits of the various specific elements of the standards themselves.
One obvious example that's brought us to this point - the semantic HTML tags are less than useless, because they're based on a now obsolete statistical analysis of common ids/classes. Obsolete because it was done before Web 2.0 was all the rage, meaning prominent ids and classes such as "comments" are now completely left out. The solution? well, it depends who you ask. Some say you should just go back to divs for things that aren't defined, others say you should use something like "article" for a comment, which frankly completely dilutes the meaning and completely destroys any semantic worth of "article" if an article tag isn't necessarily strictly really an article anymore. Effectively you can't infer any meaning from the semantic tags anymore because it's such a fucking hash up as to what they're even going to mean due to different people going different ways on them as a result of their lack of relevance to much of the modern web. This is of course besides the fact that some prominent browsers such as IE7 and IE8 don't even recognise them and so the whole blocks wont be rendered as such using these tags. There are Javascript hacks for browsers not supporting them, but then you're assuming everyone's Javascript is enabled. It wouldn't be so bad if it weren't for the fact that the ARIA attributes actually do a far better job of defining semantics, and show how a separate spec such as ARIA would've actually been a more sensible route in the first place. Separation of concerns- even better, semantics should've been defined just like styles are, in external sheets, so that you get all the benefits of that - maintainability, reusability, no effect on backwards compatibility, the ability to define externally for no longer maintained sites and so on. Similarly other issues, such as a complete and utter failure to provide any worthwhile result on a standard for the video tag and so on are why we have this news article.
So here we are, with his living standard. The whole fucking reason Ian Hixon has had to go down this route is because he royally fucked up the spec in the first place, wont admit it, but now realises the only way to make HTML5 stay relevant regarding things such as semantic tags, is to make the spec "living" so that he can update these things. The problem is, if a spec is living it's not really a spec, it's a set of guidelines at best. A spec should be something you can conform to, and not worry about it changing on you so that you no longer necessarily conform to it in the future because it arbitrarily changed.
There's no doubt the W3C was slow, but it was slow for a reason, it represents many hundreds of companies (http://www.w3.org/Consortium/Member/List) from all walks of life that make use of the internet. It was representative of everyone's needs, it took in everyone's opinions. In contrast, sure WHATWG is fast moving, but it is run in a totalitarian manner representing only a handful of companies such as Mozilla and Apple. There is no representation for by far the vast majority of companies and developers, and whatever grand dictator Ian Hickson decides goes, which would be great if he was one of those genuinely nice rational friendly people who tries hard to help everyone, but the fact he's a pretentious arrogant dick who wont listen to reason on a number of issues, kind of fucks things up (e.g. http://cssquirrel.com/2009/07/20/comic-update-the-html5-suggestion-box/ [cssquirrel.com]).
Fundamentally the underlying problem is that WHATWG, as it states in the original reason for it's creation, is that it fo
Re: (Score:2)
+1
Re: (Score:2)
>>>A constantly evolving standard creates a moving target, which I believe is actually counter-productive.
That's okay. Contractors get paid by the hour. More time wasted trying to hit a moving target == more money for us. 50, 60, 70 hours a week. Woo hoo! ;-)
Oh and yes I agree with you 100%. A "moving" standard means no standard at all. It is highly inefficient and wasteful of resources (labor/hours).
Re: (Score:2)
Re: (Score:2)
Re:How can a standard be "living"? (Score:5, Insightful)
There is no reason the HTML5 standard needs to change that often if it's well thought out in the first place .
I believe that I've detected a problem.
Slow down (Score:5, Insightful)
Re:Slow down (Score:5, Insightful)
The whole world should slow down. Stick with a stable standard for a while. And relax.
This is probably the deepest, most profound statement on the internet today, if you take the time to really drink it in.
Re:Slow down (Score:4, Interesting)
The whole world should slow down. Stick with a stable standard for a while. And relax.
Quite the opposite. We need to speed up!
We did it in the 1990s and survived fine and innovation followed and all was good. ... well except for some beancounters who wanted a bare bones IT. There was no "This is the web browser we will use for the next 8 years and lets lock it in etc". Today we have phones like my Andriod as well as IPhones that give a much better browsing experience than my desktop?!
Why?
Because webmasters cripple them to cater to ancient versions of IE still. My phone has smooth crisp texts that are better hardware accelerated that are smoth when I go up and down with my finger. On my computer it flickers unless I use IE 9. I have gradients in things like arrows on many applets and sites with HTML 5 and CSS 3 the web equivalent does not have the gradients to cater to older browsers.
It is 2012 and this is silly. We need to move on and HTML 5 in my opinion should be gutted out so it can be standardized faster and the rest of the ideas and proposals can be part of CSS 3.1 and HTML 6. Doing this will stop Chrome only sites and get people to leave IE 8 and older browsers behind. Why should the best experiences be only for phone based applets?
What kind of rubbish desktop are you using? (Score:5, Insightful)
"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?
Re: (Score:3)
We need to speed up! ... Why should the best experiences ...
The more speed, the less experiences.
CC.
Re: (Score:3)
You need to look at this from a developer's point of view as well. When one is developing a site it costs money. To update that site it costs money. When deciding a target browser a big consideration is audience. Do I target a new standard that can only be seen properly by 10% of users or do I target an older standard that can be seen by 90% of users? From a business standpoint the decision is simple; go with the 90%. It takes years for browsers to become completely compatible with new standards. IE 8 is on
Re: (Score:2)
The whole world should slow down.
The Day the Earth Stood Still ...
Well, probably.
CC.
Standards compliance with multiple standards... (Score:2)
Standards compliance with multiple standards is a headache, but diversity is generally a good thing so long as it's balanced with reliability and thorough testing.
I don't know how this will evolve over the next few years, but my gut says it'll end up being positive with a few downsides.
At risk of sounding trite (for which I apologize), I'll just say competition is a seed for innovation.
Re: (Score:2)
My first thought... (Score:5, Informative)
... was likely wrong. I saw "WHATWG" and what "who the heck is that?" - I figured the W3C version would really be the only one anybody would care about.
Turns out I was just ignorant regarding WHATWG.
Now I know that WHATWG is, in part, driven by Apple, and its head is now working for Google. That means WebKit will probably follow the WHATWG version, which in turn means the web interface on the vast majority of mobile devices will follow that standard. And that's not even considering Mozilla, who's also part of the WHATWG group.
Really the only major player not involved is Microsoft - but they've been a follower rather than a leader for the past several years, at least when it comes to web standards.
Re:My first thought... (Score:5, Funny)
I wouldn't really call Microsoft a follower of *any* standards, but I understand what you're trying to say.
Re:My first thought... (Score:5, Insightful)
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).
Re:My first thought... (Score:5, Interesting)
The criticism of the W3C that led to WHATWG being formed was twofold:
1) The W3C wasn't fixing obvious bugs in HTML4 (e.g. places where the standard required behavior that was not compatible with actual websites).
2) The W3C was instead spending its time working on XHTML2, which it had purposefully designed to be backwards-incompatible with HTML4 so that you couldn't implement the two in a single rendering engine.
A large part of the reason for #2 was that the browser vendors had at most 5 votes total on the working group, while there were lots of other voters who were more interested in pie-in-the-sky projects than actually producing something that could work on the web. So what the browser vendors _actually_ got tired of was having no say at all and everyone feeling entitled to order them to do their bidding, no matter whether the bidding made any sense.
Note that the current situation is pretty different from what was going on when the WHATWG was first founded. It's a bit of a mess, but it's not the complete and utter disaster things were back then.
Re:My first thought... (Score:4, Interesting)
"1) The W3C wasn't fixing obvious bugs in HTML4 (e.g. places where the standard required behavior that was not compatible with actual websites)."
You call them bugs, but in reality they were merely failures by the browser vendors to properly implement the spec. This was simply an excuse by browser vendors for carrying out a coup, rather than a real actual problem. There's nothing in the HTML4 spec that couldn't be implemented properly. CSS had issues,
"2) The W3C was instead spending its time working on XHTML2, which it had purposefully designed to be backwards-incompatible with HTML4 so that you couldn't implement the two in a single rendering engine."
Why is this a problem? The web needs to move forward, it can't sit on what are, in technological terms ancient foundations forever. Ignoring the fact you skipped the important versions that were XHTML1 and 1.1 which were interim specifications that bridged the two (hence why there was a transitional stylesheet in this version) then what exactly is the issue? Release of a new spec doesn't make an old spec magically vanish, if you want your site to remain standards compliant but don't want to update it to a new standard then keep it compliant with the old standard and leave it as it was. This is one of the more stupid things about HTML5 - trying to automatically make ancient sites HTML5 compliant gives us what benefit exactly? In contrast it create a lot of negatives - it means the spec is hamstrung by trying to mangle in and support ancient problems. Why does a site written 10 years ago, and that is unmaintained magically need to become HTML5 compliant overnight?
I believe most browsers have implemented XML rendering now anyway?
"A large part of the reason for #2 was that the browser vendors had at most 5 votes total on the working group, while there were lots of other voters who were more interested in pie-in-the-sky projects than actually producing something that could work on the web. "
This is a really shit argument, simply writing off those interested in true separation of concerns as pie-in-the-sky projects highlights the problem exactly - those developing browsers, and those supporting the browser manufacturers in their coup of web standards seem to completely fail to grasp how software is developed by companies in the real world. Hint: We do like to write maintainable software, we do like to automatically be able to translate content to/from web pages using the plethora of XML tools and frameworks out there, and we do like specifications that are actually specifications not "living standards". This is precisely the problem, browser manufacturers think they know better, but if nothing else the fact they're known for having horrendously glaring bugs and security issues in their browsers suggests otherwise. They had 5 votes because they only deserved 5 votes, because they only represent a small share of the players in the market. Now instead what we have is browser vendors with their shit software development practices dictating how everyone else should write software - badly. Worse, we're not even talking about the browser developers running the show currently, in fact, even one of the major browser developers, Microsoft, has raised concerns with the quality of HTML5, we're actually only talking about one guy at Google for the most part who is the one deciding everything, and a handful of smaller voices from Apple and Mozilla. That leaves even a lot of other browser developers absent.
"Note that the current situation is pretty different from what was going on when the WHATWG was first founded. It's a bit of a mess, but it's not the complete and utter disaster things were back then."
I agree it was a disaster back then but again, only because browser vendors were refusing to do anything until they got their own way, not because there was anything inherently wrong with the W3C other than the fact it tried to be represenative.
Re:My first thought... (Score:4, Insightful)
> 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.
W3C should accelerate the process (Score:4, Informative)
W3C slowed down because Microsoft refused to play along for so long and they are part of the committee. With the about face of IE 9/10 that problem should go away as all browsers rapidly race towards incorporating CSS 3 and HTML 5 features first including simply proposals that are not even draft yet!
I favor cutting off HTML 5 proposals now to finalize it faster. THen put the newer features in webkit and Gecko in HMTL 6. If people are getting giddy about HTML 6 accelerated SVG and ajax stuff it will put pressure to retire IE 8. It will be perceived as very obsolete much quicker and non compliant otherwise the corps wont leave which will mean CSS 2.1 and HTML 4 until 2019.
That thing is a thorn in our side and it will become the new IE 6 of this decade because it comes with Windows 7.
Also doing this will prevent Chrome from becoming the next non standard browser [neowin.net] as well.
Re: (Score:3)
You do realize that in the link that you're pointing to, Chrome is using *standard* features that are enabled through use of specialized CSS calls, right? That doesn't mean Google developed special features on their own and are trying to standardize them.
For example, here are the list of Firefox CSS calls that are standardized, but temporarily renamed, while they settle out exactly how they want to render them: https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions [mozilla.org]
Re:W3C should accelerate the process (Score:4, Insightful)
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.
if they are careful (Score:2)
And make sure the evolving standard is backwards compatible with all past iterations (new tags and attributes merely ignored, rather than changing the behavior of existing tags and attributes) then the evolving standard is the way to go.
Improvements have to perfect layers of onion skin. Every new version in no way modifying impacting or touching the previous behavior. If attribute x drew a red square in ver 1.3, it cannot draw a blue square in ver 1.4. If a blue square is new functionality, you need a new a
Which? Neither. (Score:3)
A snapshot of a broken, inconsistent "standard" is not an improvement. Scrap it all and start over with a sane person in charge.
I will stick with XHTML 1.0, because XHTML2 was sacrificed to appease the loonies, until a reasonable successor is devised.
Is this Google's influence? (Score:2, Insightful)
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.
Re:Is this Google's influence? (Score:4, Insightful)
Why are you trying to smear Google with innuendo? (Score:2)
Your post is nothing but Google smearing speculation.
MS and Apple are guilty of trying to strong arm computer standards. MS was even caught bribing OSI officials to sanction MS's bogus OOXML standard.
What has Google done?
Re: (Score:2)
It doesn't matter to them if we head back to a dark age where developing a site that supports all browsers is a PITA.
Or s
Re: (Score:2)
Well, unless Google stops basic Chrome on WebKit and develops its own rendering engine (admittedly a possibility) - this won't be an issue. Since we're talking about HTML and not JavaScript in this case, anything Chrome supports will also be supported by Safari.
Not to mention that Mozilla and Opera are also part of WHATWG.
Re: (Score:2)
basing not "basic".
I swear, lately my brain seems hellbent on slipping a typo into every post I make. And "typo" isn't even the right term - It's almost always a valid word; just not the one I intended to type!
Re: (Score:2)
Re:Is this Google's influence? (Score:5, Funny)
On a side note - with both Google and Mozilla involved, I'm worried they'll start an "HTML rapid release" program. It may be HTML5 today; but in six weeks they'll be on HTLM6, then HTML7... we'll be at HTML20 by the end of the year.
"Living Standard"? There is no such thing. (Score:5, Insightful)
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.
Re: (Score:2)
There goes thin client user interfaces (Score:2)
This is nothing new.. (Score:5, Informative)
This was mentioned over a year ago that this was happening? (January 2011 ! )
http://blog.whatwg.org/html-is-the-new-html5 [whatwg.org]
The standard is already a decade ahead ... (Score:2)
The standard is already a decade ahead of the implementation of the standard, what is the point of developing it faster?
And the idea of having a constantly changing standard is ridiculous, make a static standard so that eventually everyone can have a working version based in the same standard. That is the point of a standard after all.
We've been here before (Score:5, Insightful)
"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.
Begin again the browser wars have (Score:2)
Here we go again.
Feature Detection (Score:2, Insightful)
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 syst
It's about time the w3c was bitch-slapped (Score:3)
And this will sink them into irrelevancy; they're not much more than an obstacle these days. I'm sure there'll be some warts (cf. "blink") but overall it's to see things get done without the icann of the web standards world.
For those confused. (Score:4, Informative)
WHATWG split off from the W3C work because they couldn't organize additions and clarifications to the HTML 4 spec under the W3C. It is mostly a group of browser-makers (everyone except Microsoft).
The W3C then asked if they could standardize the WHATWG's work as HTML5
What happened a year ago (and is just being put on slashdot today?) was that the WHATWG announced that they weren't going to stop producing additional work. The version under the W3C would eventually be released as version 5.0, but WHATWG would effectively be the HEAD/master version of work on extending HTML.
Which HTML5 is an easy question to answer - there will only be one HTML5. People will put pressure on the browser manufacturers to support the W3C's standardization of HTML as version 5.0. But browser manufacturers will also continue to cram new crap and functionality in ahead of W3C standardization, and attempt to define interoperability of that under the flag "HTML" in WHATWG, a "specification" that grows as the members gain consensus on how new functionality should work (or in some cases, how to advertise the functionality is not offered).
In reality, this is how HTML has _always_ operated.
Good Idea! (Score:5, Interesting)
I don't understand why people think this is such a bad idea. This is the similar to any source tree having a "development branch" and a "stable branch". WHATWG will be responsible for evolving the fast-paced devlopment branch of HTML while W3C will take occasional snapshots and stabilize the features of the development branch into "full standards". I assume that most of the complaints here are related to either bad marketing - WHATWG should just start calling their version HTML6 or "future HTML" or something - or the fact that these bodies (especially the W3C) move slowly and we are in the middle of a new stable branch getting pulled.
By the way, HTML5 isn't, according to the W3C a standard yet. The current HTML standard is 4.0.1. HTML5 is planned to be a "full standard" in 2014. In that time, WHATWG will introduce dozens of new major features into what will probably be called either HTML6 or HTML5.1 when the W3C gets around to pulling another snapshot.
http://en.wikipedia.org/wiki/HTML#Version_history_of_the_standard [wikipedia.org]
Remember XHTML? (Score:3)
A few years back, it looked like XHTML was the future. The basic idea of XHTML is "the syntax has to be right". XHTML parsers are not required to parse anything that isn't valid XML. HTML5 parsers have explicitly defined semantics for common errors in HTML, like malformed comments. With XHTML, there was no question what the tree representation of the document was.
But people wanted the freedom to copy and paste broken ad code into HTML documents, so we ended up with HTML5. Personally, I'd like to have strict XHTML and require that everything be UTF-8. It's time to retire that "upper code page" crap.
Re: (Score:2)
The W3C has Amaya.
Re: (Score:3)
Re: (Score:2)
Also, W3C touts it as a web editor more than a web browser. Sorry.