[css2][css-tables] Does overflow apply to table-wrapper or table-grid? css-tables contradicts CSSWG resolution

The CSSWG resolved (https://lists.w3.org/Archives/Public/www-style/2012Aug/0298.html)

RES0LVED: Errata CSS2.1 to say that 'overflow' on a table element
applies to the table box (not table wrapper box); and
that values other than 'hidden' are treated as 'visible'.

Only the 2nd part did actually go into the errata (as noticed in #2778), but presumably the 1st part still holds?

However, css-tables says the opposite!

csswg-drafts/css-tables-3/Overview.bs

Lines 921 to 924 in c269215

    
           <li>The computed values of properties 'position', 'float', 'margin'-*, 'top', 'right', 'bottom', and 'left' on the table 
        
           	are used on the table-wrapper box and not the table grid box; 
        
           	the same holds true for the properties whose use could force the used value of 'transform-style' to <code>flat</code></a> (see [[css-transforms-2#grouping-property-values|list]]) and their shorthands/longhands relatives: 
        
           		this list currently includes 'overflow', 'opacity', 'filter', 'clip', 'clip-path', 'isolation', 'mask'-*, 'mix-blend-mode', 'transform'-* and 'perspective'.

This was added in 0363967, and I don't see any reference to some CSSWG resolution overriding the one from 2012.

Browsers do not agree: Firefox applies overflow to the table grid, while Blink and WebKit apply it to the table wrapper.

Due to the way the we implement table wrappers in Servo, it was easier for us to align with Firefox.

There are tests that assert it applies to the table grid: https://wpt.fyi/results/css/CSS2/css21-errata?q=s-11-1-1b

Agenda+ to either ratify the previous resolution, or ratify what css-tables says.

I guess css-overflow should also clarify this. Currently https://www.w3.org/TR/css-overflow-3/#overflow-control says

Applies to: block containers [CSS2], flex containers [CSS3-FLEXBOX], grid containers [CSS3-GRID-LAYOUT]

I guess "block containers" might include table wrapper boxes, but it's not much clear. Table grid boxes seem excluded.

The useful thing to do here is definitely to apply it to the table grid box, so I think we should stand by that resolution.

The useful thing to do here is definitely to apply it to the table grid box

I think there may be valid arguments for both options, applying it to the wrapper could be useful to clip an overflowing caption:

<!DOCTYPE html>
<table style="border: solid magenta; width: 100px; overflow: hidden">
  <caption style="border: solid cyan; width: 200%">caption</caption>
  <td>cell</td>
</table>

On Blink it looks like:

If you want to clip the overflowing caption... just clip the caption?

I'm not sure what you meant, but I have noticed it's possible to clip to the wrapper with contain: paint:

<!DOCTYPE html>
<table style="border: solid magenta; width: 100px; outline: solid cyan; contain: paint">
  <caption style="position: relative; left: 50px; border: solid orange">caption</caption>
  <td>cell</td>
</table>

Gecko	Blink	WebKit

WebKit looks a bit broken but there is interoperability.

So then it could be more useful indeed if overflow applies to the grid.

But there is the thing about overflow being able to affect the used value of transform-style, which applies to the wrapper. So if overflow applies to the grid, should it affect the transform-style of the grid (no-op), or affect the one of the wrapper? Or should transform-style and overflow apply to the same box? I'm not very familiar with transforms.

See also
https://issues.chromium.org/issues/40604616
https://bugs.webkit.org/show_bug.cgi?id=192249
which I filed on overflow-on-tables being wrong (not matching the spec at-the-time at least) in Chromium and WebKit in the past.

(spun off from https://bugzilla.mozilla.org/show_bug.cgi?id=1232055 where it was filed as a Firefox bug).

The CSS Working Group just discussed [css2][css-tables] Does `overflow` apply to table-wrapper or table-grid? css-tables contradicts CSSWG resolution, and agreed to the following:

RESOLVED: overflow applies to the wrapper box

The full IRC log of that discussion

<bramus> oriol: this is conflict regarding what box overflow applies to
<bramus> … spec says that by default properties that you set on a table element apply to the grid not the wrapper
<bramus> … and then for overflow it originally was not defined in CSS2 but then it was added in an errate that the overflow applies to the box not the wrapper
<bramus> … thatwas a resolution but only part of it got in CSS2
<bramus> … but then in CSS3 that became the opposite
<bramus> … so we should decide if it applies to the box or the wrapper
<bramus> … elika is of the opinion that is more useful on the grid
<bramus> … I tested if you use contain: paint it applies to the wrapper
<bramus> … so would be Ok to apply to the grid
<bramus> … reason tables-3 says it applies to the wrapper it is bc of overflow … which that applies to the wrapper
<bramus> … so need to decide if it applies to the grid, affects transform style sof the grid or the wrapper, should it apply to the same box?
<bramus> … not that familiar with transforms
<bramus> Rossen3: Comments?
<bramus> dholbert: we got a bug filed on this a while back in firefox
<bramus> … spec maybe aligns with what gecko is doing
<iank_> q+
<bramus> … i did file bugs in chromium and webkit, but dont know the progress of those
<bramus> … this is about the overflow applying
<bramus> … IIRC the spec says wrapper
<Rossen3> ack iank_
<bramus> iank_: preference to apply to the wrapper making all of the ?? and transform style props to aply to the wrapper
<emilio> q+
<bramus> … like clip and clip-path
<bramus> … just for consistency
<bramus> … suspect it is like … debatable which is most useful
<bramus> … if someone wants to clip inthe wrapper, then we allow clipping on the sectino elements which make that possible
<bramus> … so I would like to keep everything on the wrapper
<bramus> emilio: main diff here is wehter caption and so on get clippped
<bramus> … as an author I expec thte ?? behavior that what scrolls decides the content of the table
<bramus> … otherwise bottom captions become useless in scrollable tables
<Rossen3> ack emilio
<bramus> … would be odd to push ??? to the bottom of the scrollable table
<bramus> iank_: you cant scroll right?
<bramus> oriol: values other than visible or hidden
<bramus> iank_: overflow: scroll on a table does not do anything right now
<bramus> … like overflow hidden is treated as clip
<bramus> … so therefore preference to keep everything on the wrapper
<bramus> emilio: other thing we could do is apply to both, but could have observable difference
<bramus> … in that case no strong preference though
<bramus> … the caption thing still applies though right?
<bramus> … I guess not, bc you clip outside of the captions vs inside
<bramus> iank_: yes
<bramus> fantasai: same thought as emilio: if we could make it scrollable obvs thing would be to scroll the table itself.
<iank_> i don't think we'll be able to make scrolling work from a compat point of view.
<Rossen3> ack fantasai
<bramus> bramus: people want that, along with sticky headers
<bramus> fantasai: if we want to do that eventually, would taking a decision to do it on the wrapper cause a problem?
<bramus> iank_: tables and overflow:scroll have been around for long enough
<bramus> … they cant really be made scrollable bc of style constraints
<bramus> … if you set `height` it does not add … intrinsic block sizes override that
<bramus> fantasai: there is the ?? algo to make that work
<bramus> iank_: not an easy path to make tables scrollable
<fantasai> s/there is the ??in that case we'd need a new table-layout algo/
<bramus> … substantial rework to how they work
<bramus> iank_: what was your point about sticky headers?
<bramus> … we have sticky top rows, but stikcy cols is a different problem
<bramus> Rossen3: we are at time
<bramus> … not sure we can resolve right now, I think?
<bramus> … table scrolling will take up more time
<bramus> … seems like an interop nightmare
<bramus> iank_: dont think we need to make tables scrollable int he near term
<bramus> … could back ourselves in a corner
<bramus> … if we ever make them scrollable, then we can change things
<bramus> … sticking on the wrapper
<bramus> fantasai: (missed)
<bramus> iank_: putting it on the wrapper does not paint it into a corner
<bramus> s/it/us
<fantasai> s/(missed)/as you note, we'd need an opt into a different algorithm
<bramus> Rossen3: So can we decide on that?
<bramus> iank_: if no-one objects, then yes
<fantasai> s/into a different algorithm/into a different algorithm, so we could use that as a switch for overflow as well/
<bramus> PROPOSED RESOLUTION: overflow applies to the wrapper box
<fantasai> PROPOSED: overflow applies to wrapper box
<bramus> Rossen3: objections?
<bramus> RESOLVED: overflow applies to the wrapper box

Edited into css-overflow-3 for now.

@fantasai

53d6722

@fantasai Didn't we resolve on the opposite? That it applies to the wrapper box, not the grid box.

Navigation Menu

Repository navigation

[css2][css-tables] Does `overflow` apply to table-wrapper or table-grid? css-tables contradicts CSSWG resolution #10881

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	<li>The computed values of properties 'position', 'float', 'margin'-*, 'top', 'right', 'bottom', and 'left' on the table
	are used on the table-wrapper box and not the table grid box;
	the same holds true for the properties whose use could force the used value of 'transform-style' to <code>flat</code></a> (see [[css-transforms-2#grouping-property-values\|list]]) and their shorthands/longhands relatives:
	this list currently includes 'overflow', 'opacity', 'filter', 'clip', 'clip-path', 'isolation', 'mask'-, 'mix-blend-mode', 'transform'- and 'perspective'.

[css2][css-tables] Does overflow apply to table-wrapper or table-grid? css-tables contradicts CSSWG resolution #10881

Description

Activity

Loirooriol commented on Sep 12, 2024

fantasai commented on Sep 16, 2024

Loirooriol commented on Sep 25, 2024

fantasai commented on Nov 12, 2024

Loirooriol commented on Jan 3, 2025

dholbert commented on Feb 26, 2025

css-meeting-bot commented on Feb 26, 2025

fantasai commented on May 8, 2026

Loirooriol commented on May 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[css2][css-tables] Does `overflow` apply to table-wrapper or table-grid? css-tables contradicts CSSWG resolution #10881