Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Suggests Carving Up HTML 5

Posted by timothy on from the slice-and-dice dept.

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

15 of 113 comments (clear)

  1. If Anyone Else... by WED+Fan · · Score: 5, Insightful

    If anyone else were to suggest this approach, you'd all be saying, "Makes sense."

    --
    Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
    1. Re:If Anyone Else... by Gutboy · · Score: 3, Interesting

      I've said this before but I'm going to say it again.

      Before anyone can work on a standard, their company must agree to donate any patents that become part of the standard to the standards org, and the standards org must allow any patents they own to be used for no charge. The original company can say "no" to the use of their patent in the standard. If any patented stuff 'accidently' gets placed into the standard, it is up to the company to notice and reject the use of their patented stuff. Failure to do so is an implicit agreement to the previous patent requirements.

      If a third party places another company's patented stuff into a standard, the sole economic burden for any lawsuits, licenses, etc. shall fall on that third party, if there is no representation of the company on the standards committee.


      I'm sure I haven't covered all issues that could arise, but you get the idea.

    2. Re:If Anyone Else... by Nurgled · · Score: 3, Insightful

      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.

    3. Re:If Anyone Else... by hixie · · Score: 3, Interesting

      Actually the spec has an annotation system where you can see how stable each section is, so we've somewhat side-stepped the issue of the whole thing not being done being a blocker for smaller parts.

      In practice, implementors (including Microsoft!) are happily implementing HTML5 already.

      Making the one spec be a bazillion smaller specs wouldn't stop us from having to make sure that each bit is compatible with implementations of that bit. Also, a smaller spec doesn't necessarily go much faster through the system than a big spec. Just look at XMLHttpRequest, which used to be part of HTML5 -- it's been split off for years, but it's still far from being a REC, and that's for a spec that's actually just describing existing browsers! This isn't anyone's fault, it's just that specs take a long time to get right. Anne's doing a great job on that spec, and I'm really glad he took it out of HTML5.

      Hopefully other editors will come up and volunteer to take other things out of HTML5. Several people have tried; we have a very poor success rate for these specs. Generally, things that get taken out just languish and die a slow death until I fold them back into HTML5.

  2. New TLA? by clang_jangle · · Score: 3, Funny
    The WC3...


    Damn that Water Closet Three!
    --
    Caveat Utilitor
  3. Re:Embrace, Extend! by tbannist · · Score: 4, Insightful

    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.

    --
    Fanatically anti-fanatical
  4. RISKY but wise by gcnaddict · · Score: 4, Insightful

    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.

    --
    Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
  5. If it were anyone but Microsoft by jollyreaper · · Score: 4, Insightful

    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.
    --
    Kwisatz Haderach
    Sell the spice to CHOAM
    This Mahdi took Shaddam's Throne
  6. Re:Embrace, Extend! by FooAtWFU · · Score: 3, Funny
    Yeah. Microsoft can be okay. Even a stopped clock is right once a day!

    <.<

    --
    The World Wide Web is dying. Soon, we shall have only the Internet.
  7. Kitchen Sink by Chelloveck · · Score: 3, Insightful

    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.

    --
    Chelloveck
    I give up on debugging. From now on, SIGSEGV is a feature.
    1. Re:Kitchen Sink by hixie · · Score: 3, Interesting

      Until I started working on HTML5, there was no spec that defined "window" (as in, window.location, window.document, etc), there was no spec that defined XMLHttpRequest, there was no spec that defined the details of how to talk between iframes, etc. Does this mean nobody cares about those either?

    2. Re:Kitchen Sink by hixie · · Score: 3, Insightful

      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.

  8. Re:Embrace, Extend! by mrmagos · · Score: 3, Funny

    Strange, all my broken clocks are correct twice a day. Do you do out of your way to purchase 24-hour clocks and break them? I thought my hobbies were weird....

    --
    Never start vast projects with half-vast ideas.
  9. Re:HTML5 needs a lot more work by Excors · · Score: 3, Informative

    Last I checked, HTML 5's working doc says that forms aren't going to change over html4.

    They are going to change. It's not yet decided exactly how they will change – the HTML WG has Web Forms 2 (an extension of HTML4's forms), and the Forms WG is working on some rough ideas for trying to fit XForms into HTML5, and there is a joint Task Force that is meant to be working things out between the groups but hasn't actually managed to achieve anything yet. (None of the major browser developers has indicated much interest in implementing XForms, whereas Opera has already released an implementation of WF2 and there is some ongoing work to implement parts in Firefox and Safari, so the momentum is currently in that direction.)

    allow forms to validate without having to have [div]s that do nothing but hold hidden fields because [input] is a presentation tag and therefore must be within a text-carrying tag

    Web Forms 2 says "input elements of type hidden may be placed anywhere (both in inline contexts and block contexts)", which sounds like it satisfies your concern (and has the advantage of working in all existing web browsers, unlike a new <state> element).

    can we PLEASE have them back so that we can use them for tabular data (like item names, prices, descriptions, etc)?

    <table> has never been deprecated, and HTML5 still permits it. (Tables used for layout are not allowed, although that's impossible for an automatic validator to detect). There are already CSS properties that can replace cellpadding ('padding') and cellspacing ('border-spacing').

    would it really kill the documentation writers to say what something has been deprecated BY?

    It seems spec writers usually think that kind of thing should be described in tutorials or other documents, not in the specification. The HTML5 spec is far harder to read than HTML4 (because it's far more detailed, to fix the differences between implementations caused by HTML4's vagueness), so it really needs that kind of user-oriented documentation. The differences document gives a brief mention of what should be used instead of some obsolete features, but it would be nice to have more detail and examples for people who want to move to HTML5.

  10. I'm the editor of the spec and I agree... by hixie · · Score: 4, Informative

    I'm the editor of HTML5, and I agree entirely with Microsoft here (and they're far from the only people saying this). The problem is that we have very few competent specification editors, and if we did have some, there are literally dozens of specifications that are really important to the Web that need editors. Splitting the spec wouldn't make the Web platform grow any faster, it would just mean big parts of the spec would languish even longer.