Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
The Internet Technology

W3C Says Don't Use HTML5 Yet 205

GMGruman writes "InfoWorld's Paul Krill reports that the W3C, the standards body behind the Web standards, is urging Web developers not to use the draft HTML5 standards on their websites. This flies in the face of HTML5 support and encouragement, especially for mobile devices, by Apple, Google, Microsoft, and others. The W3C says developers should avoid the draft HTML5 spec (the final version is not due for several years) because of interoperability issues across browsers."
This discussion has been archived. No new comments can be posted.

W3C Says Don't Use HTML5 Yet

Comments Filter:
  • So? (Score:5, Insightful)

    by The MAZZTer ( 911996 ) <{megazzt} {at} {gmail.com}> on Wednesday October 06, 2010 @10:41AM (#33809244) Homepage
    I already had to test my websites across all the major browsers (especially IE8) before HTML5 to be sure that little differences weren't breaking everything. I would hardly expect HTML5 to magically change that anyway.
    • by mrops ( 927562 )

      Same thing happening with 802.11n

      ieee is stuck for so long that vendors have started pushing draft hardware. I can see why they are stuck, my dual mode router still works better on 802.11g compared to its 802.11n, n is choppy, slow and a huge hassels, particularly if u VPN. Clearly there are bumps with the n technology.

    • by Mazzie ( 672533 )
      The argument in the article against using HTML5 due to interoperability issues with older browsers makes zero sense. No matter how much time passes, all of the new features of HTML5 will be broken in IE6 and the like. If on the other hand they are arguing that HTML5 breaks HTML4 features of IE6, then holy crap is the W3C incompetent. Am I missing something here? Other than that, the article reads like a Silverlight advertisement, so...
  • by eldavojohn ( 898314 ) * <eldavojohnNO@SPAMgmail.com> on Wednesday October 06, 2010 @10:41AM (#33809252) Journal

    "The problem we're facing right now is there is already a lot of excitement for HTML5, but it's a little too early to deploy it because we're running into interoperability issues," including differences between video on devices ...

    Well, I read an entire book on HTML5 [slashdot.org] and, as web developers have usually done, you just build in graceful fallbacks for unsupported browsers or devices. If APIs change, then they change but a lot of developers would probably rather opt for that than something a lot more proprietary and complicated. A whole chapter of the book I reviewed was devoted to extensively detailing how one would get video working in increasingly fallback ways depending on your preference of support. Why can't we keep up that mentality? The worst case is we just default back to the Flash/HTML4 route.

    "HTML 5 is at various stages of implementation right now through the Web browsers. If you look at the various browsers, most of the aggressive implementations are in the beta versions,"

    Another sage lesson from Mark Pilgrim's book: "Those who ship code win." You can sit there and tell everyone to 'hold on' all you want but if you don't give them a good reason to stop pushing forward with the implementation, they aren't going to wait for your consortium to debate for another five years. We're moving forward. There will be bumps. The time for discussing a completely perfect approach has passed and browsers will thrust what support they can into practice, warts and all. At some point this has to be done, it will never be truly perfect.

    • by tixxit ( 1107127 ) on Wednesday October 06, 2010 @11:32AM (#33810730)
      It is also a fantastic way to actually see what works. Essentially, we are seeing a big beta test of the HTML5 spec. No one is going to go out and build a HTML5 dependent web site, but lots of folks are building in enhancements for browsers with support. It helps ensure what makes it into the spec is what people are actually building sites with and what user's are actually using, rather than simply what the workgroup thinks people would like (or what is in their interests, for whatever reasons).
    • by Lennie ( 16154 ) on Wednesday October 06, 2010 @11:33AM (#33810756)

      "The worst case is we just default back to the Flash/HTML4 route."

      Actually the worst would probably be silverlight ;-)

    • by WebManWalking ( 1225366 ) on Wednesday October 06, 2010 @11:48AM (#33811068)
      Mark Pilgrim's book is good. Very practical advice about how to use features. Also good (personal experience): Bruce Lawson and Remy Sharp, Introducing HTML5, and Peter Lubbers, Brian Albers and Frank Salim, Pro HTML5 Programming. Also good (Ben Nadel [bennadel.com] raves about it): Jeremy Keith, HTML5 for Web Designers. (I can't speak from personal experience about that one yet, but it was the first one on the iBookstore and I have the sample.)

      A little history about HTML5 books: For the longest time, people held off on publishing because of the same sort of FUD that W3C is spreading. What if it changes? What if I publish and a new feature becomes the hot topic and no one buys my book because I published too soon? But then Bruce Lawson and Remy Sharp published. Then I guess the other publishing houses realized that they'd better publish soon, or else Bruce and Remy were going to soak up all the disposable income that's been waiting on an actual book. So, like, one or two weeks later, Mark's book shipped. Then, like, 2 or 3 weeks later, Peter, Brian and Frank's book. So here's a big Thank You to Bruce and Remy for breaking the ice.

      The cat's out of the bag, W3C. People are getting antsy to code. I don't you're going to get that cat back in the bag.
    • ...will thrust what support they can into practice, warts and all.

      The most compelling case for anti-virus I've heard for quite some time.

    • Re: (Score:3, Insightful)

      by VGPowerlord ( 621254 )

      If APIs change, then they change but a lot of developers would probably rather opt for that than something a lot more proprietary and complicated.

      If APIs change, then you're stuck with a lose-lose situation.

      Either
      1. The browser makers have to support these non-standard (we could even say "proprietary") APIs, or
      2. People who designed their sites for draft HTML5 and don't update them may partially work and fail in unexpected ways that the fallback doesn't cover.

      We've already had a major electronics corporatio

  • !surprising (Score:3, Insightful)

    by iONiUM ( 530420 ) on Wednesday October 06, 2010 @10:42AM (#33809274) Journal

    I don't really find this surprising in the least. I've been saying this for awhile now. Why would you possibly want to build a professional application on top of what is basically a mudslide? The maintainability alone is completely shot.

    Not that I don't think HTML5 will have a huge impact in the future, it's just, I don't know why anyone would make a professional application in it *at the moment*. Better to stick with something that is mature and fully adopted.

    Just my $0.02..

    • I don't really find this surprising in the least. I've been saying this for awhile now. Why would you possibly want to build a professional application on top of what is basically a mudslide?

      The thing is thats how it is now and how it was before HTML5. People are still building websites and using them to make money so it can't be that bad.

    • Re:!surprising (Score:5, Insightful)

      by thestudio_bob ( 894258 ) on Wednesday October 06, 2010 @10:54AM (#33809618)

      So you would rather have everyone wait for them to "approve" it in 3-5 years, tell people to start using it and then find out that there's problems with real-world use. At which point they have to go back to "debating" how to fix the problems, which might takes another 3-5 years.

      Unfortunately, you have to get people to start using it. Better to start finding out about "problems" now before the draft is finalized. As long as people are putting in "safe" fall-backs, then this really isn't a problem. I don't see it as extra work, since I was already having to do this for IE6 anyways.

      I see you 2 and raise you another 2.

      • So you would rather have everyone wait for them to "approve" it in 3-5 years, tell people to start using it and then find out that there's problems with real-world use. At which point they have to go back to "debating" how to fix the problems, which might takes another 3-5 years.

        The nature of standards is such that they're not standards until they're approved and recognized. Flaws within the standards result in further standards and modifications - but at least you can then guarantee a minimum baseline of support. That also includes flaws -- if it fails, it will fail the same way across platforms.

        • by arose ( 644256 )

          Flaws within the standards result in further standards and modifications - but at least you can then guarantee a minimum baseline of support.

          Back in reality that is not how web standards work out. HTML4, CSS2 and PNG were finalized, did that mean that they were the minimum baseline?

      • He's not saying don't use it. He's saying if you're building something for business purposes, don't spend the extra time and money to build an HTML5 version, build a series of workarounds for the various differences in HTML5 browsers, and the build a graceful fall back version for non-HTML5 devices. He's suggesting to use a spec that's matured.

        You will still have the millions of other sites from hobbyists, pet projects, etc., out there who will use HTML5 and find its quirks and problems.

        One more note
        • by arose ( 644256 )

          As someone who runs NoScript, I can safely say the people who put those "safe fall-backs" in are in the minority, and this is currently a problem, even without HTML5.

          There is a big difference between having fallbacks for lacking features and fallbacks for existing features that the user deliberately disables. Having a duplicate version for all javascript (that can be quite a bit these days) in whatever the backend is a much bigger liability then a CSS hack for IE6. That said, it is true that far too few pl

    • by bersl2 ( 689221 )

      I don't see why using HTML5 now is a problem, with two major provisos:

      1. developers build-in the necessary hacks to deal with different implementations of the draft; and
      2. developers maintain the site such that they upgrade to comply with updated drafts (if necessary) and the final standard.

      Also, lol Slashdot for screwing up <ol> rendering?

    • by xaxa ( 988988 )

      I'm writing a "small" (counting the number of templates required) web application at the moment. I've used HTML 5 elements, mostly for my amusement and learning.

      The ones I've used are NAV, SECTION and HEADER (and I, in the HTML5 sense). I've also used a few new attributes, e.g. placeholder on a text INPUT field.

      I might get rid of the NAV/SECTION/HEADER if I find any problems with IE6, but I think it's unlikely these bits of the spec will change.

      Equally I've used some CSS3 stuff, e.g. to do row striping of t

      • Re: (Score:2, Insightful)

        IE6 is a huge security hole, why are you even catering to the lusers that use it?
        • by xaxa ( 988988 )

          We use it at work (although many people have semi-officially installed Firefox), on Windows 2000.

          We want to upgrade, but the government basically cancelled all IT spending -- it doesn't seem to matter that we've hardly spent anything on IT for the last 10 years and desperately need to upgrade, or that we'd already agreed to purchase PCs (etc) from some companies before the new policy was announced. We've lost money from not buying the stuff we'd agreed to buy, and from wasting a lot of staff time preparing

    • Re: (Score:3, Interesting)

      by Hylandr ( 813770 )
      I agree with iONiUM.

      There is no clear advantage or improvement that HTML5 would provide in delivering information or selling goods to our customers on the web. I don't feel like dropping everything I am doing, to re-write or re-implement everything I have now, and the customer is perfectly fine accepting. NO Client ever cared what language the site is presented in, as long as it looks decent. Html 5 is grand I am sure, but I still present websites in php driven html 3. I have enough on my plate with the
    • by paimin ( 656338 )

      Not that I don't think HTML5 will have a huge impact in the future, it's just, I don't know why anyone would make a professional application in it *at the moment*. Better to stick with something that is mature and fully adopted.

      You mean like (X)HTML4.x(strict|transitional), which is perfectly cohesive, and has identical and unchanging support across all modern browsers?

      :-|

    • Better to stick with something that is mature and fully adopted.

      Ha ha, good one!

  • by jaymz2k4 ( 790806 ) <jaymzNO@SPAMjaymz.eu> on Wednesday October 06, 2010 @10:45AM (#33809378) Homepage
    When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.
    • by DJRumpy ( 1345787 ) on Wednesday October 06, 2010 @10:51AM (#33809530)

      My thoughts exactly. This reminds me of 'Pre-N' wireless, which took far too long to ratify a standard that was already in wide use. They sat on their asses so long, it became a joke in the industry. If the governing body takes this long to certify it and they are claiming 'years' more in the future before the standard is finalized, then something is broken. This smacks of Google's 'beta' status. Eventually you have to shit and get off the pot.

      Essentially they just need to finalize it, and for those bits that aren't production ready, defer them to HTML6.

      • Thank you. 802.11n vs. 'Draft-N' was exactly what came to mind. If we wait around for standards bodies to approve already functional and complete specs instead of moving on with our lives, technology will progress as slowly as an involuntary bureaucracy would have made it. It's the right thing to choose to move ahead with a complete and functional spec if the paper for it isn't being pushed fast enough.
      • Maybe if manufacturers didn't flood the market with incompatible pre-n and draft-n devices then there would have been more urgency in ratifying the standard.
    • by M. Baranczak ( 726671 ) on Wednesday October 06, 2010 @10:52AM (#33809572)

      I had to read that part a couple times to make sure it was right. Several years? What are these guys smoking? They actually expect people to wait that long?

      • Re: (Score:3, Informative)

        by TheRaven64 ( 641858 )

        It sounds like he hasn't actually read the spec, or his comments are being taken out of context (sounds about right for InfoWorld). Different parts of it are at different levels of readiness, and this is indicated in the document itself. It also has a nice indicator of which browsers support which features.

        You absolutely should not use HTML 5 now, nor expect it to be stable in the next couple of years. However, there is a large subset of HTML 5 that is stable, well supported, and ready for use now. Not

    • Re: (Score:3, Interesting)

      by kccricket ( 217833 )

      What we need is "a day in the life of a W3C draft" article to figure out why these standards and recommendations take so long to mature.

      • Re: (Score:3, Interesting)

        by xaxa ( 988988 )

        In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.

        What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big compa

      • Re: (Score:3, Funny)

        by funaho ( 42567 )
        Even better, I'd like to see the story of a W3C draft done to the tune of "I'm Just a Bill" from Schoolhouse Rock. Just don't let the W3C do it or they will debate the lyrics for years and not release a draft version until 2020.
      • The W3C is not really running the HTML 5 standards process. The reason it is taking so long is that each part of the spec must first have a well-defined need that it addresses and must then have two independent implementations before it can move to final status. It takes a while for two browsers (usually WebKit and Gecko) to implement something new, to find problems (i.e. unimplementable bits) with the draft spec, then for people to start using it and test whether it really does address the defined need.
    • When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.

      This is why the WHATWG – the body that originally developed HTML5, and which still develops a version in parallel to the W3C – abandoned the idea of rating the stability of the spec as a whole. The WHATWG spec version [whatwg.org] (which is edited by the same person as the W3C spec, contains everything the W3C spec does plus more, and has useful JavaScript annotations like a feedback form) is perpetually labeled "Draft Standard", and per-section annotations in the margins tell you the implementation status of each feature.

      The W3C Process [w3.org], on the other hand, requires everything to proceed through the Candidate Recommendation stage, where it gets feature-frozen, and therefore becomes rapidly obsolete. It's quite backwards, but doesn't seem likely to change soon. So for sanity's sake, you can just ignore the W3C and follow the WHATWG instead.

      (I really doubt that Philippe Le Hegaret actually said anything like what he was quoted as saying in TFA, though. It doesn't match what I've heard from him or the W3C before – no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback. It sounds more like an anti-HTML5 smear piece. Paul Krill has apparently written other anti-HTML5 articles [infoworld.com].)

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        ._. The original plan of WhatWG was to stabilize in 2022 . Yes. 12 years from now. But the devil is in the details and I am not 100% up to date on the W3C details. I get the feeling that the W3C is trying to be the Debian of standardization organizations though. Slow and stable.

    • by Tridus ( 79566 ) on Wednesday October 06, 2010 @11:51AM (#33811146) Homepage

      This.

      The W3C is a running joke at this point. They didn't even want HTML 5 in the first place. Now they're telling people to shy away from it for a few YEARS?

      I don't know what Internet these guys are on, but it's not the same one that the rest of us inhabit.

    • Standard bodies always fall behind. If you count on them nothing can be done.

      For the same reason, let's not abuse the 'standard-compliance' weapon either. We criticized that IE wasn't standard compliant for a long time, and that was not all for a good reason.

  • Who cares (Score:5, Funny)

    by 0racle ( 667029 ) on Wednesday October 06, 2010 @10:46AM (#33809384)
    Like anyone has ever listened to the w3c about standards and coding practices before.
  • Not for not supporting HTML5, but for setting the precendent where a lot of developers made their site for the "de facto standard" of it. Implementing right now HTML5 is making the same kind of mistake, should not be future proof.

    In the other hand, the main browser that have no clue on what HTML5 is is precisely IE, so now they are getting a bit of their own medicine.
    • Part of the point of HTML 5 is that it's possible to implement it using JavaScript and plugins. For example, the storage stuff can be implemented using Flash local storage. Canvas can be implemented using some JavaScript and WML. You actually don't need Microsoft's help to use HTML 5 with IE, you just have longer load times (and more potential security holes) for IE users because you need to pull in a load of third-party crap to implement it properly.
  • W3C is the problem (Score:4, Insightful)

    by Gadget_Guy ( 627405 ) * on Wednesday October 06, 2010 @10:50AM (#33809518)

    It seems obvious to me that you wouldn't use a technology that would work in less than half of the intended audience (unless you make it degrade gracefully).

    But the real question is why does it take so long to come up with these standards? HTML5 started by WHATWG back in 2004. CSS3 has been around since 2005. Just get them finalized already. Don't whinge about browsers not fully supporting the standards if you don't give them a fixed document to work towards.

    • by Simetrical ( 1047518 ) <Simetrical+sd@gmail.com> on Wednesday October 06, 2010 @11:03AM (#33809878) Homepage

      But the real question is why does it take so long to come up with these standards? HTML5 started by WHATWG back in 2004. CSS3 has been around since 2005. Just get them finalized already. Don't whinge about browsers not fully supporting the standards if you don't give them a fixed document to work towards.

      The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.

      So it's mostly a matter of limited programming time, nothing mysterious.

      • Re: (Score:3, Informative)

        by POWRSURG ( 755318 )

        The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.

        Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5 [opera.com].

        • by Simetrical ( 1047518 ) <Simetrical+sd@gmail.com> on Wednesday October 06, 2010 @12:06PM (#33811614) Homepage

          Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5 [opera.com].

          I quite deliberately said that Firefox 4 will be the first good implementation of HTML5 form enhancements. I wrote HTML5 form support for MediaWiki, but disabled it – partly because of an inexcusably bad WebKit bug, but also because Opera's support is just cruddy. The UI is terrible – red-bordered boxes that only appear when you try to submit the form, not when you actually do the invalid input.

          And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext, so <input type=password pattern=....> to require passwords of at least four characters is a non-starter. I reported the bug to Opera around the time 10.00 was beta, and it's still not fixed in 10.60. To replicate, cut and paste this into your URL bar:

          data:text/html,<form><input name=foo type=password pattern=...><input type=submit></form>

          Then type one or two letters in the password field (not more) and try to submit. So, Opera's great and all, but its implementation of this stinks.

          • by azrider ( 918631 )

            >To replicate, cut and paste this into your URL bar:
            >data:text/html,
            >Then type one or two letters in the password field (not more) and try to submit.

            Chrome 6.0.472.63 works
            Opera 10.62-6438 fails
            Firefox 3.6.10 fails

            (All on Linux x86-64

            • by tyrione ( 134248 )

              The starting point for Opera is 10.7 and Firefox is 4.x for HTML5 standard support.

              Safari, Chrome, Epiphany and other WebKit browsers will all work. Let's test.

              Chrome 7.0.536.2 dev: passes
              WebKitGTK+ 1.3.4 passes
              Safari Release 5.0.2 passes.

              Why do they all now work? They work now with the HTML5 Algorithm complete. Go to html5test.com and check against Chrome's latest browser, WebKit Nightly and Epiphany Nightly or Epiphany with WebKitGTK 1.3.4.

          • by Y-Crate ( 540566 )

            Works properly on Safari 5.0.2

          • And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext

            Not a bug. Password masking itself is the bug [useit.com].

            • Sorry, but that's just wrong. Sometimes Nielsen has good stuff to say, but at other, he just seems out of touch:

              More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

              Who has an office? I don't. Most of my friends don't. If you log in at work, your screen is generally visible. Ditto for on your laptop when your commuting. Home is the only safe place.

              In cases where there's a tension between security and usability, sometimes security should win.

              Sometimes security should win? Usability's important, but I think Nielsen is over-emphasizing its importance because its his person crusade.

              It's therefore worth offering them a checkbox to have their passwords masked.

              His solution? Default to insecure and require user-interaction to increase

    • Re: (Score:3, Insightful)

      But the real question is why does it take so long to come up with these standards?

      Because it should. The problem is the idea that you shouldn't implement a standard until its done. The reverse is true: a standard shouldn't be done and frozen until, at a minimum, there exist independently-developed, interoperable implementations that acheive the purpose for which the standard was developed.

      A "standard" that isn't implemented at all, doesn't have interoperable implementations, or which has interoperable impl

  • If they can't write specs in less than several years, why not divide html 5 into its core components and concentrate the work on one piece at a time?

    They could work on the final specs for the canva element first, then the video tag, client storage, and so on until everything is done.

    There could be some kind of a transitionnal html5, falling back to html4 when something is not yet specified.

  • Guess I'll have to tell my client that we have to stop work on their snazzy HTML5/AJAX site and hold off on it for a few years.
    Ohhh wait.... the W3C is a bunch of prudish pencil-necks who move at a snails pace and are generally clueless to how the real world works.

    Hey W3C: Bite me, developers will develop no matter what you say.

  • Maybe it's time they speed up their process a little?
    Hopefully then they wont be passed by reality which develops at a much faster pace.
    And then maybe they can avoid painful hiccups like XHTML 1, 1.5 and 2?

    They started off great but more and more they are a waste of money and resources.

    • by Lennie ( 16154 )

      Actually HTML5 would not have existed if we let W3C figure it all out by themselves.

      It was actually the WHATWG which started on HTML5, W3C only has XHTML2 as a plan, but it wasn't even backwards compatible with XHTML.

      The WHATWG has really done a lot to get HTML5 'out there' fast.

      I think the people who do the work on HTML5 probably also need to work on CSS3. And it's a lot of work, so it seems.

  • I tried to create a website that had to present some 480p videos. I encoded them to Ogg Theora, and figured I could forgo Internet explorer compatibility by encouraging visitors to use either Firefox or Chrome. Unfortunately, for all the noise Firefox makes about supporting open standard, their insistence on implementing their own video support rather than relying on Underlying os ability is completely messed up. Every platform I tested on exposed different bugs in Firefox that prevented the site from w

    • by Lennie ( 16154 )

      That version of Firefox was the first to support Ogg Theora, the streaming in particular isn't very good. Firefox 4 will be a lot better in that regard.

    • by tepples ( 727027 )

      If I instead decided to use the de-facto x264 standard, I increase my browser compatibility across the board

      But how much would it cost to either A. obtain a license from MPEG LA to encode your videos using x264, or B. emigrate from the United States? According to a summary of the license terms [mpegla.com], the royalty for H.264 use over the Internet is zero until the end of 2016, then $2,500 per copy (the free TV rate) afterward.

      • MPEG LA has already stated that they will further extend the existing no-fee provisions. So, practically, he will most likely not have to pay.

  • by airfoobar ( 1853132 ) on Wednesday October 06, 2010 @11:30AM (#33810676)

    If developers are encouraged to use HTML5 in its present form, which has inconsistencies across browsers, some websites will not work properly on some brand new, modern browsers -- not necessarily because the browsers are not standards compliant, but because the websites had to choose to be compliant with the unfinished standard implemented within a particular browser.

    While most developers would normally choose the common factor and make their websites work on all browsers, other interests may prevent them from doing so. We've already seen Microsoft pay off certain popular websites to make their pages use HTML5 that only IE9 supports, as a marketing technique to make others look bad. While you could argue that all marketing is fair game (lies and subterfuge; smoke and mirrors), this sort of thing makes the job of the standards authority much more difficult, because some things may become defacto standards, thus undermining their efforts and ultimately making compatibility across browsers more difficult.

    Remember the last time this sort of thing happened? Don't forget that Microsoft still has a good chunk of market share, and could invent new ways of making history repeat itself.

  • by Lendrick ( 314723 ) on Wednesday October 06, 2010 @11:37AM (#33810834) Homepage Journal

    Web developer here.

    First off, HTML 4 has plenty of browser interoperability issues. Just try to develop something that works on IE and any other browser.

    Secondly, for the love of God and all that is holy, HTML is primarily a visual medium that people look at on a computer screen! Separating content (html) from presentation (CSS) was an excellent idea. Failing to allow vertical centering without dumbass CSS and javascript hacks is not. Seriously, what the hell?

    Third, why can't CSS styles inherit other styles or use constants? You were *finally* going to add that into CSS, and then some jackass decided not to include it because it would make it more *complicated*. Do you know what's complicated? Having to change 40 instances of a color in a CSS file because I can't define a damn constant. This is exactly the kind of shit CSS was supposed to *solve*. Safari implemented this briefly and removed it because *they were afraid people would like it too much and usage would become widespread before there was a standard*. Add it to the standard! Right now, we have to use ridiculous workarounds like CSS compilers, which don't fit very well into a lot of modern CMSs.

    Fourth, stop deliberating and start releasing official standards, otherwise Microsoft will just run off and do its own thing and we'll all be boned *again*. You're doing way more damage than you're preventing.

    Finally, your failure to support as standards things (like the aforementioned CSS vertical centering) that people need to do in the real world on a regular basis just leads web developers to use non-standard code and bullshit like Flash, which circumvents your standard altogether.

    End rant.

    • Re: (Score:3, Insightful)

      by atfrase ( 879806 )

      What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state? It would not be the first time a company sabotaged a cooperative effort to further their own interests.

    • Re: (Score:3, Informative)

      by nametaken ( 610866 ) *

      I can appreciate that some of that would seem more natural, but you can accomplish most (all?) of that using multiple classes and grouping. At the moment, I'd agree with this (http://dorward.me.uk/www/css/inheritance/) in that I'm not sure we even need OO style inheritance given that we have these other methods.

      That said, if you REALLY need constants and inheritance you could implement some server side hackery. I realize that would not be optimal for most folks and breaks the independent style paradigm. :

      • by dkf ( 304284 )

        That said, if you REALLY need constants and inheritance you could implement some server side hackery. I realize that would not be optimal for most folks and breaks the independent style paradigm.

        It doesn't really. If the style coming over the wire isn't the style as written by the original developer, but has a collection of transformations applied to it in between (e.g., converting "constants" to their values) then who cares except the developer? What's really wrong is that CSS isn't done with a syntax that can be produced from XSLT processing easily; if it was, all this whining about a lack of programming flexibility would be seen for what it is.

    • > ...Microsoft will just run off and do its own thing...

      With a market share below 50% and shrinking?

    • Third, why can't CSS styles inherit other styles or use constants?

      This.

      A million times this.

      Why can't CSS natively do the following?

      $constant_1 = 20em;
      $constant_2 = 10em;

      #container [ {
      width: $constant_1;
      min-height: $constant_2;
      } .foo {
      width: $constant_1 - 2em;
      }
      ]

      instead of

      #container {
      width: 20em;
      min-height: 10em;
      }

      #container .foo {
      width: 18em;
      }

      When I do CSS, I use a crapton of tabs to indent declarations, and I als

      • Because that's an engineering solution in a medium populated with designers.

        Also, I personally think you've found a solution in search of a problem, since good class naming practices essentially create a nest anyways (though not declaratory).

    • Wow. You succinctly described in three paragraphs everything I hate about CSS and HTML. If those problems were fixed, I would love web programming.
  • I can't even use Youtube anymore. Even 360p videos don't play smoothly, and when they go fullscreen (Which isn't really fullscreen anymore) it turns into a slideshow. Forget HD.

    AND THERE'S NO WAY TO DISABLE IT. Way to go, Google.

  • Sound advice (Score:3, Informative)

    by Ossifer ( 703813 ) on Wednesday October 06, 2010 @11:47AM (#33811040)

    The usual games of trying to put facts on the ground first to "win" a standards battle....

    HTML5 needs a LOT of work, especially in the realm of security.

  • HTML5 will be great, but it is not there yet. I wanted to implement HTML5 for all the videos on my website, but unfortunately, I was unable to find any good HTML5 video player with all the bells and whistles that the Flash players can offer. On top of that, the HTML5 videos players I tested with Flash fallback, were showing the video preview picture without anything suggesting that it is a video, not a picture - for example play button on the center. For the time being I am away from HTML5, even if I like
  • This isn't the W3C. (Score:3, Informative)

    by R.Mo_Robert ( 737913 ) on Wednesday October 06, 2010 @11:58AM (#33811382)

    ...just a guy who happens to be part of the W3C [w3.org] stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).

  • Use HTML 4.01 STRICT DTD. Strict fixes the IE6 box model problem, which is _huge_.

    Use a CSS reset to make all browsers start with a consistent base style which you then define.

    Use Clearfix so you can clear floats without having to insert extra HTML (a div clear class which I see people use all the time).

    Either make up your own commonly-used CSS styles, or use something pre-made like 960.

    Use DD_Roundies to give IE rounded corners and give IE6 alpha transparency for PNGs. (avoid absolute positioning with this

  • by Anonymous Coward

    As a professional web application developer, I agree with the W3C on this one. Apple is quick to push HTML5 because it has some odd fascination with hating flash. HTML5, however, does not do everything that flash can do. Furthermore, there are security implications within the draft spec.

    Standards need to be approved for professional applications. Sensitive sites like banks, hospitals, heck sites that store and use any personal information need to be secure. By introducing hacks and branches either with

  • I can't find anything on the tubes about this apart from the infoworld article (and its mirrors on apparently every site ending with -world.com). We don't know what he's actually said, and/or what his reasoning was.

    If he was saying something like "Don't rely on HTML5 being fully implemented just yet, because various things are subject to change", that's just understandable. He may not be saying "don't use it" - just "don't rely on it", or "don't use in a production environment that has to work for the next

  • I thought that one of the big factors in adoption of html5 vs the superior xhtml2 spec was that html5 was here now?

  • There is a heartfelt intention among certain members of standards bodies to want to produce something that is 'right' or 'robust' or 'logically consistent' or any number of other noble qualities that characterize enduring standards. In committee, these people carry a lot of weight with sound arguments and endless examples of lesser works. They often prevent huge holes or flawed assumptions from undermining these long and complex works. Of course, they slow things down, too. The problem comes down to con

What sin has not been committed in the name of efficiency?

Working...