Re: Deliverable for Action 72 @headers

On 22 Aug 2008, at 7:49 AM, James Graham wrote:
>  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.

This is thoroughly logical, but it's based on an over-simplified idea  
of table semantics.

Here's a rationale for preserving the HTML4 design, with @headers  
pointable at <td>:

The crux of the matter is that the (highest and best) meaning of  
'header' in <th> and
in @headers is subtly different.

1) in <th> 'header' contains metadata pertinent to a collection of  
other cells
2) in @headers, the IDs in the attribute lead you to context  
characteristics
   critical for orientation

The difference is what the database people call key fields (I think).
These are data fields, not metadata, but they are critical as indexes  
to the records
in which they appear, and hence to orientation for their peer cells  
in the same record.

It is like:
  - the <th> contents tell you what question is being answered.
      This is a qualitative distinction
  - the key fields tell you which answer you are getting.
      This is pure iteration, with no qualitative difference

Key field values are things that in creating the table, you are  
correct in treating
as data, not headers, while in threading the cells for orientation,  
you need to pick
them up so the eyes-free user can recover from being lost.

In doing HTML4, we were operating in a world where the main use by  
actual
authors of <th> was to control styling of cells.  Not mathematical  
subtleties
of Codd and Date (relational database theory).  In the spirit of "pave
the cowpaths" I think we should preserve 1) above as the concept for  
the use of <th>
because this is the rule that makes most sense in terms of what cells  
one
wants to style with the same stylistic distinction from the run-of- 
the-data
cells.

The other aspect of this is a touch of "be strict in what you emit,  
but lax
in what you accept."  There is not fundamental semantic dividing  
metadata from
data.  It's all a matter of perception.  So let the author cast to  
<th> those
things they want to emphasize for orientation of the visual user and let
@headers pick up the slack for the non-visual users.  These are trade- 
offs
made under different performance factors.  Trying to force them into  
one and
the same binary quantization is to destroy information, not encode it  
better.

Reasoning from @headers as a way to discover wrongly-typed cells is  
virtuous.
But not insisting that the author change the element type just  
because @headers
points there, or drop the cell from the list of @headers targets.

And yes, for most user's screen reader setting, @headers provides no  
clutter
because it isn't used unless the user interactively asks for more  
context.

Al

> 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 15:13:31 UTC