Re: @headers issue resolved - allowing a td to be referenced by a header to be in the HTMl5 spec.

Chris Wilson wrote:
> James Graham wrote:
>   
>> It seems to me that several aspects of this procedure have not been followed:
>>     
>
> Speaking for myself as chair, as I was chairing the call yesterday, and although I think Mike and I are in sync on this I want to offer him the opportunity to give a different take:
>
> The Charter says: "However, if a decision is necessary for timely progress, but after due consideration of different opinions, consensus is not achieved, the Chair should put a question (allowing for remote, asynchronous participation using, for example, email and/or web-based survey techniques) and record a decision and any objections, and consider the matter resolved, at least until new information becomes available."
>
> On this topic, there has been much asynchronous participation already.  I explicitly listed this as a topic for discussion for the telecon, to invite those who might not be able to participate to offer their input or ask for the matter to handled in some other way in order to incorporate their input.  (There were, BTW, no explicit regrets for this telecon.)
It was not at all clear to me that "for discussion" meant "for making a 
spec decision" in this case when it has not in the case for other items 
listed as "for discussion" in that or previous telecons.
>   I also elicited different points of view at length during the issue discussion on the telecon.  There was, in effect, no significant dissent represented on IRC or the telecon, and I considered consensus to be achieved - thereby requiring no further question to be put to the group.
As Ben has pointed out this is not reflected in the minutes.
> The chairs are NOT bound to put each and every issue to a vote or poll, when we feel consensus (= "general agreement", not unanimity) has been achieved.
How do you decide whether consensus has been achieved? In this case 
there were, roughly speaking, two opinions on the issue (although, I 
note, the telecon had far more participants with one opinion than the 
other). I have not seen significant evidence that people who started 
with one opinion have migrated to the other nor that some common ground 
in the middle has been reached. Given the relatively small number of 
participants in the discussion compared to the size of the group, it's 
not clear to me what the majority opinion is, especially given that many 
people with opinions may be staying out of the discussion if somebody 
else is adequately representing their viewpoint.
>   And, of course, after putting such a question to the group, it would still be Mike and my responsibility to declare a decision anyway.
Indeed, my reading of the charter is that as long as you /ask/ the 
group, you can /decide/ anything you please.
> As a member of the WG, of course, you can claim that the chairs are inappropriately declaring consensus, and ask for an explicit poll, or of course escalate to the Staff Contact, the Group Lead, etc.  I would ask, of course, that you start by approaching the Chairs and ask for a discussion (email, to the group even, is of course just fine) of why a particular decision might be considered consensus even when there is dissent, and I think you'll find that Mike and I are happy to oblige.  But we do want to make progress, and I don't think any of us want to be blocked by lack of unanimity.
>   
Indeed, if unanimity is a necessary requirement there will never be any 
progress, and clearly progress is necessary otherwise we will have 
failed. I certainly don't want to block progress, nor do I intend to 
spend my time escalating issues through the W3C hierarchy. However, as I 
say below, I think circumventing the ordinary feedback loop in order to 
make quick decisions should be reserved for issues where the benefits of 
a quick decision outweigh the costs. I have no idea why this was 
considered to be such an issue.
> James, you also said:
>   
>> There is no need for a decision to be made for timely progress.
>>     
>
> That could be said of pretty much any part of the specification.  We must somehow boil this ocean anyway, so I'd consider that we need to start somewhere.  If there is a reason that setting this section aside would be a good idea (e.g. new information is expected, industry is changing, etc.) then I'd be willing to entertain that.
>   
Nevertheless, for better or worse the charter puts the burden of proof 
on those wishing for a formal decision to be made to demonstrate that 
the decision is needed for progress. Is there a documented reason that 
this particular decision was so important that it should circumvent the 
usual proposal-draft-feedback-redraft cycle? We have recently seen the 
positive impact of the usual feedback cycle with the beginings of of 
convergence on the @alt issue; I think that, in that case, making a 
premature decision based on "consensus" achieved amongst a group of ~10 
people at a telecon would have been significantly less effective in 
finding a solution that the group as a whole agreed represented progress 
over the previous state of the spec than we achieved by iterating the 
draft, thus allowing for asynchronous consideration of the merits of 
each proposal.

A good example of a case where there was a need for a decision for 
timely progress was the recent forms survey; clearly HTML 5 requires 
forms support, and the longer that the forms work is left out of the 
spec, the less opportunity there is for valuable peer review.

If you are concerned that "boiling the ocean" may take a long time, I 
would suggest the right approach is not to pick the areas most likely to 
recondense, either through dissent within the group or by implementors 
doing something different so we have to change anyway in CR. This 
question, which is both controversial and about a largely unimplemented 
(except insofar as extant AT /supports/ @headers pointing to <td>, which 
is rather different from whether it should be /conforming/) section of 
the spec seems to suffer from both of those problems.

>> It is not clear that all the different opinions were adequately considered.
>>     
>
> That is always a concern of mine, of course.
>
>   
>> For example, I can see no evidence to suggest consideration of my point that
>> marking up the example table with <th> for all the cells which the UA should
>> treat as headers, and modifying the automatic association algorithm to cope, is
>> easier for authors to understand and more likely to be done by authors not
>> specifically interested in accessibility [2]. Therefore, taking this alternative
>> approach will do more to improve overall accessibility of the web than simple to
>> spec, hard to author, solutions like @headers pointing to <td> (this is related
>> to our "Priority of Constituencies" design principle [3]).
>>     
>
> Actually, we did discuss this explicitly.  See the minutes (http://www.w3.org/2008/08/28-html-wg-minutes.html) and search for "Hierarchical headers".
>   

I saw that but I'm not sure what consideration was given to my point 
that the extra complexity of the language model implied by allowing <td> 
cells to act as headers has accessibility risks. Accessibility is, of 
course, one of our design principles. At risk of repeating myself, I'll 
outline the argument for not allowing <td> to act as a header cell again:

Case a)
All header cells are always <th>
1) A normal author who has a limited interest in accessibility wants to 
mark up a HTML table.
2) He reads in a HTML tutorial that everything that should be treated as 
a header for one of the other cells must be marked up as <th>
3) He marks up his table using this relatively simple principle and, 
without any additional effort has produced an reasonably accessible 
table (except in the rare case where the table is extremely complex and 
@headers is required)

Case b)
Headers cells are either <th> or <td>
1) A normal author who has a limited interest in accessibility wants to 
mark up a HTML table.
2) He reads in a HTML tutorial that everything that should be treated as 
a header for one of the other cells must be marked up as <th> unless it 
can also be thought of as also being data in which case it must be 
marked as <td>
3) He marks up the table using this principle but has now produced a 
table which is likely inaccessible as a UA has no chance of 
understanding which of the <td> cells were supposed to be headers and 
which were supposed to be data. Having little interest in accessibility 
the author does not know about complex mechanisms like @headers, or does 
not care enough to painstakingly add all the extra markup to his table 
that use of @headers implies.

I see mixed <th>/<td> headers as a design that works for people who's 
primary interest is in accessibility; it is largely people in that field 
who have been arguing in favour of changing the spec. However such 
people do not represent the majority of authors and are presumably not 
responsible for the majority of content that people using AT want to 
visit. Therefore we should not optimize our design according to the 
principle that everyone will act like an accessibility expert, but 
rather to the principle that accessibility experts are the exception 
rather than the norm. I think, although I would be interested in seeing 
data to prove or disprove it, that the mixed <th>/<td> design for 
headers does more harm than good here.

>> A telecon does not allow for asynchronous participation.
>>     
>
> No, but a telecon and a mailing alias, plus an escalation path, do.  If you feel this issue hasn't been given due process, then let's discuss how to ensure that you believe your feedback is being listened to, even if it is not followed directly.
>   
The charter says

"If a decision is necessary [...] the Chair should should put a question 
(allowing for remote, asynchronous participation using, for example, 
email and/or web-based survey techniques) and record a decision"

At what point was the question put by the Chair? I don't recall that 
happening but I may well have missed something; I have been unusually 
busy recently. I'm also not sure which emails were considered part of 
the "remote asynchronous participation"for this question. I know some 
emails were discussed at the telecon but it's hard to ensure that a 
specific point is considered without being present. This seems likely to 
diminish the influence of the "remote asynchronous" participants 
compared to those who are present, making the final decision of the 
chairs less likely to reflect the full spectrum of considerations 
brought forward.

In general I would suggest that one way to ensure that people (not just 
me) feel like their feedback is being listened to is not to make 
decisions at telecons that they cannot attend. It seems clear to me that 
the intent of the charter is not that any topic discussed on the mailing 
list is fair game for a synchronous decision at a telecon or F2F, but 
rather that decisions are only made in asynchronous media (although I 
accept that you disagree), and I would expect that making decisions at 
telecons will often cause people to escalate the issue afterwards. 
Therefore this seems like an inefficient way of deciding things, 
particularly things that require detailed consideration of a range of 
technical arguments. Also, since  synchronous meetings necessarily 
require expediency, it seems less likely that good technical decisions 
will consistently be made this way. It also seems like the decisions 
will have obvious biases toward the opinions of people able to attend as 
part of their work and against people who have unrelated employment or 
classes to attend. Therefore, regardless of the interpretation of the 
text of the charter, I think it would be better to avoid this kind of 
decision making process.

Received on Sunday, 31 August 2008 11:42:03 UTC