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."
Embrace, Extend! (Score:1, Insightful)
Re: (Score:3, Insightful)
Re:Embrace, Extend! (Score:5, Insightful)
Re: (Score:1)
Re: (Score:2)
Only real possibility of a trap here is that
a) Microsoft claims development over those specific technonlogies and patents them (patenting them likely, but they'll do that anyway)
b) They just don't implement chunks of those technologies, leaving the web development community high and dry for some time (again, they'll probably do that anyway)
I actually have to agree with MS on this one. Client-side databases & such are exciting, and increase the possibility of offline web apps, but HTML is a *marku
Re:Embrace, Extend! (Score:4, Funny)
<.<
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
A broken regular chiming clock could be right 24 times a day.
Time Sphere (Score:2)
Re: (Score:1)
I prefer "even a blind squirrel finds a nut once in a while"
Re: (Score:2)
Re: (Score:1)
Re: (Score:3, Interesting)
Re: (Score:2)
While you certainly have a point, I think this all seems more sensible if you try to look at it from the other direction. Yes, they're stuffing all of this new stuff into HTML. But that's because the web itself has become more than purely websites with markup, and HTML does need to catch up with that.
These days the web has become a platform for a much richer experience (ugh, I feel all dirty using horrible marketing phrases like that). I'd rather that experience was grounded solidly in HTML, rather than r
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
>> what comes after that again?
4. Profit?
Re: (Score:1)
=Smidge=
Re: (Score:2)
If Anyone Else... (Score:5, Insightful)
Re: (Score:2, Insightful)
Re: (Score:1)
Re: (Score:3, Insightful)
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.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
MSFT has done it before and continues to do so. MSFT can't change without a complete workplace management change. Basically firing every man
Re: (Score:3, Interesting)
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
Re: (Score:3, Informative)
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 pate
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
I disagree with this idea. This will just cause even more pain for web developers who will be forced to do incremental HTML 5 checking to see if a users browser supports "shiny new HTML 5 standard" or not. Then iterate that out across other browsers, who will probably implement things faster than the IE, given their history.
Nope, bad idea. Release it when it's finished. Thank you.
Re: (Score:2)
I agree with you that HTML 5 should be a clean break. Put all the eggs in the basket, require them ALL to be there and leave behind anybody that can't keep up. We're still bickering about CSS2 specs that came out BEFORE IE6 and are still incorrectly implemented. A fresh reboot with the latest specs is a very good thing
Re: (Score:2)
For those not in the know:
http://www.rpm5.org/ [rpm5.org]
http://www.rpm.org/ [rpm.org]
http://en.wikipedia.org/wiki/RPM_Package_Manager#controversy [wikipedia.org]
Re: (Score:2)
If you ignore... (Score:2, Troll)
Re: (Score:1)
Re:If Anyone Else... (Score:4, 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.
Re:If Anyone Else... (Score:4, Interesting)
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.
Re: (Score:1)
Is there some reason why Microsoft, THE largest enemy of openness in software, would suggest this and nobody else would? The same company who typically loses most when there's open development outside of their company? The same company who has a terrible track record of support in the browser space?
That's the kind of thi
Re: (Score:2)
You're asking... (Score:2)
You're asking if I'd hand OJ a knife? Am I dating his ex?
Uh, wait...too soon?
Re: (Score:1, Informative)
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,
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
It's not like it is a new approach - the W3C (which includes MS) already used it with XHTML 1.1 and 2.0, CSS 3 etc.
Maybe it hasn't been used so far for HTML 5 because it was the recent W3C approach which has failed in the eyes of the HTML 5 crowd - after all, what has become of XHTML 1.1/2.0 and CSS 3?
Note: I actually would prefer XHTML 2 to HTML 5, but realistically it too much to ask for and decent browser support would never eventuate.
a burnt child... (Score:1)
New TLA? (Score:4, Funny)
Damn that Water Closet Three!
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Standard Microsoft Tactics (Score:3, Insightful)
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.
Not out to scew us over? (Score:2)
They're not out to screw us over.
The recently-reconstituted IE team has done an excellent job of building towards standards-compliance. I've been extremely pleased that some parts of Microsoft seem to be softening up. I doubt that mentality represents a general shift in Microsoft's policies, but the browser team has accomplished some outstanding work.
I think dividing the standard up into subsections is a good idea, as it helps keep the specifications small and understandable. Having all that stuffed into one big standard is just asking fo
Re: (Score:2)
Please leave us with something untouched (Score:1)
Re: (Score:2)
Re: (Score:2)
Seen from a different view, USB 2 and USB 1 standards are not incompatible, and worked well. There are devices that are not USB2 compliant, but work with systems that are.
In terms like that, if MS wants to tell the world that they will only be compliant with USB1, let them. While the rest of the world works and becomes compliant with version 2. The real problems wou
Now that they've "discovered" the idea (Score:2)
"Here Microsoft, go play with your ball." (Score:1, Flamebait)
Re: (Score:2)
November 1995
HTML 3.0 was proposed in April of 1995, but it was too complicated and nobody supported it. A simplified version, HTML 3.2, came out in January of 1997. These days, almost everyone is using HTML 4.0, which came out in December of 1997, or 4.01, which came out in December of 1999.
RISKY but wise (Score:5, Insightful)
however, the biggest benefit would be to web developers if this goes through as planned. I'd appreciate a properly modularized HTML5 myself.
Re: (Score:3, Interesting)
If it were anyone but Microsoft (Score:5, Insightful)
Re: (Score:1)
In this case at the very least Microsoft might not claim they implemented the standard when, in fac
Is there much point then? (Score:1, Insightful)
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)
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.
Re: (Score:3, Informative)
I'd like to see a rollout schedule more than anything else. Release each module
Re: (Score:3, Insightful)
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.
Re: (Score:3, Interesting)
Re: (Score:2)
Which is why it should be broken up... they don't have anything to do with HTML.
Re: (Score:2)
And I suggest... (Score:2, Funny)
You all know it makes sense.
Like they did OOXML ? (Score:1, Troll)
Business plan (Score:3, Informative)
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: (Score:3, Informative)
I'm the editor of the spec and I agree... (Score:5, Informative)
Bad ideas come back to haunt the W3C (Score:2)
CSS3 got cut up into modules, and there was a long period of bickering about them, and CSS3 still isn't here.
Putting the product manager of the least compliant browser in charge of the next generation of HTML is like appointing a career street criminal as Attorney General.
I have no trouble believing that HTML5 is being delayed so that MS has enough time to implement it correctly.
(XHTML2 > HTML5)
Well, at least they're being explicit about it (Score:2)
Well, at least now they're being more explicit about their lack of full compliance. Now, when Microsoft says that they "support" a standard, web developers have no idea how much support they're getting. With this, there'll be finer granularity, so Microsoft can say, "We only support subspecifications X, Y, and Z; everything else may not work." This'll make it easier for web developers to see what features they can use while maintaining compatibility with both Internet Explorer and Firefox.
Re: (Score:2)
Re:HTML5 needs a lot more work (Score:4, Informative)
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.)
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).
<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').
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: (Score:1)