[css-pseudo] Should the "first formatted line" propagate into a different BFC?

[kojiishi]

Split the issue from #10990 (comment) to discuss easier.

Blink I think currently has issues with ::first-line propagating into elements which establish independent formatting contexts, when arguably it shouldn't, when I last read the spec here somewhat questionable.
E.g.
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13169

@bfgeek @fantasai

[fantasai]

We need to review the implications for ::first-line, ::first-letter, and text-box-trim.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] Should the "first formatted line" propagate into a different BFC?.

The full IRC log of that discussion

<matthieud> fantasai: text-box-trim feature really on concept of first formatted line
<matthieud> fantasai: also first-line and first-letter rely on this
<matthieud> fantasai: to what extend are the allowed to intrude into a new formatting context like ???
<matthieud> fantasai: we need to think about use cases
<matthieud> fantasai: possible easy answer : they dont (current implementation)
<florian> q+
<dholbert> s/???/flex, grid, multicol/
<matthieud> fantasai: in the past, people uses ??? to create a new formatting context
<Rossen16> ack dbaron
<emilio> q+
<matthieud> dbaron: some case makes sense, other are problematic
<matthieud> dbaron: the weirdest is when a new formatting context has multiple stuff at the top
<matthieud> dbaron: like multi column or grid
<matthieud> dbaron: whether that justify to make it work with all new formatting context is another question
<dbaron> s/work/not work/
<emilio> q- emilio
<dbaron> dbaron: But I think it's weird to apply it to the cases where there are multiple thingns at the top or bottom
<Rossen16> ack florian
<matthieud> florian: by not intruding into nested contexts, you mean that the first formated line wouldn't exist in such cases, or that it would be the first line after the nested formatting context?
<matthieud> fantasai: would not exist
<fantasai> dbaron, I think it might make sense to apply it to all of the things at the top
<dbaron> (This seems different from first-line and fisrt-letter in this regard.)
<fantasai> dbaron, but definitely not just one of them

[Loirooriol]

• to what extend are the allowed to intrude into a new formatting context like flex, grid, multicol

  From https://drafts.csswg.org/css2/#first-line-pseudo

  The :first-line pseudo-element can only be attached to a block container element.

  Back then this only excluded tables, but I don't see why we should treat flex and grid containers different than tables.

  A multicol container establishes an independent formatting context, so it's automatically excluded if these are excluded. I'm fine with excluding multicol containers even if we don't exclude independent FC in general.

• current implementation

  As mentioned in the 1st comment, Blink propagates it to block containers with independent FC, including overflow: scroll, display: flow-root, column-count: 2. For multicol, it only propagates to the 1st column.

  Webkit doesn't propagate to them (but propagates to block containers that continue the BFC of the parent).

  Gecko never propagates to anything.

[kojiishi]

Here is the logic Blink excludes tables, flex, grid, <button>, and button input for ::first-letter.

[css-meeting-bot]

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

The full IRC log of that discussion

<TabAtkins> fantasai: Interesting questions here are, what do we think about the current dfn and behavior, and what the use-cases are?
<TabAtkins> fantasai: for example, if someone sets article::first-line { text-transform: uppercase }, what would they expect it to apply to
<TabAtkins> fantasai: The answer might be different for first-line and text-box-trim
<TabAtkins> fantasai: I think impl-wise they can do whatever we think makes sense
<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
<keithamus> present_
<TabAtkins> fantasai: and that was extended to Grid and Flex too. But we do propagate into other BFCs
<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?
<TabAtkins> astearns: does anyone know if Koji has an opinion, since they brought it up?
<TabAtkins> fantasai: don't think Koji has a strong opinion, just wants it defined clearly
<TabAtkins> fantasai: we can defer if people hav ea good reason, i just dont' want to pick an arbitrary reason
<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
<TabAtkins> dbaron: but don't remember what the UA divergence is
<TabAtkins> fantasai: some propagation into BFCs and multicol, but nobody into other formatting contexts
<TabAtkins> fantasai: current spec requires BFC and multicol
<TabAtkins> astearns: we could add more rigor to that dfn saying we require it for BFC and multicol, and shouldn't propagate anywhere else?
<TabAtkins> astearns: I see the argument that if it doesn't make sense for tables, it probably doesn't for flex/grid either
<TabAtkins> Agreed wrt tables and flex/grid
<TabAtkins> fantasai: I believe the spec in Pseudo 4 is clear, I'll double check
<fantasai> https://drafts.csswg.org/css-pseudo-4/#first-text-line
<emilio> I have a slight preference to not propagate to other BFCs either fwiw
<TabAtkins> fantasai: Yeah, specifies only block containers and multicol
<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?
<TabAtkins> fantasai: trimming curretnly requires first formatted line; trimming in the first line of a multicol and not subsequent is maybe a little weird
<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
<TabAtkins> fantasai: and propagation also considers what happens if you set on an ancestor
<TabAtkins> fantasai: but that currently only affects the first line in the multicol
<emilio> q+
<TabAtkins> fantasai: So I guess we could leave ::first-line/letter, and consider the text-box-trim propagation wrt multicol
<astearns> ack emilio
<TabAtkins> emilio: iirc, Gecko didn't propagate across BFCs
<TabAtkins> emilio: other browsers don't inherit quite right when they propagate, which is weird.
<TabAtkins> emilio: think there's just impl bugs across the board
<TabAtkins> emilio: I have a slight preference for not propagating, because it seems harder to get wrong
<TabAtkins> Note we now have ::column pseudo for some special cases, if that might be helpful
<TabAtkins> dbaron: I think some of the complexity i was referring to was specifically first-line/letter, which are really complicated
<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
<TabAtkins> astearns: yes, don't see a real need to keep them consistent
<TabAtkins> fantasai: yeah, was just a spec editting convenience
<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
<TabAtkins> astearns: makes sense to me
<TabAtkins> astearns: is there any different handling we should do for flex/grid?
<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
<TabAtkins> fantasai: due to alignment/etc
<TabAtkins> fantasai: it's pretty understandable to authors, i think, that it doesn't propagate into flex/grid/tables
<TabAtkins> fantasai: the difference between a BFC root and a normal BFC is a little subtle, and can be triggered by accident
<TabAtkins> fantasai: so i think it makes sense for the behavior to be more transparent there
<TabAtkins> astearns: ok so let's take a resolution on just multicol+text-box-trim
<fantasai> PROPOSED: propagation of text-box-trim from ancestor of multicol works the same as propagation from multicol itself
<florian> +1
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: propagation of text-box-trim from ancestor of multicol works the same as propagation from multicol itself