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

395 comments

  1. The great thing about standards by Anonymous Coward · · Score: 4, Funny

    There's so many to choose from.

    1. Re:The great thing about standards by wootest · · Score: 2, Funny

      I like how the first post is redundant.

    2. Re:The great thing about standards by cpu6502 · · Score: 4, 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!

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
    3. Re:The great thing about standards by Lord+Lode · · Score: 4, Interesting

      Obligatory xkcd (I can't believe it's not linked yet): http://xkcd.com/927/

    4. Re:The great thing about standards by AbrasiveCat · · Score: 1

      There's so many to choose from.

      A great quote usually attributed to Andrew Tanenbaum.

    5. Re:The great thing about standards by Anonymous Coward · · Score: 0

      now there is three standards.

    6. Re:The great thing about standards by Anonymous Coward · · Score: 1

      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!

      It's Agile, Agile, Agile, all the way up!

    7. Re:The great thing about standards by Anonymous Coward · · Score: 0

      *golf clap*

    8. Re:The great thing about standards by Anonymous Coward · · Score: 0

      Many standards means no standard. This work for MS monopoly because when there are multiple choices (like ODF and OOXML - which is not even open) people stick to what monopoly tells them, ie. closed one.
      In practice there has not yet beeen HTML5 standard and implementation. For well known reasons (any open standard is poison for a monopoly) mainly MS has been slowing HTML5 adoption. (Check html5 test site.) There are lots of usable features in HTML5 which works with other browsers, but developer has to use only the subset MS offers.

    9. Re:The great thing about standards by K.+S.+Kyosuke · · Score: 1

      There's so many to choose from.

      A great quote usually attributed to Andrew Tanenbaum.

      Hmm, I didn't know that Grace Hopper fancied cross-dressing. But why would she call herself Andrew, of all names? Surely there are nicer ones.

      --
      Ezekiel 23:20
    10. Re:The great thing about standards by Anonymous Coward · · Score: 0

      http://xkcd.com/927/

  2. Dumb idea. by kingramon0 · · Score: 5, Insightful

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

    1. Re:Dumb idea. by Anonymous Coward · · Score: 0

      WHATWG?

    2. Re:Dumb idea. by Anonymous Coward · · Score: 1

      That's the HTTP version not the HTML version. They are not the same thing at all.

    3. Re:Dumb idea. by Thiez · · Score: 2

      Ouch, you're absolutely correct. What a silly mistake to make :(

    4. Re:Dumb idea. by Kenja · · Score: 4, Informative

      HTTP is the request method, HTML is the document type. You can use HTTP to request any binary or text file such as video clips etc. HTML can be run locally without being requested through HTTP. So in other words, the two are not related in any way.

      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.

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    5. Re:Dumb idea. by Twinbee · · Score: 3, Insightful

      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!

      --
      Why OpalCalc is the best Windows calc
    6. Re:Dumb idea. by Austerity+Empowers · · Score: 1

      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.

    7. Re:Dumb idea. by icebike · · Score: 4, 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.

      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.

      --
      Sig Battery depleted. Reverting to safe mode.
    8. Re:Dumb idea. by wisnoskij · · Score: 1

      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.

      --
      Troll is not a replacement for I disagree.
    9. Re:Dumb idea. by Beardydog · · Score: 1

      Is there some reason this shouldn't go in the DocType? I'm terrible at writing valid HTML, so that's a genuine question.

    10. Re:Dumb idea. by erroneus · · Score: 0

      Is Microsoft, by chance, involved in WHATWG??? Sounds like their MO.

    11. Re:Dumb idea. by phantomfive · · Score: 1

      Has any browser ever claimed to be fully HTML5 compliant?

      --
      "First they came for the slanderers and i said nothing."
    12. Re:Dumb idea. by Tough+Love · · Score: 2

      Is Microsoft, by chance, involved in WHATWG??? Sounds like their MO.

      You could always consider reading the Wikipedia arcticle. It basically says "no". Looks more like Google and Opera with Apple also playing some role. I really don't know what's going on here, maybe pushback against W3C's agenda of abandoning HTML in favor of XML? Educate me, please.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    13. Re:Dumb idea. by ultranova · · Score: 2

      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.

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

      I just can't help but remember back when we also had a "living standard", meaning that nobody really knew how a particular document should or would be interpreted, and how it took years to hammer into people's heads the importance of including the HTML version information in their pages. Perhaps it's been long enough for the lessons of yesterday to be forgotten and in need of being re-learnt. Except that this time we have a far more complex mesh of HTML, CSS and Javascript to deal with, so this should be a popcorn-worthy farce.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    14. Re:Dumb idea. by cjcela · · Score: 2

      The idea of a browser to be fully HTML5 compliant sort of dissapears with a 'live' standard. This may be convenient for a standard body, but I do not see how this is a good thing for the people actually developing for the web. How can you guarantee a web application will work well on a browser if the standard keeps changing, other than to have the developers not using the newest features of HTML5? So while the standard evolves, deployment will be possible or not depending on whatever your browser devs decide to implement, and instead to refer to one standard document, the application developer will need to keep track to what is implemented on which browser, and having to compromise with the minimum common feature set, or falling into using middleware libraries to make the web application work the same on all browsers. How is this different than having to support legacy browsers such as IE6 and IE7? We all know what a pain that is.

    15. Re:Dumb idea. by nine-times · · Score: 1

      It's impossible to be compliant to a "living standard" anyway. I don't see a problem with the two groups working in different ways. Let W3C work on a standard called "HTML 5"that people can meet and claim to be compliant on, and let WHATWG work on a standard called "HTML-current" or something and let them push ahead and develop standards as fast as they can.

      Software developers have been doing this kind of thing for a long time, e.g. Debian's stable distribution and Debian's testing distribution.

    16. Re:Dumb idea. by Genda · · Score: 4, 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!)

    17. Re:Dumb idea. by cpu6502 · · Score: 2, Funny

      >>>Won't that be a wonderful time to develop web pages?

      Not only will you have to track if your visitor is using Firefox 3.5 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or 11 or 12 or 13 or 14 or Chrome 1 or 2 or 3 or... 22..... or IE 7 or 8 or 9..... or Opera 10, 11......

      You have to remember which ones are HTML 5 compliant, which are still stuck on HTML4, which are 5.1 compliant, which are 5.2 compliant, which are 5.3 compliant, which are...... 5.22 compliant.

      Argh!

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
    18. Re:Dumb idea. by fatphil · · Score: 1

      Absolutely. Duck, weave, bob, trip, fall, vomit, the works.

      It's basically synomymous for "not a standard, by the usual definition of the term". /caveat browsor/

      --
      Also FatPhil on SoylentNews, id 863
    19. Re:Dumb idea. by fatphil · · Score: 1

      > took years to hammer into people's heads the importance of including the HTML version information in their pages

      Am I the only one who refuses to do that? If there's a problem with my pages, blame the W3C, and netscape, and Microsoft; they're the ones who broke things, not me.

      --
      Also FatPhil on SoylentNews, id 863
    20. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 4, 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.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    21. Re:Dumb idea. by stephanruby · · Score: 1

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

      Hopefully, it will be more precise that way.
      HTML 4.9 compliant
      HTML 5.1 compliant
      HTML 5.3 compliant

    22. Re:Dumb idea. by marcello_dl · · Score: 1

      Maybe the aim is discouraging people from implementing alternative browsers.
      Most web stuff being reimplemented in html and a bunch of browsers turned app clients, with the same sets of plugins... a very controlled environment, much unlike the "real" internet.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    23. Re:Dumb idea. by Stiletto · · Score: 4, Insightful

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

    24. Re:Dumb idea. by autocannon · · Score: 1

      Sadly no mod points for this, but I fully agree with this post.

    25. Re:Dumb idea. by Knytefall · · Score: 3, 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.

    26. Re:Dumb idea. by Anonymous Coward · · Score: 0

      I agree completely. We are steering customers off chrome and ff for exactly these reasons. Business envirnment does not like this rapid fire model. They can use those if they want, but it's not supported by us.

    27. Re:Dumb idea. by diamondmagic · · Score: 1

      Except guess who decided to remove the document type header from HTML version 5?

      I swear, how did WHATWG ever get the rights to use the name "HTML" in their spec. The W3C is nice enough to write lots of small specifications. WHATWG just threw everything into a single bloated piece of crap.

    28. Re:Dumb idea. by Twinbee · · Score: 1

      I agree with you in spirit (and am also bitter about the mess), though for practical reasons, I just copy and paste a certain 'flavour' of that DOCTYPE header on a lot of my pages to get things to appear the same in all the browsers. I don't know what the heck it means, and care even less, but here it is anyway (see the top bit, and ignore the rest, I didn't make this paste, just found it from looking using google (it is the same as mine, but Slashdot doesn't allow pasting of weird characters etc.):

      http://pastebin.com/vkKDZPjJ

      --
      Why OpalCalc is the best Windows calc
    29. Re:Dumb idea. by Anonymous Coward · · Score: 0

      Call what IE 9 supports HTML 5 and css 3. Put shadows, gradients, and webworkers as HTML 6 and CSS 3.1. Put more advanced things as CSS 3.2 and HTML 7 etc. Each year finalize each version as they mature.

      Why can't we do this? The W3C went fast in the 1990s and did just that with a new version every other year.

    30. Re:Dumb idea. by JackAxe · · Score: 1

      Nope, and it's probably not going to happen, not any time soon. Apple, Google, and MIcrosoft are intentionally hampering the progress on their mobile browsers, since they all want us to live in their app-ecosystem.

    31. Re:Dumb idea. by SmurfButcher+Bob · · Score: 1

      Absolutely, but only if they use HTML5 via 4G network.

      --

      help me i've cloned myself and can't remember which one I am

    32. Re:Dumb idea. by Phroggy · · Score: 1

      They decided that all future versions will be backwards-compatible and the spec calls for new unsupported features to degrade gracefully, so even if there are new versions of the spec, you're not supposed to worry about it. All browsers will just support everything to the best of their ability anyway, regardless of what version numbers you'd like to define.

      But I don't think it was a terribly good idea either.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    33. Re:Dumb idea. by edremy · · Score: 4, Interesting
      You don't work anywhere where there are more than a dozen computers, do you?

      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

      --
      "Seven Deadly Sins? I thought it was a to-do list!"
    34. Re:Dumb idea. by tooyoung · · Score: 5, Insightful

      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.

    35. Re:Dumb idea. by Anonymous+Brave+Guy · · 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...

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    36. Re:Dumb idea. by hcs_$reboot · · Score: 1

      Agreed. The current trendy html5 doctype is to replace the ridiculously long previous v4- versions - we should soon be offered something like standard" > , standard being "w3c", etc...

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    37. Re:Dumb idea. by Anonymous Coward · · Score: 1

      protip: modern web dev is based on feature detection. anything that happens to be a collection of those claiming to be a spec isn't really relevant anymore, since browsers not supporting it will have shims/polyfills/whatever to get it to still work (like http long-polling as a fallback when the browser doesn't support websockets).

      The switch to feature detection is really the key bit (arguably with the fallbacks, but whatever).

    38. Re:Dumb idea. by Crudely_Indecent · · Score: 1

      There is a silver lining. Open source projects like Chromium and Firefox are agile enough to support recent snapshots, while Microsoft will have trouble keeping up - and will, in all likelihood, be years behind the times.

      This might be the final nail in the IE coffin - driven one snapshot at a time.

      --


      "Lame" - Galaxar
    39. Re:Dumb idea. by oiron · · 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.

    40. Re:Dumb idea. by Damek · · Score: 1

      Most of the things you want them to notice don't seem to be the case so far.

    41. Re:Dumb idea. by donscarletti · · Score: 1

      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

      The broken window fallacy is only a fallacy if you are not a glazier.

      --
      When Argumentum ad Hominem falls short, try Argumentum ad Matrem
    42. Re:Dumb idea. by guttentag · · Score: 1

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

      About as much meaning as sunglasses that say "100% UV" on them. Does that mean they block 100% UVA (400-314nm)? 100% UVB(315-280nm), 100% UVC(280-100nm), 100% of two out of three? Or perhaps it means they allow 100% of UV radiation through. The label effectively means nothing, but it makes you feel better! Perhaps the sticker on the lens should say, "this label blocks 100% of UV radiation. No ultraviolet light can pass through this label."

    43. Re:Dumb idea. by datavirtue · · Score: 1

      We need to proceed with this blitzkrieg of updates as long as it is tolerated. I know it sucks but we have serious momentum and a plethora of stuff yet to be done. It will probably settle down in ten years or so. Improved security, improved JavaScript, improved CSS, improved HTML, and the list goes on. I don't know if you noticed, but building serious web apps is just now becoming possible and this arduous march needs to continue to get things right. Web development is starting to become a sane and enjoyable profession because of this constant improvement, and the browsers have to be updated to make this possible.

      --
      I object to power without constructive purpose. --Spock
    44. Re:Dumb idea. by datavirtue · · Score: 1, Flamebait

      Then don't use stupid browser dependent features! Just deal with it. The whole world isn't going to stop improving because you can't get your shit straight.

      --
      I object to power without constructive purpose. --Spock
    45. Re:Dumb idea. by datavirtue · · Score: 0

      Dude, I don't know what you're talking about. IE9 is trashed and locks up constantly. In our IT department you often hear a mouse slam on a desk with some expletive because someone is trying to access Microsoft's website with IE9. I'm in Chrome constantly and never have a problem and I browse way outside the normal average of 7 websites per day. In fact I'm always testing new web-apps and using bleeding edge tools and libraries and still never have a problem. Firefox can be a little quirky but still better than IE.

      --
      I object to power without constructive purpose. --Spock
    46. Re:Dumb idea. by datavirtue · · Score: 1

      Business is going to benefit more than consumers from this rapid fire model. I agree that it can be unsettling, but it is worth it in the long run.

      --
      I object to power without constructive purpose. --Spock
    47. Re:Dumb idea. by lennier · · Score: 1

      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.

      I'm not seeing the downside in that scenario.

      We already have computers a million times bigger and faster than I grew up with in the 80s - say, the Commodore 64. But on the scale of security and reliability, they're at least a thousand times worse.

      (How many times did your C64 get a virus and drain your bank account?)

      Rapid feature churn is the opposite of what the industry needs right now.

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    48. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 3, 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.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    49. Re:Dumb idea. by Anonymous Coward · · Score: 1

      recent versions of IE actually have a pretty good track record for quality

      Is that the same IE that throws tantrum when it sees a single "feed" element in a generic XML document on a website's main page (it is then transformed with XSLT)? That's pretty funny quality you are speaking of then. On the level of parsing XML with regexps. Although it is, probably, bad sniffing that don't understand what a namespace even is, but that's hardly quality either.

    50. Re:Dumb idea. by Anonymous Coward · · Score: 0

      Bullshit strawman argument!

      The problem with IE was/is, that it was/is so completele non-deterministic in mnx areas, it would probably have won any Turing test.
      It was/is like having 20 knobs to set a setting, of which only one was the officially correct one, but it did nothing like what it should, so you had to use all the others, but everyone of them changed all the other knobs in a invisible and unpredictable way!

      Like the perfect machine, designed to drive a man crazy. I still have nightmares!

      And no, not being aware of that, because nobody else even sttempted to create webapps that complex doesn't make it non-existent.

      The *other* problem was its total ignorance of anything beyond DOM1/CSS1.x/..., holding the whole web hostage, because MS's monopoly meant, they didn't have to give a fuck.
      That has been fixed.. mostly.... Because of Firefox steamrolling them (esp. outside of the US).
      But as soon as they get a chance,they will do the exact same thing again. They are a many-times convicted criminal for a reason. People often forget that simple fact.

      So no. Short of a death penalty with complete incineration, I will never ever trust MS again.

      Those who do not learn from history, are doomed to repeat it.

    51. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 1

      You obviously feel passionately about the way Microsoft behaved in the past and the IE6 legacy.

      I cannot help but notice that today's situation where Mozilla and Google are throwing new extensions around every few weeks looks a lot like the IE vs. Netscape problem repeating itself, except that at least IE6 won so all the users had the same client with the same proprietary extensions for those of us writing web pages to target.

      Today, we don't even have that, and all this "living standard" madness seems like a guaranteed way to make sure we will never again have a stable, reliable platform to code against.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    52. Re:Dumb idea. by DarwinSurvivor · · Score: 0

      Don't forget w3cHTML5.0, w3cHTML5.1, w3cHTML5.2, whatwgHTML5.0, whatwgHTML5.1, whatwgHTML5.2, etc.

    53. Re:Dumb idea. by Anonymous Coward · · Score: 0

      How many users even notice the Chrome updates rolling out that frequently? For the most part Chrome does a wonderful job of hiding that from the end user.

    54. Re:Dumb idea. by Anonymous Coward · · Score: 0

      Yeah, how many times did bicycles crash into walls with lethal consequences? Cars are too unsecure and unreliable. I say, we shouldn't even stop at bicycles, and even running is rather dangerous. We should just go back to crawling.

      C64 didn't get viruses and couldn't drain bank accounts because it didn't have no technology to store those viruses for a long time and no technology to do internet banking.

      If you're not seeing downsides to this scenario, it's only because you've never had to support outdated tech while looking begrudgingly at neighbours newer solution with bumps of the old tech flattened out and features you had to do a dance to get working on a single key press.

      Web designers, specifically, would curse you and your kin for all the pleasures of supporting stable, never updated concrete environment of IE 6 (and to a lesser extent 7 and 8).

    55. Re:Dumb idea. by Xest · · Score: 1

      Perhaps somewhat ironically, Microsoft have actually been one of the only sane voices in the HTML5 standards process. Weird I know, but it's worth having a read of some of the issues they put forward to WHATWG, they were absolutely spot on in their complaints.

      WHATWG ignored them though unfortunately.

    56. Re:Dumb idea. by Xest · · 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.

    57. Re:Dumb idea. by Xest · · Score: 1

      That's because Microsoft could get away with releasing a buggy IE then, due to the fact there was no competition for people to run to. There probably really was fuck all QA for IE6, and to a lesser extent 7, why would there need to be? It's not like people had any other browser worth going to.

      In contrast, if you look at recent versions, it's hard to argue that they're particularly buggy. IE8 and 9 are at least as secure and stable as the competing browsers released at the time, if not more so in IE9's case.

    58. Re:Dumb idea. by Anonymous Coward · · Score: 0

      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.

      Actually, think about it...

      IE6 was the end result of the browser wars between IE and Netscape, where they spent several years rushing out new versions with deliberately incompatible features. Of course it's a mess.

      IE6 development stopped pretty much dead as soon as they won that war; all the bugs left in place... tough luck; that's how monopolies work. (IE7 and IE8 were basically attempts to patch up the mess they made with IE6, once they realised their market share was slipping)

      My point is that IE being buggy was caused by precisely the kind of mad-dash release-as-soon-as-possible-to-beat-the-opposition mentality that we're seeing now with Firefox and Chrome.

      It would be ironic indeed if IE came to represent a sensible browsing choice, but that is the way we're heading.

    59. Re:Dumb idea. by KiloByte · · Score: 1

      You don't need to suffer IE, there are Firefox long-term stable releases for the likes of you (and I'd prefer if they were the primary download). Currently, that's version 10.

      I refuse to call current "releases" anything more than glorified trunk snapshots.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    60. Re:Dumb idea. by TheRaven64 · · Score: 1

      No, WHATWG is basically the everyone-except-Microsoft group. It was originally Apple, Opera, and Mozilla, now Google has joined. There are a lot of things that you can blame Microsoft for, but this is not one of them, unless you count the stagnation of Internet standards post IE6 as a motivation for the formation of WHATWG.

      --
      I am TheRaven on Soylent News
    61. Re:Dumb idea. by paugq · · Score: 1

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

      That was one of the points I made in my "HTML5 for everything?" post 7 months ago:

      http://www.elpauer.org/?p=1134

      "Or maybe it’s about time to define actual “HTML5 profiles”. ACID3 seems to be too weak of a profile: two very different browsers may pass ACID3 yet a webapp would work with one browser and fail with the other due to bugs, missing features/added features, etc."

    62. Re:Dumb idea. by Anonymous Coward · · Score: 0

      Yes, the rapid release model has really held back Chrome's adoption, people are shunning it in droves.

    63. Re:Dumb idea. by webnut77 · · Score: 1

      I'm having a hard time getting IE9 installed on my XP Pro Windows.

      Yeah, I know. I know.

    64. Re:Dumb idea. by Anonymous Coward · · Score: 0

      Yeah, it's only Firefox that fucks me over routinely. Chrome, I don't give a damn.

    65. Re:Dumb idea. by Anonymous Coward · · Score: 0

      I've witnessed what you've said numerous times with Firefox, but never with Chrome.

      Are you prepared to back up any of your Chrome assertions with citations? I don't think so.

    66. Re:Dumb idea. by Anonymous Coward · · Score: 0

      XML was a good idea and you can still use it if you really want to. While it's not trivial to use XML, as long as you have a set of scripts you can always render XML in HTML4 or 5 or whatever provided you're not trying to do something that's forbidden by the version.

      XML is a good technology, there's just no particular reason why it has to be the only option. For what it's intended for it works quite well. Sometimes it's better, sometimes it's worse, but it's going to be a viable option probably forever as long as people can create their own processors.

    67. Re:Dumb idea. by UnknownSoldier · · Score: 1

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

      Well at least one of the Mozilla developers is slowly coming to their senses and seeing how this 6-week inflated version number is more harmful then helpful.

      http://evilbrainjono.net/blog?showcomments=true&permalink=1094

    68. Re:Dumb idea. by Anonymous Coward · · Score: 0

      A chance to link to my favorite site for web development dilemas such as these.

    69. Re:Dumb idea. by Anonymous Coward · · Score: 0

      You're a known jackass on slashdot. Shut the fuck up idiot.

    70. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 1

      Unfortunately, even the LTS releases aren't much use for a big business that runs numerous internal web apps.

      For one thing, the period of support is still way too short: the first one, based on Firefox 3.6, already ran out some time ago. Moving new feature development to another branch after a few months is fine, but security updates have to last for the useful lifetime of the platform if you want to be taken seriously.

      For another thing, the overlap between support for one LTS version and the next is only a few weeks, which is an absurdly short time to upgrade an entire organisation on the scale I'm talking about there. They do need to do extensive testing during that upgrade process, because for example the last Firefox LTS release seriously broke plug-ins like Flash and Java applets, which of course many of those in-house web apps rely on.

      In short, while most of the small businesses I work with could cope fine with an annual upgrade cycle, the large businesses simply can't and won't. For them, having a stable, secure platform for the long term is very much more important than having the latest shiny HTML5 gimmicks.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    71. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 1

      Businesses are shunning it in droves. There is a striking difference today between browser usage patterns during office hours and during evenings/weekends.

      The problem with updates for home users is that when one of the web apps I work on breaks because of a bad Chrome update, I can promise you it's not Google who get paged at 4am to deal with it. And the end user doesn't know where the problem is, because they don't even realise Chrome has been updating. All they know is that yesterday they could log in and see their account details and today they can't, and so they call the support number or file a bug report on the support page, and my life for the next few days gets more painful. How much do you think this makes me, as a developer, want to use any new browser feature that isn't likely to be 100% robust and future-proof?

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    72. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 1

      If you're genuinely interested, you shouldn't trust some random post on Slashdot anyway, you should go experiment for yourself and see how easy it is to break.

      Here are a couple of starting points to try out. Both of these areas get broken all the time from direct personal experience and have easily observable problems with the current Chrome release:

      • Set up a site with an HTML5 video. Try serving the video in different encoding/container formats. Try using different combinations of attributes on the video element itself. There have been so many bugs in this area that you're bound to hit one if you're even a little creative. If you want concrete citations, just try searching for "chrome html5 video bug youtube".
      • Set up a site using a plug-in like Flash or Java. Have some JavaScript (which has a single-threaded execution model) do something obvious like showing a "please wait" message with some sort of animated GIF spinner graphic, and then immediately call into your Flash or applet to do something time consuming like, say, fetching a file from the server. Observe that the whole browser locks up while this is going on. Conclude that Chrome appears to be either executing external code directly in its main UI thread or at least failing to synchronize things properly. Never mind the reliability issues, this is an obvious security vulnerability, and ever-more-obnoxious blocking of plug-in-based content is not an acceptable "fix". It's also a newbie error that most desktop app developers learned not to make 10 or 20 years ago, so it's very surprising that an application with the support of Chrome would have such a poor architecture, but there you go.
      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    73. Re:Dumb idea. by Electricity+Likes+Me · · Score: 1

      Exactly. There's nothing wrong with frequent updates provided your update mechanism is transparent, and you make sure you're not breaking things with them.

      Chrome does them perfectly.

    74. Re:Dumb idea. by Anonymous Coward · · Score: 0

      My company also routinely tests our web applications with every browser. IE9 (and IE8) are still the bottom of the barrel in just about everything, and the extra work necessary to bring those browsers up to speed with *any* other decent browser in the world is staggering. Hopefully IE10 will not drop the soap so badly on the HTML5 aspect, as IE9 surely did.

    75. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 1

      Can you give any concrete examples where IE9 doesn't work properly? Not new features in HTML5 and CSS3 that it doesn't support, but things where it's supposed to support them but is actually broken?

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    76. Re:Dumb idea. by yuhong · · Score: 1

      I think this is just standard boilerplate.

    77. Re:Dumb idea. by marcosdumay · · Score: 1

      I guess it is a recognition that: "Yeah, we tried making a standard, it didn't work."

      Everybody is complaining, while simply igoniring the elephant in the room, that is, W3C standards mean nothing in practice.

    78. Re:Dumb idea. by dkf · · Score: 1

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

      Cool. Can we start doing updates to your C library on that schedule? We'll just introduce a few incompatible changes with every release, you'll hardly even notice them. Just restart your downstream dependencies and everything will be tickety-boo!

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    79. Re:Dumb idea. by Anonymous Coward · · Score: 0

      The web protocols (HTML, CSS, etc) are an abomination. Anyone trained in computer science is horrified. Ask Alan Kay.

    80. Re:Dumb idea. by Anonymous Coward · · Score: 0

      My company also routinely tests our web applications with every browser. IE9 (and IE8) are still the bottom of the barrel in just about everything, and the extra work necessary to bring those browsers up to speed with *any* other decent browser in the world is staggering.

      Specifically what are all these problems that IE9 has that all the other browsers have no problem with?

    81. Re:Dumb idea. by Anonymous Coward · · Score: 0

      But as soon as they get a chance,they will do the exact same thing again.

      Also Apple is going to go bankrupt without Steve Jobs to come back and save them because that's what happened last time Jobs left the company. Firefox will be a lump of incompatible, memory-hogging crap because that's happened in the past. I can see you're set in your ways and can't handle change, but change is a fact of life, you can cling to a reality that has long past if that's what you really need to get by, but you'll be left behind with your conspiracy theories...look out, OSX is being locked down and turned into iOS! - maybe that will keep you busy :P

      They are a many-times convicted criminal for a reason. People often forget that simple fact.

      Probably because it's not a fact, but your belief of a situation that doesn't exist is the perfect explanation for why you are foaming at the mouth and no one else really cares.

    82. Re:Dumb idea. by Anonymous Coward · · Score: 0

      IE6 was the end result of the browser wars between IE and Netscape, where they spent several years rushing out new versions with deliberately incompatible features. Of course it's a mess.

      Both IE and Netscape were in the same boat, trying to compete by introducing new features (obviously incompatible with eachother) better than what was available in the standard specification. IE went cross-platform (supporting Mac OS) where Netscape didn't and by the time Communicator was released it was slow and crash-prone so then IE was left to dominate but of course all the proprietary extensions were still there from the battle with Netscape. If Communicator had beaten IE I doubt it would be considered any better as a browser.

    83. Re:Dumb idea. by Anonymous Coward · · Score: 0

      This is a really good question.

    84. Re:Dumb idea. by exomondo · · Score: 1

      How many times did your C64 get a virus and drain your bank account?

      How many times has that happened to you on other platforms?

    85. Re:Dumb idea. by Anonymous Coward · · Score: 0

      Ok, well...

      You can do a BIG update after a LONG period of time, or you can do more, smaller updates, more frequently.

      Likely you will overall spend slightly more overall effort on the more frequent, smaller updates, but on the other hand, the risk of big problems is drastically reduced. Big updates mean that:
      1. You are very out of date more of the time
      2. You are more likely to have security problems
      3. When you do the big update, you will have bigger problems

      The "I just updated to IE 8 and my favorite site no longer works" kinds of problems.

    86. Re:Dumb idea. by thePowerOfGrayskull · · Score: 1

      So what you're saying is that modern web dev means implementing workarounds for platforms that don't support the technology you want to use, resulting in maintaining multiple branches of your web "application"?

      How is this different from yesterday's web dev again?

    87. Re:Dumb idea. by oiron · · Score: 1

      It's poor for sales in a consumer-driven environment.

      I'm not talking about an internal ERP for a corporate which wants to track everything. I'm not talking about a stock market system that needs to work on sub-second precision. I'm not talking about a SCADA that controls a 200 acre industrial installation.

      I know that the technology behind iOS/Android had been available for at least a decade before they actually came out. Blackberry had the field back then. I've seen and operated the HP Windows tablets of the mid 2000s. Why have those efforts failed?

      One answer: They all targeted multi-year-patience corporates. Apple and Google targeted consumers. Individuals who don't have either the money, or the patience to wait for two years while you painstakingly figure out every standard, work out every bug, and produce a quality product that costs about 10 times more. In the consumer world, he who's first to market has the mind-share.

      Another: A large corporate might be perfectly happy setting up an enterprise Exchange and Sharepoint server, configuring everyone's computers and mobiles to use it, and maintain a large IT workforce to do all this and solve all the problems that would come up. A small business is never so lucky. Any system that's easily deployed and has minimal maintenance is a win. That means cloud, that means web, and that means simplified consumer devices like the iPhone and iPad. It also means that holding up the progress of standards until we "get everything right" is just too slow.

      To your specific question: Could you ever browse Wikipedia with your C64? Or play Crysis? Or even Angry Birds (with current graphics, not 8 bit ones). Or even, for that matter, compose a document with pictures in it?

      What the "industry" - a nebulous concept in itself - needs, is hardly something we can work out. Different consumers need, or want, different things. One size fits all doesn't work!

    88. Re:Dumb idea. by Anonymous Coward · · Score: 0

      ...how buggy IE has historically been.

      Boy, that made me laugh!
      Have you ever see the first netscape?

    89. Re:Dumb idea. by Xest · · Score: 1

      Possibly. To make it worse though I updated my copy of Firefox at work today, and whilst I have the new home button, I have the old back button still rather than the new one. Both machines are Windows 7 x64, and both versions identically configured. It seems the changes aren't even consistent so you get UI differences now depending on some entirely non-obvious variable.

    90. Re:Dumb idea. by CrashNBrn · · Score: 1

      Worse still is Opera's silent update of the override.js file. You don't get prompted for the update, and there is no way that I can see to revert it back to a working copy. I've used Opera since 2000/2001, but in the last few years stability has gone out the window, and I can't rely on it at all. When a silent "overrides.js" update breaks html running on localhost that is a major f'ing problem --- considering that overrides.js is supposed to be site specific - and it damn well isn't.

    91. Re:Dumb idea. by CrashNBrn · · Score: 1
      I know. It's completely ludicrous that CSS spec has never implemented basic inheritance or simple variable assignment.

      Even a simple/basic web-page is likely to have an unholy combination of CSS, JS, PHP (or other serverside language) and some version of HTML.

      The whole theory behind CSS is a bad joke. In no other program (Word Processor, Spreadsheet, etc) or programming language do you have this idealogy of complete separation of content from how it is displayed.

      Imagine if you will, if HTML had never implemented the display of text outside of a tag... you could write clean "HTML"

      if( $foo == "bar" )
      ____ [text][p]Foo is equal to bar[/p][/text]
      else if( $foo == "foo" )
      ____ [text][p]Foo is equal to foo[/p][/text]
      endif

      Or even giving "$" or "#" over to a variable indicator.

      if( $foo == "bar" || $foo == "foo" )
      ____ [text][p]Foo is equal to $foo.[/p][/text]
      else
      ____ [text][p]Foo: ERROR, invalid![/p][/text]
      endif

      Or use curly-braces if one prefers. With basic inclusion into the spec, you could easily support { } syntax as well as end-[logic Keyword] without necessitating Python's whitespace flow-control.

      One would not need to be concerned on whether JS has been disabled (user-side) as HTML could of been a complete language, including logic and flow-of-control instead of being what we are most likely stuck with.

    92. Re:Dumb idea. by Eponymous+Hero · · Score: 1

      currently browsers can't agree on what canvas is able to do, so we already have no such thing as fully html5 compliant.

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    93. Re:Dumb idea. by nullchar · · Score: 1

      What sucks are HTML5 *validators* - in-browser validation extensions/add-ons that can quickly view the source of the page and identify errors. XHTML 1.0 was awesome for this. The HTML Tidy extension for Firefox immediately finds trivial errors (I use the SGML parser) that are easily seen when validating server-generated pages.

      I'm totally fine with a "living" HTML5 specification - as long as there is some programmatic way of validating the document.

    94. Re:Dumb idea. by datavirtue · · Score: 1

      Uh, new features not working like HTML5 and CSS3. That's enough.

      --
      I object to power without constructive purpose. --Spock
    95. Re:Dumb idea. by Anonymous+Brave+Guy · · Score: 1

      In a few minutes, I'm going back to work on a web-based project that uses several parts of both HTML5 and CSS3, and which runs just fine on IE9.

      Perhaps you mean some subset of HTML5 and CSS3, possibly one that also isn't actually standardised yet, and that isn't supported reliably and portably by other browsers either, and where as a result few real-world projects are actually using the features yet anyway?

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    96. Re:Dumb idea. by cboslin · · Score: 1

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

      Well at least one of the Mozilla developers is slowly coming to their senses and seeing how this 6-week inflated version number is more harmful then helpful.

      http://evilbrainjono.net/blog?showcomments=true&permalink=1094

      Great article and thanks for sharing the link.

      I have yet to find another browser that takes a users Privacy and honestly treats them right as Firefox historically has. I am more concerned that the rapid release update/upgrade cycle will eventually result in some proprietary feature diminishing my ability to 100% control my privacy online.

      This is my main concern with the divergent HTML 5 standards as well. When a new feature ONLY works with a minority of the available browsers, its a fail no matter the reason, even if because its a living standard. Sounds like a pathetic excuse NOT to be compatible. ..but its a living standard.

      Chrome will never be an option as it only allows the user to control the main site cookie and does not allow individual control over each and every advertising, tracking and flash cookie. Firefox has always allowed this via the Exceptions-Cookies dialog. This does not exist in Chrome, most likely never will. Being faster is NOT enough.

      IE/MS violated my trust years ago, more than once...they will never be a viable option either. Not going to put myself back there. Even when everyone was wasting time developing IE hacks, I learned a simple truth, if you develop your site with HTML that works in Netscape (back than) / Firefox (today) than other browsers will render it correctly, unless MS does not want them too. However the converse is rarely true. if you develop in IE first, you can guarantee that one or more HTML IE-ONLY statements will prevent proper rendering in other browsers. Thus wasting time on specific hacks is just that a time sink and best to be avoided.

      I too am concerned when others are lied to (what the update/upgrade will do eventually) as many posters have commented about. Changing the UI in such away that the user can not preform their work flow (because options/buttons are missing after the update/upgrade) will always be wrong. It should never happen, but it does, doesn't it. Pathetic.

      Great article, here and on that blog!

      Ken;s comment in that article talked about spinning the reason for the update/upgrade to a positive. I don't want spin, I want honesty, I want reliability, I want to control 100% when my work flow is interrupted through an update/upgrade. No matter what that update/upgrade is intended to do. Anything less and my investment in hardware and software is negated and my machine becomes an expensive paper weight.

      I see the same thing here...living standard...pathetic. Don't misinterpret, I want to see these new HTML 5 commands, especially the ones that will allow a smart Linux handheld to run a web app when NOT connected to the Internet (or the cloud). Those HTML 5 commands should work in all the major browsers without exception...Major browsers being FF, Opera, Chrome, Safari, IE at a minimum. There is one other, just does not come to mind at the moment.

      I do read the security updates and 8 out of 10 times, the exploit being prevented requires 'local' access to my PC and I already know that is NOT going to happen, thus not worth interrupting my day to proceed. I will never give the keys to my home to another, thus no one will ever get 'local' access to my machine to attempt an exploit.

      Eventually, via rapid release, the users wishes get ignored and an update/upgrade proceeds without the users permission. At that point the developers have irreversibly failed. At that point you taint the user's TRUST in your product. TRUST takes years to build, but

    97. Re:Dumb idea. by SuperMillo · · Score: 1

      Hey Brave Guy, would you shoot me a private email please?
      Thanks!
      Ciao!

      M___

  3. How long until by Anonymous Coward · · Score: 0

    We start seeing "best viewed in chrome" animated gifs?

  4. Newsflash! HTML5 fork now an official Google BETA by Anonymous Coward · · 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 ...

  5. ...now you have to ask yourself 'Which HTML5?'" by ClaraBow · · Score: 5, Insightful

    The one supported by by Webkit and Gecko?

    1. Re:...now you have to ask yourself 'Which HTML5?'" by Anonymous Coward · · Score: 1

      The one that'll have new features added to it BEFORE said features are superseded two generations down the line?

      "Now, j-just hold your horses, people, we just got wind of this new technology called 'vectors'. We're going to work on adding them into the standard sometime before 2021. We might even devise some clever mechanism so somehow move them around programmaticly before the turn of the century! What's more, we hear there's this strange concept starting to gain momentum... let me see if I can describe this to you: Apparently, human beings have this... I don't know how to describe it, some manner of detecting vibrational energy in air molecules. Said energy travels in waves, as we understand it, and the best we can figure, it mostly enters those ear-holes on the sides of our heads, those things science hasn't been able to identify a use for yet. I don't know what to call this concept, but I'm very convinced that in as short a time as 2525, if man is still alive, if woman can survive, they may find that we might be able to start a draft standard that COULD allow browsers to utilize it!"

    2. Re:...now you have to ask yourself 'Which HTML5?'" by Billly+Gates · · Score: 1

      The one supported by by Webkit and Gecko?

      Indeed. That is already a problem?

      To me HTML 5 is too ambitions and big like trying to swallow a horse rather than one bite at a time approach. I think it should be split into several versions of HTML 5,6, and 7 etc.

    3. Re:...now you have to ask yourself 'Which HTML5?'" by lennier1 · · Score: 1

      Judging by the spelling error up there we'll need to use one of the Wing Commander games to view the content.

    4. Re:...now you have to ask yourself 'Which HTML5?'" by Anonymous Coward · · Score: 0

      How about a standard that standardized a way to add extensions. Something like... XHTML 2.0.

    5. Re:...now you have to ask yourself 'Which HTML5?'" by cpu6502 · · Score: 2

      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/

      "Your browser does not support this site. Try Google Chrome." Oh go shove it up your ass Microsoft clone.

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
    6. Re:...now you have to ask yourself 'Which HTML5?'" by Anonymous Coward · · Score: 0

      Try and set USER AGENT as chrome.

    7. Re:...now you have to ask yourself 'Which HTML5?'" by Anonymous Coward · · Score: 0

      Try and pull the hair out from around your poohole.

    8. Re:...now you have to ask yourself 'Which HTML5?'" by thePowerOfGrayskull · · Score: 1

      It was a project made by google labs for the google browser. The reason for it not to support Opera 11.6 could be as simple as the people who maintain it don't wnat to have to test it across multiple browsers -- you know, the kind of thing an actual stable standard would render unnecessary, thus making it more likely that these projects could support multiple browsers...

  6. I have mod points by LilBlackKittie · · Score: 5, Insightful

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

    1. Re:I have mod points by Anonymous Coward · · Score: 0

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

      They're standardizing the new markup for dropping a temblor bomb on Azeroth.

    2. Re:I have mod points by msauve · · Score: 1

      It was obviously written by a guy from WHATever.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
  7. How can a standard be "living"? by An+Anonymous+Coward · · 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.

    1. Re:How can a standard be "living"? by Anonymous Coward · · Score: 0

      Unfortunately, web is a fast moving target.

    2. Re:How can a standard be "living"? by gtirloni · · Score: 1

      Too bad for the web then. If there are many competing "standards" and a browser can, or cannot, support some of them at some point in time.. that just makes it difficult for everybody. Good standards are difficult to create however getting acceptance is a even more difficult task. If they are changing all the time it really doesn't help anymore. BTW, the web is fast moving target? Only if you mean at layer 7 and above.

      --
      none
    3. Re:How can a standard be "living"? by Anonymous Coward · · Score: 0

      Yes.

      What we're going to see is web pages that won't load correctly because one's particular web browser hasn't yet incorporated the latest "standard". We're going to go back to the days where we're going to see "This website works best with xxx browser; version y.z"

      Web devs, go with the W3C standard and save yourselves a lot of support issues and pissed off customers.

      - Just an old fart who's been there.

    4. Re:How can a standard be "living"? by Anonymous Coward · · Score: 0

      Yo dawg, we herd you like standards. So we put a standard in your standard, so you can develop while you develop!

      Werd!

    5. Re:How can a standard be "living"? by thetoadwarrior · · Score: 1

      And if you make it too fast it ruins it for a lot of people. There is no reason the HTML5 standard needs to change that often if it's well thought out in the first place.

    6. Re:How can a standard be "living"? by colinrichardday · · 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.

    7. Re:How can a standard be "living"? by crankyspice · · Score: 1

      +1

      --
      geek. lawyer.
    8. Re:How can a standard be "living"? by Anonymous Coward · · Score: 1

      A constantly evolving standard creates a moving target, which I believe is actually counter-productive.

      What if they could guarantee that all new features would be added in a backward-compatible way?

      Take video for example -- right now it's a mess that will take some time to clean up. Instead of waiting around for that to happen, they could publish standards for the features that are ready, leaving out video for now. Then once video gets cleaned up, they can amend the standard in a backward-compatible way.

      Would that really be a "counter-productive" approach? Or would that just be trying to make the best of an unfortunate reality?

    9. Re:How can a standard be "living"? by cpu6502 · · Score: 1

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

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
    10. Re:How can a standard be "living"? by nine-times · · Score: 1

      Well yes, it is a bit of an oxymoron, but it's not quite nonsense. They can try to codify sensible conventions for the current state of the art and say, "this is our thinking, as of today, on how things should be done." Developers could then use it as a reference, even if it's not quite a stable standard they can rely on.

      As new technology comes along and people are racing to make use of it, it probably makes sense to have somebody trying to set best practices ASAP, and hash out problems as they go. However, I think it's still important to trail along behind and develop a coherent and consistent standard that is more reliable.

    11. Re:How can a standard be "living"? by theshowmecanuck · · Score: 1

      Even the agile fanatics use the fact that shooting at a moving target is a bad thing and is the reason they have their scrum masters to keep the business which is constantly changing their minds off their backs until they at least finish something. And these are the guys who don't like documentation. Point in time snapshots of the standard is absolutely required when the number of organizations that need to synchronize is so vast. Otherwise we drift back to having to have hacks for every browser and piece of web technology or risk no communication at all. Hmmmm.... maybe the anti-internet RIAA and assorted SOPA Freaks are behind this. Nah that would be too much of a conspiracy. :)

      --
      -- I ignore anonymous replies to my comments and postings.
    12. Re:How can a standard be "living"? by pentadecagon · · Score: 1

      It is backwards-compatible, so what works today will most likely work tomorrow as well. There is no other way. Maybe stay with HTML 4 until HTML 5 is finished? But of course, it's much easier to whine and complain than coming up with a better proposal.

    13. Re:How can a standard be "living"? by Zontar+The+Mindless · · Score: 1

      Yes (almost).

      Except there won't be any "version y.z" thanks to this rolling release bullcrap.

      (I would LOVE to see us try that with our users. We'd be out of business in 6 months, tops.)

      --
      Il n'y a pas de Planet B.
    14. Re:How can a standard be "living"? by CrashNBrn · · Score: 1

      Which begs the question why did we have to go over 10+ years before it's fully coming to light what a clusterfuck webdesign is. Completely ass-backwards to every other language one can program with. I'm not positive, but I bet I could layout a page with content and colors easier on a Commodore64 with Basic than trying to deal with HTML/CSS/JS and possible server-side controllers (PHP et al).

  8. Why would they do this to us by Anonymous Coward · · Score: 0

    We were only 10 years from something beutiful...

    captcha is "savaging"

  9. Slow down by MS · · Score: 5, Insightful

    The whole world should slow down. Stick with a stable standard for a while. And relax.

    1. Re:Slow down by CanHasDIY · · 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.

      --
      An enigma, wrapped in a riddle, shrouded in bacon and cheese
    2. Re:Slow down by Billly+Gates · · 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?

    3. Re:Slow down by foobsr · · Score: 1

      The whole world should slow down.

      The Day the Earth Stood Still ...

      Well, probably.

      CC.

      --
      TaijiQuan (Huang, 5 loosenings)
    4. Re:Slow down by foobsr · · Score: 2

      We need to speed up! ... Why should the best experiences ...

      The more speed, the less experiences.

      CC.

      --
      TaijiQuan (Huang, 5 loosenings)
    5. Re:Slow down by Anonymous Coward · · Score: 0

      I'm too busy sucking down a triple shot latte macchiato with soy milk to relax.

    6. Re:Slow down by jklovanc · · Score: 2

      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 only three years old. You may see that as a long time but companies who have invested large sums of money in a web site see it as very short.

      In effect a developer has a choice between targeting an non-cutting edge standard or greatly increasing their budget to deal with multiple standards and continue to pour money down that hole as standards change. Again the business decision is pretty clear; go with the non-cutting edge standard.

      Living standards are useless. It is very simple to write a standards that says a browser should do such and such when presented with this new tag. It takes time to work through how those new tags interact with existing tags and decide how conflicts are handled. What if the new tag is inside this other tag? What if it is wraps this other tag? That analysis has to be done for every tag in the standard. When that is done then the browsers have to be written, tested and deployed. It takes a lot of money to write browser code and I doubt very much that any company if ever going to keep up with a "living standard".

      Browsers will always lag behind standards due to implementation time and sites will always lag behind browser due to audience concerns. In the end, if HTML 5.99 appears in a couple of years I bet that most browsers will still be at HTML 5.20 and most sites will still be at HTML 5.0.

    7. Re:Slow down by cpu6502 · · Score: 1

      >>>Stick with a stable standard for a while.

      What? You're not interested in my new Superdooperlooper Bluray version 26 that Sony just developed last week? Awww c'mon! Everybody knows Blurays work* better with a "living" standard..... and besides it has 20 layers, 2 terabytes, and 4000x2000 resolution!!! You'll love it.

      *
      *Downloaded firmware will not work with any BD-Player slower than a 3GHz embedded CPU. (It's Apple-style planned obsolescence.)

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
    8. Re:Slow down by cpu6502 · · Score: 1

      >>>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 :-o Well DS that's because your phone is only ~720x640 resolution while the PC is 1920x1080 resolution. The browser on the PC has to move almost 5 times as many pixels. If your 1GHz phone had to move that much data, it would probably look like my old 1 GHz laptop. (st-st-stutter, stutter, st-st-stutter, stutter).

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
    9. Re:Slow down by gbjbaanb · · Score: 1

      I suppose they could stick with stable HTML5 that W3C supports and properly defines (and clarifies, obviously, like its not clear enough as it stands) while WHATSIT (never heard of them TBH) starts work on HTML6 that remains bleeding edge/unstable until ratified by W3C.

      I guess that's too simple for a standards committee though.

    10. Re:Slow down by cpu6502 · · Score: 1

      FIXED:
      >>>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

      :-o Well DS that's because your phone is only ~720x640 resolution while the PC is 1920x1080 resolution. The browser on the PC has to move almost 5 times as many pixels. If your 1GHz phone had to move that much data, it would probably look like my old 1 GHz laptop. (st-st-stutter, stutter, st-st-stutter, stutter).

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
    11. Re:Slow down by Billly+Gates · · Score: 1

      My comment had to do with GPU acceleration too. Your 1 ghz on XP probably doesn't do it at all. A phone will. IE 9 does it fully. Chrome is getting close as that and Mozilla partially do it under Windows 7. YOu can enable it fully on Chrome with about:flags but it doesn't use DirectX11 which can do font smoothing and other effects due to supporting ancient XP.

      The other point was that sites dumb down their CSS 3 content on the web due to ancient browser support while they use if fully for the IPHone and Android as they know it is a modern web rendering engine on the inside. So the okcupid applet on my phone looks better than the website on a desktop browser as an example.

      Moving standards forward faster with better browsers will fix this and it is bizarre that a powerful desktop has to be neutered for corporations and grandmas running IE 8 and earlier.

    12. Re:Slow down by Waccoon · · Score: 1

      You mean HTML4?

    13. Re:Slow down by Anonymous Coward · · Score: 0

      In terms of your sig. I hardly use 8 gigs at all and that is with an VM or 2 opened mixed with Chrome with +30 tabs plus Office 2010 on. I have a 2.6 ghz Phenom II as well and it is fine. i5 is more than enough if you have a 10 year old computer and it is my educated guess you are not a power user at all based on your hardware :-)

      Get an i5 laptop with a decent GPU with 8 gigs and it will last many years.

    14. Re:Slow down by Billly+Gates · · Score: 1

      Developers viewpoint?

      Wouldn't it be great to write one test case for a certain standard of CSS and HTML 5 features. You write them and they work flawless with all browsers! That is the goal here and IE 8 has a crappy ancient javascript engine though it does try to correct its mistakes from IE 6 with rendering Html and css.

      It is not standard and proprietary and needs to go. You would not in 2001 when IE 6 came out be told oh, this product needs to support Netscape 3 and IE 4 because it is 3 years old. Perhaps we should standardize on that until 2006?!

      Hell no. Browsers change in 6 weeks and if a standard is selected it makes your job easier as it gives incentive for the web to ignore users on 3 year old browsers. IE 10 is about down too I may add. It is silly to be spending millions today to upgrade to IE 8 when it is already obsolete and IE 9 is about to go out of date.

      But a site made for IE 9 will work for almost any other browser including IE 10. The latest standard will free up your time and a browser will be just a browser again and not a whole browser-like mess that IE and Netscape were in a battle to proprietize the web.

    15. Re:Slow down by Anonymous Coward · · Score: 0

      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.

      That is the most insightful observation ever expressed in written word, a rose that one must really stop and smell.

    16. Re:Slow down by jklovanc · · Score: 1

      It is not standard and proprietary and needs to go.

      Agreed but not right now. What happens to all the sites that are designed for IE 8? Do they just disappear? IE 9 has only been out for a bit over a year and that is a bit too soon for it to be the oldest supported browser.

      It is silly to be spending millions today to upgrade to IE 8 when it is already obsolete and IE 9 is about to go out of date.

      Agreed but I was not talking about upgrading. It is also silly to throw away all the investment in IE 8 sites and have to re-design and re-program them for IE 9 when they work just fine in IE 8. I am not talking about new sites; I am talking about legacy sites that work fine in current browsers but might not in future browsers.

      The latest standard will free up your time and a browser will be just a browser again and not a whole browser-like mess that IE and Netscape were in a battle to proprietize the web.

      Chasing changing standards and standards becoming obsolete does not "ree up your time" it just make you re-program the same site over and over because it needs to be done a little differently in the new standard and the old standard no longer works.

    17. Re:Slow down by shutdown+-p+now · · Score: 1

      We did it in the 1990s and survived fine and innovation followed and all was good

      Ugh. Do you actually remember what the Net was like in late 1990s? Banners like "this site is best viewed in NN", which slowly transitioned to "this site is best viewed in IE" - both being lies, since it wouldn't be viewable in the other browser at all. Wonders such as two incompatible ways to do overlapping layers, or such design gems as BLINK and MARQUEE elements.

    18. Re:Slow down by pentadecagon · · Score: 1

      The most important part is missing from your proposal: What would that standard be?

    19. Re:Slow down by MS · · Score: 1

      A new standard every 5 years for example. Since HTML is around since 1994, HTML5 would be out in 2014. Developers can easily adapt, and wouldn't have to support other version than the current one and its predecessor... 5 years is also enough time to reach a "stable" and mature standard.

    20. Re:Slow down by Zontar+The+Mindless · · Score: 1

      FYI, I view all posts containing the string "smooth crisp texts" with a -1 modifier.

      --
      Il n'y a pas de Planet B.
    21. Re:Slow down by Anonymous Coward · · Score: 0

      When I subtract 1994 from 2014... I get 20, not 5. What base are you working in?

    22. Re:Slow down by MS · · Score: 1

      Think a moment before posting:
      1994 HTML1
      1999 HTML2
      2004 HTML3
      2009 HTML4
      2014 HTML5
      2019 HTML6 ...

      q.e.d. :-)

  10. Let me be the first to ask... by Anonymous Coward · · Score: 0

    WHAT The Fork?

  11. Standards compliance with multiple standards... by pegasustonans · · Score: 1

    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.

    --
    And all our yesterdays have lighted fools The way to dusty death. --Will
    1. Re:Standards compliance with multiple standards... by gtirloni · · Score: 1

      Generally agree although reality is a bit harsh on getting everybody to accept any new standard.. let alone multiple new standards. IPv6 anyone?

      --
      none
  12. Code that doesn't compile by Anonymous Coward · · Score: 0

    I read somewhere that there are something like 500 tests for compliance, and that the current "good" browsers are hitting 300-450 of them.

    Stick a fork in this process. It's done. Classic example of the difference between architects and programmers. The programmer's code compiles. The architect's doesn't (and yet they get paid more, respected more, etc.).

    Solution: fire all the architects, release a reference implementation under a permissive OSS license (BSD, MIT, etc.) and make that the standard.

    1. Re:Code that doesn't compile by Anonymous Coward · · Score: 0

      Who's dreaming up that reference implementation?

    2. Re:Code that doesn't compile by colinrichardday · · Score: 1

      The W3C has Amaya.

    3. Re:Code that doesn't compile by siddesu · · Score: 2

      Amaya can't possibly be a reference for HTML5, it only supports XHTML 1.1 or tharabouts.

    4. Re:Code that doesn't compile by colinrichardday · · Score: 1

      Also, W3C touts it as a web editor more than a web browser. Sorry.

    5. Re:Code that doesn't compile by siddesu · · Score: 1

      W3C touts it as a web editor more than a web browser

      But it is quite hard to say which function is the bigger failure.

    6. Re:Code that doesn't compile by Anonymous Coward · · Score: 0

      I read somewhere that there are something like 500 tests for compliance, and that the current "good" browsers are hitting 300-450 of them.

      Stick a fork in this process. It's done. Classic example of the difference between architects and programmers. The programmer's code compiles. The architect's doesn't (and yet they get paid more, respected more, etc.).

      Solution: fire all the architects, release a reference implementation under a permissive OSS license (BSD, MIT, etc.) and make that the standard.

      I hope that's a joke because history has taught us that that crap never ends well. It's practically impossible to create a perfect parser for BASH scripts for example, even though BASH is fully GNU OSS, its syntax is only defined by "what works when you run it" which is full of corner cases and bugs that are not documented such that only running BASH itself will get the proper result.

      Code is not documentation, any programmer who believes in "self-documenting" code is a moron who should not have a job. The purpose of documentation is not to describe what code does, but what it SHOULD do so that the next programmer who comes along can actually tell when its broken instead of being stupid-by-design.

  13. My first thought... by 93+Escort+Wagon · · Score: 4, 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.

    --
    #DeleteChrome
    1. Re:My first thought... by Anonymous Coward · · Score: 5, Funny

      I wouldn't really call Microsoft a follower of *any* standards, but I understand what you're trying to say.

    2. Re:My first thought... by Anonymous Coward · · Score: 0

      There were suggestions (later) that they should have named it WTF, so your first thought might not have been that "wrong".

    3. Re:My first thought... by Jesus_666 · · Score: 0

      Well, at least now Microsoft distantly follows the standard instead of completely ignoring it like before...

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    4. Re:My first thought... by Anonymous Coward · · Score: 0

      Correct, which means that if you don't give a crap about 50% of your potential user-base, then have at WHAT WG's here-today-and-changed-tomorrow napkin scratchings. When stuff blows up in your face, you have only yourself to blame...

      (And BTW, Microsoft's IE 10 will be very HTML5 compliant)

    5. Re:My first thought... by Xest · · Score: 4, 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).

    6. Re:My first thought... by BZ · · 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.

    7. Re:My first thought... by TrekkieGod · · Score: 1

      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.

      Standards should be slow, otherwise you can't have a healthy number of standards compliant competing products.

      Another poster above really said it all. We just need to slow down and take a breath. The biggest problem with chrome and firefox is precisely their unwillingness to just let things sit for a while. It seems that every time I start my browser I get a message saying I need to update it. If you've got a security bug, by all means, fix it immediately. If you're adding new features, I don't want to see a new version in less than a year. I don't want to see a standard change in less than 5.

      --

      Warning: Opinions known to be heavily biased.

    8. Re:My first thought... by Xest · · Score: 3, 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.

    9. Re:My first thought... by BZ · · Score: 3, 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.

    10. Re:My first thought... by Xest · · Score: 1

      "They were failures caused by the spec being deliberately written to not match behavior of already existing and deployed systems."

      If by deliberately you mean they came to a compromise because existing browsers implemented the feature inconsistently, hence the spec made a decision how to implement properly then yes, otherwise no, you're just making shit up.

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

      No it's not, that's what HTML5 is doing and that's why it's failing miserably. The point of a specification is to specify how things should be done, it should focus towards best practice, to raise the standard, not cater to the lowest common denominator anything goes scenario like HTML5 else there's no point even bothering with a spec in the first place.

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

      What are you on about? You use your XML parser for XHTML (including 1 because it's XML, that's kind of the point) and your existing parser for HTML. It's not difficult, in fact, this is exactly what some browsers now do.

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

      Right, so one minute you're pretending there was no transitional tool (XHTML1) now you're complaining XHTML2 did things differently? Again, that's kind of the point. Seems like you just want to slag the W3C off whatever they do, because your argument isn't consistent.

      "No, I'm writing off the particular _approach_ they took to that goal as a pie-in-the-sky project."

      Right, because browser vendors were being childish because it meant they had to start doing things properly, something they decided not to do.

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

      Okay so what changed? why do browsers now support both is this is true? do you think there was some magical breakthrough in computer science that allowed browsers to have two parsers? No, the fact is it was always possible to handle two paths. It's basic software engineering, the parser should be separated from the renderer with an abstraction layer, it shouldn't care how the data is read and again, that's now exactly what happens with browsers supporting both paths.

      Step 2 was never addressed because browser vendors found it too tempting to try and push the web they wanted, rather than the way everyone else wanted.

      It's hard to have a deployment plan if the key players wont play ball making up nonsensical excuses about how they can't have two parsers, something they now magically have.

    11. Re:My first thought... by BZ · · Score: 1

      > If by deliberately you mean they came to a
      > compromise

      No, I meant what I said. Please do go and compare the HTML4 spec to what browsers actually implemented at the time it was written. I'm talking basic stuff like the comment syntax.

      > The point of a specification is to specify how things
      > should be done

      Well, sure. But it needs to do this in a way that interoperates with existing things to some extent if it wants to be successful in the market. Or put another way... if a specification is too wacky, people can't use it in practice even if they want to, and then it fails.

      And to be more precise, a specification should say how things should be done to enable all the various parties involved (software, in the case of the W3C, but for other specifications in other contexts it can be hardware of various sorts) to interoperate with each other. Things like your nuts fitting your bolts, or your web browser understanding the bytes your server sends. If implementing the specification does not in fact allow interoperability to a sufficient extent (and the extent can include legacy systems in many cases), then the bug is in the specification.

      > You use your XML parser for XHTML

      XHTML2 requires different output from your parser than XHTML1 does. For the same input.

      Have you ever actually _read_ these specs?

      > so one minute you're pretending there was no
      > transitional tool

      XHTML1 was a recasting of HTML4 in XML syntax. XHTML2 was a completely unrelated beast that made the mistake of reusing the same namespace for incompatibly functionality. XHTML1 doesn't help you get to XHTML2; arguably it makes it _harder_.

      > why do browsers now support both is this is true?

      Both what? HTML5 doesn't redefine the behavior of HTML4 tags in incompatibly ways. That's one of your complaints about it, in fact, as far as I can tell. But it sure does make it possible to actually implement HTML5.

      > It's basic software engineering, the parser should
      > be separated from the renderer with an abstraction
      > layer

      XHML1 and XHTML2 use the same (XML) parser, by definition.

      The problem, again, is that the two specs require different semantics out of elements with the same namespace and localname. Which happens way after the parser.

      Note that there's a lot of stuff that happens above the syntax level in HTML (everything operating on the DOM, including CSS), and the DOM level is what was incompatible between the two specs.

      > Step 2 was never addressed because browser
      > vendors found it too tempting to try and push the
      > web they wanted,

      OK, so how would you have addressed it if you were a browser vendor?

      > It's hard to have a deployment plan if the key
      > players wont play ball

      Bingo. But I think you have a different impression of what "play ball" means here than I do. The only way to deploy XHTML2 would have been to have a flag day when everyone stopped using XHTML1 and HTML4. And website operators were refusing to play ball on that. Can't say as I blame them.

      > two parsers, something they now magically have.

      Web browsers have an XML parser and an HTML parser. Is that what you mean? Because if not, I'm following. Of course if that _is_ what you mean, I don't understand the relevance, since the XML parser would be used for both XHTML1 and XHTML2... except it would magically need to behave differently for them.

    12. Re:My first thought... by Xest · · Score: 1

      I can't be arsed to respond to most of it because it's largely bollocks, but I have to ask, do you actually have any grounding in software development? Your repeated suggestion that it would be impossible for browsers to support both HTML4/XHTML1 and XHTML2 without some changeover day is fucking laughable.

      How the hell do you think applications such as Word deal with different file formats such as .doc and .docx? It's a long solved problem, if you can't figure out how to implement the relevant abstractions to be able to support multiple document formats you have absolutely no business whatsoever writing something like a web browser.

      It is not an unsolveable problem, on the contrary, with a bit of competence it's a trivially solvable problem, even if it means supporting different DOM implementations. Suggesting magically behaving different is magic is absolute madness. Even a 1st year software engineering undergrad could tell you how to achieve it.

    13. Re:My first thought... by yuhong · · Score: 1

      BZ is a Mozilla developer.

    14. Re:My first thought... by BZ · · Score: 1

      > How the hell do you think applications such as
      > Word deal with different file formats such as .doc
      > and.docx?

      Easy. You don't have requirements about being able to move things from one to the other in unconstrained and non-opaque ways like web pages do.

      > even if it means supporting different DOM
      > implementations

      You have to be able to move elements from one DOM to the other whenever script decides to do it. That's the whole problem, as you would have realized if you'd taken a moment to think about this instead of assuming that everyone else has no idea what they're doing.

      Of course with enough effort and pain and memory usage and indirection this is all achievable. You _can_ get to a world where two elements with the same tag name and namespace in the same document have totally different DOM behavior. It just means you can't serialize that document as XML. And violates some other W3C standards. But it _can_ be done.

      Then the question becomes whether creating an inconsistent and confusing system that violates existing standards is better for the world than just ignoring XHTML2. This is indeed debatable, but in practice most people decided it's not.

      And yes, I do have some grounding in software development. Both academic and practical. Though I've only been working on web browsers for about 12 years or so; obviously there are people who have more experience than me.

    15. Re:My first thought... by RebelWebmaster · · Score: 1

      but I have to ask, do you actually have any grounding in software development?

      lol, facepalm

    16. Re:My first thought... by Xest · · Score: 1

      Thank you, it's a shame he couldn't disclose his bias himself as is normal in such discussions.

    17. Re:My first thought... by Xest · · Score: 1

      "You have to be able to move elements from one DOM to the other whenever script decides to do it. That's the whole problem, as you would have realized if you'd taken a moment to think about this instead of assuming that everyone else has no idea what they're doing."

      This simply isn't true. You can perfectly well move content between different versions of Word/Excel documents using VBA.

      "Of course with enough effort and pain and memory usage and indirection this is all achievable. You _can_ get to a world where two elements with the same tag name and namespace in the same document have totally different DOM behavior. It just means you can't serialize that document as XML. And violates some other W3C standards. But it _can_ be done."

      Again, this is simply false. Why would your in-memory representation effect your serialisation to/from XML? Again, it's a pretty basic software engineering task to separate this sort of thing. Is the Firefox code base such a mess that it can no longer be properly architected without a re-write or something?

      "Then the question becomes whether creating an inconsistent and confusing system that violates existing standards is better for the world than just ignoring XHTML2. This is indeed debatable, but in practice most people decided it's not."

      Sure, "Most people" being a handful of self interested browser developers who apparently had no idea what they were doing. In fact, most people - i.e. by far the democratic majority were behind XHTML2 until browser devs scuppered it.

      "And yes, I do have some grounding in software development. Both academic and practical. Though I've only been working on web browsers for about 12 years or so; obviously there are people who have more experience than me."

      Right, well thank you for at least partially admitting where your bias stems from, although someone else had to disclose you're a Mozilla developer for me. I'm not suprised therefore that you're making excuses, because obviously this makes you part of the problem. It's no wonder browsers have consistently failed to implement standards, and even HTML5 is no different if the code bases are developed by people who simply cannot figure out how to decouple different sections of a system.

    18. Re:My first thought... by BZ · · Score: 1

      > You can perfectly well move content between
      > different versions of Word/Excel documents

      Please read what I said more carefully. I addressed this.

      > Why would your in-memory representation effect
      > your serialisation to/from XML?

      Because what's serialized is the localname and namespace, and those are identical for the two elements that are supposed to have different behavior. Again, did you actually read what I wrote?

      I think we're done here, since you've moved on to ad hominem attacks....

    19. Re:My first thought... by Xest · · Score: 1

      "Please read what I said more carefully. I addressed this."

      The only address you made was to imply that Word is somehow different because you have to cater for interaction between two different versions in HTML when scripts interact with them. I pointed out that this isn't in fact any different because other applications, such as Word, do exactly this.

      "Because what's serialized is the localname and namespace, and those are identical for the two elements that are supposed to have different behavior."

      Yes, and you know what version you're dealing with and serialising to/from using the DTD, so there's no issue. This is a common problem in software, software dealing with multiple protocol versions for example also deal with this sort of thing all the time in that they have to alter their input/output, and how features are handled for the user based upon that. The key is good versioning information, and up until HTML5 we had that. Good versioning is not exactly something Mozilla has shown any competence in in recent times though, despite much of their userbase telling them how stupid the new versioning system is, so again, perhaps there is a culture problem there that leads to failing to grasp the importance of that.

      "I think we're done here, since you've moved on to ad hominem attacks...."

      Ah I see, so now it's clear that you're not exactly approaching the discussion from a neutral standpoint you cry foul?

    20. Re:My first thought... by BZ · · Score: 1

      I never claimed to be "neutral", but you're trying to focus the discussion on claims that I personally am incompetent instead of the actual issues.

      > other applications, such as Word, do exactly this.

      No, they do not. They expose foreign objects through abstraction layers of their choosing, while web browsers have to expose everything through the DOM, which exposes all sorts of implementation details.

      > so there's no issue.

      Sure there is. Once nodes can be moved via script, your DOM may no longer match your DTD, because a DTD is a _syntax_ description.

      Seriously, please go and look through XHTML2 and think about what would be involved in implementing a UA that has to allow mixing XHTML2 and XHTML1 in the same document, which is what web browser would be required to do.

    21. Re:My first thought... by Xest · · Score: 1

      "Sure there is. Once nodes can be moved via script, your DOM may no longer match your DTD, because a DTD is a _syntax_ description."

      Apologies, I'll try and be more clear, I wasn't referring to usage of the DTD itself to help define the DOM but merely to the fact your doctype declaration defines the version of the markup from which the DOM is created, and can hence be used to determine how the DOM can be manipulated, any cross-version DOM manipulation can similarly be handled based on the version information provided. The key is simply to ensure version information is available when handling manipulation - this is again exactly how many protocols work.

      It's not going to be the most simple task to do throughout, but it's far from a particularly complex task. I've architected and worked on many business systems that deal with far more numerous and far complex DTDs than those provided by XHTML1 and 2, which result in in-memory representations that ultimately need to communicate in different manners based on their origins and I still simply don't see anything intractable about producing something that will handle both XHTML1 and XHTML2.

      Do you have any examples of specific problems you feel would not realistically be solvable?

    22. Re:My first thought... by BZ · · Score: 1

      The basic "insoluble" problem is that XHTML1 and XHTML2 share a namespace. XML and the DOM specs define that the behavior and semantics of nodes depend only on their local name and namespace. But XHTML2 reuses some local names from XHTML1 but assigns different semantics to them.

      Tracking origin information in memory _could_ be done, but it would result in bizarre behavior where you recreate a node in a way that XML and the DOM say should give you the same thing as you already have ... and it doesn't.

      Now obviously changes could have been made to the XML and DOM specs to allow this all to work somehow, unintuitive as it would be, but the W3C wasn't willing to do that, unfortunately.

    23. Re:My first thought... by Xest · · Score: 1

      "The basic "insoluble" problem is that XHTML1 and XHTML2 share a namespace. XML and the DOM specs define that the behavior and semantics of nodes depend only on their local name and namespace. But XHTML2 reuses some local names from XHTML1 but assigns different semantics to them."

      But again, this isn't an uncommon problem in software engineering, it's simply a case of determining what actions you should take based on what version of the namespace you're dealing with, the fact you have the version information makes it trivial to do that.

      "Tracking origin information in memory _could_ be done, but it would result in bizarre behavior where you recreate a node in a way that XML and the DOM say should give you the same thing as you already have ... and it doesn't."

      Once more it's not uncommon to solve this problem though. Sticking to the same example as before, if you transfer content between versions of Word you have to accept some limitations will be imposed on that content in some cases. This really isn't a new thing, and for the relatively few cases where people would want interop. in script between XHTML1 and XHTML2, and for something that would in effect merely be a transitional stage, it doesn't seem much of a big deal. It's certainly far better than the current status quo which has instead just chosen to take the rather backwards step of using standards to make abysmal quality markup the standard, rather than the XHTML approach which was to up the standard of markup meaning markup would be far more flexible, far more portable, and far more interoperable. The W3C approach was never going to be fast, it takes a long time to transition, but people were moving their markup to XML syntax, even if they weren't serving as XML, and that was a massive first step. The problem is that HTML5 seems to actively discourage the XML route (and yes, I've read Ian Hickson's rant about XML, but it's mostly FUD, arguments such as "different browsers render XML when not served as XML differently" are retarded in the context of the fact that HTML - even HTML5 with it's defined parsing exactly the same). The discouragement of XML seems to be more about some personal vendetta Ian Hickson has against the W3C rather than as a result of any rational reasoning. Even if WHATWG encouraged the XHTML5 route rather than the HTML5 route it would be something, but the fact they don't do that shows what a pathetic attempt it is at taking the web forward. Arguments such as "People find XML syntax too confusing" are more bollocks than they ever were nowadays, your average joe just doesn't touch the syntax anymore, it's all done through tools which developers develop, and they DO want decent syntax. HTML5 doesn't offer that.

      One personal example I can give is that I had to deal with a system a few years back that was quite old, but not so old that it didn't at least make sure it output XHTML1 seemingly because at the time the product was developed it was a buzzword that gave salespeople a hardon. The product in question was an expert system, a closed source black box, that output XHTML wizard interfaces to work through branches of that expert system to find answers. I was given the task of integrating this into the company's new systems as part of an overall workflow process as an interim measure until a replacement was found, and because it output XML it was actually amazingly simple because I could simply apply XSLT transforms to the output of the system to integrate them directly into the output of the new web based system, and similarly issue responses back to the system in a trivial manner. If this was 10 years on, and the system was using HTML5, rather than XHTML5, then we'd be better just writing it off because the HTML5 standards are so awful that it's unlikely any tools will ever be as good as those available for XML. This is in large part, despite some years having gone by, there are still no HTML5 validators that are anything other than "highly experimental". It's easy for Hickson and co. to bitch abou

    24. Re:My first thought... by BZ · · Score: 1

      See, the thing is that there is no such thing as a "version of a namespace" in XML. Just no such concept. There is just a namespace. What's supposed to happen when you have incompatible versions is a new namespace. But that didn't happen.

      > it doesn't seem much of a big deal.

      It's a huge deal. The corresponding bustage in IE6 where nodes from XHR couldn't be moved into normal documents was a huge pain point for developers until it was fixed.

      > t's certainly far better than the current status quo

      That's debatable, honestly.

      > but people were moving their markup to XML
      > syntax

      No, they were moving it to XML cargo-culting. 99% of the stuff pretending to be "XML syntax" was not well-formed XML.

      > I suspect the core problem here is a clash of
      > ideologies

      To some extent, yes. There _was_ a clash between "write specs that won't work with real-world content" and "write browsers that work with real-world content"...

      But the authoring of self-contradictory specs has nothing to do with desire for stability and everything to do with the fact that the "W3C" is a bunch of independent working groups, composed of independent members, each with their own political, technological, and business ends. Sometimes the whole thing produces standards. Sometimes they're even good. Sometimes, it instead produces a self-contradictory ball of string that can't be implemented, and the you just have to excise enough of the bits to get something sane and only implement that. Which is what happened with XHTML2...

    25. Re:My first thought... by Xest · · Score: 1

      "See, the thing is that there is no such thing as a "version of a namespace" in XML. Just no such concept."

      No, I'm well aware of that, and it's not what I said. What there is is a version of the spec which defines the two conflicting namespaces- you know the version of the spec, hence you know the version of functionality to apply to that namespace, providing you've sensibly ensured you have tracked the version of the spec to be applied to that specific namespace. Again, it's a common solution to a common problem.

      "No, they were moving it to XML cargo-culting. 99% of the stuff pretending to be "XML syntax" was not well-formed XML."

      99% is rather a gross over-exageration. Many, many businesses across the globe don't even hand craft XHTML, it's built automatically using tools like XSLT, so well formedness isn't even a problem.

      "To some extent, yes. There _was_ a clash between "write specs that won't work with real-world content" and "write browsers that work with real-world content"..."

      A spec isn't really meant to work with real world content. A spec is supposed to define what standards content should conform to going forward, that's kind of the point. If you write a spec to define the combined mess that is already there, then what exactly have you achieved? Throwing in a few bones like canvas don't exactly make up for the fact you've really failed to do anything worthwhile standards-wise because a competent standards process would both clean up the mess going forward, and give you those new features to boot.

      "But the authoring of self-contradictory specs has nothing to do with desire for stability and everything to do with the fact that the "W3C" is a bunch of independent working groups, composed of independent members, each with their own political, technological, and business ends." ...and that's different to WHATWG how? the difference is that WHATWG real controllers are a closed group, whilst the W3C's groups were at least open to all members. Further, those groups were still all at least much more represenatative than WHATWG which merely represents a couple of browser developers and nothing more, and again, those groups were at least democratic whilst WHATWG is entirely totalitarian. It's pretty clear that Hickson's personal distaste of XML has been a prime example of personal bias replacing rational decision making- at least in the W3C where there wasn't this King model of leadership, and more rational members of a group could rally against such personal stupidity. With WHATWG you don't have that, if the guy at the top makes a foolish decision and refuses to listen to millions of voices beneath him, you still all get screwed.

    26. Re:My first thought... by BZ · · Score: 1

      > 99% is rather a gross over-exageration

      Not in my experience... I think you underestimate the extent to which XHTML was cargo-culted. I think I've literally run across only 2 or 3 non-example XHTML pages that were actually well-formed over the last 10 years or so.

      > Many, many businesses across the globe don't
      > even hand craft XHTML, it's built automatically
      > using tools like XSLT

      Sure. Though note that it's possible to produce non-well-formed XML even using XSLT (disable-output-escaping, which people use a fair bit). But there are also lots of non-XSLT toolchains that claim to produce XHTML... and just don't.

      > A spec isn't really meant to work with real world
      > content.

      That, right there, is definitely a philosophical disagreement. There are lots of specs out there in which backwards compatibility was a hard requirement during spec development. Especially in the non-web world (gigabit ethernet, USB3, dual-channel DVI, and so on, and so forth). W3C specs were actually really _weird_ in their willingness to throw away backwards compat.

      > and that's different to WHATWG how?

      It's not that different in theory. In practice the set of participants is somewhat different at the moment, as you noted. So there are, for example, few people who are working in the WHATWG to shape HTML around their specific non-web use case.

      Not that the development process for the WHATWG is a picnic, and God knows I've had my share of disagreements with the WHATWG spec, some of them still outstanding. Coordinating thousands of people with differing opinions is really hard. WHATWG is doing ok, but not necessarily great, in my opinion. I understand that you think they're not even doing ok.

      But my personal experience, which reflects the interactions _I_ have had with WHATWG and W3C, is that WHATWG is more willing to at least listen to feedback and respond (if not necessarily take it into account) than some W3C working groups were back when WHATWG was founded. For those working groups, there was _real_ work behind closed doors going on: closed meetings that you couldn't attend unless you paid up, closed mailing lists you couldn't read or post to unless you paid up, closed decision process. Oh, and they were completely ignoring the W3C process requirements to address feedback on the drafts that they were in the end required to publish. _That_ sort of thing has largely gone away in the last 5 years, thankfully, due to WHATWG existing, but back when WHATWG started it was a very real part of trying to deal with the W3C.

  14. W3C should accelerate the process by Billly+Gates · · 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 as well.

    1. Re:W3C should accelerate the process by Anonymous Coward · · Score: 0

      Chrome is open source and is supported on every major platform.

      Neowin is a microsoft shill site, who gives a fuck what they think?

    2. Re:W3C should accelerate the process by Billly+Gates · · Score: 1

      I know it is but the link had a point.

      IE 8 will stick around the corporations for a long time until there is a reason to upgrade. Chrome is not an option PERIOD. No AD support and is released too fast for testing. Having the web not support it is one! Otherwise they would still be running IE 6. Most have left it or are in the process of upgrading as I type this because many sites refuse to support it.

      IF HTML 5 is done and HTML 6 is coming through the other half of the proposals not finished yet that Chrome and Firefox already do it will give a checklist to the beancounters to upgrade and webmasters will be eager to implement them across all modern browsers.

    3. Re:W3C should accelerate the process by Altanar · · Score: 2

      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

    4. Re:W3C should accelerate the process by znrt · · Score: 0

      IE 8 will stick around the corporations for a long time until there is a reason to upgrade.

      the portion of internet web content aimed at corporations is insgnifficant. it's the end-user where the buck lies. corporations mostly use browsers for their own intranet stuff and can happily continue for years with, be it IE or whatever. (if it is IE, at least as long as they choose to pay for explicit IE support on their sw).

      Chrome is not an option PERIOD. No AD support and is released too fast for testing.

      i suspect you're just trying to turn down chrome but i would like to comment on this "too fast for testing" thing. while this is true for chrome and firefox and while i don't quite like it, it shows some actual shift in the browser compatibility world. in fact, as browsers *and* web developers conform more and more to standards, there are actually fewer "compatibilty" issues and fewer testing is at all necessary. things tend to "just work" (apart from IE, of course). this could mean that we are *finally* starting to get things right.

      of course, testing is still necessary but it's far less problematic as it was, say, just 2 years ago. working with products with very extensive compatibility matrixes and very demanding requirements, we've found very few signifficant incompatibilities lately with the release storms of firefox or chrome. other browsers with slower release cycles also have long improved their compliance a great deal (i'm thinking of opera and specially safari).

      regarding TFA ... if as developers we stick to w3c methinks we should be fine. for specific targets/platforms/issues maybe the WTF group comes up with something interesting, that will be great. but that stuff is not likely to get general until approved by w3c anyway.

    5. Re:W3C should accelerate the process by jisatsusha · · Score: 1

      No AD support

      Not true anymore. Chrome Browser for Business.

    6. Re:W3C should accelerate the process by Anonymous Coward · · Score: 0

      >>> That thing is a thorn in our side and it will become the new IE6 of this decade because it comes with Windows 7.

      IE8 came with Windows 7. IE6 came with Windows XP SP2.

    7. Re:W3C should accelerate the process by Billly+Gates · · Score: 1

      Special CSS is proprietary. They exist due to the lack of standards from the W3C which is precisely the point.

      Also the Chrome one uses its proprietary audio api which is not standard at all. That sounds IE 6 ish if you ask me. 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. Again, the result of rushing in and standards taking too long which is the number one rendering bug why older apps can't run on any newer browser.

    8. Re:W3C should accelerate the process by A+Friendly+Troll · · Score: 3, 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.

  15. if they are careful by circletimessquare · · Score: 1

    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 attribute xx. Attribite x never changes.

    It could get messy and very inelegant to remain backwards compatible.

    --
    intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
    1. Re:if they are careful by Anonymous Coward · · Score: 0

      This is how you got the abominations known as IE 6, 7.

    2. Re:if they are careful by foniksonik · · Score: 1

      Is there a rule that all old websites should work? If its being maintained then it will be reviewed and updated. If no then it's probably best that it is broken so people will know it isn't being maintained.

      Old cars that do not meet current safety standards can't be driven on highways. old TVs can no longer be used without an addon tuner. Lead paint can't be used anymore, asbestos is no longer legal for insulation, Windows 95 isn't supported by modern games, etc etc.

      The reality is that HTML from 2000 still works as intended but that's a coincidence. There's no good reason to use it as a reference for a browser in 2012. If you want to archive information, HTML is one of the poorest of options. It is a presentation language only, not a primary source or a data store.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
  16. New naming by Anonymous Coward · · Score: 0

    One should be called Pentiuml and the other Pentiuml 2.

  17. Perfect! by Anonymous Coward · · Score: 0

    I was considering whether or not to implement my new cross-platform application in a web-standard markup language. Now I will abandon all of the retarded HTML for good.

    This news actually makes this choice very easy for me as a developer. I now see the browser landscape as inhospitable for cross-platform development.

  18. Which? Neither. by Dracos · · Score: 2

    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.

  19. What is the point of a living standard by Anonymous Coward · · Score: 1

    Call the standard HTML 5.
    Make sure it's fixed and doesn't change.
    Then you can make HTML 5 extensions or whatever you want to call them,
    and browser vendors can implement them as they wish.
    You could even bundle these extensions into groups that don't change any more, for instance:
    HTML 5 extension set a
    Later these can be incorporated into HTML 6 if needed.
    If you make HTML 5 a "living standard" it becomes useless.
    Saying this browser implements HTML 5 would mean nothing, because next week the standard could be different.

    I hope they at least try to work together to ensure they don't make the two standards completely conflicting.

  20. HTML5 is hell to develop for, will get worse by Anonymous Coward · · Score: 0

    HTML5 is, by any sane definition not a standard. A constantly changing standard is even less sane. The "try to keep up" mantra the WHATWG is pure evil.

    Why? No browser will ever be able to "support" WHATWGs HTML5. So each browser will only support a subset of the current dialect of 6 months ago, at best. One of the symptoms is the current browser-specific CSS3 mess. Developing a website with this mess means not only writing each CSS3 property several times in all webkit- moz- foobar- and plain variants but also cross-testing everything with every browser every release, since almost always something changes there.

    No fixed standard means that there is never any consistent rendering of anything for longer than a few months. Except for the "old HTML5" subset that everybody has already consistently implemented and tested for a year or so. Which is what the W3C ought to use for the standard, so we should applaud them for it. Fixed, tested, proven standards are a good thing. Only remaining question is, what will the standard be named and how does one annotate the version which a document should be compliant to, given the current HTML5 "there is no doctype" crazyness?

  21. Is this Google's influence? by thetoadwarrior · · Score: 1, Insightful

    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.

    1. Re:Is this Google's influence? by Altanar · · Score: 3, Insightful

      Domination through improvement? BTW, the WHATWG is run by people from Mozilla, Apple, and Opera.

    2. Re:Is this Google's influence? by 93+Escort+Wagon · · Score: 1

      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.

      --
      #DeleteChrome
    3. Re:Is this Google's influence? by 93+Escort+Wagon · · Score: 1

      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!

      --
      #DeleteChrome
    4. Re:Is this Google's influence? by thetoadwarrior · · Score: 1

      I'm aware of that. But Google also has the most invested in web applications taking over and always implementing features first gives them the perception of being the most feature filled browser and it may piss off others and then cause them go off and do their thing own thing and it all becomes a mess because we've decided it's better to split off and do our own thing rather than work together.

    5. Re:Is this Google's influence? by thetoadwarrior · · Score: 1

      I'm aware it's not just google. Though Google does have the most to benefit from rapidly push us into a internet only sort of world. Now that they can go off and do their own thing. Why shouldn't Microsoft go off and do their own thing or do it with their own group of companies to lend it more legitimacy. The W3C can die off and we can have a bunch of groups all doing their own thing.

    6. Re:Is this Google's influence? by 93+Escort+Wagon · · Score: 4, 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.

      --
      #DeleteChrome
    7. Re:Is this Google's influence? by BZ · · Score: 1

      > anything Chrome supports will also be supported by
      > Safari

      Not necessarily. Chrome supports WebGL, and has for a while. Safari does not. Chrome supports Theora and VP8 video and Vorbis audio. Safari does not. They have totally separate implementation of requestAnimationFrame, which behave pretty differently. They have totally separate network stacks (and for example Chrome supports SPDY while Safari does not). They have different crypto libraries with different capabilities. They have different JS engines with different capabilities and different levels of support for the ECMAScript standards.

      It goes the other way too. Safari on iOS supports a bunch of -webkit CSS properties that Chrome (and for that matter Safari on desktop) doesn't support. Safari on recent MacOS beats the pants off Chrome in terms of painting performance last I tested.

      Key to all this is that there are multiple different "WebKit"s involved, and a lot of the functionality of a browser is not part of WebKit proper.

    8. Re:Is this Google's influence? by fatphil · · Score: 1

      So its driving force includes the companies who popularised the tag and the one-button mouse.

      --
      Also FatPhil on SoylentNews, id 863
    9. Re:Is this Google's influence? by webnut77 · · Score: 1

      Makes you wonder what portion of the brain that comes form.

  22. "Living Standard"? There is no such thing. by gweihir · · Score: 4, 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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:"Living Standard"? There is no such thing. by Altanar · · Score: 1

      As far as I'm concerned, there's no such thing as a HTML standard. As it is right now, every single browser handles HTML5 in slightly different ways. Every browser has handled rendering differently since the creation of the Internet. I fail to see how this is any worse. There are already HTML5 sites that only work in Chrome. There are a couple HTML5 showcase sites Microsoft had made that barely run in Chrome, but run fine in IE 9/10. I've seen some that only work in Firefox, not Chrome or IE 9/10.

    2. Re:"Living Standard"? There is no such thing. by Anonymous Coward · · Score: 0

      I concur, but not the "easy to implement" part, a standard does not imply "easy" it just everybody understands/use them. It would be nice if one reference implementation for HTML5 come up so the competition goes to features, improvements, and code portability.

    3. Re:"Living Standard"? There is no such thing. by Anonymous Coward · · Score: 0

      A standard is a standard. It is not a moving target. That is its whole point.

      Correct.

      Other things that are mandatory for a standard:
          - simple (or as simple as possible)

      False.

      - clear

      False.

      - easy to implement

      False.

      I think you are confusing standard with good standard.

      HTML is made for flowing text. Things like positioning and scripting are hacks build upon it to make it possible to do things it weren't made to do from the beginning.
      If we are looking for a good standard for web pages today then HTML might not even be the way to go at all. It seems to me that a lot of HTML is written to get around the layout problems that are introduced by having pages based on HTML to begin with.

    4. Re:"Living Standard"? There is no such thing. by Anonymous Coward · · Score: 0

      "A standard is a standard. It is not a moving target. That is its whole point."

      Well, some of the more successful current interweb standards started out exactly like that. Email, for instance explicitly says in one of the RFCs that the point of the updated RFC is to document the evolved practice since the last standard.

       

    5. Re:"Living Standard"? There is no such thing. by Anonymous Coward · · Score: 1

      Every browser has handled rendering differently since the creation of the Internet.

      The internet has been around far longer than the first browsers.

    6. Re:"Living Standard"? There is no such thing. by Anonymous Coward · · Score: 0

      Yes, but these idiots are going down the same path microsoft did by extending things with activex, where instead of HTML5 being supported everywhere it'll have incremental support depending on browser and whatever moving standard release number it targets. We're right back to 1998 and "this site works best with IE" or this site works best with "netscape" except now you can add Firefox and Chrome and then whatever version number of the standard is supported by the version of the browser released on whatever device they are running. Which is exactly the thing that having a standard is supposed to get rid of in the first place.

    7. Re:"Living Standard"? There is no such thing. by BZ · · Score: 1

      The problems start when you create a non-moving-target standard that contains bugs. Little things like self-contradictory language, obviously false statements, requirements incompatible with the laws of physics. Sane standards bodies have an errata process to handle these things. Unfortunately, the W3C is ... not very good at issuing errata in my experience (e.g. it took close to a decade before people gave up on getting any errata issued for HTML4 and created the WHATWG).

      Now some people do thing that "living standard" means "add whatever you want, whenever you want it". That's pretty broken, I agree. But so is never fixing the bugs in the standard.

    8. Re:"Living Standard"? There is no such thing. by gweihir · · Score: 1

      I have no issue with errata. Any good standard has them. And I am aware that the W3C is at least partially to blame for this mess, even if indirectly.

      Still, putting in everything and the kitchen sink means this standard is basically worthless. Not fixing the bugs is a lot better, because for small things like bug workarounds, "industry standards" generally work. Of course YMMV, but my impression is that the WHATWG is not an improvement.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    9. Re:"Living Standard"? There is no such thing. by Damek · · Score: 1

      When it comes to the web and web browsers, a shared grammatic space, you're not engineering anymore, you're growing. Good luck resisting. Authors of dictionaries gave up long ago.

    10. Re:"Living Standard"? There is no such thing. by Anonymous Coward · · Score: 0

      As far as I'm concerned, there's no such thing as a HTML standard. As it is right now, every single browser handles HTML5 in slightly different ways. Every browser has handled rendering differently since the creation of the Internet. I fail to see how this is any worse.

      I assume you're blind, or a teenager.

      During the mid-2000s, standard support was improving drastically. IE6 was the universal boat anchor but Opera and Firefox were converging on consistent rendering to the point of being pixel perfect on the same hardware. (ACID tests for example)

      Then Safari/Webkit came and HTML "5" (infinity more like) in its wake, now we have Chrome and the standard that isn't. This is IE6 redux which pisses us all off because something which had been improving so well is now rapidly diverging into a clusterfuck again.

  23. No shit by Sycraft-fu · · Score: 4, 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.

    1. Re:No shit by Shifty0x88 · · Score: 1

      Well that is part of the problem too, every browser implements things slightly differently, leading to phrases like: "recommended browser"

      This is all going to lead to more: if IE_6, do something, else if IE_7 do something else, else if HTML_5_0 do this, else if HTML_5_1 do that.

      Oh well, its not like standards are suppose to be standard or anything

    2. Re:No shit by Anonymous Coward · · 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/).

      Fundamentally the underlying problem is that WHATWG, as it states in the original reason for it's creation, is that it fo

    3. Re:No shit by Fjandr · · Score: 1

      They wanted to standardize fragmented browser support.

    4. Re:No shit by caspy7 · · Score: 1

      The sound doesn't work in Firefox because they used Flash to implement the audio. I believe Firefox intentionally does not allow mixing Flash & HTML5 in this manner.

    5. Re:No shit by jimshatt · · Score: 1

      Well, I think you're right for the most part. OTOH, W3C was kinda not getting anywhere with XHTML 2.0 and XForms and the likes, so it's good someone kicked up the dust a bit. I don't entirely get the Hixie hatin', but other than that a good read. Thanks.

    6. Re:No shit by theweatherelectric · · Score: 1

      My favourite example is the HTML 5 Angry Birds game.

      Angry Birds Chrome is a poor example of an HTML5 game as it relies on Flash for audio. If I try it with Firefox 14.0.1, for example, without Flash installed I get a message which tells me that I either need to install Flash or use Chrome as it has Flash built-in. Better examples of HTML5 games which work without Flash are Cut the Rope, Pirates Love Daisies, World's Biggest Pac-Man, and Word Squared.

      The development of the first three games was funded by Microsoft to demonstrate that credible applications can in fact be built against an HTML5 runtime. They also demonstrate that there are already high quality applications available for Firefox OS. It's pretty trivial to make them installable on Firefox OS.

    7. Re:No shit by Anonymous Coward · · Score: 0

      I'm a professional web developer who did web applications since back in Netscape 4, and this is seriously the best comment on the current state I have ever read.

      People tend to forget the horrible mess we had with HTML 3, and how only the W3C standardization process saved us from the digital bling (remember the marquee/blink tags?) that the companies had created to woo dumb users.

      Unless it's stable, as in not changing, as a whole, in's by definition not a standard, and any actual professional can't rely on it for any production code. End of story.

    8. Re:No shit by Tablizer · · Score: 1

      You see, you accidentally downloaded Angry Users, not Angry Birds.

    9. Re:No shit by Anonymous Coward · · Score: 0

      Responsive web design is also my pet peeve. To me it tries to kill 3 birds with 1 stone. The problem is the 3 birds are an ostrich, chicken and a swallow. (desktop,tablet,mobile) You can only choose 1 stone so if you take the biggest rock you can find, because that will kill the ostrich, but it is completely overkill for the swallow. This amounts to loading too much data into the low processor device (mobile) and asking it to do processor intensive tasks. (scale images + run js). IMHO the better way is to choose the right stone for each bird.

    10. Re:No shit by mister_dave · · Score: 1

      the semantic HTML tags are less than useless, because they're based on a now obsolete statistical analysis of common ids/classes.

      Schema.org does much the same thing, labelling headers, footers, navigation etc.

      I believe Mr Hickson used to work for Google, perhaps the HTML5 semantic tags were just a search engine wishlist, that they've now decided to push via schema.org?

    11. Re:No shit by Anonymous Coward · · Score: 0

      Semantic markup is on many people's wishlist, starting with Timothy Berners-Lee.

      It would be fucking nice if there was uniform way to tell the browser to only show you <article>s or to make a widget retrieving <comments> from a page of your choice or to create a contact in your phone book based on a contacts page open in your browser.

      Too bad it's all just a dream. We don't even have uniform structural elements, FFS, speaking about semantic elements is just sillly in comparison.

    12. Re:No shit by fatphil · · Score: 1

      There's at least a very long precedent for that. I believe standards committees call this "codifying existing practice".

      --
      Also FatPhil on SoylentNews, id 863
    13. Re:No shit by cshbell · · Score: 1

      I appreciate your passion, but you have a lot of things wrong. Chiefly this: HTML5 is not a singular entity, but rather a broad description of several emerging web technologies. I launched one of the first commercial HTML5 sites on the Web, and in the years since, the meaning of "HTML5" has already changed significantly, and that's okay.

      The semantic HTML tags are less than useless, because they're based on a now obsolete statistical analysis of common ids/classes.

      Nearly every site on the Internet has a header and footer, though; sides/sidebars are pretty common too.

      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.

      I'd like to introduce you to the complexity of human language. This isn't a problem specific to HTML5, or HTML, or heavens, even markup languages. People use words and descriptions in different ways. There is not now, never was, and never will be a singular and coherent semantic structure. What's an article to one person is a section to another.

      It's important to note that the specs you rail against go to great lengths to avoid enforcing a rigid semantic context. The new HTLM5 elements aren't complete, and nobody ever claimed they were. Their role is purposefully vague, giving web authors new markup tags that infer some semantic structure without enforcing precision. I mean, how many hundreds of roles does the good old tag play? Semantically it indicates a heading of some sort, but what that means, precisely, is intentionally undefined -- and it works great.

      The solution to your problem is XML, wherein authors can markup every document with precisely-semantic tags. We tried that with XHTML, and it turned out to be a solution in search of a problem. HTML, with its imprecision, is fine for markup because it's good enough and broad enough that we can do what we want. And when it isn't -- for example, when it fails to define a drawing canvas for complex visual manipulation -- then a new branch (HTML5) was developed. Repeat ad infinitum.

      Also, note that I'm talking about just the HTML5 spec here, I have little problem with for example, CSS3.

      This is where your argument runs off the rails. You're incensed by HTML5, which has a pretty widely-accepted core implementation, but you have "little problem" with CSS3, which is also incomplete and an ever-changing amalgam of over 50(!) modules, of which only four are in a somewhat-settled state of definition? Come on.

      Imagine my horror when I encountered the term "Responsive web design" the other day, apparently it's about creating device/resolution independent web designs. Yeah, great one kiddies who coined that term, we already figured this out some years back.

      The "kiddie" who developed responsive web design was Ethan Marcotte, a highly-respected designer and one of the principle authors of new web design techniques. Responsive design was first presented in A List Apart, the leading journal for web design techniques. Responsive web design chiefly involves the use of CSS3 (remember? that thing you have "little problem" with?) media queries in its implementation. And it has nothing to do with resolution independence, but rather, about dynamically adapting both content and layout to a variety of different usage roles (desktop, mobile, etc.).

      Again, I appreciate your passion, but it's heavily misinformed. Sure, HTML5 has problems, and they're no secret -- they've been debated ad nauseum since WHATWG first convened. But the fact is that there is a generally-agreed-upon HTML5 baseline, it's in wide use across the Web, and it's enabled some pretty terrific new sites and apps. This will continue, regardless of hand-wringing about standards and forks. The Web adapts.

    14. Re:No shit by Anonymous Coward · · Score: 0

      Hmm... Angry Birds has always had sound for me in Firefox... In fact, i just fired it up on my old laptop (WinXP), in FF13. The sound turns off and on in the options for the game...
      PEBKAC?

      As long as Chrome and FF keep trying to dick-wag each other, perhaps it's not so bad. Safari, and to a much lesser extent, IE, will vainly try to bring up the rear.

    15. Re:No shit by Anonymous Coward · · Score: 0

      There's several of features in HTML5 that make a web designers life easier, not just canvas. SVG, Audio, Video, and the aforementioned Canvas will go a long way in helping us remove our dependencies on 3rd party plugins like Flash for example. You can get hung up on label's here, but HTML5 is more than just the name of the spec for tags, it's a buzzword for a lot of things including several new DOM API's like Geolocation. HTML5, in all that that implies, is great.

      Competition is the most important factor with consistency of implementation of web standards, but let's not kid ourselves. If there was no HTML5 spec, then there wouldn't be any way to be consistent with these new features. They go hand in hand.

      Finally, you're really showing that you're "stuck in your own ways" if you're horrified by Responsive Web Design. Responsive Web Design doesn't rely on JavaScript as it's foundation, but on Media Queries to dynamically apply styles based on environmental variables (most often resolution and device pixel ratio). It's also the umbrella term for innovative techniques like responsive images (which does use JavaScript). It's a lot more than your traditional fluid widths and JavaScript window.resize hacks. A good web designer knows that we can't just build a mobile site and desktop site and call it good anymore. We're seeing tons of new devices from new tablets to smart tv's with smaller/greater resolutions with normal/higher pixel densities saturating the market, and Responsive Web Design is the umbrella term answer to that problem.

    16. Re:No shit by Anonymous Coward · · Score: 0

      But... HTML5 has what plants crave!

    17. Re:No shit by Zontar+The+Mindless · · Score: 1

      I've been on the WHATWG mailing list since 2004. I quit bothering to read the damned thing a couple of years ago, it just started to hurt too much.

      --
      Il n'y a pas de Planet B.
    18. Re:No shit by foniksonik · · Score: 1

      Responsive design in its current form has been around for several years now. It was popularized in an article on A List Apart. The concept was to use media queries (very new at the time) to define CSS rule for different sized screens while using the same HTML markup for all screens. This was in contrast to the then standard approach of using server side lookups Ina DB such as WURFL to get screen sizes and then serve up different markup and different CSS.

      JavaScript is not necessary or even desired as a part of it.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    19. Re:No shit by Anonymous Coward · · Score: 0

      I think his argument wasn't that responsive web design is a bad thing, but that the name must have been coined by someone with rather limited experience with the history of web design, because responsiveness and fluidity are two different things. Responsiveness has historically referred to how well a site responds to actions, fluidity has historically referred to sites rendering in a fluid manner relative to the size of the viewport.

      Calling it responsive web design does seem to muddy the waters somewhat, unless you assume responsiveness of sites is not an issue anymore.

    20. Re:No shit by Anonymous Coward · · Score: 0

      "I appreciate your passion, but you have a lot of things wrong. Chiefly this: HTML5 is not a singular entity, but rather a broad description of several emerging web technologies."

      This article is about the HTML5 specification, not the full set of technologies such as CSS3 that people have lumped into the HTML5 basket which seem more about the WHATWG HTML5 thing trying to take credit for things they don't deserve than anything.

  24. 3D? Cameras? Microphones? by ShanghaiBill · · Score: 1

    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.

    1. Re:3D? Cameras? Microphones? by jklovanc · · Score: 1

      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.

    2. Re:3D? Cameras? Microphones? by Shifty0x88 · · Score: 3, Insightful

      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.

    3. Re:3D? Cameras? Microphones? by ultranova · · Score: 2, Insightful

      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?

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    4. Re:3D? Cameras? Microphones? by SplashMyBandit · · Score: 3

      You mean WebGL that has been stable for a year and a half? Turn in your geek badge please! :) OpenGL r0x0r!
      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).

    5. Re:3D? Cameras? Microphones? by SplashMyBandit · · Score: 2

      Have a look at WebGL. 3D on the web using OpenGL has been possible for a year and a half.

    6. Re:3D? Cameras? Microphones? by Genda · · Score: 2

      In HTML23 you'll have tags for elective genital origami or macrame! Oh, the unadulterated power!

    7. Re:3D? Cameras? Microphones? by Genda · · Score: 1

      You seem to be missing the strong likelihood that, by the time there's an HTML6 (if current trends continue), the computing device of choice will be a phone, it'll use a multi-terabyte micro-SD card, have 8 cores and outperform your current desktop, do real-time speech recognition for data entry, and have an HD projector on it side, for when you aren't using your HD-Real-media glasses. The only folks with PCs, will be gamers and researchers running on monitored fixed service lines (when the phone companies have squished all the ISPs and all network access looks like today's phone contracts), and government oversight will be the order of the day.

      How much you wanna bet my crystal ball is closer than yours?

    8. Re:3D? Cameras? Microphones? by Genda · · Score: 1

      Actually, it should be possible to reduce 3-D to a simple symbolic description that would be easily transmitted over a thin client, and let all the heavy processing happen on the local machine. If you think about it, all human perceived 3D is just two simultaneous 2D images. With sufficient bandwidth it wouldn't even matter what side the rendering was taking place, and by the time HTML6 rolls around... virtual processor will be cheap and plentiful indeed.

    9. Re:3D? Cameras? Microphones? by fatphil · · Score: 2

      I remember seeing VRML on an SGI box back in, ... so bloody far back I can't even remember when it was. When VRML was "the future of the internet".

      --
      Also FatPhil on SoylentNews, id 863
    10. Re:3D? Cameras? Microphones? by ChunderDownunder · · Score: 1

      Have a look at WebAPI, Mozilla's app platform for Firefox OS.

    11. Re:3D? Cameras? Microphones? by Anonymous Coward · · Score: 1

      HTML: Hyper Text Markup Language...

      Cant we just have that back? I dont want a website to acces my GPU, or webcam, or other pheriphals.

      Where did we go wrong? I already hate websites using javascript and being interactive. It sure as hell should never be in 3D or some other graphics designer's wet dream.

    12. Re:3D? Cameras? Microphones? by lister+king+of+smeg · · Score: 1

      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.

      maybe so i can watch 3d movies on netflix instant stream.
      or so i can see google streetveiw/maps/earth in 3d
      or becuase i want to write a web app game so that i can have my app on multiple platforms without porting with 3d
      there 3 reasons there are more
      but i agree this does not belong in html put it in javascript, java, flash, light, or webgl. html is a markup language for displaying text and graphics.

      --
      ---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
    13. Re:3D? Cameras? Microphones? by jklovanc · · Score: 1

      It all depends on what you mean by "by the time there's an HTML6". If you are talking about 2015 the mine is probably closer. If you are talking about 2030 then your is probably closer.

      By the way, there are a few physical issues with speech recognition that can not be overcome by technology. First, that do not work well when you are close to others and do not want to bother them or let them know way you are doing. A bus or a crowded office does not work well when everyone is using speech recognition to control and input to a computer. Secondly, speech recognition is a very poor command method for doing fine work like editing a document. How would you tell a computer exactly where you wanted to insert some text? Pointing with a mouse is faster. Data entry is very different than data editing.

      Until we get true, low cost, gesture based VR the desktop is not going away for the average person.

    14. Re:3D? Cameras? Microphones? by SplashMyBandit · · Score: 2

      Yeah, VRML was much ballyhooed. I think the situation may have changed somewhat these days though. For one, consumer devices almost always have devices capable of supporting OpenGL/OpenGL ES (all computers do, even those with integrated graphics; all smartphones do since OpenGL ES is the graphics library for those devices; even the PS/3 can. The exception is the Xbox 360 that has the hardware, but I'm not sure about libraries [someone might be able to confirm whether there is an OpenGL ES library for the Xbox 360]). The other thing is that bandwidth is much higher these days. So sending the mesh, shaders and textures for a scene is much easier. Complex 3D (eg big games and flight simulators) probably will always be run outside web browsers though.

    15. Re:3D? Cameras? Microphones? by jo42 · · Score: 2

      A web app should have direct access to an OpenGL.

      No it shouldn't. I don't want to go to a web site and have all sorts of flying 3D shite on my screen. Flash is bad enough in this department.

      HTML5 can play audio (usually poorly) but there is no API for recording it.

      No there shouldn't be. I don't want to go to a web site and worry if it is recording me or not. Hello FBI, CIA, NSA, Facebook, Google, etc. - sod you with a stiff wire brush.

      There should be a way to interface with cameras, etc.

      No there shouldn't. I don't want to go to a web site and have the fumbducktards at the other end spying on me - see above.

    16. Re:3D? Cameras? Microphones? by Raenex · · Score: 1

      HTML: Hyper Text Markup Language...

      Cant we just have that back?

      No, it's dead, and do you really want what you stated? That would include no images, no forms like the one you typed your comment into, and certainly nothing as fancy as draggable maps. Do you really want to install an app for that?

    17. Re:3D? Cameras? Microphones? by datavirtue · · Score: 1

      I twill probably get to the point where the browser acts like a VM that provides a translation from HTML down to the OS API. the browser is the desktop. Isn't that where we are heading? Look at Windows8/Metro and the tablets. Hell Mozilla is launching a Firefox OS for phones/tablets.

      --
      I object to power without constructive purpose. --Spock
    18. Re:3D? Cameras? Microphones? by datavirtue · · Score: 1

      I don't doubt this at all. Seriously.

      --
      I object to power without constructive purpose. --Spock
    19. Re:3D? Cameras? Microphones? by datavirtue · · Score: 1

      Can't fuckin wait. WebAPI is awesome! Web-app accessing the OS FTW. It's about time.

      --
      I object to power without constructive purpose. --Spock
    20. Re:3D? Cameras? Microphones? by DarwinSurvivor · · Score: 4, Interesting

      YES! Non-text media should be handled by the system's media software. I would LOVE it if youtube would just have a link that I can click on that opens in VLC, your website's contact page would have a link that I click on that opens in Google Earth or Marble. The only exception I can think of would be images as *thumbnails* only. I'm sick and tired of being trapped in my browser shitty excuse for a video player (be it flash or HTML5) when I have a VERY capable fully-featured video player with frame-by-frame playback, rewind, subtitle support and tracking controls.

      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.

    21. Re:3D? Cameras? Microphones? by Anonymous Coward · · Score: 0

      You mean WebGL that has been stable for a year and a half?

      You mean WebGL that has the exact problem that has been described by GP? Not to mention the fact that it also exposes any security issues there may be in your graphics card drivers (which are plenty, because those drivers were never written with the assumption that they will be directly driven by untrusted code)?

    22. Re:3D? Cameras? Microphones? by Electricity+Likes+Me · · Score: 1

      More importantly the desktop is very likely to fork through whatever that final interface would be first.

      If we're going to head towards Augmented Reality VR-gesture recognition systems, well, unlike current mobile technology they're all things with very significant gains and least-resistance implementation on the desktop.

      I've love to ditch my monitors, clear my desk and seamlessly work with physical and virtual documents in an intuitive way.

    23. Re:3D? Cameras? Microphones? by Electricity+Likes+Me · · Score: 1

      The problem is we're not taking appropriate security precautions yet again. Bothering the user about every little thing isn't the way - you either click 'no' all the time, or 'yes' all the time and the whole thing is moot.

      We're getting to the point where what we need is for our browsers to lie convincingly about what personal data they have.

    24. Re:3D? Cameras? Microphones? by exomondo · · Score: 1

      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.

      Yes let's give web apps direct access to the hardware, uploading shader code directly, access to the framebuffer, ease of performing a DOS attack, etc... WebGL is what you describe but it isn't in the HTML standard because it has a lot of problems that would need to be addressed first.

    25. Re:3D? Cameras? Microphones? by Anonymous Coward · · Score: 0

      VRML was replaced by x3d and recent improvements in HTML5 that allow svg and mathml to be mixed in with html have inspired x3dom. It's not part of the standard yet but there is a w3c community group working on it. They currently have a lot of originally x3d demos running in html5 browsers via canvas & webgl.

      http://www.x3dom.org/
      http://www.3dcoform.eu/x3domCatalogue//
      http://x3dom.org/x3dom/example/x3dom_jQueryManip.xhtml
      http://x3dom.org/x3dom/example/x3dom_onClickEvent.xhtml

      So in theory it's pretty much _done_ except they currently have to use javascript to interpret their x3d tags and feed that to the webgl canvas rather than the browser doing it automatically. Also there are a few tag attributes in x3dom that clash with existing html tag attributes so they're looking into work arounds and renaming or removing some.

    26. Re:3D? Cameras? Microphones? by thePowerOfGrayskull · · Score: 1

      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.

      Alternatively, you can use hte native tools provided for the environments you want to work in, and stop trying to fit a round peg into a square hole.

      Your users will thank you.

    27. Re:3D? Cameras? Microphones? by thePowerOfGrayskull · · Score: 1

      maybe so i can watch 3d movies on netflix instant stream.

      Wouldn't it be spiffy if we could use a dedicated video player (and all of the advanced features it supports) for watching Netflix, instead of being forced to use an embedded player?

      or so i can see google streetveiw/maps/earth in 3d

      Imagine what could be done if you had a Google Maps Viewer application that had full access to system libraries - including 3d.

      or becuase i want to write a web app game so that i can have my app on multiple platforms without porting with 3d

      Let me translate that for you: because I want to write a web app game that offers a sub-par experience on multiple platforms because it fails to use what those platforms have to offer; and instead has been shoehorned into a web app.

    28. Re:3D? Cameras? Microphones? by Anonymous Coward · · Score: 0

      Sounds like a great idea. May I suggest a name for the thing? I'd like to call it Gopher

    29. Re:3D? Cameras? Microphones? by eriqk · · Score: 1

      Cant we just have that back?

      Sure you can.

  25. There goes thin client user interfaces by WOOFYGOOFY · · Score: 1

    There goes thin client user interfaces and thank god for that, quite frankly. And in related news, the cost of writing thin clients just went up 70%.....

  26. This is nothing new.. by EMR · · Score: 4, Informative

    This was mentioned over a year ago that this was happening? (January 2011 ! )

    http://blog.whatwg.org/html-is-the-new-html5

  27. What kind of rubbish desktop are you using? by Viol8 · · Score: 4, 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?

    1. Re:What kind of rubbish desktop are you using? by Billly+Gates · · Score: 0

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

      The size of the screen is not the issue I am referring too. It is the legacy software support. I own a hex core phenom II with an ATI 5750 with 8 gigs of ram. My Samsung Galaxy with modern optimized apps with HTML 5 and gpu acceleration perform better sadly.

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

      No IE 9 has hardware acceleration with my GPU. The other ones do not by default.

      The other browsers still do not support it by default or only accelerate part of it.

      For browsing experience take a look at www.okcupid.com? The web applet for Android and iOS has more graphical effects and detail than the desktop version. This is because of a combination of supporting obsolete browsers as well as GPU acceleration on the desktop is behind. Webmasters do not include it because not everyone uses modern web browsers and decent dedicated graphics that even your phone has better. Intel 915 and earlier are less powerful than my Samsung Galaxy GPU wise.

      Also if you have an IPAD or any smartphone go to www.slashdot.org and move your screen up and down with your finger? See how is slides like butter? No chops at all like your browser. I can get Chrome to work like this only if I go into about:flags and turn on some experimental GPU features. Not something an average user will do. Why should a much more powerful desktop behave like that?

      "Errm , you do realise that applets are programs, not web pages?"
      Why can't they be applets? Metro apps are coming and many apps like salesforce.com are moving to the internet. It is a whole platform and one where the PC is losing.

    2. Re:What kind of rubbish desktop are you using? by Viol8 · · Score: 1

      "No chops at all like your browser

      Firefox on linux doesn't chop at all. Get yourself a proper OS while you're at it.

      "It is a whole platform and one where the PC is losing."

      If you seriously believe that then plug a 3 inch monitor into your PC and see how long you can put up with it.

    3. Re:What kind of rubbish desktop are you using? by exomondo · · Score: 1

      Then your computer is a piece of junk. Go and buy one built in the 21st century.

      Yes even though the hardware is clearly capable you should buy new hardware to compensate for software inefficiencies!

    4. Re:What kind of rubbish desktop are you using? by Anonymous Coward · · Score: 0

      An Applet is a program that runs in a web page - A Java based one, last time I checked.

      I assume the person making the comment meant "application", but even then, like 80% of the apps on the App store are just using HTML compiled into an App with PhoneGap or something.

    5. Re:What kind of rubbish desktop are you using? by foniksonik · · Score: 1

      No IE 8 is a heap of memory leaks pretending to be a browser. It never cleans up after itself, rudimentary DOM work brings it to its knees and generally it's rendering engine (Trident) is just a poorly written pile that was corrupted from the start to make it backward compatible with OS rendering needs and Sharepointe.

      Microsoft has yet to write a render engine for the web. They still have to answer to too many masters in other product divisions.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    6. Re:What kind of rubbish desktop are you using? by Viol8 · · Score: 1

      "An Applet is a program that runs in a web page - A Java based one, last time I checked."

      Last time you checked being 1995 by the looks of it. These days a phone "app" means a standalone program.

      "but even then, like 80% of the apps on the App store are just using HTML compiled into an App with PhoneGap or something."

      Yeah , right. You might want to look up Objective-C sometime.

  28. Why are you trying to smear Google with innuendo? by walterbyrd · · Score: 1

    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?

  29. Fucked up by Psicopatico · · Score: 1

    So, if I get this right, there will be two standards: the working one and the non-working one.
    Guess which one the web-developers will follow?

    --
    Mastering the English language is fucking easy: all you have to do is to put an f* word in every fucking sentence.
    1. Re:Fucked up by fatphil · · Score: 1

      Which one do you think will be the "working" one? IMHO, standards only work when they're cast in stone. Otherwise, they're unreliable.

      History show that web developers will use the <blink> tag. And will use javascript to do exactly what an <a href=...> can do. I'm not sure what that tells us.

      --
      Also FatPhil on SoylentNews, id 863
  30. The standard is already a decade ahead ... by wisnoskij · · Score: 1

    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.

    --
    Troll is not a replacement for I disagree.
  31. We've been here before by mrbester · · Score: 4, 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.

    --
    "Wait. Something's happening. It's opening up! My God, it's full of apricots!"
    1. Re:We've been here before by shutdown+-p+now · · Score: 1

      as new shiny stuff is added by the competing browsers (Internet Explorer is not one of these).

      It is, actually. Here is one example (introduced by IE10 beta).

  32. Begin again the browser wars have by SilverJets · · Score: 1

    Here we go again.

  33. Feature Detection by Anonymous Coward · · 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 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"?

  34. HTML Already Is Two Standards by Anonymous Coward · · Score: 0

    IE and everybody else.

    This is de facto true for anyone who has tried developing websites for a living.

    This is also true in the standards bodies where MS is keeping the brakes on W3C so that resources don't have to put into keeping IE current.

  35. Re:Why are you trying to smear Google with innuend by thetoadwarrior · · Score: 1

    No need to get butt hurt. You're right about MS. They had the most to lose by Office losing its dominance by having a free standard controlled by someone else. Google isn't the only company in WHATWG but they're certainly the biggest one who has the most to gain by pushing everything into onto the web and of course they have the most to lose if that doesn't happen or takes too long.

    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 stuff like this, as noted by one of their WHATWG partners. https://twitpic.com/a9cji2

  36. If it is constantly changing, it isn't a standard by Anonymous Coward · · Score: 1

    A standard is something that is defined. If you are constantly changing it and updating it, it isnt a standard.

  37. Re:The great thing about first posts by Genda · · Score: 1

    The standard is living and the users die... I here a soviet Russia joke coming on...

  38. Re:The great thing about first posts by Fjandr · · Score: 4, Funny

    In Soviet Russia, here's you.

  39. XHTML by Anonymous Coward · · Score: 1

    I wan't the well-behaved structure of XHTML! :-(

    1. Re:XHTML by Mystra_x64 · · Score: 1

      XHTML mode was still present in HTML5 last time I checked.

      --
      Quick way to get 30% Funny 70% Troll: defend Opera browser on /.
    2. Re:XHTML by Eponymous+Hero · · Score: 1


      <html xmlns="http://www.w3.org/1999/xhtml">

      now calm down and back away from the ledge.

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
  40. The WC3? by Sam+H · · Score: 2

    How can one misspell W3C twice in so few words?

    --
    God, root, what is difference ?
    1. Re:The WC3? by Anonymous Coward · · Score: 0

      How can one misspell W3C twice in so few words?

      ahah, funny, didn't notice it before reading your comment!

    2. Re:The WC3? by Anonymous Coward · · Score: 0

      How can one misspell W3C twice in so few words?

      You type "W", then you type "C", then you type "3". Then you repeat the process.

  41. WHATWG needs to stop calling their work HTML5 by mysidia · · Score: 1

    HTML is a W3C standard. You can't have two competing parties developing new versions of a standard and both calling their work by the same name.

    While what the W3C based the HTML5 standard on was WHATG's work. The W3C "owns" this standard, and any extensions WHATWG makes, for now, will just be unofficial extensions. A working group does not make a standards body.

    You can't have a "living standard" per se.

    You can standardize an options/extension mechanism, and make a provision for vendor-specific addons, or additional options, but that's about it.

    Ultimately you do have to have a snapshot, and set some things in stone, so that developers can implement the standard, they're not going to rewrite their browser every few months for you, and a "standards" body ignoring details like agreement among the vendors is not likely to succeed!

    Also, it takes a long time for developers to implement new changes to standards, get the bugs out, AND meet compliancy levels. Look how long it took to get anything close to an Acid3 compliant browser. Finally Internet Explorer 10 will supposedly pass all the basic tests (and still doesn't guarantee compliance with the standard).

    1. Re:WHATWG needs to stop calling their work HTML5 by chris.alex.thomas · · Score: 0

      a standard is what we make it, if we give a group the sole right to define a standard, we end up with the bullshit that is the W3C in the first place.

      they're not going to rewrite their browser every few months?? they already are! every few months I get a new version, new tricks, new problems, new solutions. nothing will change.

      the good developers will write code which can flex and adapt, the bad ones won't, I'll get all the work from the shitty programmers cause my work does adapt and I take those things into account, the dreamweaver developers won't, they'll suffer, thats fine with me, they do shitty work anyway.

      the web is the mess it is today because of people's reluctance to fix things because it "will break the internet" well guess what, the internet is already broken....perhaps a release often methodology is what we need to fix it whilst targetting new browsers and things will get better.

      slowing down and it'll just get worse, so I'm all for stepping on the accelerator a little bit, even if it causes a little "discomfort"

    2. Re:WHATWG needs to stop calling their work HTML5 by MassacrE · · Score: 1

      They did stop calling it HTML 5. They call it HTML.

  42. Wither Javascript? by Anonymous Coward · · Score: 0

    Javascript seems to be everywhere, and so I doubt it will disappear after HTML5 comes out real soon now. Are draft standards for the shitty Javascript language as strict as HTML5 was first envisioned to be?

  43. Wasted Effort by Anonymous Coward · · Score: 0

    Imagine where we would be today if only people had put their time into automatic application upgrade and deployment systems instead of trying to force everything into a browser by recreating everything that had already existed just one level down. The software world would be so much nicer. You'd click a link that downloads and installs the correct version of the application for your OS+hardware. You'd then go through a list of security check-boxes approving which parts of the system the new program requests to use and you're off and running. (This in no way prevents most of the data from being served from and/or stored on the server)

    But no. HTML is the fully cross-platform language that works everywhere, is supported by everything, and looks the same across all platforms. Except if..., except when..., except on.., except..., except..., except..., etc...

    Now we're getting browser plug-ins being listed as programs on the task bar. Programmers like to torture themselves. Somehow the most fucked up and hacky solutions are rated better than the nice elegant ones. If it wasn't hard to do or the solution isn't difficult to understand, it must not have been worth doing.

  44. They can't both be... can they? by flibbidyfloo · · Score: 1

    I don't know a lot about how these types of standards work, so I could be wrong, but they can't *both* be HTML 5 if they aren't the same, right?

    Shouldn't one be HTML 5 and the other would be a superset of that... maybe HTML 5.x ?

    Unless WHATWG plans on removing features so their browsers can't properly render stuff that's compliant with WC3's standard. It sounds sort of like being in a developer's beta stream for an app. You can stay with the "stable" version, or get nightly builds with new features that may or may not eventually end up in the stable channel.

  45. It's about time the w3c was bitch-slapped by rs79 · · Score: 2

    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.

    --
    Need Mercedes parts ?
  46. CANT READ SLASHDOT ANYMORE by Anonymous Coward · · Score: 0, Troll

    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!

    1. Re:CANT READ SLASHDOT ANYMORE by PT_1 · · Score: 3, 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.

    2. Re:CANT READ SLASHDOT ANYMORE by fustakrakich · · Score: 5, Funny

      He would... if he could see where he was..

      --
      “He’s not deformed, he’s just drunk!”
    3. Re:CANT READ SLASHDOT ANYMORE by Anonymous Coward · · Score: 0

      I fixed this by following this guide:

      Fix Facebook Comments font size in Chrome
      http://www.incendiary.ws/node/256

    4. Re:CANT READ SLASHDOT ANYMORE by Anonymous Coward · · Score: 0

      I've made the complaint on his behalf. Poor fella.

  47. Re:The great thing about first posts by irtza · · Score: 1

    In soviet Russia, the standard chooses you!

    --
    When all else fails, try.
  48. This was news -- at the beginning of 2011 by DragonWriter · · Score: 1

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

    This (except correctly referring to the W3C instead of "WC3", whatever that might be) was announced on the WHATWG blog on January 19, 2011. How is this news?

    Whatever happens, the future has just become more complicated — now you have to ask yourself 'Which HTML5?'"

    Actually, no -- prior to the change at WHATWG in 2011, there were two HTML5 efforts (WHATWG and W3C). Now there is only one (W3C). WHATWG's living standard is for HTML, with no number attached to it. The two standards have somewhat different purposes. The WHATWG living standard represent the common functionality that browser vendors have agreed to implement, the W3C standard is more conservative. In theory, given the goals of the two standards, the W3C one would be the better one for app developers to target and the WHATWG one would be mostly a tool for browser vendors to align on what features they were going to work toward getting to the point where they were generally usable, and be much more forward looking. But that requires the W3C to draw a line in the sand and commit to finishing HTML5 (and then get started on HTML6, etc.) Otherwise, you end up with the WHATWG work that is officially a living standard, and the W3C work is a series of "Working Drafts" chasing the WHATWG living standard but never actually producing a stable standard, either.

  49. Back on topic, the editor of both docs wrote this: by YA_Python_dev · · 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

    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

    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!

    --
    There's a hidden treasure in Python 3.x: __prepare__()
  50. For those confused. by MassacrE · · 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.

  51. Good Idea! by TwinkieStix · · 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

    1. Re:Good Idea! by Anonymous Coward · · Score: 0

      HTML5 is not a standard because it has to be implemented by at least three major browsers in order to become officially done. Guess what, not a single browser fully implements it. Neither one. So, what is the point of running into HTML23 and adding some new random features into it? They killed the last hope that things may ever become standard.

      And what is the point of calling the thing HTML with no version? That is the most idiotic thing anybody ever did. It is not even possible to speak about what HTML parser does. Hey, our project parses HTML and there is no name, so we can only tell you that we are compatible with 11.3.2012 12:30 versions. The other project is compatible with 12.3.2012 14:30 and if you want to know what it means run a diff. There is infinite amount of versions, so there will be no "what is new" overview you can read.

    2. Re:Good Idea! by Anonymous Coward · · Score: 0

      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.

      How about: "HTML5 is badly managed"? "HTML5 is a mess"? Or, "HTML5 ignores other W3C standards and prefers to dream up its own stupid [non-]solutions instead"?

      In order for the W3C to standardize HTML5 they will have to alter it. Since WHATWG is run by browser idiots... I mean, developers, what do you think the chances are that those changes will actually be implemented instead of ignored? What do you think the chances are that the W3C's changes will be adopted into the WHATWG clusterfuck... er, "standard"?

      WHATWG is essentially a party for 3 year olds, they throw crap at the wall and see what sticks, good design be damned.

    3. Re:Good Idea! by Anonymous Coward · · Score: 1

      Uh, except the purpose of a stable branch is for making public releases.

      If you allow third parties to integrate with your dev tree, why have a stable?
      It's a recipe for disaster. The presence of a "stable" tree implies you will break things on a whim in the dev tree.

      Go back to your Ruby... God damn I hate the Internet.

    4. Re:Good Idea! by TwinkieStix · · Score: 1

      ... It's openness. The Linux kernel is available in both development and stable branches, and I am free to write applications that force my users to use the absolute bleeding edge unstable kernel to use my application. Here, I am free to write web pages that force my users to use the absolute bleeding edge unstable HTML features such as those vendor-specific "beta" tags (such as those that start with -webkit-). Most if HTML5 is backward compatible with HTML4. The difference here is that we are talking about document standards with multiple competing implementations, so the standardization process is much slower than the implementation process (the opposite of source code where the implementation precedes/is the standard).

      I'm not really much of a Ruby programmer.

  52. Re:The great thing about first posts by vjoel · · Score: 5, Funny

    In soviet Russia, the standard chooses you!

    In soviet Russia, the standard forks you!

    --
    What part of `yes no` don't you understand?
  53. Heh by kiddygrinder · · Score: 1

    either they just came up with a process to explain why they can't finalize html 5 or they just decided to split the people who are dragging their feet out of the equation.

    --
    This is a joke. I am joking. Joke joke joke.
    1. Re:Heh by DragonWriter · · Score: 1

      either they just came up with a process to explain why they can't finalize html 5 or they just decided to split the people who are dragging their feet out of the equation.

      They didn't just do anything; this is essentially the way WHATWG has been working for years, and they announced the change in the name of the WHATWG document from "HTML5" to the "HTML Living Standard" at the beginning of 2011.

  54. Guidelines by Fls'Zen · · Score: 0

    "Living standard"? They're more like guidelines.

  55. Re:Back on topic, the editor of both docs wrote th by TapeCutter · · Score: 2

    Agree. "Living standards" reflect the reality of the software industry much more accurately, as long as they stay backwardly compatible with previous generations of the standard the I don't see the problem. If you need to break backward compatibility* then you need to fork the standard. Snapshot standards are ok for technologies that have more or less stopped evolving.

    * - Backward compatibility is what users need, forward compatibiliy is what users want, and they will get it when the first software dev gets his hands on a time machine.

    --
    And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
  56. It's a shame by Anonymous Coward · · Score: 0

    ...that this split officially happened in January 2011. It's also a shame that HTML5 has been a "living standard" for two years, seven months and eleven days. At least you try, /., at least you try.

  57. Obligatory by El_Oscuro · · Score: 1, Funny
    --
    "Be grateful for what you have. You may never know when you may lose it."
  58. New direction should have a new name. by GrantRobertson · · Score: 1

    Whoever, is forking the process should trademark a new name and call their standard by that name. To keep calling it "HTML5" is just mean.

    Perhaps "HTML5X"

  59. Re:Back on topic, the editor of both docs wrote th by martin-boundary · · Score: 4, Insightful
    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.

  60. Simple solution by edremy · · Score: 1

    Code all your websites in Flash! You get a stable, cross-platform rich browsing experience without all the issues of figuring out what version of HTML you need. With some work, we can turn the browser into a stable, speedy Flash-delivering platform and let HTML die like the dinosaur that it is.

    --
    "Seven Deadly Sins? I thought it was a to-do list!"
    1. Re:Simple solution by JustNiz · · Score: 1

      Except no google platforms even support flash, because its a buggy piece of shit.

    2. Re:Simple solution by Anonymous Coward · · Score: 0

      Flash seems to work fine in Chrome and on my Android phone.

  61. We need reliable useful standards. by gorehog · · Score: 1

    So, what the point here? Is it to make development as difficult as possible and presentation unpredictable? WHATWG's living standard is going to ensure that developers waste all sorts of time trying to figure out what feature is supported on what browser. Is feature x supported on Webkit? Gecko? IE? Oh wait, what about the various implementations of feature x?

    Honestly I just want to know what's going to allow me to deliver a reliable, effective product with the highest profit. I should never ever see "Sorry, this website requires BAR browser." A living standard will require more software patches and less backwards compatibility. If someone tells me that their user-agent is fully FOO 3.4 compliant I expect it to behave like every other FOO 3.4 labelled software out there.

  62. Re:Dumb idea. No not really by Anonymous Coward · · Score: 0

    Not really. If the clients accept his work on the basis he describes and it allows him to pay is bills on time AND go on vacation with his family for a couple of weeks in the summer, he is absolutely right.

  63. Who cares? by Anonymous Coward · · Score: 0

    HTML has always been what browser vendors and the developer community said it was, not something in a W3C standard. So W3C just became irrelevant for the future of HTML5. Or, as previous posters point out, they haven't been relevant in the first place, so now they just officially announced the Status Quo. In any case, nothing to worry about.

  64. Re:Newsflash! HTML5 fork now an official Google BE by Damek · · Score: 2

    It's how the human mind & language work... Just sayin'.

  65. Remember XHTML? by Animats · · Score: 2

    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.

    1. Re:Remember XHTML? by Anonymous Coward · · Score: 0

      I share your view on strict syntax and would have loved to see XHTML become the defacto standard for that reason, however i don't think requiring UTF-8 is somehow beneficial.

      UTF-8 still lacks a lot of things that most of us in the US and most of Europe don't really wrestle with, but there is a reason there is also a UTF-16 and UTF-32 and
      many variations there of.

      I would have liked to see defining a charset (and language/locale) be required, where browsers would reject the entire document if either they were undefined, or if characters were present in the document that aren't defined in that particular charset.

    2. Re:Remember XHTML? by Xest · · Score: 1

      Yes, but all the kiddies complained about how HTML hurt their brain, how things like div soup was just too confusing for them, and so we got HTML5.

      Problem is, the kiddies are now all off using Facebook, Joomla, Wordpress, Twitter, and Blogger, and so aren't touching HTML anyway, and here we are, those of us who do actually have to touch it, dealing with a shambolic mess.

      It's a shame that web standards are ruled by those who simply don't have a clue about what it takes to write good quality software.

    3. Re:Remember XHTML? by Anonymous Coward · · Score: 1

      Nothing is stopping you from sticking to proper, well-formed XML to write HTML5 with. In fact, you should. The same goed for UTF-8; unless you have a very good reason not to use it (unlikely), you should use it.

      Don't worry about the HTML written by others.

  66. HTML 4.01 button for browser by Spazmania · · Score: 1

    Can I please have a button that limits my browser to html 4.01? HTML 5 has thrown in everything including the kitchen sink. I don't want that functionality available to the web hack at http://random.web.site/. It's too much. I only want it on a web site I've decided I trust and I'd rather have it in a completely different program.

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
    1. Re:HTML 4.01 button for browser by YA_Python_dev · · Score: 1

      You seem to think that HTML 4.01 is a subset of the HTML (a.k.a. "the standard formerly known as HTML5"). That's not the case, HTML 4.01 is a completely different and incompatible HTML dialect. When I say incompatible I mean that 4.01-compliant browsers (which obviously don't exist and never did) would not be able to correctly display ANY of the following website: slashdot, Wikipedia, Google, Yahoo, BBC, CNN, eBay, Amazon, Facebook, Twitter, YouTube and many, many others. If you want an HTML 4.01 browser, you can't just limit existing browsers to a subset of their functionality, you have to write one yourself because 4.01 was so utterly broken and incompatible with the actual web that exists in this reality that no browser vendor ever implemented it. Even lynx is more similar to HTML than to HTML 4.01 when it comes to parsing web pages, otherwise it would be completely unusable. HTML 4.01 was promoted to a "standard" only because the W3C rules at the time were very lax, with the current rules that require two independent complete implementations, it would still be a "working draft".

      --
      There's a hidden treasure in Python 3.x: __prepare__()
    2. Re:HTML 4.01 button for browser by MagdJTK · · Score: 1

      I don't think I understand. What would you like this putative browser to do when it sees an HTML5 document? Simply refuse to render it? Considering it's the dominant standard now, you'll just be shutting yourself from more and more of the web.

    3. Re:HTML 4.01 button for browser by Eponymous+Hero · · Score: 1

      fail. what you need is to develop your own browser. then you can tell it what portions of any html standard to ignore or accept. good luck, have fun.

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    4. Re:HTML 4.01 button for browser by Spazmania · · Score: 1

      For sites I trust I want a different application. A true remote display language without all the godawful workarounds it takes to do that in html.

      I'm the kind of guy who surfs with noscript turned on and usually leaves a website that would require me to enable javascript to use it. For all the untrusted web sites I want a *simple* document markup language. Heck, I was happy with html3. And I don't feel any compelling need to access untrusted sites that require more functionality on my computer.

      --
      Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
  67. Make that three standards! by Anonymous Coward · · Score: 0

    1. Microsoft codes the next version of IE for the W3C HTML5 Standard.
    2. Microsoft adds some "enhancements" to IE that diverge from the standard.
    3. Microsoft publishes said browser.
    4. Being IE, every website makes itself compatible with the browser.

    5. We now have three standards.

  68. General "web apps" are a bad idea anyway by Anonymous+Brave+Guy · · Score: 1

    The trouble is, trying to shoehorn every application under the sun into a web app format is a bad idea. The web is not designed to be an operating system or an application delivery platform. It's designed to efficiently and portably distribute content.

    The longer we persist with this fad of trying to make it do more than that, the longer it will be before we switch back to building real applications with tools that are fit for purpose. JavaScript and the typical server-side scripting languages are OK (not great in most cases, but OK) for their common jobs, but they are somewhere in the dark ages when it comes to general programming power. The kind of software execution models for things security and concurrency that we have in browsers and therefore web apps today are similarly prehistoric by modern standards.

    And so I respectfully disagree that building serious web apps is just now becoming possible. The state of the art in web-based applications is decades behind the state of the art in native coding, with absolutely zero exceptions to my knowledge.

    The only "serious" web apps that have enjoyed wide success are those that are essentially front ends for a database with perhaps some limited interactivity. Obviously that covers a fairly wide class of software development projects. Moreover, it has certainly shown that there is a lot of value in providing simple but effective tools to manage everyday tasks, often at the expense of incumbent 800lb gorilla do-everything applications. Still, writing simple database front-ends is very far from being the whole software development industry.

    Even in that field, these database UI web apps don't really do anything that a native app, a basic data transfer protocol and a sensible software install/update protocol couldn't do at least as well and often much better. (What do you think a huge proportion of mobile apps really are?) If only we could stop trying to replace that final software install/update protocol with web-hosted apps or proprietary distributions/repositories/app stores and just make the damned thing part of every major operating system the way it always should have been.

    IMHO, what actually needs to happen if we're going to make real progress with this part of the software development industry is to establish a systematic, robust architecture that learns from the many successes of web apps but is built to support general applications from the start, running on a serious OS platform either natively or in a powerful and flexible VM, supporting a variety of languages and programming styles, dealing with distributed resources and security as first-class concepts, and so on. We already know how to solve most of the relevant problems, but we aren't using that knowledge. Apparently it's cleaner to write every trivial database UI using at least five different programming or mark-up languages, or something, and it will probably stay that way as long as we try to make every programming job into a web app.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  69. Re:The great thing about first posts by tgv · · Score: 1

    -1? How undeserved. It's a great, ironic retort.

  70. Re:Why are you trying to smear Google with innuend by Anonymous Coward · · Score: 0

    Lol. "this site has features Your browser may not support. Please try Google Chrome." Was that the point you were trying to make, or just a funny coincidence?

  71. Re:Back on topic, the editor of both docs wrote th by Anonymous Coward · · Score: 0

    Can you back up the claim about IE?

  72. Re:Newsflash! HTML5 fork now an official Google BE by Anonymous Coward · · Score: 0

    It's how the human mind & language work... Just sayin'.

    And that's a golden standard right there. /sarcasm

    A fixed standard is predictable and easy to develop for. A constantly changing "standard" isn't a standard, it's just a reader's digest of the current "state of the art".

  73. Re: now you have to ask yourself 'Which HTML5?'" by Anonymous Coward · · Score: 0

    No, I don't. The answer to that question is Gopher.
    http://en.wikipedia.org/wiki/Gopher_%28protocol%29

  74. Single Render Engine by Tablizer · · Score: 1

    There should be a single implementation, not a single standard. Testing different brands is a pain in the ass and wasteful. There will always be subtleties in interpretation. Why not just have a single render engine and share the fucker?

    Sure, there are still versioning problems even with a single engine, but they are smaller than MultiVendors x Versioning would be.

    1. Re:Single Render Engine by syockit · · Score: 1

      But who will be responsible for the development of the engine? How will it be funded? If changes are to be introduced to the standard, how quickly will it adapt to the changes? Will it be free from ideological or political nonsense?

      --
      Democracy is for the people; you only vote once per season and we'll do the rest of the work for you don't have to.
    2. Re:Single Render Engine by Tablizer · · Score: 1

      I can't say there won't be forks, but they will likely be closer in genetics than today's browser options.

  75. Just drop the number already ! by cr_nucleus · · Score: 1

    They should do the same thing as the doctype and drop the number altogether.
    Like anyone would understand HTML as "the old html from before the beginning of time, when netscape was a browser and people used newsgroups as forums and irc and whatever".

    Let legacy apps use HTML 4, xhtml et al and just move forward.

  76. Already has a new name by DragonWriter · · Score: 1

    Whoever, is forking the process should trademark a new name and call their standard by that name. To keep calling it "HTML5" is just mean.

    The WHATWG standard is the HTML Living Standard.

    The W3C standards effort is HTML5.

    See the blog post (from January 2011, so this is decidedly not news) announcing the whole process shift at WHATWG.

  77. "2 standards" is an oxymoron - nt by Anonymous Coward · · Score: 0

    nt

  78. Quite the opposite by YA_Python_dev · · Score: 4, Insightful

    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__()
  79. So.. by Anonymous Coward · · Score: 0

    HTML 5-Vorbis and HTML 5-MP4

    Oh lovely, a complete square one.

  80. HTML5 is dead. Long Live Apps. by VortexCortex · · Score: 1

    Screw HTML5. It's, what 12 years too late? Web enabled Applications are the future!

    You disagree? Really? Think about what you even need HTML5 for... Yep, Making apps. Exactly my point. Ah, but not really, because you need a shitty scripting language that's not very standardised to make everything work. Fuck THAT unsigned code mess and ridiculous document display language...

    Applications do it faster, better, with less development time (In my experience), and with more consistent rendering.

    Let's see: I push out a Windows, Linux, Mac, Android and iOS app with a single cross platform toolchain, OR, I try to support ALL of those [b]plus[/b] SEVERALl different browsers, each with SEVERAL different versions.... Yeah, it's death by over 9000 papercuts.

    Protip: The web really isn't designed to do what you want, and there's a perfectly good OS API sitting RIGHT THERE.

  81. The future of the desktop is assured! by Moondevil · · Score: 1

    Great, now I really know which technology to use for desktop applications!

  82. Solution: by Anonymous Coward · · Score: 0

    Solution:

    XHTML1 + balls

  83. Re:Back on topic, the editor of both docs wrote th by yuhong · · Score: 1

    Because there is a separate W3C spec for 2D canvas:
    http://www.w3.org/TR/2dcontext/

  84. funny, but not true by globaljustin · · Score: 1

    I'm starting to feel like the whole "standards will never evolve predictably" argument is a troll argument...

    "The great thing about standards_There's so many to choose from."

    haha, but in any context where standards change, there will be an **ongoing** conversation about what the standards should be. Evolving standards will **certainly** precipitate competing ideas. (see also xkcd comic linked below)

    And people will discuss and debate those ideas. That is **normal**...actually its **necessary**

    In this particular standards debate, HTML, there are clear goals and values. The conversation should be about which option meets those the best, other non-traditional options...then a **decision** and a moving forward.

    That's how the "standards are important but foster endless arguments point" becomes a troll...

    We know its possible to argue infinitely about standards...the idea is to **not** do that, thank you very much ;)

    --
    Thank you Dave Raggett
  85. UTF-8 only. by Animats · · Score: 1

    UTF-8 still lacks a lot of things that most of us in the US and most of Europe don't really wrestle with, but there is a reason there is also a UTF-16 and UTF-32 and many variations there of.

    No, no. UTF-8 is a variable length encoding and can represent all 1,112,064[ potential Unicode characters. RTFM. That's all you need in a sequential file. The in-memory representation of strings is usually expanded to a fixed-length character size, but that's specific to the implementation and independent of the file format.

  86. This is just another symptom by PJ6 · · Score: 1

    of trying to shove a square peg into a round hole. For God's sake why are we still attempting to make web page standards high level and human-readable?

    Throw that shit right out the window. High-level should be handled by vendor products that compile to a standard so low-level that it really doesn't need to change more often than every few years.

  87. A victory against special interests! by core_dump_0 · · Score: 1

    One of the most disturbing things about HTML5 is the "living standard" idea. "Living standard" is the same mentality as the DVD-CCA and Region Coding.

    There is no way we can trust corporations like Microsoft to act in the interest of "compatibility" for hundreds of years! They already proved themselves crooked after HTML5 - the DRM proposal was an attempt to hard-code DRM into every HTML page on the Internet!
    Also note the "rating" meta tag, which is forced to use the proprietary RTA(R) system rather than self-rating by webmasters. If I self-rate my site "general" or "14 years", will I be put on a blacklist just because of a pre-HTML5 industry-decided "relic"?

    Why doesn't anyone protest this trust? While fixed standards may be corrupted by Hollywood and special interests, they (like other fixed standards) are optional to use, without subjecting Web sites to the mercy of a trust?

    I for one am glad there will continue to be reliable fixed standards, protecting the Internet from the long-term will of Big Government and Big Business.

  88. new standard going to have clipboard support. by Anonymous Coward · · Score: 0

    will the new html standards finally allow us to copy text to the clipboard so we can actually make useful web apps. Or is this just another example of security people going too far.

    If its really a security problem then I suggest a dialog that says the following:

    This website would like to submit something to your clipboard. Would you like to allow the site to access your computers clipboard? yes or no.

  89. The technology is all wrong. by master_p · · Score: 1

    The problem behind all this is that the technology is all wrong. HTML was a document delivery technology, it's done and should be left alone. We should move on to better things, like a web UI technology that allows the full spectrum of today's computers to blossom.

  90. Re:Newsflash! HTML5 fork now an official Google BE by Anonymous Coward · · Score: 0

    Perhaps you should upgrade off IE6 and see what the new HTML format is all about.

  91. jobs by zodwallopp · · Score: 1

    Yep, go for it, who needs standards? HTML5 employs thousands of website professionals every year! This new split will create even more jobs. Imagine every snot nosed, green behind the ear, kid designer using whatever technology they want to build websites for friends, family and businesses. Then when they break, not in a year or three years, but in say... oh... 48 hours and can't fix it... they hire me! I'm all for this, chaos = cashola!

  92. Re:Back on topic, the editor of both docs wrote th by jschottm · · Score: 1

    What planet did you do web development on? HTML4 totally evolved (that's quite literally what the 4.x stands for - an evolution from 3.x). And what people do now is vastly different than the capabilities and vision that the W3C had in mind in 1997.

  93. Re:HTML5 is dead. Long Live Apps. by cboslin · · Score: 1

    Screw HTML5. It's, what 12 years too late? Web enabled Applications are the future!

    Yea everyone is saying that, love the Cloud monkier too. The future for me is never going to be an application and/or service that can ONLY be accessed via an active internet connection.

    The future for many of us are applications, esp web applications, that work whether we are currently connected to the Internet or not. Let em sink up to add value when we are connected, but tying me to the net like a dog on a leash is just not going to work in my world, ever. That is DUMB.

    The future means being smart. Smart means the device, whoever makes it, runs more applications on day one than the last release of that device. There are no acceptable exceptions to this rule. To do that it must be rootable.

    To be smart, the device must be open, it must be rootable (allow admin access) so that the owner of the device can configure as they wish and install the software they wish on it.

    I imagine purchasing only open rootable devices that will allow me to install and run, PHP, Python, Ruby, whatever I want and therefore have access to every application written in those environments the first day I purchase the device.

    If a device will not allow me to install, configure, run and play the content I want/need, well it just is not smart and I will never purchase it.

    If you change your answer to web enabled apps that will run standalone when not connected to the Internet/cloud, than we are in agreement...something tells me that is NOT what you were saying. Sigh.

    That dog did not hunt when people started spinning it, many of us realized this from the beginning, we are just waiting for the rest of you to figure it out as well. Eventually you will be forced too, not a matter of if, only when.

  94. Code on webpages is still the bane of the internet by omfglearntoplay · · Score: 1

    If devs could have just stuck to making programs and leaving webpages static safe places to browse for information, the world would be a better place. We wouldn't have rampant malware on 99% of home user boxes. People wouldn't be throwing away good hardware and buying even cheaper PCs because they don't know how to clean off malware. PC manufacturers would actually still attempt to make hardware that lasts for longer than a year. Browsers wouldn't need constant updates to stay secure. Java wouldn't need constant updates. China wouldn't own 90% of the fortune 500's servers, Russia wouldn't be backdooring the pentagon,Etc. Etc. Etc.

    HTML 5 will surely make all of this even worse, with yet more technology holes to deal with. The web could be so nice... but it'll never be anything but a cesspool of malware trash.

  95. The funny part of HTML standard by aglider · · Score: 1

    is that HTML4 browsers implementation is being left behind because there's a new standard. But:
    1. HTML5 is not a standard at all. Not yet, at least.
    2. HTML5 is not a standard but possibly two or more.
    3. HTML4 sites and applications won't disappear overnight.

    --
    Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.