Thoughts On WHATWG
February 21st, 2008
Whenever the question of HTML5’s ridiculous scope creep is broached, Hixie changes the subject. I don’t think we need to agree on everything, but I appreciate straightforward answers.
My concern is that HTML5 is becoming a dumping ground for any feature that any vendor wishes to implement. Mozilla lends credibility to this specification, and Mozilla doesn’t need everything we do to be called a “standard”, at least not at first, because we have credibility. Standards bodies are a poor place for innovation. It’s not clear to me that a tacit endorsement of other people’s extensions does the Web any good.
I am also disturbed by the steamrolling I see in the WHATWG process (or lack thereof). The way changes to the document are made in response to private or unspecified feedback doesn’t seem any better than the “secret” W3C process.
February 22nd, 2008 at 12:22 am
haha! What a fucking surprise, we all demand “standards complaint browsers” then all the browsers just add their bugs into the official standards = one standards compliant browser – look we even implement all the CSS rules in a buggy and unreliable way just like the standard.
Makes me want to puke.
Have managed to get text at an angle yet? Is that in HTML 5?
monk.e.boy
February 22nd, 2008 at 1:03 am
No, but it’s in SVG.
February 22nd, 2008 at 1:08 am
I think this is unfair. All the HTML5 work I’ve been following has involved at least two vendors providing feedback, and the process has worked well and quickly and produced reasonable results.
We add credibility to HTML5 but we also get credibility from HTML5. One of the things everyone asks me when I speak in public is, “aren’t you guys heading back to the old days of implementing unilateral extensions to standards”, and I can say “no” because of the HTML5 process.
February 22nd, 2008 at 2:15 am
I could be wrong but I think Hixie’s point is that we have a bunch of nominally “in progress” specs that are actually not receiving any attention due to a lack of an editor. By contrast HTML 5 has a full time editor and a large community. This basically leaves us with three choices:
a) Keep these HTML-the-platform features in the HTML 5 spec, ensuring they get some attention but delaying the overall progress of the spec.
b) Split these features off into separate specs and hope that somebody comes along to pick up the pieces.
c) Put the specification of these features on indefinite hold, ignoring the fact that many of them already have one or more implementations in major browsers and other browser makers interested in implementing it.
I think most people would agree that b) can work if, and only if, suitable editors, who are able to make a large enough commitment of time, can be found in advance. If you can make that happen, it would be a constructive way of addressing the problem. If that doesn’t happen, option b) looks a lot like option c) and we have a choice between haste and interoperability. Advocating haste here requires a stronger justification than you’ve given so far.
February 22nd, 2008 at 2:21 am
I guess that’s the rub. Some people want things in the spec, while at least I wish for a smaller one. And the objection is brushed off with the suggestion that /I/ have to find “editors” for all these specs concerning only barely related capabilities.
I think the HTML5 system works really for editorial issues. It doesn’t seem to work very well for scope issues.
Pardon me while I sync over IrDA.
February 22nd, 2008 at 4:16 am
> And the objection is brushed off with the suggestion that /I/ have to find “editors”
I’m not sure why editors needs quotation marks here.
I object to the characterization that I “brushed off” your suggestion. I think damaging the standardisation of features that are actively being implemented by one or more browser vendors and are needed for HTML-based web-apps to compete with those based on proprietary systems is a legitimate concern. I also provided a analysis of why I believe your suggestion would cause that to happen.
With regard to finding editors, it’s clear that someone needs to take positive action to get the existing unloved specs moving, not to mention all the extra specs that would be created by breaking features out of HTML 5. If you’re advocating creating more specs, it doesn’t seem entirely unreasonable to suggest that you also advocate, to your employer for example, dedicating more manpower to spec editing roles.
February 22nd, 2008 at 10:56 am
I put the word in quotation marks because that’s the only answer to every question.
I do think my employer can do more. But I also think that, say, client side storage, is “damaging the standardization” of HTML. That’s something Mozilla implemented, but I still think it’s true.
The justification of “people are implementing it” just means things will continue to grow. We’ll see how the feature freeze works out.
February 22nd, 2008 at 12:02 pm
I desperately want to split things out of the HTML5 spec. I’ve already tried splitting out six things:
* The Window object. I totally removed all the text for this from HTML5, the WebAPI group started a new spec, we got an editor for the spec, and the spec languished. I needed the Window object to be specced out because HTML5 features left and right depend on it, but the spec just bit-rotted. I ended up being forced to remerge everything back into HTML5 just so that I could fix the issues people were raising. Both removing the features and readding them were a giant amount of work, and thus the net result was a delay of several weeks in the spec’s development.
* The new Alternative Stylesheet API (implemented in Moz and Safari). The API was moved to the CSSOM spec, which has, again, basically died, despite theoretically having an editor. This feature isn’t critical to the rest of the spec, so it’s not a huge deal that it has died, but it _does_ mean that we can’t fix the interoperability problems between Mozilla and Safari.
* setTimeout(). I moved the text for that section to a separate section of HTML5 labelled “things to be removed” or some such. Nobody has done anything that would take that text and spec it in another document.
* XMLHttpRequest. This is one of only two success stories, and it has only been a success story because we have a strong editor behind the spec. XHR started in HTML5, and I did a lot of the initial work, but eventually Anne volunteered to work on it and I moved all the XHR feedback over to him.
* The Selectors API. Not technically something that was ever in HTML5, but people kept suggesting it and wanting to implement it, so I eventually put a placeholder in place and it was only because Anne volunteered that we were able to avoid speccing it in HTML5 (or getting proprietary extensions, which is the alternative). Lachlan is now working on this spec.
* The Bindings for DOM requirements. Not technically something that is in HTML5, but it would have been had it not been for heycam volunteering to edit the spec to define this. Unfortunately the spec has been slow to develop (it’s been six weeks since it was last updated) and unless progress happens here, I’m going to again have to fix that spec myself before HTML5 can be finished.
I have tried splitting stuff out. It doesn’t work without editors to take over. I’m not specifically asking _you_ to find editors; I’ve been looking for editors myself for years, though with very minimal results — Lachlan and Anne have begun editing some specs, but they are not able to work on this full time, and they are still new to the process (though they have proved quite competent).
I don’t think _anyone_ wants HTML5 to be the size that it is. But we are not willing to compromise on the progress of the Web just to get a smaller spec. The “companion specifications” wiki page lists features that are currently dead, due to lack of editors. All of those features need an editor more desperately than anything in HTML5, because getting any progress at all is better than nothing, which is what they are currently getting, whereas at least those features in HTML5 are getting something right now.
Progress on the Web is a higher priority than spec size idealism.
We’ve managed to not add any new features for several months, despite some pretty strong demand that I add, e.g., workers. If people start implementing things without a standards consensus to achieve interoperability with other browsers, that might change — so to prevent the end of the feature freeze, you should make sure your employer works on already-specced features rather than on new ones.
Incidentally, why does the client side storage section damage the standardisation of HTML5?
February 22nd, 2008 at 12:14 pm
“Progress on the Web is a higher priority than spec size idealism.”
Fully agree, but there’s no free lunch. I want to make progress on HTML, because that’s the most important work. The other stuff is promising, but standards bodies are a slow place to innovate. It seems obvious that things like the Video API and storage have taken focus away from HTML.
“you should make sure your employer works on already-specced features rather than on new ones.”
Work on new features is not limited to the stuff standardized by the WHATWG. That group is quite busy, so it might be best to document it elsewhere. Anything Mozilla works on would be openly documented and free to implement, of course.
February 22nd, 2008 at 12:33 pm
Just out of interest, what areas of HTML do you think should be focused on that aren’t getting focused on?
February 22nd, 2008 at 12:35 pm
Personally, I think it’s far better for extensions to web technology to happen through the WHATWG process than to be pushed unilaterally by a single vendor. Even if that vendor is Mozilla and you promise to document it.
Keep in mind, the Mozilla Foundation’s stated mission is to “preserve choice and innovation on the Internet”, not just to improve Firefox. It seems to me that open standards do a much better job of furthering this mission than unilateral Mozilla extensions.
For similar reasons, we try to do as much as possible through open standards for Safari/WebKit. We want to make WebKit a great Web engine and platform, sure, but we also want the Web as an open platform to succeed. Some spec bloat seems like a small price to pay.
Fortunately, I think many key people at Mozilla agree with this sentiment, notwithstanding your remarks.
February 22nd, 2008 at 12:43 pm
> Keep in mind, the Mozilla Foundation’s stated mission
Thanks, will do.
> It seems to me that open standards do a much better job of
> furthering this mission than unilateral Mozilla extensions.
I didn’t mention unilateral extensions. I mentioned that work could happen elsewhere.
> Fortunately, I think many key people at Mozilla agree with this
> sentiment, notwithstanding your remarks.
I have asked around, you know. There are a variety of opinions. Some “key people” agree with many of my opinions on this particular issue.
February 22nd, 2008 at 1:53 pm
@rsayre
You wrote:
“I didn’t mention unilateral extensions. I mentioned that work could happen elsewhere.”
Earlier you wrote:
“Mozilla lends credibility to this specification, and Mozilla doesn’t need everything we do to be called a “standard”, at least not at first, because we have credibility. Standards bodies are a poor place for innovation.”
What did your earlier statement mean, if not unilateral extensions?
To me it sounded like you think Mozilla should trade on its credibility as self-appointed guardian of the “open web” to develop and promote proprietary extensions.
If that is not what you had in mind, then my apologies.
February 22nd, 2008 at 2:36 pm
I meant that we can work on new features without them being placed in the WHATWG HTML5 document.
That doesn’t mean we’ll ship anything without it being documented in a neutral place, but WHATWG is just one choice of many, and I would like that group to finish work on HTML elements and DOM Level 0.
As for credibility regarding openness, I don’t think we’re burdened with WKSkeletons.
February 22nd, 2008 at 3:29 pm
I read your complaint as basically saying that you don’t really care about anything beyond “pure” HTML and DOM 0. If I understand you right, you don’t care whether things beyond this move forward or languish, and you perceive the progress they make by being included in HTML5 as damaging to the things you care about. But I question how accurate that perception is. To restate an earlier question in this thread: what, specifically, do you feel is not moving forward, that would have save for these other items?
Incidentally, some of what you request is, in fact, happening. For example, Google’s Gears project is an area where people have begun speccing and implementing various different pieces of functionality, some similar to HTML5 specs, some in addition to them or orthogonal to them.
Finally, I find it fairly amusing that you accused my response to your last post of “intellectual dishonesty” when I’m not the one using such forceful language like “ridiculous scope creep” for an issue on which we seem to have opinion to go on, rather than fact that the scope creep is in fact “ridiculous”. It may be worse than the ideal, but that doesn’t mean it’s not better than the alternatives. See Ian’s long post above.
February 22nd, 2008 at 3:38 pm
Are you kidding me? The document is huuuuge. Don’t be an apologist for it. It is loony.
I want the parsing, DOM Level 0, and other ready-for-standardization work to be done, stable, and published. Simple.
February 22nd, 2008 at 3:59 pm
Indeed (re pkasting and maciej’s comments).
As far as I can tell I _am_ working on HTML and DOM Level 0 stuff. See, for example, r1236, r1234, r1224, r1222, r1218… and that’s just in the last ten days:
http://html5.org/tools/web-apps-tracker
“HTML and DOM0″ is a big area. If there’s anything in particular you think I should prioritise, please do let me know. I’m here to serve the needs of the browser vendors, including you.
BTW, if there really are many people who are able to document the innovations to which you refer, please let me know who they are so that I can get into contact with them. It would be awesome to have these people work on taking things out of HTML5.
February 22nd, 2008 at 4:04 pm
> “HTML and DOM0″ is a big area.
Fully agree.
I’m not sure what the last paragraph of your message means, other than you have the final word on the scope of HTML5.
February 22nd, 2008 at 4:10 pm
You said “That doesn’t mean we’ll ship anything without it being documented in a neutral place, but WHATWG is just one choice of many”. I’m just saying, maybe the people who would be willing to document what you ship in these many other neutral places, would be willing to document some of the things in HTML5 so that we can take them out of HTML5. If you could let me know who they are, I could start that process of shrinking HTML5 as you request.
My problem is that I _don’t_ effectively have the final word on the scope of HTML5. If I take something out and that piece thus languishes and fails to get interoperability, then I have failed the Web, and that’s not good. I can only take things out if they have somewhere to go.
From your earlier comment it looks like the main concrete area you want specified is the parser. Is that right? I can certainly step up the priority of that section if that would help.
February 22nd, 2008 at 4:28 pm
“…would be willing to document some of the things in HTML5 so that we can take them out of HTML5. If you could let me know who they are, I could start that process of shrinking HTML5 as you request.”
I’m not going to comment on other people, other than to say they know where to find you. I’m not sure they’ll help you shrink HTML5. A lot of the problem looks like things you should have put in other documents, that won’t be ready at the same time as the actual HTML part of the spec.
“I can only take things out if they have somewhere to go.”
Disagree. If they are valuable, they will get done by someone. If someone has implemented an IrDA sync JS API (is their identity a secret?), maybe they should document it in an API spec.
February 22nd, 2008 at 4:47 pm
Well there are plenty of important things that already ARE put in other documents, that are still waiting for editors. Why don’t the people you refer to go and specify _those_? I posit it is because in fact there _aren’t_ many places and people who are able to specify things, despite what you say above.
And actually, historical evidence suggests that things *don’t* get specified just because they are valuable. Otherwise, why haven’t the HTML parser rules and DOM Level 0 features been specified already? Why are you waiting for me to do them, if they’re so valuable that “they will get done by someone”? Similarly, why do all the other specs I mention not already “done”? Some of them — e.g. flexbox — are things that I know Mozilla itself has been trying to find editors for for literally years (about 8 years in the case of flexbox).
Also, many of the new features in HTML5 — e.g. canvas — are actually more reliably implemented, more “ready”, than what you call “the HTML part of the spec” (e.g. the parser, DOM level 0). I agree the IrDA part should be dropped, but then I haven’t even touched that section of the spec in years, precisely because I’m waiting for a W3C spec covering the same topic to get off the ground (in the WebAPI WG — no progress has been made on this in over a year, IIRC).
February 22nd, 2008 at 5:22 pm
> Also, many of the new features in HTML5 — e.g. canvas —
> are actually more reliably implemented
I don’t have a problem with stuff like that. Let’s not forget that canvas is/was a proprietary Apple extension. But that’s small beans. If it’s ready, let’s include it.
flexbox may not be as important you think it is. I wish it was done, because I think it is cool too.
> Why are you waiting for me to do them
because you have already done a lot of the work, and done a good job.
> haven’t even touched that section of the spec in years
Then I am not sure what harm would come from moving it into cold storage on the wiki. What about the entire TCP section?
February 22nd, 2008 at 7:48 pm
I’ve added an entry to the FAQ about how we decide to remove features, by the way:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_bad_ideas_things_from_the_spec.3F
Note that all the IrDA and bluetooth stuff (which is no more than a section header right now — the sections themselves are empty) is marked as being considered for removal.
This is about removal from the platform altogether, though, not about moving something to another spec. The process for that is simply that someone has to volunteer to work on the spec and demonstrate that they will do a good job on a realistic timetable.
(And seriously — could you _please_ get the many other places to which you refer to standardise the flexbox spec? Mozilla has been looking for someone to do that literally since before Mozilla 0.6 came out, with no success. Since you know of all these people, it would be good to see them actually do something.)
February 22nd, 2008 at 7:49 pm
Er, make that:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_the_spec.3F
February 22nd, 2008 at 8:04 pm
[Note, Ian's last two comments were not written in response to my previous one. Wordpress fail.]
That FAQ is still quite fuzzy. Removal of a feature rests on the authority of “we”, but it’s not clear who that is. I also don’t like the definition. If one browser implements it, it must stay? That sounds exactly like what I’m complaining about.
> This is about removal from the platform altogether,
> though, not about moving something to another spec
WHATWG is not the only venue available for standards work, so it does not define the whole platform. Thus it is possible to remove things from the HTML5 spec that aren’t HTML, without changing the Web as a whole.
February 22nd, 2008 at 8:14 pm
The removal of features “we” is the same as the adding of features “we”. It’s my judgement (or the editor’s judgement, if we ever add other specs where I’m not editor), based on the arguments and data provided.
It’s not “one browser adds it, it stays”. It’s all judgement calls. Obviously if a browser with 80% market share implements something and everyone uses it, it’s different than if a browser with 0.8% market share implements something and nobody uses it.
Re your earlier comment: I don’t think we should remove the entire network connection section, as there is massive demand for two-way stateful connection. But that area certainly needs further work before it’s ready. I wish the WebAPI group would do a good job of taking that spec and running with it. So far they have not. (Indeed, both attempts at defining a network connection API in the W3C have been horrible failures.)
Anyway. At this point I’m not really sure what the complaint is. I think we’ve addressed all your concerns, or explained why they aren’t realistic. The parsing section will be prioritised. I’m not sure what else we can do for you.
February 22nd, 2008 at 8:51 pm
> I think we’ve addressed all your concerns, or explained why they aren’t realistic.
OK, thanks.