[cssom] Table row resolved width and height.

[emilio]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1590837 / jquery/jquery#4529.

In the following test-case:

<table style="border-collapse: separate; border-spacing: 0; background: #baffc9"><tbody>
	<tr id="tr" style="margin: 0; border: 10px solid black; padding: 0">
		<td style="margin: 0; border: 0; padding: 0; height: 42px; width: 42px;"></td>
	</tr>
</tbody></table>
    <div id="result"></div>
<script>
var result = document.getElementById('result');
var tr = document.getElementById('tr');
result.innerHTML = getComputedStyle(tr).width;
</script>

Gecko reports 42px. Blink/WebKit report 22px. EdgeHTML reported auto.

width and height on table rows have no effect, so I think Edge was right on this one, and table rows should behave the same way non-replaced inlines behave, and just return the computed value... Thoughts?

I should update the spec to better reflect implementations on this regard, btw...

[Loirooriol]

width and height on table rows have no effect

Are you sure? From https://drafts.csswg.org/css2/tables.html#height-layout

it is the maximum of the row's computed 'height', [...]

If I set height: 50px to the row, the table grows from 42px to 50px.

width seems to have no effect indeed for horizontal writing modes. But if I set writing-mode: vertical-lr to the table, then width has effect (and height doesn't).

[emilio]

Ah, yeah, good point, I guess this is only about inline-size.

[Loirooriol]

It's not exactly inline-size either, because if you use writing-mode: vertical-lr to the row, then inline-size will refer to the height and it will have effect. So the size that doesn't have effect is the one in the axis of the table's inline size (or the tbody's? Orthogonal flows in table parts are confusing for me).

[FremyCompany]

I see that this is open for discussion later today. I should be able to make the call, but even if not here are a few thoughts:

• border-*-width should return 10px because border-width is not a property that returns its used value for getComputedStyle;
• height however should return its used value. So basically, you want to return 42px here, because the used value of border is 0px, and the full row height is 42px so 42px - 0px = 42px.
• I would thus argue Firefox 70 is correct. The problem is that this kind of correct is also unpractical for authors, because they will inevitably try to compute the full height by adding the border-width and the height, unknowing of the fact that the border was actually ignored in the first place. Chrome avoids that pitfall by subtracting from 42px the 2*10px from the border they report but actually do not use.

So, well, this isn't great, but I don't think there is any behaviour here that makes a lot of sense. Firefox 70 is compliant with the specs as they are today, but that behavior is annoying for web developers because unpredictable. Ideally, all browsers would adopt Firefox 68's behaviour (then we need to change CSSOM to enable reporting the used value of border-width on elements which cannot draw borders) but otherwise we might have to specify Chrome's behavior (height return its used value minus the computed value of border-*-width, regardless of the used value of border-*-width).

A final option would be to make a change to css-tables and specify that the computed value of border-*-width on table-track elements in separate mode is forced to 0px. That would make Firefox 68's behavior valid per spec again, for different reasons.

The main concern I have with Chrome's behavior is that it doesn't round-trip. As mentioned before, setting height on a table row does have an effect, and that effect ignores any border-width set on the table row, so basically setting height to Chrome's getComputedStyle().height value can alter the table layout in the end.

[FremyCompany]

While EdgeHTML's behavior makes the most sense in the end, it's also not spec-compatible right now because height should return its used value, not its computed value. The reason Edge reports its computed value is that the row doesn't have a box, so it behaves similarly to a display:none element.

[fantasai]

@Loirooriol The writing-mode property doesn't apply to internal table or ruby elements: they all use the writing-mode of the table wrapper/ruby container box. ( But see also https://www.w3.org/TR/css-writing-modes-3/#placement )

[fantasai]

Also, given @FremyCompany’s observation that Chrome's value doesn't round-trip, I think we really really really should not go with that option. Roundtripping getComputedStyle() values is probably the most fundamental rule about defining them.