原文：The Next-Gen Web: HTML5 - Will We Ever See A Real Standard?。

本地存储相关的 API 作为最新的 HTML5 规范草案的一部分，我们在上个星期看到一些浏览器和插件已经开始采纳这些 API。虽然 Gears、Op…

HTML5 is currently in the draft stage, and the latest specification is available at the W3C web site. User experience on the Internet will change for sure, and here’s why:
1. Persistent Local Storage: Two different mechanisms are introduced for l…

What’s most disappointing about the whole thing, however, is that the W3C moves at an excruciatingly slow pace. They’ve been working on XHTML 2 for almost 7 years now, and they have almost nothing to show for it. I don’t have much faith in HTML 5 either… I think we are going to have to continue to rely on JavaScript hacks and browser plugins in order to enhance the browser experience for quite some time.

“First of all, everything you talk about is from my comments here, not the post, and is my opinion - so it doesn’t have much to do with ‘research’.”

I had found the original post a bit head-scratching in places, but it was the comment itself that made me more concerned, so I was responding to it specifically.

“I have seen *numerous* occassions where effort is spent to spec out some feature or function, and then when somebody comes along to actually implement it, it comes back again with all these changes.”

Yes, that seems like an expected part of the spec lifecycle. As you note, it’s basically impossible to spec in a vacuum — and unwise to implement in a vacuum. Only after a few iterations of both is something reasonably stable likely to emerge.

“I am not sure what I said is even a complaint about anything or anyone, its just a fact.”

I agree completely (I didn’t think I ever disagreed).

“You might think that a spec being certified is important,”

No, I think a spec being “certified” is almost completely irrelevant. The spec and the implementations will be roughly “done” at the same time; they proceed in parallel and each informs the other. By the time the spec is marked “done” it’s a reflection of a reality that already exists, not a blueprint for further work. Or at least hopefully so.

“almost everybody follows and knows about the draft process, they dont suddenly find out about this great new html5 spec only when it becomes a recommendation.”

Right, I agree. And this is as it should be. (It seems like we’re very much on the same page here, I’m not sure why you seem to feel I think differently.)

“Also, please explain to me how fixing CSS bugs in a major browser release is different to fixing CSS bugs in a minor browser release.”

CSS changes break site compatibility (”fixes” included; web developers rely on existing bugs). No browser manufacturer wants to break compat needlessly.

I paraphrase a major Gecko developer (I forget if it was roc or dbaron) who said “the sad truth is that when we’re in the final push for a major version, rendering glitches are *more* critical to analyze than crashes, since we can fix crashes in a point release, but we can’t change the renderer.”

“Fact is also that Microsoft could do a lot more to force an upgrade path for IE users”

I don’t think anyone (well maybe anyone outside Microsoft) would disagree that precisely by not upgrading IE sooner and more frequently, they set an expectation of frozen behavior that has hampered their ability to upgrade and get their users to accept changes. Compare to Firefox’ shorter (though still too long!) release cycles, where developers expect that every year or two, they’ll need to “fix” their site to be compatible with the newest Firefox release, and do so.

So I don’t disagree that more frequent renderer changes are a good thing. But given the chaos that they can cause, it would be extraordinarily risky for any browser maker to make them in a point release.

Perhaps this is a question of degree. If you merely meant that “it would be nice to fix rendering bugs faster” I wholeheartedly agree, and note that, encouragingly, IE8 is coming much sooner after IE7 than 7 followed 6, and the increasing competition provided by Safari should spur all major browsers to improve faster as well. I was only commenting on the specific proposal to do such things in “a point release”, and nothing more.

“All that it comes down to is that WHATWG can’t take criticism, even when it is of the softest kind.”

I think you’re assuming that
(a) I was taking your comments as criticism (I didn’t; I took them as misunderstandings/confusion; in fact I was hoping for pointedly _more_ criticism in your article or your comments, as it’s not clear how you propose to improve the current situation), and
(b) I have some connection with the WHATWG (I don’t; when I said I work with Hixie, I meant that I am another Google employee, not that I’m part of the WHATWG, whatever it would mean to be “part of” such a thing. I’m also an ex-Firefox developer, occasional WebKit contributor, and constant follower of browser development, so I consider myself involved and informed, but not a representative of some group. I’m sorry for any misimpression.)

“you are ignoring 99% of other things that developers and bloggers are saying (such as the timeline for implementation) and why html5 is being picked up so slowly.”

I’m not actually sure what it is that they are saying that I am ignoring. I certainly don’t contradict the idea that “many bloggers feel HTML5 development is slow” — many do feel it’s slow, and even those who don’t wouldn’t be unhappy if it were faster; to state otherwise would be ignorant.

“You may have noticed that there are a ton of developers out there who are simply just confused by html5 and whatever it is that is going on.”

I have indeed noticed that. Spec development and browser development have always been incredibly confusing an probably always will be. I appreciate the efforts to which the WHATWG goes to make the process as open as possible, and beyond that I’m not sure what more can be done to help a more casual audience understand what’s going on.

