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)

RESOLVED FIXED in Firefox 67

Status

()

enhancement
P2
normal
RESOLVED FIXED
6 months ago
5 months ago

People

(Reporter: twisniewski, Assigned: dholbert)

Tracking

Trunk
mozilla67
Points:
---
Bug Flags:
webcompat ?

Firefox Tracking Flags

(firefox66 wontfix, firefox67 fixed)

Details

(Whiteboard: [webcompat][wptsync upstream])

Attachments

(4 attachments)

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.

Flags: webcompat?

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

Priority: -- → P2

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?

Flags: needinfo?(miket)

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).

Flags: needinfo?(miket) → needinfo?(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).

Flags: needinfo?(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)

Flags: needinfo?(twisniewski)

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

Flags: needinfo?(twisniewski)

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).

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.

(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

Summary: Gecko and Webkit/Blink default to different box-sizing values for table tags. → 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)
Summary: 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) → 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)

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.

Status: NEW → RESOLVED
Closed: 5 months ago
Flags: needinfo?(dholbert)
Resolution: --- → INVALID

WPT test posted.

Flags: needinfo?(dholbert)

(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.

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

Reopening since we'll land something in this bug.

Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Assignee: nobody → dholbert
Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7754ccd4cb02
Add web-platform-test for table element's UA-stylesheet-provided CSS rules. r=heycam
Status: REOPENED → RESOLVED
Closed: 5 months ago5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15620 for changes under testing/web-platform/tests
Whiteboard: [webcompat] → [webcompat][wptsync upstream]
Upstream PR merged
You need to log in before you can comment on or make changes to this bug.