[css-contain] Becoming a formatting context

I see various problems with the Becoming a formatting context section.

In some circumstances (See [CSS-CONTAIN-1] or [CSS3-MULTICOL] for examples), an element may need to become a formatting context.

"See" should be lowercase.

Situations that CSS2.1 said produced a block formatting context when in fact they only needed to become a formatting context should be listed here. This includes out-of-flow boxes, and boxes to which overflow applies and is different than visible. Maybe also mention block containers that are not block boxes.

If the element already establishes a formatting context of any kind, this condition is satisfied.

Except for inline formatting contexts! Inline formatting contexts are not contained at all, they are e.g. affected by floats, so contain: layout is not satisfied by a block container that establishes an inline formatting context, it must establish a block formatting context instead.

And what about ruby formatting contexts? I know very little about them, but I don't think establishing a ruby formatting context is enough neither.

I propose:

If the inner display type is flow-root, table, flex or grid, the condition is satisfied.
If the inner display type is flow, it is changed to flow-root.
An element with a ruby inner display type always (not just if the outer display type is different than inline) generates two boxes: a principal box with the inner display type set to flow and the outer display type set to the outer display type of the element, and an inline-level ruby container. "Becoming a formatting context" only affects the principal box, changing its inner display type to flow-root.
Not sure about layout internal types.

This note also needs to be fixed:

Exclusions are able to affect content across formatting context boundaries. (At time of writing, they are the only layout feature that can.)

Maybe it would be better to say that inline (and ruby?) are pseudo-formatting contexts or some thing different than "real" formatting contexts.

Wow, I didn't even notice this section being added. The whole thing makes no sense. For example, it's saying that display: ruby element becomes a display: flow-root when contain: paint is set on it, and that this is a used value time transformation of the display value... which makes no sense because box generation depends on computed values. Then it goes on to define a concept of “becoming a formatting context”, but doesn't explain how this is different from “establishing a formatting context” (which is an established term of art that has a specific meaning as defined in the Display glossary and CSS2.1), nor how that works.

Imho, either this needs a proper definition that makes sense, is appropriate to the issues in paint containment, and doesn't conflict with the rest of CSS, or contain needs to limit itself to appropriate display values so that it's not creating nonsensical layout effects out of thin air.

Origin of section: https://github.com/w3c/csswg-drafts/pull/831/files
Move to Display: https://hg.csswg.org/drafts/rev/49ade53b18a2
Current location: https://drafts.csswg.org/css-display-3/#becoming-formatting-context

@Loirooriol

Then it goes on to define a concept of “becoming a formatting context”, but doesn't explain how this is different from “establishing a formatting context”

As Tab commented in #1581 (comment)

Some elements define that they establish a formatting context; there is no general definition of how to make an arbitrary element establish a formatting context.

If the element already establishes a formatting context of any kind, this condition is satisfied.
Except for inline formatting contexts!

I agree, this exception should be called out.

[...] and that this is a used value time transformation of the display value... which makes no sense because box generation depends on computed values.

Ok, that was the wrong way to go about it. Would there be a problem with simply moving this fix-up to computed value time?

for example, it's saying that display: ruby element becomes a display: flow-root when contain: paint is set on it.

I don't think it is saying that: display: ruby causes the box to be a ruby container, which in turns means it establishes a ruby formatting context. Since it already establishes a formatting context, becoming a formatting content is a no-op:

If the element already establishes a formatting context of any kind, this condition is satisfied.

That said, as @Loirooriol pointed out, this may be insufficient, and we may need to come up with something better.

That said, maybe this should be excluded from css-contain? css-contain already layout and paint containment do not take effect on internal table elements. Maybe ruby elements should be excluded as well? I have a bit of a hard time thinking of legitimate use cases of containment on ruby or ruby parts.

Not sure about layout internal types.

For internal table parts, neither css-contain nor css-multicol invoke "becomes a formatting context". For ruby internal parts, multicol does not, and (as discussed above) maybe contain shouldn't either.

This doesn't mean that we don't need to define what this does, but there is no particular expectation from the current places that invoke this.

[css-multicol] Revert part of a change about formatting contexts

In #1496 there are some ideas about how to treat a ruby that becomes a formatting context. Probably the independent flow-root keyword won't happen, but maybe a new ruby-root inner display type could be added, it would wrap the inline ruby container inside an inline-block or a block BFC-root, depending on the outer display type.

