In current Blink, Safari, Firefox, on MacOS only the first thead or tfoot is collected and moved, according to the test case.

The relevant section of the current draft has the same algorithm as HTML 5

To fix it for current behaviour of tfoot would mean changing step 15 so it runs a maximum of once. There is no mention of thead, so according to the spec it doesn't move - there should be an analogue to the (edited) step 15 that takes the first thead found and moves it to the top.

It is worth describing this in the prose at the beginning of the section.

The content model for the table element should also be updated, to allow a mix of tfoot, tbody, thead, tr etc.

And we probably need more tests for the various methods related to rows…

Hi @chaals,

Good spotting! It's indeed the first tfoot which is the one moved to the last position, I miswrote this in my email (similarly, only the first thead is moved first). Subsequent tfoots/theads are handled like tbodys.

Here's some background for this issue: @gregwhitworth and myself are currently revisiting the interactions between HTML Tables and CSS, and the new specification currently relies on the HTML algorithm to describe the tracks spanned by cells, rows, columns, and groups, and their relationships.

The fact the algorithm is incorrect on something like this makes me somewhat unconfident about it. It lacks examples and I am not sure it has been tested thoroughfully. Do you think writing more tests on this algorithm and fixing the edge cases is something the HTML Working Group could do during the coming months?

Another option would be to pull this out of the HTML spec into the new CSS spec (or at least duplicate it there temporarily), but if the HTML Working group feels up to the task, I think we would rather keep the statu quo and let this algorithm lives in the HTML spec.

What do you think?

@FremyCompany Sorry for the delays, I've been busy.

I'd like to get the algorithms more accurate, which means getting tests for them, and doing relevant editing.

I agree that we should keep doing this in the context of HTML, and I think managing the work there is pretty straightforward. Indeed, if you have pull requests and tests… :)

(otherwise I'll be working on it in the next couple of days).

Another testcase showing the same behaviour in Firefox/Safari/Yandex browser, with more combinations.

There's an interop problem with reordering in the API that I've looked at, so this caught my attention.

The original test case demonstrates that there's reordering in rendering, but I don't understand what #435 is fixing. AFAICT, the "forming a table" algorithm isn't where reordering happens or should happen, and I don't think that algorithm is actually implemented in browsers. Reordering is during layout, and I think covered by display: table-footer-group.

@adanilo

AFAICT, the "forming a table" algorithm isn't where reordering happens or should happen, and I don't think that algorithm is actually implemented in browsers. Reordering is during layout

Yeah, it's obvious that the algorithm wasn't implemented. Given that it attempts to describe how tables are processed, it seems useful to have, if we make it match reality, and that's the purpose of #435.

I expect to rework the algorithm more for 5.2 - it's pretty convoluted, and I think there are some useful simplifications that would make it almost comprehensible and perhaps accurate as a description of what happens. That strikes me as useful. Making the algorithm informative might also make sense.

The alternative for fantasy algorithms is get rid of them.

But what is the reality you were attempting to match? If it's the fact that rows are reordered during rendering, then I don't think this algorithm really has anything to do with rendering, that's defined by CSS:
https://www.w3.org/TR/CSS2/tables.html#table-display

The bits of what browsers do when building a table that is consistent…

Which leaves the algorithm still looking vague because it is - it doesn't address the inconsistent reality of what happens when there are multiple thead or tfoot elements, but it does end up with something closer to what gets rendered.

The CSS rules don't seem to apply to that case either.

Although it is possible that I have missed something in the spec, it seems browsers set table.tHead and table.tFoot by invisible magic, and then apply rendering rules that look like the relevant CSS rules by more magic.

In the course of chasing this issue I updated the test case I was using so it shows a bit more. It's not entirely self-explanatory. Pull requests welcome.

The CSS rules don't seem to apply to that case either.

Can you elaborate? Does "If a table contains multiple elements with 'display: table-footer-group', only the first is rendered as a footer; the others are treated as if they had 'display: table-row-group'." from https://www.w3.org/TR/CSS2/tables.html#table-display and similarly for headers not fully explain the reordering of thead and tfoot in rendering? I think it does, and am very keen to learn if there's more to it.

it seems browsers set table.tHead and table.tFoot by invisible magic

This is separate reordering, which is a bit confusing. It's not interoperable, and the topic of https://www.w3.org/Bugs/Public/show_bug.cgi?id=29018

This behavior is specified by https://html.spec.whatwg.org/multipage/tables.html#dom-table-rows but the question is how to reach interop since browsers diverge slightly.

Anyway, I don't understand what #435 is intended to do, that algorithm is about the semantics AFAICT. My best guess is that it's used by validators to report errors.