- From: SelenIT via GitHub <sysbot+gh@w3.org>
- Date: Sat, 10 Jun 2017 22:00:02 +0000
- To: public-css-archive@w3.org
> this does not solve #1246 and #1486 @Loirooriol, you are right, I already realized this myself. This can be kind of worked around by chahging the blockification rule from "preserve the inner display type, change the outer one to `block`" to "take the hyphened shorthand and drop the `inline-` prefix" (so that the `block` part in `inline-block` transparently changes its meaning and starts to refer to outer display type, but otherwise the conversion would _look_ consistent visually, be easy to memorize and match the existing browsers behavior). Technically it will mean that, for legacy reasons, blockification of `inline-block` (and only this value) changes both its outer and inner display types. But I admit that it feels hacky. > it would be nice if inline-block and block had the same inner display type Again, it's hard to disagree. As I was thinking about that, even a more crazy idea came to me: what if we reconsider the `flow-root` value as the _outer_ display type? It effectively changes the way the block interacts with its surroundings, creating an "island" of different formatting context instead of continuing the same formatting context inside it. So it's different from 'block' outer behavior that doesn't create such an "island". And the outer display type of `grid`, `table`, and `flex` is effectively `flow-root` (in this interpretation) rather than `block` — an "island" of different formatting context inside the parent one. Similarly, instead of one inline outer display type we could have two: ordinary `inline`, that continues the parent inline formatting, and, for example, `inline-flow-root`, that creates an "island" with new formatting context. Current `inline` and `ruby` values would have `inline` outer display, but `inline-block` and other `inline-*` values would have `inline-flow-root`. And the inner display of all current `inline`, `block`, `inline-block` and `flow-root` values would be the same (`flow` or its better-sounding synonym), as they differ primarily externally (which box they generate and whether they continue the parent FC or start a new one). This would automatically solve #1457 by introducing `inline-flow-root ruby`. And it would allow things like multi-line flexboxes that join their lines with surrounding lines of text (like inline-blocks, but without rendering inter-element spaces and with all new shiny flexbox alignment/justification options), grids that flow around floats/shapes, etc., in future levels (e.g. `inline flex` instead of the current behavior that would be `inline-flow-root flex`). But when I started think on this idea further, I realized that it also would require some non-intuitive rules for blockification (e.g. `inline-flow-root` would still blockify as `block`, which than would produce the `flow-root` used value). And yes, it's almost the same as to make a new keyword just for the FCness of the element:). But maybe that direction of thinking still may bring something useful? -- GitHub Notification of comment by SelenIT Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307592707 using your GitHub account
Received on Saturday, 10 June 2017 22:00:13 UTC