[css-tables] track merging

[gregwhitworth]

Compat Issues: no

Description:
CSS 2.1 has very complex rules to decide when or when not to have border-spacing between two tracks.
Careful investigation yielded a much simpler way to deal with the problem.

Proposed Option:
Tracks that are not explicitly defined by a table-track box can be merged with the previous track for layout purposes if they are spanned with same set of cells (plus some minor fine prints for fixed layout). This is primarily proposed for spec sanity.

Here is the proposed text:
The HTML Table Formatting algorithm sometimes generates more tracks than necessary to layout the table properly.

Those tracks have historically been ignored by user agents, so the next step just gets rid of them entirely to avoid dealing with them as exceptions later in the spec.

CSS 2.1 Option:
Continue to pretend that the HTML algorithm generates an accurate representation of the table, and try to emulate previously-exposed behavior by cancelling the side-effects of the existence of some tracks.

Testcases:
https://github.com/w3c/csswg-test/tree/css-tables/work-in-progress/microsoft/css-tables/html5-table-formatting-1.html
https://github.com/w3c/csswg-test/tree/css-tables/work-in-progress/microsoft/css-tables/html5-table-formatting-2.html
https://github.com/w3c/csswg-test/tree/css-tables/work-in-progress/microsoft/css-tables/html5-table-formatting-3.html

Browsers Passing Test:
As far as I know, this change is just another way of doing the same thing, but it is easier to implement that way.

[dbaron]

For what it's worth, Gecko has a bunch of tests for whether a row or column has a nonzero number of cells "originating" in it, where originating means that the row/column is the first row/column in the cell's span.

[FremyCompany]

This was discussed but not resolved by the CSSWG during TPAC2016, and the change was agreed upon but a temporary note should be added to make sure we didn't miss some specific case.

We should also have a look at the gecko test cases.