I don’t know because the WHATWG mailing list archive page vexes me.

For example, was there any discussion at the WHATWG involving any of the splits from the W3C copy of the text?

You say the HTML5 specification is not over-specified, but Matt’s example is a perfect demonstration of an overspecification.

We don’t need to tell user agents that if they have image recognition software, it’s ok they can use it. Especially since we took pains to demonstrate how inappropriate this type of statement is, when discussing it as a workaround for missing alt text.

The spec is full of crap like this. A specification’s job is provide a precise description of that which it controls. No more, no less. Yet there’s crap in the spec where Ian is telling the web page author what to actually put in as _content_, not as markup. Unbelievable.

Unless we want to make something an error or warning, we have no right to tell people what to do or not to do, especially when it comes to what they provide as content material.

As for his rationales, look at some of them (this will trigger comment hold):

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8118#c11
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552#c15
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8818#c1

And I could go on. Now, what useful info is in these rationales? “Um, these are good things” is about what they boil down to,except for the last one, which is a snarky aside about another bug.

What use continue these discussions, though? We’ll never agree. You think Ian walks on water, and I think his actions, and the W3C’s tactic permissions to continue such actions, are going to ultimately sink HTML5 as a standard for all web communities.

http://lists.w3.org/Archives/Public/public-html/2010Jun/0525.html

I strongly disagree that HTML5 is overspecified. It is as detailed as it needs to be, which is to say, specified to the last detail. Other specs are far vaguer, and interoperability suffers greatly as a result. For instance, take a look at this www-style thread:

http://lists.w3.org/Archives/Public/www-style/2010Jun/0349.html

box-shadow in CSS 3 is defined at http://dev.w3.org/csswg/css3-background/#the-box-shadow. Shadow-drawing in HTML5 is also defined, for canvas, at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#when-shadows-are-drawn. Compare the precision of the descriptions. Now look at these two images comparing WebKit’s and Firefox’s box-shadows:

http://www.bradclicks.com/cssplay/blur_100px_webkit.png
http://www.bradclicks.com/cssplay/blur_100px_firefox.png

You can verify yourself by going to the data URL

data:text/html,!doctype html
div style=”width:200px;height:200px;margin:50px 500px 50px -208px;-moz-box-shadow:250px 0 100px black;-webkit-box-shadow: 250px 0 100px black;”/div

with angle brackets inserted at the right places (to avoid the angle-bracket-eater I suspect is present). By contrast, take a look at how they render canvas shadows at, say, http://www.robodesign.ro/coding/canvas-primer/20081208/example-shadows.html. Pixel-perfect identical. That is not “overspecified”, that is what standards should be — the same markup generates the same results.

Some W3C people absolutely have contributed to the spec in the W3C. However, those people could just as well have contributed in the WHATWG. The actual changes that the HTMLWG made that Ian didn’t support (and which therefore would have not happened at the WHATWG) are not significant at all, certainly not compared to the size of the spec.

Matt, that text is an excellent example of something that makes no difference in practice. At worst it was mildly misleading, which isn’t a big deal since practically no one would read it (certainly not typical authors). It imposed no implementation or authoring requirements, and its removal is unlikely to have any detectable effect on anything. It is not an “obvious accessibility flaw”, because even if it was wrong, there’s no reason to think that it would actually hurt accessibility anywhere.

This is the kind of thing that WHATWG supporters get fed up by — significant amounts of HTMLWG time getting taken up by something that makes no difference in the end anyway. It’s why more than one implementer uses the WHATWG list instead: much higher signal-to-noise ratio.