From kfm-devel Mon Dec 09 21:39:03 2002 From: David Faure Date: Mon, 09 Dec 2002 21:39:03 +0000 To: kfm-devel Subject: Fwd: Re: Order of table sections X-MARC-Message: https://marc.info/?l=kfm-devel&m=103947000511415 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We shouldn't reorder the table sections in the DOM tree (only at rendering time). This is the last main cause of failure for the DOM testsuite in Konqueror. - ---------- Forwarded Message ---------- Subject: Re: Order of table sections Date: Monday 09 December 2002 21:33 From: Philippe Le Hegaret To: David Faure Cc: www-dom-ts@w3.org 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 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: [...] [...] and in tablerow: comments? objections? Philippe - ------------------------------------------------------- - -- David FAURE, david@mandrakesoft.com, faure@kde.org http://people.mandrakesoft.com/~david/ Contributing to: http://www.konqueror.org/, http://www.koffice.org/ Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE99Q1372KcVAmwbhARAoJRAKCy53z7Q2ls4qrA0mblck3tPMrAYACgntxZ kU9vr9p1c1yIgz4ndiJeIGo= =4mPy -----END PGP SIGNATURE-----