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


Forgot your password?
Microsoft The Internet IT

Microsoft Suggests Carving Up HTML 5 113

dp619 writes "HTML 5 is extensive and may take years to complete. Microsoft's solution to hasten its development is to carve it up. The company wants to divide HTML 5 into sub-specifications overseen by different working groups. Internet Explorer platform architect Chris Wilson said that HTML 5 features including its Canvas APIs, offline caching of Web applications' resources, persistent client-side data storage, and peer-to-peer (P2P) networking connection framework would be useful outside of HTML. The WC3 seems to be receptive to the idea and says that a consensus is forming among working group members to do just that."
This discussion has been archived. No new comments can be posted.

Microsoft Suggests Carving Up HTML 5

Comments Filter:
  • Embrace, Extend! (Score:1, Insightful)

    by Gewalt ( 1200451 ) on Thursday April 24, 2008 @11:07AM (#23183246)
    what comes after that again?
  • If Anyone Else... (Score:5, Insightful)

    by WED Fan ( 911325 ) <akahige.trashmail@net> on Thursday April 24, 2008 @11:16AM (#23183422) Homepage Journal
    If anyone else were to suggest this approach, you'd all be saying, "Makes sense."
  • by snoyberg ( 787126 ) <<snoyberg> <at> <>> on Thursday April 24, 2008 @11:16AM (#23183436) Homepage
    As much as we all hate Microsoft, I think this is genuinely a good idea. Can't we put aside our biases and consider this proposal on its own merits?
  • by quanticle ( 843097 ) on Thursday April 24, 2008 @11:18AM (#23183468) Homepage

    This is pretty standard for Microsoft. I mean they've always only supported part of the specification. Now, I guess they're making this lack of full support explicit.

    In one way though, this is a good thing. If Microsoft says we'll only support sub-specifications A, B, and C, then web developers will have a better idea as to what restrictions they're working under to create cross platform sites. It'd be an improvement over the current system, which seems to consist of coding for one browser, and then going through and testing/experimenting with the other browser to see what's broken.

  • by Tangent128 ( 1112197 ) on Thursday April 24, 2008 @11:20AM (#23183502)
    True. Microsoft actually does have technical ideas worth considering. However, I wouldn't want to see Microsoft politically in charge of any of these efforts, given the influence of their marketing department.
  • by tbannist ( 230135 ) on Thursday April 24, 2008 @11:29AM (#23183672)
    Well we should carefully consider whether it's a trap or not. I mean Microsoft isn't always wrong, but they have a strong track record of evil. It bears examining their proposal closely to see if you can spot the evil machinations.
  • RISKY but wise (Score:5, Insightful)

    by gcnaddict ( 841664 ) on Thursday April 24, 2008 @11:30AM (#23183712)
    There are a few risks. The biggest one is if any of the teams slip behind or run ahead of schedule. If that happens, pieces will begin to fall out of sync.

    however, the biggest benefit would be to web developers if this goes through as planned. I'd appreciate a properly modularized HTML5 myself.
  • by jollyreaper ( 513215 ) on Thursday April 24, 2008 @11:33AM (#23183766)

    If anyone else were to suggest this approach, you'd all be saying, "Makes sense."
    If it were anyone else but Microsoft, we might be willing to extend them the benefit of the doubt.
  • by Anonymous Coward on Thursday April 24, 2008 @11:41AM (#23183924)
    Is there still a point to HTML5 then though?

    Wouldn't it be better to just take the existing XHTML and extend it seeing as that's the point of XHTML? That it's eXtensible?
  • Kitchen Sink (Score:4, Insightful)

    by Chelloveck ( 14643 ) on Thursday April 24, 2008 @11:46AM (#23184050) Homepage

    On the one hand, I want to say that this sounds reasonable, despite it being suggested by Microsoft.

    On the other hand I want to say... WTF?!? Why does a markup language need all that crap anyway? Persistent local storage? What does that have to do with page markup?

    I'm not saying that these other things are bad or unnecessary. Just that they shouldn't be part of the HTML spec. Just like CSS and JavaScript are both widely used with HTML, but are defined in their own separate complementary specs.

    I suppose the real reason for the kitchen sink approach is pragmatic. As explained in TFA, no one has volunteered to take over individual parts. But if nobody cares enough to commit to that, maybe nobody really cares about the result either and those other parts are unnecessary? I say keep HTML as a markup language, add hooks for other things, and let those other things be specified if and when someone actually cares enough to do it.

  • by ( 1108067 ) on Thursday April 24, 2008 @12:30PM (#23184960) Homepage Journal

    Actually, it doesn't make sense. Under that scenario, you could have different sub-groups interpreting the specs in varying, contradictory ways, and end up with supposedly "conforming" implementations that break other sub-groups' work. We've already got too much of that in the browser world, and the chief villain has always been Microsoft.

  • by Nurgled ( 63197 ) on Thursday April 24, 2008 @12:54PM (#23185462)

    I don't really care who's suggesting it; I've been thinking similar things myself. The amount of content in HTML5 is getting ridiculous. If none of it can be declared final until it's all done then there's going to be uncertainty surrounding it for a long time to come, and that'll either put off implementors or lead to the spec hanving to be backward-compatible with earlier drafts of itself and it'll be years before there's interop between browsers.

  • Re:Kitchen Sink (Score:3, Insightful)

    by hixie ( 116369 ) <> on Thursday April 24, 2008 @06:17PM (#23190672) Homepage
    I'd love to be able to make the Web browser developers not implement anything but what the spec says. However, they don't obey us. :-)

    Better to have a spec for them to follow than to say "no, implement the rest first!" and have them make up their own thing.

Do not underestimate the value of print statements for debugging.