I think it makes sense to exclude contain from applying to layout-internal boxes, because they are internal things with special behaviors, and can be tightly entangled with other boxes in the same FC. But I would not exclude contain from ruby containers, because they are not internal.

Another thing: I initially described this as used value time on the display property, which was wrong because there isn't really such a thing, but the intent behind this attempt was:

Hook into an existing mechanism (the flow-root logic of the display property) to avoid creating a similar but different thing
Don't affect the computed value of the display property, because multicol (which uses this) never did, and other cases that turn things into (B)FCs (such as setting overflow to something other than visible, or the position property, or the float property) also don't affect the computed value of the display property

Regardless of what we do, I do not think that we should affect the computed value of the display property, as that would introduce a behavior change through inheritance. I don't expect that the following code is particularly common, but there's no reason to introduce a breaking change if we can avoid it:

.abs { position: absolute; }
.abs > div { display: inherit; }

This should not result in the nested div having a display flow-root.

Maybe we can just change this to "has the same effect as".

@Loirooriol

I think the approach proposed in #1550 by @Loirooriol is likely to solve this issue as well.

The CSS Working Group just discussed Becoming a formatting context, and agreed to the following resolutions:

RESOLVED: Move "becoming a formatting context" section back to css-contain, mark ruby/inline as open issues to figure out

The full IRC log of that discussion

