Re: headers= and rowgroup

On 2007-09-14 08:45:30 +0200 "Thomas Broyer" <t.broyer@gmail.com> wrote:

> 2007/9/14, Leif Halvard Silli:
>> we can apply logic to see
>> if it would be in accordance with anything in spec to say that
>> @HEADERS is agumentative. E.g. if we have these two rows,
>> 
>> <TR><TH ID=myhead>1<TD>2</TR>
>> <TR><TH SCOPE=row>3<TD HEADERS=myhead>4</TR>
>> 
>> then, if we were to expect that the header information which cell
>> «3» propagates was added to the information from @HEADERS
>> in cell «4» (so that cell «4» would have both cell «3» and cell «1»
>> as headers), then we would contradict how @HEADERS is
>> described other places, e.g. in section 11.4.3 («the basic algorithm»),
>> where it is clearly said that
>> 
>>          If a header cell has the headers attribute set, then the headers
>>          referenced by this attribute are inserted into the list and the
>>          **search stops for the current direction**.
> 
> Except that this algorithm applies "in the absence of header
> information from either the scope or headers attribute", i.e. as soon
> as a data cell is in the @scope of header cell, the given algorithm
> *doesn't* apply.

Except that except is the rule: The algorithm also doesn't apply when a cell has the @headers attribute set - because then, the @HEADERS attribute is considered the authorithy - it overrules the basic algorithm. This same rule, namely that the @headers attribute is considered the authority, is also baked into the basic algorithm. The basic algorithm takes the single cell as starting point. And that is also what is happening when the single cell has @HEADERS - it starts - but also end in that point. (And that is why I said that the basic algorithm is always happening.)

The @SCOPE, on the other side, starts with a header cell. And it might well be that if the UA ask the cell with @SCOPE about who its datacells are, then it will also tell that even the cell with @HEADERS is one of its data cells (because, there hasn't been designed any exceptions into @SCOPE). But when you go an ask each cell within the scope of that @SCOPE, then, for that cell which has @HEADERS set, it seems logical that is business a usual: just look at the @headers attribute and nothing more.

There is no patterns within all that is said about header cells, which allows a single cell to catch its header cells from anywhere else than the @headers - when the single cell has that attribute.

It could of course be that @SCOPE overruled any other mechanism ... that it made @HEADERS not work. But sofare, noone has proposed such a reading.

[...]

>> But if I get you right, then for e.g. the last example, you are saying
>> that the R-cell, which has the @SCOPE=rowgroup, is header for all
>> the other cells - as below?
>> 
>>                     R s
>>                     s s
> 
> Yes
>
>> Are you then reading the wording «the rest of» in the specification for
>> 'rowgroup' as «all the others»? (I.e. «... the rest of the row group that
>> contains it» = 'all the other cells in the row group').
> 
> Yes.
> 
> If it had been "R s / _ _" it wouldn't have been any different from scope=row.
> If it had been "R _ / s _", it wouldn't have been any different from 
> scope=col.
> And I can't imagine how scope=rowgroup could lead to e.g. "R _ / _ s".

"R s / _ _", which has been my reading, might not be different from scope=row, as long as you do not want to have two levels of @SCOPE. But as soon as you try to have two levels, then it becomes different, because it is not possible with two levels of @SCOPE=row - simultaneously, the least one will overrule the other.

There also isn't any difference between @SCOPE=col and SCOPE=colgroup, except for the two levels that it makes possible. Or would you say that "C _ / _ _", where C was a cell with SCOPE=colgroup would also result in "C s / s s"?

> But the point is: we could discuss what HTML4 says (or does not say)
> ad nauseam, that's not what will make HTML5 go forward. What's needed
> is to define what people want and need, and compare that with what
> current UAs do to try to not break backwards compatibility (and search
> for existing documents making use of both headers and scope, to try to
> continue "supporting existing content").

I look upon HTML4 as a help for defining what people want and need. 
-- 
leif halvard silli

Received on Saturday, 15 September 2007 02:28:20 UTC