Re: Answering the question... (timing of table headers issue)

Hi Dan,

I'm glad to see you bring these issues to the list They are pressing  
issues and I think even these issues of conveying a  'bad image' can  
have detrimental effects down the road on the adoption of our  
deliverables. We want to make sure that HTMl5 is taken seriously by  
both authors and developers.

On Aug 23, 2007, at 3:52 PM, Dan Connolly wrote:

> On Thu, 2007-08-23 at 12:14 -0700, John Foliot wrote:
>> Dan Connolly wrote:
>>>
>>> I sympathize with your frustration, but I ask that you remain  
>>> patient.
>>
>> Dan,
>>
>> Thank you for your prompt response.  While patience is indeed a  
>> virtue, my
>> (our?) patience is being sorely tested, as while the official word  
>> is that
>> we're nowhere near deciding anything, current editors and  
>> contributors are
>> going ahead and making "pronouncements" that lead many to believe  
>> that much
>> of HTML5 is 'fait accomplis'.  As someone once said to me, you  
>> can't suck
>> and blow at the same time.
>>
>> To whit:
>> * Is Anne ("Standards Suck") van Kesteren out of place to be  
>> announcing that
>> HTML5 has dropped <input usemap>?
>> [http://annevankesteren.nl/2007/08/input-usemap]
>
> Evidently; i.e. perception is reality, and I'm getting complaints
> about this weblog entry.
>
> Anne, you and I have certainly talked about the connotations and
> denotations of "dropped".
>
> Something like "the editors are evidently inclined to drop
> <input usemap>; it will be interesting to see whether any new
> arguments come up" perhaps wouldn't have generated as many complaints.

However even that language conflicts with your earlier post on the  
state off the WG where you said:
> But keep in mind that we have, so far, made *no* design
> decisions. We haven't decided that HTML 5 will have a p element.
> Before we address subtle issues like the table headers issue,

Any edits to the draft so far are just that edits to a draft. Really  
they are proposals of the editor to the WG. These are hardly  
different than the proposals on the wiki, except those are proposals  
from one or more  WG members who are not editors.

> How about updating your weblog entry with something like that, Anne?
>
>> * Is Lachlan Hunt definitive when stating, "HTML5 now defines the  
>> usemap
>> attribute as a Hashed ID Reference, not a URI, and can only  
>> reference maps
>> within the same document."
>> [https://bugzilla.mozilla.org/show_bug.cgi?id=189643], as well as  
>> "HTML5
>> currently will not be including the usemap attribute on input  
>> elements."
>> [https://bugzilla.mozilla.org/show_bug.cgi?id=392994]
>
> He seems to be accurately quoting from current editor's drafts.
> That seems like a useful way to get feedback from the
> mozilla development community, no?

It does not at all seem to be a quote from an editors draft to me.  
Lachlan neglects to mention that it's a draft. He states it an way  
that makes it sound authoritative on the verge of final  
recommendation status. He links to document fragments in the draft  
that skip right past the disclaimers about the document status. Now  
we can pretend that developers read every word of a specification  
before writing a single line of code, but I think we should instead  
admit that's avery rare developer.  You may think that developers  
know better, but since these are diverse open source communities,  
they have the same vulnerability to be swayed by such rhetoric as  
most any community. Bugs have even been closed as wontfix due largely  
to confusion created by pronouncements like Lachlan's. (I don't mean  
to single out Lachlan here; he is not the only one. This is just one  
example.)

> It seems to me that in the bugzilla context, it's reasonably well
> known that HTML 5 is a moving target. The Mozilla foundation
> is reasonably well represented in this working group; I'm interested
> to get confirmation as to whether this is business-as-usual
> or something counter to norms there.

I would say it is very counter to norms. Sure you'll see it quite  
often relating to HTML5 and WebForms 2.0, but I cannot recall any  
other cases where you see these types of pronouncements. CSS 2.1  
might often get quoted as a if its a final recommendation, but at  
least that has first reached a candidate recommendation status on a  
few occasions .

Also the mozilla foundation may be well represented here, but Mozilla  
is a large project and largely a de-centered community of developers.  
Unless the Mozilla members of our group are going to spend an  
inordinate amount of time trying to counter these claims, they will  
have detrimental effects in the Mozilla community. It's best to just  
not make such claims in the first place.

>> * Is From Maciej Stachowiak correct when he states, "This feature is
>> underspecified in HTML4, and not implemented by IE. It is also  
>> likely to be
>> dropped in HTML5 and may be removed from Mozilla and Opera as a  
>> result."
>> [http://bugs.webkit.org/show_bug.cgi?id=15032]
>
> I accept "underspecified" and "likely to be dropped" as his opinion,
> and as far as I know he's correct that it's not implemented by IE.

However, I think the concern is not over the "underspecified in HTML  
4" as the "likely to be dropped in HTML5". By what basis could anyone  
make such an estimation when as you yourself said: we should all  
"keep in mind that we have, so far, made *no* design decisions. We  
haven't decided that HTML 5 will have a p element." Making such a  
claim at this stage  seems on par with claiming HTML5 will address  
the issues surrounding area 51; though to those outside the WG, it  
doesn't sound so absurd. It sounds more persuasive than that.

Yet we have a forms taskforce that has barely just convened. We have  
made not a single design decision. Rather, a few members of the WG,  
including one editor, have proposed dropping use of image maps by  
input elements, based on either 1) a misunderstanding of the HTML  
4.01 recommendation (not hard to do because it is ambiguous on the  
issue) or 2) another premature consideration of the WebForms 2.0  
draft regarding the <input usemap> feature; or 3) another fair  
reading of HTML 4.01, but a reading that should still be open to WG  
discussion. Either way, it is clearly an issue that will (and needs  
to) get a much more thorough consideration by the WG.

