Intent to ship: Changes to how offset*, client*, scroll* behave on tables

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=820891

Summary: In other browsers, and arguably per spec as far as cssom-view 
specs things, various geometry APIs on tables should report values for 
the table wrapper, not the table itself, because they are defined to 
work on the "first" box generated by the element.  That means that the 
caption is included in the returned values and that things like 
clientWidth should include the table border, modulo the various 
box-sizing weirdness around tables.

Right now, we are just applying the geometry APIs to the table box 
itself.  The patches in the above bug change this.

The behavior of getBoundingClientRect and getClientRects is not being 
changed here, though there is lack of interop around it as well; I filed 
https://bugs.webkit.org/show_bug.cgi?id=187524 and 
https://bugs.chromium.org/p/chromium/issues/detail?id=862205 on that.

Our new behavior aligns much better with other browsers and the spec, 
but this is a general heads-up in case there is compat fallout due to 
browser-sniffing or something...

-Boris
0
Boris
7/10/2018 4:25:45 PM
mozilla.dev.platform 6415 articles. 0 followers. Post Follow

2 Replies
8 Views

Similar Articles

[PageSpeed] 50

On 10/07/2018 17:25, Boris Zbarsky wrote:
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=820891
> 
> Summary: In other browsers, and arguably per spec as far as cssom-view 
> specs things, various geometry APIs on tables should report values for 
> the table wrapper, not the table itself, because they are defined to 
> work on the "first" box generated by the element.  That means that the 
> caption is included in the returned values and that things like 
> clientWidth should include the table border, modulo the various 
> box-sizing weirdness around tables.
> 
> Right now, we are just applying the geometry APIs to the table box 
> itself.  The patches in the above bug change this.
> 
> The behavior of getBoundingClientRect and getClientRects is not being 
> changed here, though there is lack of interop around it as well; I filed 
> https://bugs.webkit.org/show_bug.cgi?id=187524 and 
> https://bugs.chromium.org/p/chromium/issues/detail?id=862205 on that.
> 
> Our new behavior aligns much better with other browsers and the spec, 
> but this is a general heads-up in case there is compat fallout due to 
> browser-sniffing or something...

Are there web-platform-tests covering this behaviour (both the part we 
are changing and the part we aren't)?
0
James
7/10/2018 6:47:51 PM
On 7/10/18 11:47 AM, James Graham wrote:
> Are there web-platform-tests covering this behaviour (both the part we 
> are changing and the part we aren't)?

I added some tests in bug 820891.  See the three 
testing/web-platform/tests/css/cssom-view/table-*-props.html tests.

There was also a tiny little bit of coverage in 
testing/web-platform/meta/css/css-tables/width-distribution/computing-table-width-0.html 
that we now no longer fail.

I'm not sure whether there is coverage for 
getBoundingClientRect/getClientRects on tables.

In general, test coverage for cssom-view is terrible.  For example, 
apart from the tests I just added, the only test we have for offsetWidth 
is 
testing/web-platform/tests/css/cssom-view/htmlelement-offset-width-001.html 
which is clearly buggy (e.g. assets that an element is not equal to 0, 
which is going to be true, sure) and basically just tests that 
offsetWidth on an empty div or a div with no box is 0.  There is no 
testing of offsetWidth for any of the interesting cases (interesting 
box-sizing, fieldsets, non-blocks, etc, etc).

-Boris
0
Boris
7/10/2018 7:13:56 PM
Reply: