Re: Deliverable for Action 72 @headers

Gez Lemon wrote:
> 2008/8/21 James Graham <jg307@cam.ac.uk>:
>> Laura Carlson wrote:
>>> The headers/id markup is functional and works today. Results of some
>>> recent testing:
>>> http://esw.w3.org/topic/HTML/TableHeadersTestingBug5822
>> 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] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822#c5
[2] 
http://james.html5.org/cgi-bin/tables/table_inspector.py?uri=&input_type=type_source&source=%3Ctable+summary%3D%22Child+investment+portfolios+with+budgeted%2C+actual+and+forecast+running+costs+for+dates%22%3E%0D%0A%3Cthead%3E%0D%0A%0D%0A%3Ctr%3E%0D%0A%09%3Cth+rowspan%3D%222%22+scope%3D%22col%22%3EChild+Investment%3C%2Fth%3E%0D%0A%09%3Cth+rowspan%3D%222%22%3EType%3C%2Fth%3E%0D%0A%09%3Cth+rowspan%3D%222%22%3EStatus%3C%2Fth%3E%0D%0A%09%3Cth+rowspan%3D%222%22%3EAllocation%3C%2Fth%3E%0D%0A%09%3Cth+rowspan%3D%222%22%3E%3Cabbr+title%3D%22Total+cost+of+ownership%22%3ETCO%3C%2Fabbr%3E%3C%2Fth%3E%0D%0A%09%3Cth+rowspan%3D%222%22%3E%3Cabbr+title%3D%22Return+on+investment%22%3EROI%3C%2Fabbr%3E%3C%2Fth%3E%0D%0A%0D%0A%09%3Cth+rowspan%3D%222%22%3E%3Cabbr+title%3D%22Net+present+value%22%3ENPV%3C%2Fabbr%3E%3C%2Fth%3E%0D%0A%09%3Cth+rowspan%3D%222%22%3EProperty%3C%2Fth%3E%0D%0A%09%3Cth+colspan%3D%226%22%3ERunning+Cost%3C%2Fth%3E%0D%0A%3C%2Ftr%3E%0D%0A%3Ctr%3E%0D%0A%09%3Cth%3E12%2F12%2F2005%3C%2F
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%3C%
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%3C%
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 Friday, 22 August 2008 11:50:28 UTC