>> These types of pronouncements *do* tend to send mixed messages,  
>> don't you
>> agree?
>
> Yes.
>
> That's an accurate reflection of the constituencies in the working
> group: there are a variety of opinions. We could have chartered
> the working group to keep its discussions member-confidential until
> we reached consensus, but I don't think that would be better.

There's a bid difference between not making the WG discussions  
confidential and going further to have WG members making  
pronouncements in public that misrepresent where the WG stands right  
now. If all of those pronouncements ended with: "But keep in mind  
that we have, so far, made *no* design decisions. We haven't decided  
that HTML 5 will have a p element.", then I don't think anyone would  
be raising these concerns.

>>   If these authors/HTML 5 contributors can be categorically making
>> these kinds of statements, then is it not unreasonable to expect  
>> something
>> like, "Based upon current feedback, the headers attribute will be  
>> preserved
>> in HTML5" (attribute to whom you wish)?
>
> What I get from Al Gilman's 6 June message is that something that
> provides the functionality of the headers attribute is needed.
> He doesn't argue that the headers attribute is the only acceptable
> solution.
> http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html
>
> I have seen a fair amount of test data fly by and I have
> seen a lot of discussion of use cases. I have not digested it all yet.

I agree with your assessment of Al Gilman's message. And I think  
there have been a lot of fruitful discussion surrounding table data/ 
header cell associations that could lead to some excellent solutions.  
However, the issue being raised is not specifically about header  
cells (as i understand it). It''s a broader issue regarding the  
disjoint between deliberations and reviews of the WG and the editing  
that's happening to the draft. Not long ago you said you've seen WGs  
work well with either 1) the editor making edits introducing proposed  
changes to the draft for subsequent WG discussion or 2) the  
discussion taking place first followed by edits to the draft  
reflecting the WG's views . However, in this WG there's a third  
approach we're seeing that  is hard to imagine working well. We have  
edits to the draft that neither reflect discussions occurring in the  
WG, nor do these edits serve as a catalyst to initiate discussions  
that appear to have any influence over future edits. That to me  
suggests a gradual widening of the separation between the views  
expressed in the WG and the views penned into the draft. That's a  
problem for the WG. There should be some gradual process approaching  
editor/WG unity instead.

Take care,
Rob

Received on Thursday, 23 August 2007 22:31:58 UTC