New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-contain] Becoming a formatting context #1457

Closed
Loirooriol opened this Issue May 23, 2017 · 27 comments

Comments

@Loirooriol
Collaborator

Loirooriol commented May 23, 2017

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.
@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented May 24, 2017

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.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Jul 5, 2017

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

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Jul 7, 2017

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.

frivoal added a commit to frivoal/csswg-drafts that referenced this issue Jul 7, 2017

[css-multicol] Revert part of a change about formatting contexts
Stating that the element establishes a new formatting context, without
saying what kind of formatting context it needs to establish is not
specific enough. Also, saying that it must establish a "new" formatting
context is ambiguous or misleading for elements that would establish one
anyway.

The current definition of "becomes a formatting context" is
problematic (see w3c#1457), so we
need to fix it, but it is precisely aimed at solving this: defining what
kind of formatting context to establish for the boxes that wouldn't
otherwise, and being clear about which boxes are fine as is and don't
need to be changed.
@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Jul 7, 2017

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.

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Jul 19, 2017

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".

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Jul 19, 2017

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

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Aug 3, 2017

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
@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Aug 3, 2017

I'm confused, if in #1550 you approved that flow never establishes a BFC (but it can be switched to flow-root via "becoming a formatting context"), shouldn't "becoming a formatting context" remain in CSS Display?

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Aug 6, 2017

possibly, but we haven't figured out what to do with ruby yet, and don't want to block the display spec on something that only matters for css-contain. Once we figure it out, it is possible it will make its way back to the display spec.

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Aug 6, 2017

But after #1550 I don't think this is only a css-contain problem. Now if flow ends up establishing a BFC that's via becoming a formatting context, and I don't see why it should be different for ruby. So if you float a ruby then it also becomes a formatting context. If you use overflow: hidden on a block-level ruby it also becomes a formatting context. If you make a ruby be a flex or grid item it also becomes a formatting context.

Now I'm more convinced that this should be explained by adding a new inner display type: ruby-root. Becoming a formatting context would switch ruby to ruby-root at used-value time. Exposing this inner display type in <display-inside> syntax is not necessary, for the moment it could be kept as an internal thing of the spec.

This should all be CSS Display things, then in CSS Contain you can decide whether contain applies to ruby or whether the ruby is blockified when contained.

@tabatkins

This comment has been minimized.

Member

tabatkins commented Aug 7, 2017

That might end up being how we solve it, yes, but in the meantime we don't need to worry about it, because aside from Contain, every instance of something becoming a formatting context also blockifies it.

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Sep 22, 2017

The above resolution (moving the definion back to css-contain and noting an issue about ruby) is done. We still need to resolve that issue.

@frivoal frivoal added the Agenda+ F2F label Nov 3, 2017

@astearns astearns removed the Agenda+ F2F label Nov 6, 2017

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Nov 7, 2017

The Working Group just discussed becoming a formatting context root.

The full IRC log of that discussion <fantasai> Topic: becoming a formatting context root
<astearns> github: https://github.com//issues/1457
<fantasai> TabAtkins: we addressed this a bit in the past, text we had was bad
<fantasai> TabAtkins: layout containment needs a formatting context root
<fantasai> TabAtkins: wanted to say that the element ends up being an FC root somehow
<fantasai> TabAtkins: only a few places where that's difficult
<fantasai> TabAtkins: Some are easy
<fantasai> TabAtkins: flow root, table, flex, grid, all satisfy condition
<fantasai> TabAtkins: for display: flow, becomes flow-root
<fantasai> TabAtkins: Next issue is with ruby
<fantasai> TabAtkins: ruby is effectively inline element
<fantasai> TabAtkins: wanted to create a ruby inline block thing
<fantasai> florian: we don't have that yet. If it's not useful, do we really want to add it?
<fantasai> TabAtkins: Better to fill the boxes, so this is consistent and defined
<fantasai> fantasai: How about saying layout containment doesn't apply to inlines. If you want it to apply, turn it into an inline block
<fantasai> Xidorn: create a wrapper box?
<fantasai> TabAtkins: wrapper boxes are scary and bad
<fantasai> fantasai: We have block ruby, it just creates a wrapper
<fantasai> TabAtkins: Make something block-like, either inline-block or block or somehting
<fantasai> fantasai: For most of these layout modes, the FCR-ification doesn't have much effect. Layout is fundamentally the same
<fantasai> fantasai: but for inlines and ruby, it's a very significant change to layout
<fantasai> fantasai: I'd rather say that layout containment just doesn't apply here, so the author is making an explicit decision about the layout change they're getting
<fantasai> TabAtkins: My two constraints for this problem is that contain should work on ruby because it works on inline, and that whatever effect it has should be possible to get without using 'contain' for its side-effect
<fantasai> florian: Suggestion is to apply contain to neither inline nor ruby
<fantasai> fantasai: that is my suggestion, yes
<fantasai> astearns: We don't have contain and inline ruby
<fantasai> astearns: is there a use case for contain on inlines?
<fantasai> fantasai: You can't get that. It turns into inline-block
<fantasai> astearns: So if we do this, what do we lose?
<fantasai> TabAtkins: Just that authors have to take an extra step of declaring inline-block
<fantasai> fantasai: I'm arguing that's a feature, not a bug
<astearns> s/if we do this/if we choose not to apply contain to inlines/
<fantasai> fantasai: If the author wants to have an inline block, should be explicit about it. if they didn't, then they're not going to be happy anyway
<fantasai> TabAtkins: internal table elements?
<fantasai> florian: We already resolved they don't apply
@fantasai

This comment has been minimized.

Contributor

fantasai commented Nov 7, 2017

My preference here would be to say that layout containment doesn't apply to inlines or ruby, just like it doesn't apply to internal table elements. Turning blocks into BFCs is straightforward, a lot of other CSS properties do it as a side-effect, and it doesn't change layout much. But turning an inline into inline-block or ruby into inline-block-ruby-thing would make a major difference to the layout, and I think that if the author wants that they should be requesting it explicitly. Making it a side effect of a perf tweak doesn't make much sense to me.

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Nov 7, 2017

OK, but note that contain is not the only reason that makes ruby-root desirable.

For example, flow-root was supposed to kill the overflow: hidden hack, but if people can't use display: block ruby-root I think they will use display: block ruby; overflow: hidden.

Additionally, someone may use block ruby because they want to use height or width. But if the element is inlinified (e.g. it's inside a run-in), then it will become inline ruby and will stop generating a block container. Just like block flow inlinifies to inline flow-root, block ruby should inlinify to inline flow-root (#1700).

I agree wrapper boxes are not much desirable, but since there already is block ruby, I think we should go all the way and cover all cases.

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Mar 20, 2018

@fantasai But then the inlinification of a block ruby is not consistent with the inlinification of block flow. And people will continue using overflow: hidden or clearfix hacks just to have a block ruby with a BFC. And when a block ruby is forced to establish a BFC, this can't be explained in terms of display at used-value time. This is not nice.

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Mar 21, 2018

I think I'm not opposed to making contain not apply to inline or ruby boxes. This isn't sort of the same layout with optimization-friendly tweaks turned on, but a radically different layout, so if an author wants that, they should ask for it. Maybe somebody has good use cases though, we could try to do some outreach, see if people have good reasons for wanting it to apply, and decide against it if not.

Either way, I still think we should define the whole table. To me it really seems to be an underlying concept that's slowly emerging as various specs expose various aspects of it. Defining the full model would give us a more solid foundation for spec building, avoiding us having to wonder exactly what these different operations mean in different contexts, or to accidentally redefine them incorrectly when we forget to think things through.

Having this table (and the becoming a FC terminology) would have avoided #1071.

It would also have helped steer the discussion about whether contain should apply to inlines/ruby, from "what would that even mean" to "would that be good for authors".

It would allow for more precise wording in the flexbox spec (there's the same thing in grid):

A flex item establishes a new formatting context for its contents. The type of this formatting context is determined by its display value, as usual.

What's "as usual"? → See the table.

Maybe this should also be invoked from the table spec (but then again, tables are weird, so the logic may be different there).

Anyway, that's my reasoning for wanting the table (and the becoming a FC terminology) to exist.

As for exactly what it should say, I am less strongly locked into any particular solution, but I do find @Loirooriol's arguments persuasive.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Mar 21, 2018

@frivoal I don't understand what you're confused about. The type of formatting context is defined by the outer display value; this is explained in css-display-3 under the definition of 'display'. The table screenshotted above does nothing to make this clearer. And “becoming a formatting context” is a seriously awful phrase: a box is not a formatting context.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Mar 21, 2018

@Loirooriol If you come back to me with significant use cases where we need an element to be a block-level ruby container that establishes a new block formatting context, I will reconsider. Until then I don't see any reason why we need to add such a feature. “For completeness” is not sufficient reason to add a new display type. I'm already skeptical that we even need block ruby at all, other than to explain what happens when you blockify it.

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Mar 21, 2018

And “becoming a formatting context” is a seriously awful phrase

@fantasai I complained about the name in #1758, now it's "becoming a formatting context root".

I'm already skeptical that we even need block ruby at all, other than to explain what happens when you blockify it.

I want ruby-root just for the same reason: to explain what happens when it becomes a formatting context root (e.g. via float, position, overflow, contain, etc.) in terms of display types.

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Apr 6, 2018

So, this issue has two problems tangled in:

  1. Should layout containment and paint containment apply to non-atomic inline-level boxes (inline ruby, inline flow, run-in flow, and run-in ruby), and if so, how?

  2. Should we have an anchor term (so far: becomes a formatting context root, could be something else) that defines which formatting context elements establish when they're told they have to establish one?

    2.1. If yes to 2 does that work by altering the computed value of the display property (in a way that involves flow-root / ruby-root, as suggested in @Loirooriol 's tables)

I believe that fantasai's position is:

  1. No: there are no identified use cases
  2. No: it's clear enough already by just saying "must establish a formatting context"

My latest position is:

  1. No: there are no identified use cases

  2. Yes: we're re-defining this in an ad-hoc manner in a number of places, and that this has caused confusion (here) and spec bugs (multicol in #1071, or an older version of css-overflow, both accidentally turning flex containers, grid containers, or tables into BFCs).

    2.1. No: at least not at computed value time, as that is not compatible with existing uses.

If we take fantasai's approach, I should:

  • Drop the becomes a formatting context root
  • state that layout and paint containment have no effects on non-atomic inline-level boxes (inline ruby, inline flow and inline run-in)
  • state that layout and paint containment cause block containers to establish a BFC (with no effect on the computed value of the display property) (and the other type of things it applies to already establish an FC of some kind, so there's no need to say more)

If we take my approach, I should:

  • Rename and rewrite the becomes a FC root section to something like this, to be included in css-display (probably at the end of https://drafts.csswg.org/css-display-3/#formatting-context):

    Specifications may call for an element or box to <dfn export>establish a formatting context</dfn> without further precision as to the type of formatting context or how to do so.
    This operation is not applicable to non-atomic inline-level boxes nor to boxes with a layout-internal display-type. Specifications that invoke this must either exclude such boxes, or to blockify them first.
    If the box is a block container that does not establish a BFC, it is made to establish a BFC. Otherwise, the box already establishes a formatting context, and this operation is a no-op.

    Note: This has no effect on the computed value of the display property.

    Note: If a specification defines a new type of box which are neither non atomic inline level, layout-internal, block containers, or some other display type that establishes a FC, then that specification must define the meaning of this operation for that type of box.

  • state that layout and paint containment have no effects on non-atomic inline-level boxes (inline ruby, inline flow and inline run-in)
  • Also use and link to that terminology:
    • in css-contain to in state that layout and paint containment cause the box they apply estblish a formatting context
    • in css-multicol for column-span
    • in css-overflow for overflow
    • in grid and flexbox for the definition of grid items and flex items instead of "[...] establishes a new formatting context for its contents. The type of this formatting context is determined by its display value, as usual"

Agenda+F2F to hopefully resolve on either of these two proposals (I prefer mine but won't object to fantasai's).

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Apr 6, 2018

does that work by altering the computed value of the display property (in a way that involves flow-root / ruby-root, as suggested in @Loirooriol 's tables)

Only blockifications and inlinifications happen at computed value time. Becoming a FC root happens at used value time.

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Apr 11, 2018

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

  • RESOLVED: layout and paint containment does not apply to non-atomic inlines
  • RESOLVED: clarify the definition of what and how a FC is created
The full IRC log of that discussion <dael> Topic: Becoming a formatting context
<dael> github: https://github.com//issues/1457
<florian> https://github.com//issues/1457#issuecomment-379156461
<dael> florian: Start reading here ^
<dael> florian: We've been discussing for a while, there's something in contain saying things must become a formatting context root. We've been deciding if this is the generic thing that should go in and if yes does it apply to inlines or ruby.
<dael> florian: fantasai has been pushing back for combined reasons. 1) do it make sense to layout and paint containment apply to non-atromic inlines. If yes we have to FC them. If not we shouldn't apply that. I'm reasonably convinced they shouldn't apply to inlines. This is a radically different thing and if you want hte layout ask for it.
<dael> florian: I agree there is no need for containment to apply on these things.
<dael> TabAtkins: Yeah.
<dael> florian: Maybe we can resolve on that?
<dael> Rossen: Prop: Layout containment and paint containment do not apply to non-atomic inlines.
<dael> smfr: THings with more then one box?
<dael> florian: Principle box.
<dael> dbaron: smfr means more then one fragment. I think they would apply to something inside a multicol over many columns. So what that means might be a problem. But if you have layout and size cotnainment for a thing split over multi columns you have to decide how to paginate and that gets interesting.
<dael> TabAtkins: It's either 0 or fixed height.
<dael> dbaron: Do you split arbitrarily or it has to be one piece? You can't use middle line breaks because it's not containing.
<dael> florian: I think containing and fragmenting is a separate discussion we should look at.
<dael> dbaron: File and issue?
<dael> florian: Yes.
<dael> RESOLVED: layout and paint containment does not apply to non-atomic inlines
<dael> florian: Do we need a term for this? There's a bunch of specs that talk about establishing a BFC. In flex is says that you establish a FC and it means blah blah. However in overflow spec when you set it to non-visible it must establish a formatting context. Same with multi column spanners. It's not a new type of FC, we jsut say you need to get one of these.
<dael> florian: In this case when you need to be a FC everything is already one except blocks and blocks become BFCs. We can just say that.
<dbaron> I filed https://github.com//issues/2527 on the fragmentation and contain issue
<dael> florian: What I'd like to have is...have an anchor term that is establish a formatting context because then it says what type of FC it is. We've many times said BFC and that's not what we meant.
<dael> florian: To try and stop from BFC-izing things having a term that does that sounds nice to me.
<dael> florian: fantasai was pushing back against this.
<dael> fantasai: I think it's "establishes a formatting context" and there's a definition for that.
<dael> florian: For what a FC is, but not when you establish one.
<dael> fantasai: Okay. We can add one to display.
<dael> florian: That definition should include that if you invoke that on non-atromic inlines you wrote your spec wrong because you need to blockify them first.
<dael> florian: I've got suggested text.
<dael> fantasai: There's a definition for a new formatting context but it doesn't say type.
<dael> florian: Buy you made the mistake of the wrong kind so if we get it repeatedly wrong.
<dael> fantasai: Some specs have said BFC when they meant FC. We have an anchoring term, if you have a problem with the definition we can adjust.
<dael> fantasai: Specs like multicol were written before flex and grid so writers were thinking about things that aren't blocks.
<dael> Rossen: The definition you're referring so, can you paste a link?
<dael> Rossen: florian if the definition is not enough, then where is your proposed text?
<dael> florian: Toward the bottom of the comment https://github.com//issues/1457#issuecomment-379156461
<dael> florian: [reads]
<dael> fantasai: It's not true. If you try and establish on a table row.
<dael> florian: It doesn't invoke on internal display types.
<dael> TabAtkins: If you're trying to FC [missed]
<dael> florian: I won't block on this, but it seems reasonable to me given that we've made the mistake multiple times after creation of flexbox and grid.
<TabAtkins> TabAtkins: This'll go in the guidance, like "don't blockify and inlinify the same element".
<dael> fantasai: I'd like to put effort into merging the wording.
<dael> Rossen: Let's resolve on clarifying the definition of what and how a FC is created.
<dael> Rossen: Objections?
<dael> RRESOLVED: clarify the definition of what and how a FC is created
<dael> RESOLVED: clarify the definition of what and how a FC is created

@frivoal frivoal closed this in 2a2356d Apr 20, 2018

@frivoal frivoal removed the Needs Edits label Apr 20, 2018

frivoal added a commit to frivoal/csswg-drafts that referenced this issue Apr 20, 2018

[css-contain][css-align][css-multicol][css-rhythm] Link to exported term
These specs used the "establish a [new] formatting context" terminology.
Link to the exported definition now that there is one.

This change is editorial.

This is a follow up on w3c#1457

frivoal added a commit to frivoal/web-platform-tests that referenced this issue Apr 20, 2018

@frivoal frivoal referenced this issue Apr 20, 2018

Merged

Css contain #10549

frivoal added a commit to frivoal/csswg-drafts that referenced this issue May 2, 2018

[css-contain][css-align][css-multicol][css-rhythm] Link to exported term
These specs used the "establish a [new] formatting context" terminology.
Link to the exported definition now that there is one.

This change is editorial.

This is a follow up on w3c#1457

fergald added a commit to fergald/csswg-drafts that referenced this issue May 7, 2018

tabatkins added a commit that referenced this issue May 7, 2018

[css-display][various] Split out 'independent FC' from 'new FC' and r…
…ewrite definitions to be more explicit in general, and edit various specs to properly refer to it. Closes #2597. Fixes #1457 properly.
@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented May 23, 2018

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment