Re: Order of table sections

On Thu, 2002-09-26 at 07:25, David Faure wrote:
> > pettit1 : HTMLTableRowElement.rowIndex
> >
> > Brad: within the table definition, order is different from how they
> > appear.
> >
> > -> OPEN ISSUE for WG.
> 
> The tests HTMLTableRowElement01 and 04 rely on the order of the table
> sections in the DOM tree. They look for a certain row using
> document.getElementsByTagName("tr").item(4). This assumes the useragent
> doesn't sort the table sections during parsing.

I finally took the time to examine HTMLTableRowElement01 and
HTMLTableRowElement04:
DOM nodes are always in document order. While DOM Level 1 and 2 Core are
only implicit about node order, DOM Level 3 Core is explicit and defines
the notion of document order. So yes, the test is correct in assuming
that the table sections are not reordered during parsing.

> Konqueror currently sorts the table sections (to the visual order,
> thead/tbodies/tfoot), but the table rendering guys say this isn't
> necessary anymore, and should probably be fixed so that the DOM tree can
> be "mapped back to the input file".
> 
> But is this really considered a bug, or are user-agents free to order or
> not order the table sections in the DOM tree?

It is a bug in Konqueror.

> What does Mozilla do? What does IE do? (I suppose at least one of them
> reorders the sections too, since the issue is mentionned here?)

They don't reorder the sections. The issue was open against rowIndex,
not the ordering of the nodes. rowIndex was defined as being in document
order previously and it was a mistake. I fixed the documentation of
HTMLTableRowElement01 to indicate that rowIndex is in logical, and not
document order.

> If the answer is that useragents are free to do so, then those tests
> should be changed, e.g. with <tr id="therowtotest"> and
> testNode=document.getElementById("therowtotest"). This would allow testing
> rowIndex and sectionRowIndex without relying on the order of the sections.
> (Hmm, at least sectionRowIndex. rowIndex has sort of the same problem:
> is it the index in the dom tree, or the index on screen, i.e. with TFOOT
> at the bottom?)
> 
> If sections shouldn't be reordered, a specific test for that would be
> easier to debug than noticing it as a side effect of the current tests'
> failure - so I suggest doing the getElementById change anyway.

Given that HTMLTableRowElement01 is testing the rowIndex, I don't think
it is necessary to change it. Its role is to test the ordering anyway.

Regarding HTMLTableRowElement04: yes, it could be change to avoid the
ordering given that it is testing the sectionRowIndex attribute.
However, if getElementById fails, we're back at the beginning, ie the
tests should not rely on other methods to accomplish its goal.

Anyway, it has been suggested to accept the changes, so here is a
proposed change for HTMLTableRowElement04:
[...]
<var name="testNode" type="Node"/>
<var name="vsectionrowindex" type="int"/>
<var name="doc" type="Node"/>
<load var="doc" href="tablerow" willBeModified="false"/>
<getElementById interface="Document" obj="doc" var="testNode"
elementId="&quot;tbody_2nd&quot;"/>
<sectionRowIndex interface="HTMLTableRowElement" obj="testNode"
var="vsectionrowindex"/>
<assertEquals actual="vsectionrowindex" expected="1"
id="sectionRowIndexLink" ignoreCase="false"/>
[...]

and in tablerow:
<TR id='tbody_2nd'>

comments? objections?


Philippe

Received on Monday, 9 December 2002 15:33:19 UTC