If the point of your article was to try and shed light on current process, then I think you did a nice job laying out the history of some of the spec issues, and noting who a lot of the current players are, but some points seemed a bit confusing (the article seemed to imply that Gears has dramatically sped up HTML5 spec development, which I don’t think it has; and the picture at the bottom simply stumps me), and I missed what the real thrust was. The headline implied that there was something that could cause HTML5 to simply never get off the ground at all, but that wasn’t how I read the rest of the article, so I wasn’t terribly sure of your point.

“I was referring to getting the implementations done right (and 50% of commenters here have referred to the same thing). The work on this spec will probably continue for another 5 years, but there are some pretty big issues that need some attention today.”

I don’t think anyone in the web development community wants to see problems solved more slowly. Given the massive scope of the problem set web browsers are supposed to solve, and the hugely varied opinions on which of these problems are more important, I think browser manufacturers have improved quite a number of things, but that doesn’t mean that the current state of browser capabilities is “good”. What’s not clear to me is what in this process you’re saying is problematic, or what you’re proposing to improve. From your tone it sort of seems like you view the efforts on the spec side of HTML5 as somehow delaying browser implementors, which I don’t really see as the case; or else sucking up the time of people who would otherwise be writing code in browsers, which I think is also not the case. If the problem is that browser makers aren’t improving things fast enough, well, Gecko and WebKit are both open-source engines and I’m sure would be eager to accept more contributions :).

So if the point of your article was to say that you wish all of HTML5 was implemented now, then I applaud the sentiment, but it doesn’t do much to help us get there or even expose what’s holding things back. And if there was a more detailed point along those lines, I apologize, for I’ve missed it.

“I hope you coming here and telling me my opinion isn’t correct is not a reflection of how the rest of the WHATWG works”

Again, I have no connection with the WHATWG and my opinions do not reflect anyone else’s; but I don’t think it’s out of line for a person with some familiarity with browsers and web technology to read comments about browsers and web technology and question them. I mean no personal attack or mischaracterization, and would appreciate not receiving any in return.

“I also hope that the WHATWG definition of reesarch doesn’t mean “whatever WHATWG thinks is correct, please ask us to find out what that may be””

I’m not sure exactly what this comment means, so I will merely say that as I am observing, Ian is currently attempting to respond to every topic that has ever been sent to the mailing lists about HTML5, has open lines of communication with all browsers, and is always interested in comments about what works best in the real world. I don’t think that guarantees the best possible spec, but it probably comes closer than any other method.

Best wishes.

First of all, everything you talk about is from my comments here, not the post, and is my opinion - so it doesn’t have much to do with ‘research’. I am on the mailing lists and have been for years, I have seen *numerous* occassions where effort is spent to spec out some feature or function, and then when somebody comes along to actually implement it, it comes back again with all these changes. Its impossible to account for all potential user, developer and environment variations, I am not sure what I said is even a complaint about anything or anyone, its just a fact.

You might think that a spec being certified is important, but almost everybody follows and knows about the draft process, they dont suddenly find out about this great new html5 spec only when it becomes a recommendation.

Also, please explain to me how fixing CSS bugs in a major browser release is different to fixing CSS bugs in a minor browser release. I have seen numerous hotfixes from Microsoft that fix smaller issues in point releases. Or is it part of the spec that changes can only be made in major browser releases? Fact is also that Microsoft could do a lot more to force an upgrade path for IE users

All that it comes down to is that WHATWG can’t take criticism, even when it is of the softest kind. You can pick-and-choose as many statements from the comment thread here as you like, but in doing so you are ignoring 99% of other things that developers and bloggers are saying (such as the timeline for implementation) and why html5 is being picked up so slowly. You may have noticed that there are a ton of developers out there who are simply just confused by html5 and whatever it is that is going on.

I also know that there are formal ‘proposals’ for most of those technologies that I pointed out, but the point is that we have had ‘proposals’ for as long as the web has been around, yet everything is still a mess because of implementations. I was referring to getting the implementations done right (and 50% of commenters here have referred to the same thing). The work on this spec will probably continue for another 5 years, but there are some pretty big issues that need some attention today.

I hope you coming here and telling me my opinion isn’t correct is not a reflection of how the rest of the WHATWG works with the actual specs as well. I also hope that the WHATWG definition of reesarch doesn’t mean “whatever WHATWG thinks is correct, please ask us to find out what that may be”

IE6 is only great if you are Microsoft or an MS fanboy, if you are a web developer it is junk… actually it is just junk. Firefox was the light at a long dark tunnel of sites design to work in IE instead of all browsers, and forced MS into actually working on a half decent standards based browser - IE8.

People don’t spend time “making their code “compatible with Firefox””, they simply design sites based on standards supported by millions of web developers and almost all modern browsers. It’s IE6 that they waste time getting sites to work on.