- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Feb 2025 18:02:50 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <bramus> oriol: this is conflict regarding what box overflow applies to<br> <bramus> … spec says that by default properties that you set on a table element apply to the grid not the wrapper<br> <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<br> <bramus> … thatwas a resolution but only part of it got in CSS2<br> <bramus> … but then in CSS3 that became the opposite<br> <bramus> … so we should decide if it applies to the box or the wrapper<br> <bramus> … elika is of the opinion that is more useful on the grid<br> <bramus> … I tested if you use contain: paint it applies to the wrapper<br> <bramus> … so would be Ok to apply to the grid<br> <bramus> … reason tables-3 says it applies to the wrapper it is bc of overflow … which that applies to the wrapper<br> <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?<br> <bramus> … not that familiar with transforms<br> <bramus> Rossen3: Comments?<br> <bramus> dholbert: we got a bug filed on this a while back in firefox<br> <bramus> … spec maybe aligns with what gecko is doing<br> <iank_> q+<br> <bramus> … i did file bugs in chromium and webkit, but dont know the progress of those<br> <bramus> … this is about the overflow applying<br> <bramus> … IIRC the spec says wrapper<br> <Rossen3> ack iank_<br> <bramus> iank_: preference to apply to the wrapper making all of the ?? and transform style props to aply to the wrapper<br> <emilio> q+<br> <bramus> … like clip and clip-path<br> <bramus> … just for consistency<br> <bramus> … suspect it is like … debatable which is most useful<br> <bramus> … if someone wants to clip inthe wrapper, then we allow clipping on the sectino elements which make that possible<br> <bramus> … so I would like to keep everything on the wrapper<br> <bramus> emilio: main diff here is wehter caption and so on get clippped<br> <bramus> … as an author I expec thte ?? behavior that what scrolls decides the content of the table<br> <bramus> … otherwise bottom captions become useless in scrollable tables<br> <Rossen3> ack emilio<br> <bramus> … would be odd to push ??? to the bottom of the scrollable table<br> <bramus> iank_: you cant scroll right?<br> <bramus> oriol: values other than visible or hidden<br> <bramus> iank_: overflow: scroll on a table does not do anything right now<br> <bramus> … like overflow hidden is treated as clip<br> <bramus> … so therefore preference to keep everything on the wrapper<br> <bramus> emilio: other thing we could do is apply to both, but could have observable difference<br> <bramus> … in that case no strong preference though<br> <bramus> … the caption thing still applies though right?<br> <bramus> … I guess not, bc you clip outside of the captions vs inside<br> <bramus> iank_: yes<br> <bramus> fantasai: same thought as emilio: if we could make it scrollable obvs thing would be to scroll the table itself.<br> <iank_> i don't think we'll be able to make scrolling work from a compat point of view.<br> <Rossen3> ack fantasai<br> <bramus> bramus: people want that, along with sticky headers<br> <bramus> fantasai: if we want to do that eventually, would taking a decision to do it on the wrapper cause a problem?<br> <bramus> iank_: tables and overflow:scroll have been around for long enough<br> <bramus> … they cant really be made scrollable bc of style constraints<br> <bramus> … if you set `height` it does not add … intrinsic block sizes override that<br> <bramus> fantasai: there is the ?? algo to make that work<br> <bramus> iank_: not an easy path to make tables scrollable<br> <fantasai> s/there is the ??in that case we'd need a new table-layout algo/<br> <bramus> … substantial rework to how they work<br> <bramus> iank_: what was your point about sticky headers?<br> <bramus> … we have sticky top rows, but stikcy cols is a different problem<br> <bramus> Rossen3: we are at time<br> <bramus> … not sure we can resolve right now, I think?<br> <bramus> … table scrolling will take up more time<br> <bramus> … seems like an interop nightmare<br> <bramus> iank_: dont think we need to make tables scrollable int he near term<br> <bramus> … could back ourselves in a corner<br> <bramus> … if we ever make them scrollable, then we can change things<br> <bramus> … sticking on the wrapper<br> <bramus> fantasai: (missed)<br> <bramus> iank_: putting it on the wrapper does not paint it into a corner<br> <bramus> s/it/us<br> <fantasai> s/(missed)/as you note, we'd need an opt into a different algorithm<br> <bramus> Rossen3: So can we decide on that?<br> <bramus> iank_: if no-one objects, then yes<br> <fantasai> s/into a different algorithm/into a different algorithm, so we could use that as a switch for overflow as well/<br> <bramus> PROPOSED RESOLUTION: overflow applies to the wrapper box<br> <fantasai> PROPOSED: overflow applies to wrapper box<br> <bramus> Rossen3: objections?<br> <bramus> RESOLVED: overflow applies to the wrapper box<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10881#issuecomment-2685810362 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 February 2025 18:02:51 UTC