This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As per the spec https://html.spec.whatwg.org/multipage/tables.html#dom-table-rows "The rows attribute must return an HTMLCollection rooted at the table node, whose filter matches only tr elements that are either children of the table element, or children of thead, tbody, or tfoot elements that are themselves children of the table element. The elements in the collection must be ordered such that those elements whose parent is a thead are included first, in tree order, followed by those elements whose parent is either a table or tbody element, again in tree order, followed finally by those elements whose parent is a tfoot element, still in tree order." When there is multiple thead/tfoot (https://jsfiddle.net/ckcjczk2/1/) elements, even though all browser vendors render the table same as per the CSS spec (http://www.w3.org/TR/CSS2/tables.html#table-display), but rows attribute returns different row collection. For eg: 1) Firefox -> rows attribute returns first thead rows follwed by tbody rows then first tfoot rows i.e rows in other thead/tfoot rows are ignored (not returned even though they are rendered). 2) Blink -> rows attribute returns thead rows collection followed by tbody rows then tfoot rows collection. 3) IE -> rows attribute returns first thead rows followed by tbody rows then rows in remaining thead/tfoot which are rendered as tbody rows finally the first tfoot rows. So IE returns the rows collection as it is rendered, this seems right as this avoids the confusion between rows returned and rows rendered.
I also think this should change, if there is any reordering then it should be the same as for rendering. If IE's reordering matches exactly that of the rendering then doing that makes sense to me. (In reply to Prashant Hiremath from comment #0) > 3) IE -> > rows attribute returns first thead rows followed by tbody rows then > rows in remaining thead/tfoot which are rendered as tbody rows finally > the first tfoot rows. Just to clarify, it's just the first row in a thead and the first in a tfoot that is moved, right? From this description it sounds like all of the rows in tbody come before any "extra" rows in thead/tfoot, which I don't think is the case.
(In reply to Philip Jägenstedt from comment #1) > > Just to clarify, it's just the first row in a thead and the first in a tfoot > that is moved, right? From this description it sounds like all of the rows > in tbody come before any "extra" rows in thead/tfoot, which I don't think is > the case. Hi, Philip Sorry my mistake, didn't word it properly. In case of IE rows attribute returns first thead rows followed by tbody rows then first tfoot rows. In case of multiple thead/tfoot(other than first thead/tfoot) which will be rendered as tbody rows, are returned in rows collection the order in which they are present in the table. Wrote one small application (https://jsfiddle.net/d2ghq0n2/2/ ), which clearly shows the rendering/ rows attribute in case of multiple thead/tfoot elements.
Thanks you Prashant, so it looks like IE indeed matches rendering, and only changes the order of the first <tr> in <thead> and the first <tr> in <tfoot>, all other <tr>s being in tree order. Jacob, can you confirm that Edge has the exact same order for rendering and the rows API, perhaps it's even a shared code path? I take it you'd have no objection to standardizing this?
Yes, looks like Edge has the same behavior as IE11. It does seem like the most reasonable behavior. I think the only concern for us would be whether both Firefox and Chrome intend to match our behavior (we want interop). The other concern would be whether sites depend on Chrome/Firefox behavior. I CC'd Rossen who is the best guy to look at this and comment from our side. He's OOF at the moment though.
Olli, do you think the suggested change would make sense for Gecko?
What is meant with rendering order here? That sounds rather wrong in light of potential new CSS features that could influence that. We want an order that can be determined without CSS.
I don't mean something that depends on style or layout, just something that matches the prose for table-header-group and table-footer-group in http://www.w3.org/TR/CSS2/tables.html#table-display The other alternative that seems OK is to just have no reordering at all, but it doesn't look like there's any implementation that currently does this, which makes it slightly more risky.
(In reply to Philip Jägenstedt from comment #3) > Thanks you Prashant, so it looks like IE indeed matches rendering, and only > changes the order of the first <tr> in <thead> and the first <tr> in > <tfoot>, all other <tr>s being in tree order. All <tr>s in the relevant <thead>/<tfoot> are moved, not just the first one, no? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3778
(In reply to Simon Pieters from comment #8) > (In reply to Philip Jägenstedt from comment #3) > > Thanks you Prashant, so it looks like IE indeed matches rendering, and only > > changes the order of the first <tr> in <thead> and the first <tr> in > > <tfoot>, all other <tr>s being in tree order. > > All <tr>s in the relevant <thead>/<tfoot> are moved, not just the first one, > no? > > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3778 It seems so, yeah. I must have misread https://jsfiddle.net/d2ghq0n2/2/
New proposal: Make rows just use the tree order, assuming that orders other than thead-tbody-tfoot are made non-conforming in https://github.com/whatwg/html/issues/352
In httparchive I see 1423 resources containing "table.rows". On github there are 983,628 HTML results for "thead tfoot" (matches </thead>\n<tfoot>). https://github.com/search?l=html&q="thead+tfoot"&ref=searchresults&type=Code&utf8=✓ Code that iterates the rows and sets a class name on every other row, to get striped tables, would be broken on tables with <tfoot> before <tbody> with such a change. e.g. https://github.com/gary0726/Dangjian/blob/b510eb89c3b2edff9998105e043c4a56dbbe1106/trunk/zhdj/src/main/webapp/js/do1/common/table.js I suppose you could argue that it is a good thing because it's just visual, and it might encourage the author to move the <tfoot>. But maybe other things break in more severe ways? For tables that use thead-tbody-tfoot markup order, there will be no reordering, so the only benefit is really slightly simpler implementation of HTMLTableElement#rows. Is it worth the risk?
If the change make sense ignoring risk, I could try to measure the risk with use counters. Only if the risk is insignificant and multiple implementors are on board do I think we should actually make the spec change. People from both Mozilla and Microsoft are on CC, any thoughts?
If we change this, should probably also change the table model in the same way. (Search for "pending tfoot elements".)
Hmm, how is that algorithm used in implementations? In Blink I find nothing with "pending" and "foot" (case-insensitive) on the same row.
I don't know if it's implemented, but it's used for associating <td>s with <th>s (necessary for ATs) and table sorting in the spec. Also the cellpadding attribute in the rendering section, but I don't know if that one is necessary/correct.
FWIW, I think what the standard says today here makes the most sense. We should simply change Firefox and Edge. Rendering order is not a good order as you can change it by changing the display property. We don't want APIs to depend on that. I also don't think we simply want tree order, since that doesn't match table element semantics.
The proposal is not to make the order change depending on 'display'. Again see comment 7 :-)
https://github.com/whatwg/html/issues/4470