Slashdot Mirror
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."
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.
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?
Thank God for evolution.
Damn that Water Closet Three!
Caveat Utilitor
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.
We all know what to do, but we don't know how to get re-elected once we have done it
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
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/
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
<.<
The World Wide Web is dying. Soon, we shall have only the Internet.
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.
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.
...carving up Microsoft!
You all know it makes sense.
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?
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
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.)
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 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.
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.
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.
I agree. Hearing all of the things that they want to put in it now, I'm not really sure that a lot of them belong in HTML anyway. It seems like we're trying to stuff everything that was hot over the last 10 years into a language that was meant to be used purely for website markup.