Re: [csswg-drafts] [css-tables][css-backgrounds] Does background-clip work on table columns and rows? (#9916)

The CSS Working Group just discussed `[css-tables][css-backgrounds] Does background-clip work on table columns and rows?`, and agreed to the following:

* `RESOLVED: background-clip on table columns and rows is interpreted against the cells' box geometry`

<details><summary>The full IRC log of that discussion</summary>
&lt;jarhar> oriol: they both are ? table rows, table row group, table columsn, but im going to say rows<br>
&lt;jarhar> oriol: they have a special behavior when they get a background, the background applies to the entire row but instead of padinding that we clip the result to each cell in the row, then when implementing this in servo we had that qeustion about how we should treat the background clip property<br>
&lt;jarhar> oriol: there are two reasonable interoper4tations. the backbground clip applies to the row itself, but since the row doesnt haef padding or border of its own, unless you use border collapse or something, otherwise it doesnt have pading or border so basicaly the property has noe ffect. this would resolve in the firefox behavior where you resolve to<br>
&lt;jarhar> content box and it doesnt change from border box<br>
&lt;jarhar> oriol: when c.ipping to each cell, we takt eh backgorund and borer of each cell into account and then ? into the area<br>
&lt;jarhar> oriol: clip to the contnet box itself. this is what blink is doing. webkit was completely broken<br>
&lt;jarhar> oriol: asking which option would be preferred<br>
&lt;jarhar> dbaron: i have two thoughts on this and they contradict each other. neither is very strong<br>
&lt;jarhar> dbaron: it seems liek theres a readonable thing for th eproeprty to do and that makes it do the same thing it does everywherele slse so why not have it do a thing instead of do nothing.<br>
&lt;jarhar> dbaron: the other thought is that it wseems weird for backgrounde clip and background origin to do different things, it seems weird for background origin and backbground clip be relative to different things. one argues one way the other argues another<br>
&lt;astearns> q+<br>
&lt;miriam> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to show some diagrams<br>
&lt;jarhar> fantasai: i work on this part of the spec a long time ago<br>
&lt;jarhar> fantasai: the model we have for how rows paint is that you dra wht erectangle and thn you clip out the indificual cell areas because otherwise tihings wont line up nicely<br>
&lt;jarhar> fantasai: if you explode the cells it isnt as nice as when the cells are windows<br>
&lt;futhark> present-<br>
&lt;jarhar> fantasai: the paint area is not that the row boxes mean, it expands beyond that so that the window of an indivicual ceel has to include the row boxes area because it expands into a different row. otherwise you ge thti sefect where you can tsee the text<br>
&lt;jarhar> fantasai: the origin is relative to the row box<br>
&lt;jarhar> fantasai: ill drop a link to this<br>
&lt;fantasai> https://fantasai.inkedblade.net/style/discuss/table-backgrounds/<br>
&lt;jarhar> florian: i think hyou already have an issue<br>
&lt;miriam> ack astearns<br>
&lt;jarhar> astearns: am i interpreting these diagrams then fantasai you are going for the second propsal<br>
&lt;jarhar> fantasai: i think i agree with davids assessment of this situation.we can argue there is a bit of differece in terms of the rows painting. it can paint well outside the rows area<br>
&lt;jarhar> fantasai: so i thin kk i might lean more towards making it useful<br>
&lt;jarhar> astearns: my response to david on theidea of having it do something rather than nothinkg , whats the likelihiood of having something we specify be interoperably imnpelemtned, might not be a priority<br>
&lt;jarhar> iank_: we improved a bunch of our rendering a few years ago because we had bugs in this area and webdevs were complaining about it, so given enough webdev response we prioritize it<br>
&lt;jarhar> dbaron: my intuition is that this i sprobably a single digit ish number of lines of code change, maybe a little worse if you need to change 7 functions to pass the right thing throughj them but if it already works for cells then just do the same thing as scells for these other things<br>
&lt;astearns> then I withdraw my concern<br>
&lt;jarhar> miriam: i like useful things more than non useful things<br>
&lt;jarhar> miriam: is there more discussion here?<br>
&lt;jarhar> fantasai: so the propolsal is to make background clip on tables cols and rows change the clip of the cell box?<br>
&lt;jarhar> miriam: are there any issues with how that interacts with clipping on cells or is taht well defined<br>
&lt;jarhar> fantasai: its well defined<br>
&lt;jarhar> fantasai: we kind of already have a cell defined clip area so that ? the cell respond to the rows or columns<br>
&lt;jarhar> miriam: lets take that resolution if we cna<br>
&lt;fantasai> s/that ?/that would make/<br>
&lt;fantasai> RESOLVED: background-clip on table columns and rows is interpreted against the cells' box geometry<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9916#issuecomment-2161064136 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 11 June 2024 15:34:37 UTC