[css-contain] Becoming a formatting context #1457
Comments
|
This note also needs to be fixed:
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 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 Origin of section: https://github.com/w3c/csswg-drafts/pull/831/files |
As Tab commented in #1581 (comment)
I agree, this exception should be called out.
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?
I don't think it is saying that:
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.
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. |
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.
|
In #1496 there are some ideas about how to treat a ruby that becomes a formatting context. Probably the independent I think it makes sense to exclude |
|
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:
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: 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". |
|
I think the approach proposed in #1550 by @Loirooriol is likely to solve this issue as well. |
|
The CSS Working Group just discussed
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 |
|
I'm confused, if in #1550 you approved that |
|
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. |
|
But after #1550 I don't think this is only a css-contain problem. Now if Now I'm more convinced that this should be explained by adding a new inner display type: This should all be CSS Display things, then in CSS Contain you can decide whether |
|
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. |
|
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. |
|
The Working Group just discussed 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 |
|
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. |
|
OK, but note that For example, Additionally, someone may use I agree wrapper boxes are not much desirable, but since there already is |
|
@fantasai But then the inlinification of a |
|
I think I'm not opposed to making 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 It would allow for more precise wording in the flexbox spec (there's the same thing in grid):
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. |
|
@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. |
|
@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 |
@fantasai I complained about the name in #1758, now it's "becoming a formatting context root".
I want |
|
So, this issue has two problems tangled in:
I believe that fantasai's position is:
My latest position is:
If we take fantasai's approach, I should:
If we take my approach, I should:
Agenda+F2F to hopefully resolve on either of these two proposals (I prefer mine but won't object to fantasai's). |
Only blockifications and inlinifications happen at computed value time. Becoming a FC root happens at used value time. |
|
The Working Group just discussed
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 |
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
… inline Reflects the spec changes from w3c/csswg-drafts#1457
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
|
The Working Group just discussed
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 |
I see various problems with the Becoming a formatting context section.
"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
overflowapplies and is different thanvisible. Maybe also mention block containers that are not block boxes.Except for inline formatting contexts! Inline formatting contexts are not contained at all, they are e.g. affected by floats, so
contain: layoutis 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:
flow-root,table,flexorgrid, the condition is satisfied.flow, it is changed toflow-root.rubyinner display type always (not just if the outer display type is different thaninline) generates two boxes: a principal box with the inner display type set toflowand 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 toflow-root.The text was updated successfully, but these errors were encountered: