Re: Deliverable for Action 72 @headers

For the benefit of tracker, this thread is related to ISSUE-20

James Graham wrote:
> Gez Lemon wrote:
>> 2008/8/21 James Graham <>:
>>> Laura Carlson wrote:
>>>> The headers/id markup is functional and works today. Results of some
>>>> recent testing:
>>> It seems to me that this testcase is wrong in that the contents of 
>>> columns 1
>>> and 8, and of row 2, should be marked as headers not as data cells. This
>>> change would appear to be needed for the table to be consistent with the
>>> current spec, which says that <th> represents a header cell; the 
>>> expected
>>> results of your test clearly depend on these cells being treated as 
>>> header
>>> cells by UAs.
>> According to the HTML5 editor, hierarchical headers aren't allowed in
>> the current spec [1].
> I'm not sure what hierarchal headers has to do with my suggestion that 
> the elements that you intend to be processed as headers by UAs be marked 
> as headers in the source. Indeed, rereading that bug the first thing 
> suggested was the same as I said i.e. that you should mark your headers 
> as such in the source [1]
>>  Allowing a header attribute to reference a td a well
>> as a th would be the simplest solution, and works well with current
>> implementations, but I'm not yet clear on why that has been deemed
>> unreasonable, as no explanation has been provided.
> So as far as I can tell the problem you actually have with this table, 
> when correctly marked up, is that the headers are not associated with 
> each other in the way you would like (what you call "hierarchal 
> headers"). Allowing the headers attribute to point to data cells seems 
> like the wrong way to go about solving this problem (HTML4 
> notwithstanding). Requiring the use of @headers to mark up such a simple 
> table is surely overkill. It also seems much more logical to insist that 
> cells users wish the UA to treat as headers be marked as such in the 
> source. This is, after all, the point of using a mark up language; to 
> communicate meaning to UAs so that they can act on it.
> For what it's worth the Smart Headers algorithm that Ben and Simon and I 
> developed (which is not quite the same as the current spec) can provide 
> the associations that I think you want with only the correct use of <th> 
> and a single extra scope="col" attribute on the top left cell [2]
>>> We would need to re-examine the reason for the current behavior
>>> being chosen to see if this case was an oversight or if there is a good
>>> reason the current spec.
>> I completely agree you need to re-examine the reason for the current
>> behaviour, as it clearly hasn't been thought out properly
> My recollection is that the reason for the difference between the smart 
> headers algorithm and the current spec is that Hixie was concerned that 
> repeating too many headers on each cell would lead to a bad user 
> experience. If this is indeed the reason, I think the spec should be 
> adjusted to allow "hierarchal headers" and UAs should be encouraged to 
> adjust the verbosity to suit their users' needs.  However I may be wrong 
> about the rationale for the current design.
> Also, I intuitively think that the spec algorithm should be adjusted to 
> /work/ if @headers points to <td> (needed for backward compatibility 
> with existing UAs). However I have not yet seen a convincing reason to 
> make this conforming and there may even be reasons to make it not work.
>  - you don't
>> even appear to have reached consensus amongst yourselves.
> As a final aside, I have no idea who the antecedent of "yourselves" in 
> this sentence is. You also referred to "your editor" several times; I 
> guess you mean Hixie but I have no idea how he is more "my" editor than 
> anyone else's.
> This use of language suggests to me that you are still seeing HTML 5 
> development as a pitched battle between "us and them" where (from your 
> point of view) "us" is the accessibility freedom fighters and "them" is 
> the evil HTML 5 overlord and his band of minions. I don't think this is 
> a helpful viewpoint, and I was hopeful we had got past it. It's much 
> better to work from the point of view that everyone is trying to make 
> the spec better but there are disagreements, even amongst reasonable 
> people, about what that entails. In the specific case of table headers, 
> I have reservations about the current spec, but I recognize that it is 
> in a state where the best way to produce improvements is to see how it 
> fares in actual implementations and under user testing. People 
> implementing the spec and going "look this user can't understand this 
> type of table because they need more information" is a really strong 
> argument, and really likely to produce a change. In the meantime by not 
> focusing on this issue I hope to free up enough bandwidth for everyone 
> that progress can be made in other areas.
> [1]
> [2] 
> th%3E%0D%0A%09%3Cth%3E12%2F19%2F2005%3C%2Fth%3E%0D%0A%0D%0A%09%3Cth%3E12%2F26%2F2005%3C%2Fth%3E%0D%0A%3C%2Ftr%3E%0D%0A%3C%2Fthead%3E%0D%0A%3Ctbody%3E%0D%0A%3Ctr%3E%0D%0A%09%3Cth+rowspan%3D%223%22%3EPartner+Portal%3C%2Fth%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3EService%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3EApproved%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3E100%3C%2Ftd%3E%0D%0A%0D%0A%09%3Ctd+rowspan%3D%223%22%3E73%2C271.46%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3E50%25%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3E100%3C%2Ftd%3E%0D%0A%09%3Cth%3EBudgeted%3C%2Fth%3E%0D%0A%09%3Ctd%3E10%2C000.00%3C%2Ftd%3E%0D%0A%09%3Ctd%3E10%2C000.00%3C%2Ftd%3E%0D%0A%0D%0A%09%3Ctd%3E10%2C000.00%3C%2Ftd%3E%0D%0A%3C%2Ftr%3E%0D%0A%3Ctr%3E%0D%0A%09%3Cth%3EActual%3C%2Fth%3E%0D%0A%09%3Ctd%3E11%2C123.45%3C%2Ftd%3E%0D%0A%09%3Ctd%3E11%2C012.34%3C%2Ftd%3E%0D%0A%09%3Ctd%3E10%2C987.64%3C%2Ftd%3E%0D%0A%0D%0A%3C%2Ftr%3E%0D%0A%3Ctr%3E%0D%0A%09%3Cth%3EForecasted%3C%2Fth%3E%0D%0A%09%3Ctd%3E12%2C000.00%3
> 2Ftd%3E%0D%0A%09%3Ctd%3E12%2C000.00%3C%2Ftd%3E%0D%0A%09%3Ctd%3E12%2C000.00%3C%2Ftd%3E%0D%0A%3C%2Ftr%3E%0D%0A%3Ctr%3E%0D%0A%09%3Cth+rowspan%3D%223%22%3EPartner+Portal+2%3C%2Fth%3E%0D%0A%0D%0A%09%3Ctd+rowspan%3D%223%22%3EService%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3EApproved%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3E100%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3E97%2C611.80%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3E50%25%3C%2Ftd%3E%0D%0A%09%3Ctd+rowspan%3D%223%22%3E100%3C%2Ftd%3E%0D%0A%0D%0A%09%3Cth%3EBudgeted%3C%2Fth%3E%0D%0A%09%3Ctd%3E30%2C000.00%3C%2Ftd%3E%0D%0A%09%3Ctd%3E30%2C000.00%3C%2Ftd%3E%0D%0A%09%3Ctd%3E30%2C000.00%3C%2Ftd%3E%0D%0A%3C%2Ftr%3E%0D%0A%3Ctr%3E%0D%0A%09%3Cth%3EActual%3C%2Fth%3E%0D%0A%0D%0A%09%3Ctd%3E31%2C121.21%3C%2Ftd%3E%0D%0A%09%3Ctd%3E32%2C321.11%3C%2Ftd%3E%0D%0A%09%3Ctd%3E29%2C123.98%3C%2Ftd%3E%0D%0A%3C%2Ftr%3E%0D%0A%3Ctr%3E%0D%0A%09%3Cth%3EForecasted%3C%2Fth%3E%0D%0A%09%3Ctd%3E33%2C000.00%3C%2Ftd%3E%0D%0A%0D%0A%09%3Ctd%3E33%2C000.00%3
> 2Ftd%3E%0D%0A%09%3Ctd%3E33%2C000.00%3C%2Ftd%3E%0D%0A%3C%2Ftr%3E%0D%0A%3C%2Ftbody%3E%0D%0A%3C%2Ftable%3E%0D%0A&algorithm=smartheaders 

"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Thursday, 28 August 2008 16:59:37 UTC