1520018 - Gecko and Webkit/Blink default to different box-sizing values for table tags (though WebKit/Blink *behave* as if they had `box-sizing:border-box` on their `<table>` elements if you don't touch `display` val)

Status: RESOLVED FIXED

(Core :: Layout: Tables, enhancement, P2)

Description

[Thomas Wisniewski [:twisniewski]]

By default, a table tag has box-sizing content-box in Chrome/Safari. In Firefox, it gets border-box. This can cause interop issues, such as when the table tag is assigned a different CSS display value like inline-block (as in the see-also webcompat.com link).

I see that HTML4's default UA sheet was apparently supposed to use border-box, but I'm not sure if that carried over to HTML5: https://www.w3.org/TR/css-tables-3/#mapping

But in light of the other two major engines using content-box, I suspect it might be worth changing our default to match.

Comment 1

[Jonathan Watt [:jwatt]]

Seems like a low effort compat win, so let's start with P2.

Comment 2

[Thomas Wisniewski [:twisniewski]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=37e30ea816765d20f3719e878d395a9987209b43

Comment 3

[Thomas Wisniewski [:twisniewski]]

Actually, looking over the related web platform tests in that try-run, I found this Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=598134

So I'm not sure what we realistically ought to do here. It sounds to me like Blink is doing something subtler than just using content-box, and would like to align with our behavior, but will not do so anytime soon.

Mike, what's our preferred approach to situations like this?

Comment 4

[Mike Taylor [:miketaylr]]

I'm curious if dholbert has thoughts here, since he filed that linked crbug.

In general my opinion is that if we find this breaks a lot of sites, and sites are relying on Chrome's behavior we should get the spec updated and move to match it (assuming it doesn't break the universe).

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Mike Taylor [:miketaylr] from comment #4)

I'm curious if dholbert has thoughts here, since he filed that linked crbug.

I'm pretty sure that Chromium bug is something entirely different. That bug is about an element with display:table, not about the <table> tag itself. (Plus, the padding there is on a child of a table, not on the table itself.)

Put another way: our rendering of that Chromium bug's testcase would not change if we were to take action on this bug here (i.e. if we were to flip https://searchfox.org/mozilla-central/source/layout/style/res/html.css#268 )

In general my opinion is that if we find this breaks a lot of sites, and sites are relying on Chrome's behavior we should get the spec updated and move to match it (assuming it doesn't break the universe).

I agree with this in spirit, yeah. If the web seems to depend on something other than what the spec says, then we should get the spec changed (as long as the depended-on-behavior isn't arcane/crazy).

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (trying unstyled `div` & `table` with default vs. explicit content-box/border-box)

Comment 7

[Daniel Holbert [:dholbert]]

So testcase 1 shows that Chrome seems to disregard box-sizing entirely on <table> elements and behaves as if they had box-sizing:border-box (even though they don't by default). So they're basically compatible with us, in that their default styling differs but they ignore it and behave as if the table's styling was the box-sizing:border-box that we do in fact have here.

Do you have an example of a webcompat issue that was caused by this bug? (a website depending on some aspect of Chrome's behavior around this)

Comment 8

[Daniel Holbert [:dholbert]]

(ah, it's in "see also" -- looking now...)

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (table with display:inline-block)

Aha, the site seems to have <table style="display:inline-block">.

I can indeed imagine that that could produce different results, since it won't get Chrome's automagic table-boxes-behave-as-if-they-had-border-box-styling behavior.

That will trivially get the box-sizing value that we provide for <table>, yeah, which is why we draw the purple boxes as different sizes here and Chrome draws them as the same size.

I'm going to guess/hope that <table style="display:inline-block"> is vanishingly rare on the internet, so I hope the web doesn't depend on Chrome's behavior here? So, following up on my assessment in comment 5:

• I'm hoping the web doesn't depend on Chrome's behavior (only one webcompat issue so far [?] and it seems pretty edge-casey)
• Chrome's behavior does seem pretty arcane/crazy, so it's non-obvious that we'd want to standardize on it (even if some part of the web did depend on it).

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: comparing `<div style="display:table">` vs. `<table>`

This testcase compares box-sizing values between a div with display:table vs. an actual <table> element.

Chrome agrees with us on the rendering of the div with display:table (the top half of this testcase). So they are sane about handling box-sizing on table boxes, it seems -- they just have some hardcoded special case for table-boxes-that-are-generated-by-the-<table>-element.

All the more reason to suspect this is something weird/arcane/not-standardizable, i.e. a chrome bug that should be fixed.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

(In reply to Mike Taylor [:miketaylr] from comment #4)

I'm curious if dholbert has thoughts here, since he filed that linked crbug.

I'm pretty sure that Chromium bug is something entirely different. That bug is about an element with display:table, not about the <table> tag itself. (Plus, the padding there is on a child of a table, not on the table itself.)

Ah, my mistake -- I didn't read far enough down on that bug. I just read a bit more, and I guess that chromium bug evolved into covering roughly what's being discussed here, and it looks like it's roughly covering a special case where they disagree with us on sizing in div with display:table (despite the fact that they agree with us on simple div-display-table scenarios per testcase 3 here). This must be due to them activating their tables-get-border-box-behavior for some special case when sizing children of the table box, or something.

Anyway, bottom line, this is some dark magic that I would hate for us to have to reverse-engineer and standardize on. And it seems that it's absolutely not as simple as just changing the default value in our UA stylesheet. :)

I would hope that Chromium might fix this as part of their "LayoutNG" effort and/or "the big table rewrite" that was referenced in https://bugs.chromium.org/p/chromium/issues/detail?id=598134#c6

Comment 12

[Daniel Holbert [:dholbert]]

Gonna call this INVALID for now since we're matching the spec and it doesn't seem yet like it's causing serious enough webcompat problems to try to be Chromium bug-compatible on this. (Though if that changes or I'm misunderstanding on that, please reopen!)

I'll aim to land a WPT test for this, too. Setting needinfo=me to do that.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: Bug 1520018: Add web-platform-test for table element's UA-stylesheet-provided CSS rules. r?heycam

Comment 14

[Daniel Holbert [:dholbert]]

WPT test posted.

Comment 15

[Daniel Holbert [:dholbert]]

Try run for WPT test: https://treeherder.mozilla.org/#/jobs?repo=try&revision=563e3cd9a07f4c4e4cca26ea5c35cbd58837f255

Comment 16

[dgrogan (chrome)]

(In reply to Daniel Holbert [:dholbert] from comment #11)

Anyway, bottom line, this is some dark magic that I would hate for us to have to reverse-engineer and standardize on. And it seems that it's absolutely not as simple as just changing the default value in our UA stylesheet. :)

I'd also hate to standardize on Blink's stupid behavior. I hope y'all keep Gecko's sane behavior.

I would hope that Chromium might fix this as part of their "LayoutNG" effort and/or "the big table rewrite" that was referenced in https://bugs.chromium.org/p/chromium/issues/detail?id=598134#c6

That's our plan, but it's unlikely to be soon because even after re-implementing tables in LayoutNG (which will happen no sooner than summer/fall, and maybe 2020) we'll probably need to collect data on how many sites would break and do outreach until it's low enough to switch over.

Comment 17

[Daniel Holbert [:dholbert]]

Sounds great. Thanks for that confirmation & for the rough timeline!

Comment 18

[Cameron McCormack (:heycam)]

Reopening since we'll land something in this bug.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7754ccd4cb02
Add web-platform-test for table element's UA-stylesheet-provided CSS rules. r=heycam

Comment 20

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/7754ccd4cb02

Comment 21

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15620 for changes under testing/web-platform/tests

Comment 22

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged