1590837 - table <tr>'s getComputedStyle reports width without subtracting borders (long interop issue) and borders started being reported in bug 1404140.

Status: NEW

(Core :: DOM: CSS Object Model, defect, P3)

Description

[Michał Gołębiowski-Owczarek [:mgol]]

Start with the following HTML:

<table style="border-collapse: separate; border-spacing: 0; background: #baffc9"><tbody>
	<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>

In Firefox (all versions, from very old to Nightly) getComputedStyle(tr).width is 42px while in Chrome 78 & Safari 13 it's 22px. IE 11 & Edge 18 report "auto".

This made one of the tests in the jQuery test suite fail as our outerWidth() API adds borders to the reported computed width and Firefox 70 started reporting borders on trs in computed style (aligning with other browsers).

See https://github.com/jquery/jquery/issues/4529, in particular my comment at https://github.com/jquery/jquery/issues/4529#issuecomment-545569311.

Comment 1

[Michał Gołębiowski-Owczarek [:mgol]]

An online test case: https://output.jsbin.com/pujukar/1. Expected output: PASS: 22px.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Oh, so the regression here is that we started reporting the borders, IIUC, right?

Thanks for filing this. jQuery should probably run the test-suite with firefox Nightly, or we should run jQuery's test-suite, or something :/

This was a regression from bug 1404140, I'm pretty sure. I think the right thing is to report auto, for width and height in that case, tbh. width and height don't apply to table rows anyway, so it'd be consistent with how <span> / regular inlines work.

Would that make jQuery happy out of curiosity? Or would it break more than it fixes?

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Relatedly, these kinds of interop issues would be terribly useful to know in the CSS working group :)

I filed https://github.com/w3c/csswg-drafts/issues/4444 for this.

Comment 4

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Oh, so the regression here is that we started reporting the borders, IIUC, right?

Yes and no. That changed caused our test suite to fail one test but if you read https://github.com/jquery/jquery/issues/4529#issuecomment-545569311, other similar APIs like .innerWidth() already behaved differently, we just didn't have a test catching that discrepancy. The test that started failing was kind-of passing by accident as the differences in various APIs were nullified in jQuery's .outerWidth().

Thanks for filing this. jQuery should probably run the test-suite with firefox Nightly, or we should run jQuery's test-suite, or something :/

We run tests on BrowserStack which doesn't have nightly versions. But we also started running them on Travis on Chrome & Firefox & the Firefox Travis addon supports Nightly so maybe we could make it run:
https://docs.travis-ci.com/user/firefox
However, even if we run tests on Nightly, this would only be done when we commit something to jQuery so it might not catch some regressions. If you want to make sure Nightly passes the jQuery test suite, it might be better for you to run it.

This was a regression from bug 1404140, I'm pretty sure. I think the right thing is to report auto, for width and height in that case, tbh. width and height don't apply to table rows anyway, so it'd be consistent with how <span> / regular inlines work.

Would that make jQuery happy out of curiosity? Or would it break more than it fixes?

We make sure we report actual values instead of auto so Firefox returning auto would make jQuery use its fallbacks: the old offsetWidth & offsetHeight API. That would lose fractional support, etc. This doesn't look like a good direction to take to me.

Comment 5

[Michał Gołębiowski-Owczarek [:mgol]]

Can we please mark this bug as blocking bug 968240? This is an issue that jQuery is currently working around.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Can you link to the jquery workaround?

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Though in https://github.com/w3c/csswg-drafts/issues/4444#issuecomment-567146465 Chrome engineers agree that this is really a Chrome bug.

Comment 8

[Michał Gołębiowski-Owczarek [:mgol]]

We run a support test here:
https://github.com/jquery/jquery/blob/3.6.0/src/css/support.js#L106-L146
The test succeeds if tr.offsetHeight matches the value you get from adding height & the top & bottom borders from the tr computed style.

We check the value of this support test here:
https://github.com/jquery/jquery/blob/3.6.0/src/css.js#L152
and when the test fails, we fallback to tr.offsetHeight here:
https://github.com/jquery/jquery/blob/3.6.0/src/css.js#L172