Microsoft Suggests Carving Up HTML 5

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

Business plan

[WK2]

1) complain about how slow HTML 5 is coming along
2) implement HTML 5 early; broken and unfinished
3) web developers use IE HTML 5
4) even after HTML 5 comes out, most web developers are confused as to the difference between HTML 5 and IE HTML 5
5) non IE web browsers have a tough time implementing HTML 5, and trying to render broken web pages
6) ????
7) Profit!!!

Also, what does Warcraft III have to do with anything?

Re:If Anyone Else...

[peragrin]

Yet your missing the fine print. There are Patents on OOXML, The Patent license which MSFT lets others duplicate OOXML specifically doesn't allow licenses that redistribute the patented software.

so you can't write an OOXML parser with the GPL, Apache, MPL, and several other licenses. Yet the ISO still allowed it to pass.

Enjoy the fine print. MSFT owns souls because of it. MP3 decoders are the same way. MSFT isn't the only company to endorse a standard that can't be implemented by anyone because of patent licensing restrictions.

Re:Kitchen Sink

[mabhatter654]

The browser makers and web designers really pushed for WHATAG standards and were about to push HTML5 over top of the W3C. It's a standard made of what people that WRITE web pages and people that WRITE web browsers want to see changed/fixed versus the last 8 years that nothing much has changed. Web designers need to have ALL the parts there, and browser makers need everybody to develop at the same time so people USE the specs.

I'd like to see a rollout schedule more than anything else. Release each module 3-6 months apart and allow no other non-spec addons until the whole thing is out. That would let Safari, Opera, Firefox keep up and let designers build the new sites organically rather than trying to use any random piece of a large spec all at once.

Re:HTML5 needs a lot more work

[Excors]

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 [whatwg.org] (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 [w3.org] 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.

Re:If Anyone Else...

[Anonymous Coward]

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

Not if you were actually reading the HTML Working Group mailing list, you wouldn't. If you'd been reading the messages related to the subject, you'd know that the spec editor Ian Hickson has thus far not had a problem keeping all the content in a single specification, that there's a lack of editors to handle more specifications, that there are many interdependencies within the specification that make it difficult to modularize, and that the biggest reason people want to split the spec apart is to appease other working groups outside of the HTML WG.

The <canvas> element is a good example of a feature in HTML 5 that would only suffer if split from the main specification. Supposedly, you'd want to split it off so that you can have a task force of graphics API experts evaluate and refine the 2D graphics context. In reality, the existing 2D context already is a standard used by ever major browser vendor save Microsoft. Changing it would introduce compatibility concerns with existing <canvas> content. In fact, there was a release of Firefox solely to fix a regression in its support for <canvas>. It would make far more sense to standardize the existing 2D context, then create a second generation 2D context later if the current one proves inadequate.

Modularization can indeed be a good thing, but in this particular case it's not worth the trouble.

I'm the editor of the spec and I agree...

[hixie]

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.

Re:Considering their history?

[hixie]

HTML5 doesn't actually have the problem of some parts being "delayed" because of other parts being immature -- the spec has annotations all the way down showing how stable each section is, and browsers (including Microsoft!) are implementing it. The HTML5 spec has been progressing much faster, with much more input being taken into account, than other specs at the W3C. In fact, splitting the spec would likely make things go significantly slower, since it would mean that there would be much more cross-group and cross-spec coordination to do.

As far as splitting out the spec goes, I don't think anyone especially disagrees that it should happen. The problem is that we don't have anyone who is volunteering to do the work.