Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



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 ) <.moc.liamg. .ta. .tzzagem.> on Wednesday October 06, 2010 @11: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.
  • "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.

  • !surprising (Score:3, Insightful)

    by iONiUM ( 530420 ) on Wednesday October 06, 2010 @11: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..

  • 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.
  • W3C is the problem (Score:4, Insightful)

    by Gadget_Guy ( 627405 ) * on Wednesday October 06, 2010 @11: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.

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

    by thestudio_bob ( 894258 ) on Wednesday October 06, 2010 @11: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.

  • by airfoobar ( 1853132 ) on Wednesday October 06, 2010 @12:30PM (#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 Lennie ( 16154 ) on Wednesday October 06, 2010 @12:33PM (#33810756)

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

    Actually the worst would probably be silverlight ;-)

  • by Lendrick ( 314723 ) on Wednesday October 06, 2010 @12:37PM (#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.

  • by atfrase ( 879806 ) on Wednesday October 06, 2010 @12:55PM (#33811302)

    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.

  • by Anonymous Coward on Wednesday October 06, 2010 @12:58PM (#33811390)
    Agreed.

    Turd == Shit
  • Re:Jeeze. (Score:5, Insightful)

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

    Why does it have to be implemented before it can become a finalized specification?

    Because before it's implemented, it's just some words on a web page, and no one has actually tried it. Implementers inevitably spot parts that are vague, or too complicated or expensive or slow to implement, only when they actually try to implement it. Also, implementing it will mean it gets the regular security and UI review that all new browser features get, which will result in more feedback. And finally, you get almost no feedback from regular authors or users until it's shipping in at least beta versions of browsers. This is why no W3C spec can be declared finished without two interoperable implementations.

    Another way of looking at it is that you could try speccing everything first, then implementing it. But it means that you miss a lot of things and wind up putting out a bad standard. Instead, web standards are usually developed in tandem with implementations, and are open to change as long as it's feasible if new information comes to light. They're only really set in stone when so much content depends on particular behavior that browsers can't change it without breaking websites – barring that, they can always be improved. Even Recommendations aren't final in practice, because they can be superseded by later versions. HTML 4.01 is a recommendation, but HTML5 contradicts it in many places, and takes precedence.

  • by Anonymous Coward on Wednesday October 06, 2010 @01:20PM (#33812032)

    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 within code or within the browsers themselves can lead to security vulnerabilities that are unknown. In addition, if the spec changes and browsers have implemented something based on the draft that gets changed it can have a huge impact.

    For example, let's say company A writes a web application based on IE9 that uses canvas in a certain way throughout the application. The canvas spec gets changed before the HTML 5 spec is ratified. The cost to update the code to work in the new IE 10 or 11 or whatever is out at the time is a couple of hundred thousand dollars. This company will now stick with IE 9 because it works. It will be like IE6 all over again and people will never get off of the older versions. The same scenario can happen with Firefox or Chrome.

    In addition, professional site development will incur extra costs across the board. More QA, more development to make all the hacks work, more security testing, more load testing, etc. So companies will a) not do the extra work and the site will be insecure, not always work, etc or b) incur the cost and pass it to consumers in some way either more ads or higher costs.

    Lastly, and this is my pure developer rant here, HTML and javascript needs to be thrown out in total. Updating these dated technologies and ideas doesn't really address what the web is today. For example, it would be nice to componentize HTML structures for reuse. The technologies (including IP, HTTP, FTP, etc) need to be rewritten to be more flexibile to change with the times as oppossed to holding everything back. Modern web apps would do well with more secure implementations of languages and sandboxing the web to a specific domain in order to make it more secure. Right now flash and active x and java applets can be hacked to gain full system control. But some apps would be better served with offline storage and the ability to work offline. However, the user needs to be able to remove the items in the storage area easily. HTML local storage is being exploited TODAY with tracking information that users can not remove easily. Delete all the cookies you want, it will not delete local storage. See the following links why it needs to be standardized first: http://www.scribd.com/doc/4012693/Abusing-HTML-5-Structured-Clientside-Storage and http://arstechnica.com/tech-policy/news/2010/09/lawsuit-targets-advertiser-over-sneaky-html5-pseudo-cookies.ars. But yeah, let's just move ahead and screw the consequences.

    I'm really blaming Apple here for pushing this so hard. Now all my clients are aware of HTML 5 and think it is the best thing since sliced bread. Until I educate them that it is a draft spec with large consequences. Apple is certainly making my job more difficult. And what about developers who are unaware and implement HTML 5 as per a client without educating them? Who the heck is going to pay for all of the consequences of that? Is Apple going to set aside an HTML 5 rush to implement disaster fund?

  • by DragonWriter ( 970822 ) on Wednesday October 06, 2010 @01:38PM (#33812530)

    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 implementations but doesn't meet the needs for which it was developed, isn't meaningfully done, and if its treated as "done" it will likely only ever be "done" in the sense of "dead" rather than "complete and worth using."

  • by VGPowerlord ( 621254 ) on Wednesday October 06, 2010 @01:58PM (#33813140)

    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 corporation telling people to use vendor extensions (specifically Apple with webkit extensions) instead of waiting for the finalized versions. We don't need HTML5 being diluted any further,

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

    by SpaceLifeForm ( 228190 ) on Wednesday October 06, 2010 @02:07PM (#33813354)
    IE6 is a huge security hole, why are you even catering to the lusers that use it?
  • by BZ ( 40346 ) on Wednesday October 06, 2010 @02:35PM (#33813984)

    OS X doesn't involve reconciling multiple constituencies or implementors with divergent interests. It was also not aiming to create a _specification_; just an implementation. It's often easier to implement than to specify.

  • by tyrione ( 134248 ) on Wednesday October 06, 2010 @02:38PM (#33814036) Homepage
    Your job is to write code, not to design a Sculpture to be admired throughout the ages. Designs are fluid, so is the code that implements them.

"Engineering without management is art." -- Jeff Johnson

Working...