- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Aug 2017 15:03:30 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Becoming a formatting context<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1457<br> <fantasai> TabAtkins: big issue is 'contain' property<br> <fantasai> TabAtkins: which requires element to establish a formatting context<br> <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<br> <fantasai> TabAtkins: can't establish a formatting context<br> <fantasai> TabAtkins: could say that it turns into an inline-block, tho<br> <fantasai> TabAtkins: But can't do that to Ruby<br> <fantasai> TabAtkins: So what should we do here?<br> <fantasai> TabAtkins: Most cases it's a no-op, grid/table/etc is a no-op<br> <fantasai> TabAtkins: block has an easy answer: switch to flow-root<br> <fantasai> TabAtkins: inline has an easy answer: switch to inline-block<br> <fantasai> TabAtkins: ruby is the only one that has a difficult issue<br> <fantasai> Florian: In other cases, we haven't had a problem with this<br> <fantasai> Florian: e.g. 'overflow' doesn't apply to inline/ruby, so don't have to worry about these cases<br> <fantasai> Florian: similarly column-span only applies to block-level elements, so no problem there<br> <fantasai> Florian: The only case where we have a problem is 'contain'<br> <fantasai> Florian: which needed to apply to 'inline' and 'ruby'<br> <fantasai> Florian: So we need to establish terminology, and oriol's suggestion works for this<br> <nainar> fantasai: ruby cant block<br> <astearns> s/cant/can/<br> <nainar> fantasai: ruby spec defines block ruby. AYOu cant turn into a inline block ruby which is what you were trying to say<br> <fantasai> Florian: The alternative is to not add terminology for this, and just say that these things blockify and th<br> <fantasai> (shift that up)<br> <fantasai> Florian: Might be worth leaving existing places the way they are<br> <fantasai> Florian: and have 'contain' blockify, and the rest is obvious<br> <fantasai> Florian: If there's an easy way to define this, then we should, and then call into it ffrom all these places<br> <fantasai> Florian: Oriol's suggestion solves this case<br> <fantasai> TabAtkins: So what should we do for ruby<br> <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<br> <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<br> <nainar> fantasai: weird to have ruby turn into a block element<br> <nainar> fantasai: you could turn all inline level things into block level things<br> <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<br> <fantasai> TabAtkins: No reason not to apply contain to inline-block<br> <fantasai> TabAtkins: you mentioned block ruby<br> <nainar> fantasai: confirms that if you specify display block ruby you get a block with ruby inside it<br> <fantasai> fremy: ruby does special alignment things<br> <fantasai> Florian, fantasai: it's not different from iline<br> <fantasai> inline<br> <fantasai> TabAtkins: Can we make block ruby a BFC?<br> <fantasai> TabAtkins: Only thing is that if you have a float, it won't intrude the way it does for regular blocks<br> <fantasai> Rossen: No reason to have inline layout of ruby be different from regular inline layout<br> <nainar> fantasai: why not go with the last option?<br> <fantasai> TabAtkins: ...<br> <nainar> fantasai: to apply to neither inline/ruby - you the author must turn it into an inline-block or block (preferred)<br> <fantasai> TabAtkins: Ok, I'm down with that<br> <fantasai> s/preferred/depending on the author's preference/<br> <fantasai> dbaron: Issue is that contain is that authors won't know what effects to get<br> <fantasai> TabAtkins: Then it's a no-op, they're putting it there for trash reasons<br> <fantasai> fremy: They're not getting worse performance<br> <fantasai> ...<br> <fantasai> dbaron: Elements nested inside each other, and accidentally stuck property on inline instead of the inline-block<br> <fantasai> fremy: dom inspector can show that it doesn't apply<br> <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<br> <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.<br> <nainar> fantasai: if we didnt ignore it we would be forcing it into an inline then<br> <fantasai> fremy: Your question is like someone getting perf benefit from ? and then turning it off and wondering why benefit is gone...<br> <fantasai> astearns: I like the fact that 'contain' doesn't have the blockification transformation<br> <fantasai> TabAtkins: That would be a significant layout change, whereas for other things its relatively minor<br> <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<br> <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<br> <fantasai> Florian: and for contain we will eliminate the problematic situations so that it is also good enough<br> <fantasai> TabAtkins: First resolution is for 1457, which is "what does it mean to become a formatting context"<br> <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<br> <fantasai> TabAtkins: so we will change 'contain' accordingly<br> <fantasai> astearns: dbaron?<br> <fantasai> dbaron: I think ppl often have a bunch of nested elements and the display types are pretty random, and that usually just work<br> <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<br> <fantasai> TabAtkins: You have to learn that<br> <fantasai> Florian: Or fix it with margin-bottom: -2px :D<br> <fantasai> T_T<br> <fantasai> dbaron: If they have a baseline, won't have that problem tho<br> <fantasai> dbaron: only if they fail to have a baseline<br> <fantasai> astearns: So we could resolve on what Tab said, or resolve part of it<br> <Loirooriol> Hi CSSWG, what about 'block ruby'? The block container could establish a BFC.<br> <fantasai> astearns actually just asked that question to dbaron, didn't get a chance to type it yet :)<br> <fantasai> 2nd question was also asked earlier, no answer yet<br> <fantasai> dbaron: I'm okay with resolving but kinda concerned about making 'contain' even more random<br> <fantasai> dbaron: I think one thing that is hard about web dev is that it's hard to understand perf effects of things<br> <fantasai> dbaron: Part of why contain is useful is it provides a way to make them more predictable<br> <fantasai> dbaron: by forcing various types of isolation<br> <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.<br> <fremy> q+<br> <fantasai> dbaron: If you make contain less reliable, then you're back to unreliable<br> <fantasai> fremy: I have a solution<br> <astearns> ack fremy<br> <fantasai> fremy: display: none<br> <fantasai> fremy: then author will find out it's a problem<br> <fantasai> fantasai: we don't do dataloss by default<br> <fantasai> s/solution/solution but no one will like it/<br> <fantasai> Florian: Do we also need to stop confusing formatting contexts and formatting contexts?<br> <fantasai> TabAtkins: not directly relevant<br> <Loirooriol> Tabatkins, I meant only when 'contain' needs a formatting context<br> <TabAtkins> Loirooriol, then there's no way to create a block-ruby FC without side-effects. :(<br> <fantasai> s/without/without using/ ? :)<br> <fantasai> TabAtkins: Thinking to leave 'contain' issue undef for now<br> <fantasai> TabAtkins: or figure out something for ruby<br> <fantasai> TabAtkins: or say that contain doesn't apply to inline ruby<br> <fantasai> TabAtkins: which do you like best?<br> <fantasai> dbaron: I guess I don't feel that strongly<br> <astearns> s/inline ruby/inline and ruby/<br> <fantasai> dbaron: I think you could say they become inline flow root or ...<br> <nainar> fantasai: I think we imply ... the container<br> <nainar> fantasai: I think if you turn display:ruby into flow-root you will.. Ruby does the same thing as table.<br> <nainar> fantasai: set display:flow-root on a ruby element you will get a block ruby BFC - all boxes in ruby will generate correctly.<br> <nainar> TabAtkins: you get a contained block and all the perf benefits there<br> <nainar> fantasai: you have sideeffects like we turn of inlinification<br> <fremy> s/of/off<br> <nainar> fantasai: you have block boxes inside a ruby container they inlineify. They wont anymore<br> <nainar> fantasai: there will be some differences in behaviour.<br> <nainar> fantasai: it woudl break the case of not using rb elements to wrap bases?<br> <nainar> fantasai: because parent is no longer ruby container<br> <nainar> fantasai: scooping algo would ...<br> <fantasai> s/.../not scoop up ruby bases that aren't in explicit elements/<br> <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<br> <fantasai> astearns: Any resolution for becoming a formatting context?<br> <fantasai> TabAtkins: not yet<br> <fantasai> astearns: proposed resolution to take Oriol's proposal in 1550<br> <fantasai> TabAtkins: This is just an editorial change<br> <fantasai> RESOLVE: Accept 1550<br> <fantasai> s/RESOLVE/RESOLVED/<br> <fantasai> fantasai: Could say that the "becoming a formatting context" section is css-contain's problem, remove it from css-display<br> <fantasai> TabAtkins: yeah, since it's no longer affecting anythng other than contain<br> <fantasai> TabAtkins: so let's move to 'contain' spec, mark ruby and stuff as open issues<br> <fantasai> RESOLVED: Move "becoming a formatting context" section back to css-contain, mark ruby/inline as open issues to figure out<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-319996309 using your GitHub account
Received on Thursday, 3 August 2017 15:03:31 UTC