<fantasai> Topic: Becoming a formatting context
<astearns> github: https://github.com//issues/1457
<fantasai> TabAtkins: big issue is 'contain' property
<fantasai> TabAtkins: which requires element to establish a formatting context
<fantasai> TabAtkins: But it's not meaningful, can't just say it establish a formatting context out of the blue, e.g. an 'inline' can
<fantasai> TabAtkins: can't establish a formatting context
<fantasai> TabAtkins: could say that it turns into an inline-block, tho
<fantasai> TabAtkins: But can't do that to Ruby
<fantasai> TabAtkins: So what should we do here?
<fantasai> TabAtkins: Most cases it's a no-op, grid/table/etc is a no-op
<fantasai> TabAtkins: block has an easy answer: switch to flow-root
<fantasai> TabAtkins: inline has an easy answer: switch to inline-block
<fantasai> TabAtkins: ruby is the only one that has a difficult issue
<fantasai> Florian: In other cases, we haven't had a problem with this
<fantasai> Florian: e.g. 'overflow' doesn't apply to inline/ruby, so don't have to worry about these cases
<fantasai> Florian: similarly column-span only applies to block-level elements, so no problem there
<fantasai> Florian: The only case where we have a problem is 'contain'
<fantasai> Florian: which needed to apply to 'inline' and 'ruby'
<fantasai> Florian: So we need to establish terminology, and oriol's suggestion works for this
<nainar> fantasai: ruby cant block
<astearns> s/cant/can/
<nainar> fantasai: ruby spec defines block ruby. AYOu cant turn into a inline block ruby which is what you were trying to say
<fantasai> Florian: The alternative is to not add terminology for this, and just say that these things blockify and th
<fantasai> (shift that up)
<fantasai> Florian: Might be worth leaving existing places the way they are
<fantasai> Florian: and have 'contain' blockify, and the rest is obvious
<fantasai> Florian: If there's an easy way to define this, then we should, and then call into it ffrom all these places
<fantasai> Florian: Oriol's suggestion solves this case
<fantasai> TabAtkins: So what should we do for ruby
<nainar> fantasai: two solutions here. third one is what you were trying to do - ruby makes an inline block ruby thing. No use case - not a good idea
<nainar> fantasai: second thing we could do - florian mentioned to blocify ruby and the inline. That is inconsitent with inline block. They get to stay as inline-blocks
<nainar> fantasai: weird to have ruby turn into a block element
<nainar> fantasai: you could turn all inline level things into block level things
<nainar> fantasai: last thing, this aspect of contain doesnt apply to inline/ruby - the author should change it into a block first. Author then chooses to make the display transformation
<fantasai> TabAtkins: No reason not to apply contain to inline-block
<fantasai> TabAtkins: you mentioned block ruby
<nainar> fantasai: confirms that if you specify display block ruby you get a block with ruby inside it
<fantasai> fremy: ruby does special alignment things
<fantasai> Florian, fantasai: it's not different from iline
<fantasai> inline
<fantasai> TabAtkins: Can we make block ruby a BFC?
<fantasai> TabAtkins: Only thing is that if you have a float, it won't intrude the way it does for regular blocks
<fantasai> Rossen: No reason to have inline layout of ruby be different from regular inline layout
<nainar> fantasai: why not go with the last option?
<fantasai> TabAtkins: ...
<nainar> fantasai: to apply to neither inline/ruby - you the author must turn it into an inline-block or block (preferred)
<fantasai> TabAtkins: Ok, I'm down with that
<fantasai> s/preferred/depending on the author's preference/
<fantasai> dbaron: Issue is that contain is that authors won't know what effects to get
<fantasai> TabAtkins: Then it's a no-op, they're putting it there for trash reasons
<fantasai> fremy: They're not getting worse performance
<fantasai> ...
<fantasai> dbaron: Elements nested inside each other, and accidentally stuck property on inline instead of the inline-block
<fantasai> fremy: dom inspector can show that it doesn't apply
<fantasai> astearns: What if they applied it to a box that was block, and then changed it to an inline and now they lose the perf benefits
<nainar> fantasai: keep in mind that if you had a contain on there - when you turned it into an inline you would not get the layout you expected.
<nainar> fantasai: if we didnt ignore it we would be forcing it into an inline then
<fantasai> fremy: Your question is like someone getting perf benefit from ? and then turning it off and wondering why benefit is gone...
<fantasai> astearns: I like the fact that 'contain' doesn't have the blockification transformation
<fantasai> TabAtkins: That would be a significant layout change, whereas for other things its relatively minor
<fantasai> Florian: After understandign it, you used oriol's terminology, so regardless of whether we become an FC, i would support adopting oriol's terminology
<fantasai> Florian: It seems to me that we are getting closer to fantasai's position, which is to not define the idea of becoming an FC, and for all the situations except contain that may have been ambiguous it was good enough
<fantasai> Florian: and for contain we will eliminate the problematic situations so that it is also good enough
<fantasai> TabAtkins: First resolution is for 1457, which is "what does it mean to become a formatting context"
<fantasai> TabAtkins: resolution is that blocks become flow roots, inlines and rubies can't establish a formatting context, and so any property that tries ot nvoke this must exclude them somehow
<fantasai> TabAtkins: so we will change 'contain' accordingly
<fantasai> astearns: dbaron?
<fantasai> dbaron: I think ppl often have a bunch of nested elements and the display types are pretty random, and that usually just work
<fantasai> TabAtkins: Kinda, until people are like "why is there a 2px gap below this thing?" and it's because they have an inline-block instead of a block
<fantasai> TabAtkins: You have to learn that
<fantasai> Florian: Or fix it with margin-bottom: -2px :D
<fantasai> T_T
<fantasai> dbaron: If they have a baseline, won't have that problem tho
<fantasai> dbaron: only if they fail to have a baseline
<fantasai> astearns: So we could resolve on what Tab said, or resolve part of it
<Loirooriol> Hi CSSWG, what about 'block ruby'? The block container could establish a BFC.
<fantasai> astearns actually just asked that question to dbaron, didn't get a chance to type it yet :)
<fantasai> 2nd question was also asked earlier, no answer yet
<fantasai> dbaron: I'm okay with resolving but kinda concerned about making 'contain' even more random
<fantasai> dbaron: I think one thing that is hard about web dev is that it's hard to understand perf effects of things
<fantasai> dbaron: Part of why contain is useful is it provides a way to make them more predictable
<fantasai> dbaron: by forcing various types of isolation
<TabAtkins> Loirooriol, It would be rather unfortunate if it was impossible to have block-ruby flow around a float; there's no reason to restrict that.
<fremy> q+
<fantasai> dbaron: If you make contain less reliable, then you're back to unreliable
<fantasai> fremy: I have a solution
<astearns> ack fremy
<fantasai> fremy: display: none
<fantasai> fremy: then author will find out it's a problem
<fantasai> fantasai: we don't do dataloss by default
<fantasai> s/solution/solution but no one will like it/
<fantasai> Florian: Do we also need to stop confusing formatting contexts and formatting contexts?
<fantasai> TabAtkins: not directly relevant
<Loirooriol> Tabatkins, I meant only when 'contain' needs a formatting context
<TabAtkins> Loirooriol, then there's no way to create a block-ruby FC without side-effects. :(
<fantasai> s/without/without using/ ? :)
<fantasai> TabAtkins: Thinking to leave 'contain' issue undef for now
<fantasai> TabAtkins: or figure out something for ruby
<fantasai> TabAtkins: or say that contain doesn't apply to inline ruby
<fantasai> TabAtkins: which do you like best?
<fantasai> dbaron: I guess I don't feel that strongly
<astearns> s/inline ruby/inline and ruby/
<fantasai> dbaron: I think you could say they become inline flow root or ...
<nainar> fantasai: I think we imply ... the container
<nainar> fantasai: I think if you turn display:ruby into flow-root you will.. Ruby does the same thing as table.
<nainar> fantasai: set display:flow-root on a ruby element you will get a block ruby BFC - all boxes in ruby will generate correctly.
<nainar> TabAtkins: you get a contained block and all the perf benefits there
<nainar> fantasai: you have sideeffects like we turn of inlinification
<fremy> s/of/off
<nainar> fantasai: you have block boxes inside a ruby container they inlineify. They wont anymore
<nainar> fantasai: there will be some differences in behaviour.
<nainar> fantasai: it woudl break the case of not using rb elements to wrap bases?
<nainar> fantasai: because parent is no longer ruby container
<nainar> fantasai: scooping algo would ...
<fantasai> s/.../not scoop up ruby bases that aren't in explicit elements/
<fantasai> TabAtkins: Then let's go ahead and do Loirooriol's thing of having "used value of flow-root" terminology for all of our BFCs
<fantasai> astearns: Any resolution for becoming a formatting context?
<fantasai> TabAtkins: not yet
<fantasai> astearns: proposed resolution to take Oriol's proposal in 1550
<fantasai> TabAtkins: This is just an editorial change
<fantasai> RESOLVE: Accept 1550
<fantasai> s/RESOLVE/RESOLVED/
<fantasai> fantasai: Could say that the "becoming a formatting context" section is css-contain's problem, remove it from css-display
<fantasai> TabAtkins: yeah, since it's no longer affecting anythng other than contain
<fantasai> TabAtkins: so let's move to 'contain' spec, mark ruby and stuff as open issues
<fantasai> RESOLVED: Move "becoming a formatting context" section back to css-contain, mark ruby/inline as open issues to figure out

