W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: Deliverable for Action 72 @headers

From: James Graham <jg307@cam.ac.uk>
Date: Thu, 28 Aug 2008 17:59:00 +0100
Message-ID: <48B6D954.9020101@cam.ac.uk>
CC: HTML WG <public-html@w3.org>

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

James Graham wrote:
> 
> 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%3
C% 
> 
> 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
C% 
> 
> 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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:57 UTC