- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Oct 2024 16:17:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Should the "first formatted line" propagate into a different BFC?`, and agreed to the following:
* `RESOLVED: propagation of text-box-trim from ancestor of multicol works the same as propagation from multicol itself`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> fantasai: Interesting questions here are, what do we think about the current dfn and behavior, and what the use-cases are?<br>
<TabAtkins> fantasai: for example, if someone sets article::first-line { text-transform: uppercase }, what would they expect it to apply to<br>
<TabAtkins> fantasai: The answer might be different for first-line and text-box-trim<br>
<TabAtkins> fantasai: I think impl-wise they can do whatever we think makes sense<br>
<TabAtkins> fantasai: A bunch of these didn't get propogated in the past becasue, as Oriol points out, tables didn't accept ::first-line/letter propagataion<br>
<keithamus> present_<br>
<TabAtkins> fantasai: and that was extended to Grid and Flex too. But we do propagate into other BFCs<br>
<TabAtkins> fantasai: So first quextion we have is, what use-cases do we have for propagation, and what dfn would make the most sense for it?<br>
<TabAtkins> astearns: does anyone know if Koji has an opinion, since they brought it up?<br>
<TabAtkins> fantasai: don't think Koji has a strong opinion, just wants it defined clearly<br>
<TabAtkins> fantasai: we can defer if people hav ea good reason, i just dont' want to pick an arbitrary reason<br>
<TabAtkins> dbaron: in some cases propagating is more difficult, so it would be good to have some justification in terms of use-cases before we decide to do it<br>
<TabAtkins> dbaron: but don't remember what the UA divergence is<br>
<TabAtkins> fantasai: some propagation into BFCs and multicol, but nobody into other formatting contexts<br>
<TabAtkins> fantasai: current spec requires BFC and multicol<br>
<TabAtkins> astearns: we could add more rigor to that dfn saying we require it for BFC and multicol, and shouldn't propagate anywhere else?<br>
<TabAtkins> astearns: I see the argument that if it doesn't make sense for tables, it probably doesn't for flex/grid either<br>
<TabAtkins> Agreed wrt tables and flex/grid<br>
<TabAtkins> fantasai: I believe the spec in Pseudo 4 is clear, I'll double check<br>
<fantasai> https://drafts.csswg.org/css-pseudo-4/#first-text-line<br>
<emilio> I have a slight preference to not propagate to other BFCs either fwiw<br>
<TabAtkins> fantasai: Yeah, specifies only block containers and multicol<br>
<TabAtkins> astearns: So should we leave it at that and close no change? or do you want to go back to the issue to search for use-cases that would justify amending the spec?<br>
<TabAtkins> fantasai: trimming curretnly requires first formatted line; trimming in the first line of a multicol and not subsequent is maybe a little weird<br>
<TabAtkins> fantasai: it's currently a little unclear fo rmulticol because we resolved it shoudl apply to all columns if you set trim on the multicol itself<br>
<TabAtkins> fantasai: and propagation also considers what happens if you set on an ancestor<br>
<TabAtkins> fantasai: but that currently only affects the first line in the multicol<br>
<emilio> q+<br>
<TabAtkins> fantasai: So I guess we could leave ::first-line/letter, and consider the text-box-trim propagation wrt multicol<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: iirc, Gecko didn't propagate across BFCs<br>
<TabAtkins> emilio: other browsers don't inherit quite right when they propagate, which is weird.<br>
<TabAtkins> emilio: think there's just impl bugs across the board<br>
<TabAtkins> emilio: I have a slight preference for not propagating, because it seems harder to get wrong<br>
<TabAtkins> Note we now have ::column pseudo for some special cases, if that might be helpful<br>
<TabAtkins> dbaron: I think some of the complexity i was referring to was specifically first-line/letter, which are really complicated<br>
<TabAtkins> dbaron: if there are text-box-trim cases that'll be solved from it propagating more, maybe we can just fix that rather than change all three<br>
<TabAtkins> astearns: yes, don't see a real need to keep them consistent<br>
<TabAtkins> fantasai: yeah, was just a spec editting convenience<br>
<TabAtkins> fantasai: so my suggestion is to make no change to ::first-line/letter (tho we could come back if we needed to). for text-box-trim, because it propagates to columns of a multicol, if set on an ancestor it should similarly propagate when it hits the multicol<br>
<TabAtkins> astearns: makes sense to me<br>
<TabAtkins> astearns: is there any different handling we should do for flex/grid?<br>
<TabAtkins> fantasai: currently we don't trim them. might be simplest, we don't actually know if the flex/grid will coincide with the top of the container<br>
<TabAtkins> fantasai: due to alignment/etc<br>
<TabAtkins> fantasai: it's pretty understandable to authors, i think, that it doesn't propagate into flex/grid/tables<br>
<TabAtkins> fantasai: the difference between a BFC root and a normal BFC is a little subtle, and can be triggered by accident<br>
<TabAtkins> fantasai: so i think it makes sense for the behavior to be more transparent there<br>
<TabAtkins> astearns: ok so let's take a resolution on just multicol+text-box-trim<br>
<fantasai> PROPOSED: propagation of text-box-trim from ancestor of multicol works the same as propagation from multicol itself<br>
<florian> +1<br>
<TabAtkins> astearns: objections?<br>
<TabAtkins> RESOLVED: propagation of text-box-trim from ancestor of multicol works the same as propagation from multicol itself<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11038#issuecomment-2432766401 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 October 2024 16:17:10 UTC