[css-contain][css-align][css-multicol][css-rhythm] Link to exported term

[css-contain] layout and paint containment do not apply to non-atomic…

[css-contain][css-align][css-multicol][css-rhythm] Link to exported term

[css-contain] Terminology clean up: **establish** a formatting context

[css-display][various] Split out 'independent FC' from 'new FC' and r…

The Working Group just discussed Establishing independent formatting contexts, and agreed to the following:

RESOLVED: accept the edits

The full IRC log of that discussion

<dael> Topic: Establishing independent formatting contexts
<dael> github: https://github.com//issues/1457#issuecomment-380357179
<dael> fantasai: THere was an action to clarify what a formatting context is and how established.
<fantasai> https://drafts.csswg.org/css-display-3/#formatting-context
<dael> fantasai: re-wrote the definition ^ and added a defintion for independent formatting context. Example ruby isn't really independent. Inline isn't independent of block
<dael> fantasai: Created the new term, did a lot of edits. Independent is what css-contain is trying to do.
<dael> florian: I reviewed it, I like it.
<dael> Rossen: Anyone else reivew?
<dael> Rossen: Anyone want to review before resolving?
<fantasai> changeset is https://github.com/w3c/csswg-drafts/commit/94982e838a558e6c66516b3b13e403eae32e27ad
<dael> [silence]
<dael> Rossen: Objections to accepting the edits
<dael> RESOLVED: accept the edits

Navigation Menu

Repository navigation

[css-contain] Becoming a formatting context #1457

29 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-contain] Becoming a formatting context #1457

Description

Activity

Loirooriol commented on May 24, 2017

fantasai commented on Jul 5, 2017

frivoal commented on Jul 7, 2017

Loirooriol commented on Jul 7, 2017

frivoal commented on Jul 19, 2017

frivoal commented on Jul 19, 2017

css-meeting-bot commented on Aug 3, 2017

29 remaining items

css-meeting-bot commented on May 23, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions