1520264 - Use table wrapper box in window.getComputedStyle(elem).height, in order to include table's caption height

Status: NEW

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

Description

[Timmy Willison]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

Test case: https://jsfiddle.net/timmywil/Lqrwhnxu/7/

Actual results:

While recent changes were made to use the table wrapper box in offset/client/scrollHeight properties, the computed CSS still does not include the caption height.

Expected results:

Firefox seems to be the odd one out here, but I'm not sure if the spec says to use the table wrapper for computed height. If it's determined that it does not, I'll open tickets on other browsers. However, the quickest route to browser consistency would be if Firefox were updated. Then jQuery wouldn't have to change anything. Otherwise, we'll likely do a feature test and fall back to offsetHeight for tables in Firefox.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that shows the problems this can cause in other browsers

Chrome and Safari are both violating the "setting specified style to return value of getComputedStyle() should not change the style" invariant here... Every time the button in this testcase is clicked, the table grows in those browsers.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Is there a spec issue on this? Seems like it'd be worth at least pinging the CSSWG about this, even if it's to say "We're implementing this due to compat".

I think the behavior described in comment 1 is pretty unfortunate though.

In terms of implementation it's a matter of using mOuterFrame instead of mInnerFrame in DoGetHeight in:

https://searchfox.org/mozilla-central/source/layout/style/nsComputedDOMStyle.cpp

But then there's the question of whether the other uses of mInnerFrame should also be adapted for this... Looks like some of them should probably be.

https://drafts.csswg.org/cssom/#resolved-values is of course not very helpful in this case....

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is there a spec issue on this

Not yet.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Otherwise, we'll likely do a feature test and fall back to offsetHeight for tables in Firefox.

Wait, why do you need this? Are you trying to determine geometry (in which case getBoundingClientRect might work better), or actual styles?

Comment 5

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

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #4)

Otherwise, we'll likely do a feature test and fall back to offsetHeight for tables in Firefox.

Wait, why do you need this? Are you trying to determine geometry (in which case getBoundingClientRect might work better), or actual styles?

Good question. In this case it's about styles as we need it for https://api.jquery.com/outerHeight/.

As I understand it, the issue arises from the fact that table is higher than its set CSS height when it contains caption, regardless of box-sizing used. In a way, caption acts like another form of padding or border which affects the table box model.

The problem is that jQuery's outerHeight is supposed to contain all those paddings/borders and return the enclosed element height but it doesn't happen in the case of table due to special caption behavior. In case of padding or border we have box-sizing, though, and there's no analogous way to include caption in height computations.

Due to all that, it may make sense to actually settle on Firefox behavior & document it. But for us it's more important to have consistent behavior in supported browsers. And since there's no spec for that yet, it's hard to make a concrete decision.