Forgot your password?
typodupeerror
Programming The Internet News

HTML5 Splits Into Two Standards 395

Posted by timothy
from the so-many-to-choose-from dept.
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?'"
This discussion has been archived. No new comments can be posted.

HTML5 Splits Into Two Standards

Comments Filter:
  • Dumb idea. (Score:5, Insightful)

    by kingramon0 (411815) on Saturday July 21, 2012 @03:46PM (#40725507) Homepage

    So when browsers claim to be fully HTML5 compliant, will that even have any meaning anymore?

  • by ClaraBow (212734) on Saturday July 21, 2012 @03:49PM (#40725523)
    The one supported by by Webkit and Gecko?
  • I have mod points (Score:5, Insightful)

    by LilBlackKittie (179799) on Saturday July 21, 2012 @03:49PM (#40725525) Homepage

    and I wanted to moderate this story down for its appalling failure to call W3C "W3C" two times out of three.

  • by An Anonymous Coward (236011) on Saturday July 21, 2012 @03:49PM (#40725529)

    "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.

  • Slow down (Score:5, Insightful)

    by MS (18681) on Saturday July 21, 2012 @03:51PM (#40725535)
    The whole world should slow down. Stick with a stable standard for a while. And relax.
  • Re:Slow down (Score:5, Insightful)

    by CanHasDIY (1672858) on Saturday July 21, 2012 @03:57PM (#40725577) Homepage Journal

    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:Dumb idea. (Score:4, Insightful)

    by Twinbee (767046) on Saturday July 21, 2012 @04:09PM (#40725661) Homepage
    Oh yes, 100%.

    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!
  • by thetoadwarrior (1268702) on Saturday July 21, 2012 @04:12PM (#40725685) Homepage
    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.
  • by gweihir (88907) on Saturday July 21, 2012 @04:13PM (#40725687)

    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.

  • No shit (Score:5, Insightful)

    by Sycraft-fu (314770) on Saturday July 21, 2012 @04:14PM (#40725693)

    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.

  • by colinrichardday (768814) <colin.day.6@hotmail.com> on Saturday July 21, 2012 @04:17PM (#40725707)

    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.

  • by Altanar (56809) on Saturday July 21, 2012 @04:21PM (#40725723)
    Domination through improvement? BTW, the WHATWG is run by people from Mozilla, Apple, and Opera.
  • by Viol8 (599362) on Saturday July 21, 2012 @04:22PM (#40725733)

    "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:Dumb idea. (Score:5, Insightful)

    by icebike (68054) * on Saturday July 21, 2012 @04:28PM (#40725767)

    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.

  • by mrbester (200927) on Saturday July 21, 2012 @04:39PM (#40725841) Homepage

    "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.

  • by Shifty0x88 (1732980) on Saturday July 21, 2012 @04:40PM (#40725847)
    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.
  • by ultranova (717540) on Saturday July 21, 2012 @04:43PM (#40725855)

    There is no good way to do 3D. A web app should have direct access to an OpenGL.

    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?

  • Feature Detection (Score:2, Insightful)

    by Anonymous Coward on Saturday July 21, 2012 @04:49PM (#40725893)

    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"?

  • by Xest (935314) on Saturday July 21, 2012 @05:30PM (#40726121)

    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:Dumb idea. (Score:5, Insightful)

    by Anonymous Brave Guy (457657) on Saturday July 21, 2012 @06:14PM (#40726305)

    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.

  • by PT_1 (2425848) on Saturday July 21, 2012 @06:42PM (#40726443)

    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:Dumb idea. (Score:5, Insightful)

    by Stiletto (12066) on Saturday July 21, 2012 @06:44PM (#40726445)

    Six weeks is not really an unreasonably short release cadence, unless you work for a defense contractor or something.

  • Re:Dumb idea. (Score:4, Insightful)

    by Knytefall (7348) on Saturday July 21, 2012 @06:49PM (#40726481)

    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.

  • by martin-boundary (547041) on Saturday July 21, 2012 @08:17PM (#40726935)
    Without a W3C "snapshot" standard, there's a greater chance that companies will pick and choose the pieces they want/like in the "living" standard, leading to greater incompatibilities for users.

    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.

  • Re:Dumb idea. (Score:5, Insightful)

    by tooyoung (853621) on Saturday July 21, 2012 @09:21PM (#40727181)

    Six weeks is not really an unreasonably short release cadence

    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:4, Insightful)

    by Anonymous Brave Guy (457657) on Saturday July 21, 2012 @09:35PM (#40727229)

    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:5, Insightful)

    by Xest (935314) on Sunday July 22, 2012 @03:09AM (#40728451)

    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.

  • by A Friendly Troll (1017492) on Sunday July 22, 2012 @05:35AM (#40728885)

    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.

  • Quite the opposite (Score:5, Insightful)

    by YA_Python_dev (885173) on Sunday July 22, 2012 @06:11AM (#40728965) Journal
    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.
  • by BZ (40346) on Sunday July 22, 2012 @10:00AM (#40729763)

    > 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.

Promising costs nothing, it's the delivering that kills you.

Working...