Re: [csswg-drafts] [css-display] Make 'flow-root' an independent keyword

> what if we reconsider the `flow-root` value as the outer display type?

@SelenIT I also considered this possibility, but discarded the idea because inlines and run-ins may also want a FC. You addressed the former with `inline-flow-root`, but your proposal does not allow a run-in block container.

And yes, serialization is non-intuitive and will still have problem #1486, because you are still limited to 4 values: `{inline, block, inline-flow-root, flow-root} x {flow}` instead of the current `{inline, block} x {flow, flow-root}`.

You could add an inner display like `{inline, block, inline-flow-root, flow-root} x {flow, block}`, but that's 8 values, so `{inline, block} x {flow, block} x {flow-root, ∅}` seems better. This was basically my proposal.

But I like Tab's proposal with 6 values. Maybe the flow-abracadabra names were not the best, but they offer more flexibility to the users, because they can choose how the element will be blockified or inlinified. I don't think they are against that Priority of Constituencies principle. May be clearer with the new proposed names:

 - `block-root`: creates block container that is a BFC root.
 - `block`: creates block container.
 - `flow`: creates an inline box if the outer type is `inline` or `run-in`, otherwise behaves as `block`.

I think it's reasonably intuitive. There can by syntactic equivalences, and blockifications/inlinifications are simply a change of the outer type. Only some handwaving about blockifying `inline` to `block` is needed, e.g. `block flow` might always compute like `block block`, or the blockification could change the inner type only in this case.

-- 
GitHub Notification of comment by Loirooriol
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307596543 using your GitHub account

Received on Saturday, 10 June 2017 23:41:10 UTC