[css-tables-3] Make rendering of border intersections undefined for collapsed borders model

[fantasai]

There are a lot of considerations that go into the rendering of border intersections in the collapsed borders model that don't apply to normal corners, so I think we should make the rendering of such intersections explicitly undefined.

[FremyCompany]

We could do that. Currently there's a model described in the spec but it isn't implemented like that anywhere, and I don't think there's any buy-in in trying to change things on user agent side, so it might be worth making all this undefined (possibly keeping the current text in an html comment to serve as a basis if we ever want to standardize this).

[FremyCompany]

This is what is currently in the spec btw:

[The used value of border-width on a table cell in collapsed-borders mode is set to half the width of the corresponding harmonized border along that edge]

Borders of a table-cell are rendered in collapsed-borders mode as if the cell border was twice as big as its used value specify, and as if that excess was rendered in the margin area of the cell, with the added constraint that for each side of the border which isn’t located at one of the table edges, the border is actually clipped to the border-box drawing area.

[atotic]

We might not be able to completely specify border intersection painting, but I think it would be worthwhile some things can be specified.
One example: https://jsfiddle.net/atotic/zLsyh1b9/

<tr>
  <td border:5px>0,0</td><td>0,1</td>
</tr>
<tr>
  <td>1,0</td><td border:40px>1,1</td>
</tr>

In this example, part of the border of cell 1,1 will be painted inside cell 0,0. This means that part of cell's 0,0 content box will be painted over by a border defined by non-neighboring cell.
I think that this cannot be accomplished by painting algorithm currently described by the standard. In my understanding the standard specifies that each cell is responsible for painting inside its own border box. But cell 0,0 has no knowledge of the cell1,1's borders, so that cannot be accomplished.

As an implementor, I'd really appreciate some guidance from csswg regarding painting of intersections, maybe not "must implement", but at least "this is what we are hoping for". I do not think there are that many issues to sort through.

My pet peeve is trying to make dotted borders look good. The problem is that if you paint each border independently, the dots clump at the intersections. Making them overlap gets rid of the clumping, but then you are painting twice over the intersections, which is visible with alpha-transparent colors. Which borders should I prioritize to look good: transparent, or dotted?

The issue might be: "Should intersections ever be painted over by more than a single edge?" If the answer is no, what do we do about pattern borders? Discourage their use?

Without guidance, intersections are being implemented differently in every browser, which is not great for web developers.

[faceless2]

All the borders are painted after all the cells - https://www.w3.org/TR/CSS21/zindex.html - and I think that's covered by "borders of table cells are rendered as usual" from 5.3.3.

Agree it's a mess, particularly when you come to translucent or dotted borders. But as @FremyCompany said, as there seems to be little will from any of the main ones to change. Better that the spec reflects that than set unrealistic expectations of how it should work - I think explicitly undefined is a good option, although keeping what we can of the existing text to say how it might work in in ideal world.

[atotic]

there seems to be little will from any of the main ones to change

Chrome has just reimplemented tables (my work), and is about to reimplement table fragmentation. Reimplementation is the best time to advocate changes.