[csswg-drafts] [css-display][css-ruby] Does inlinification really need recursion?

Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-display][css-ruby] Does inlinification really need recursion? ==
CSS Display defines [inlinification](https://drafts.csswg.org/css-display-3/#inlinify) as such:

> inlinification [...] sets the box’s outer display type, if it is not none or contents, to [...] inline [...]
>
> If a box with a flow inner display type is inlinified, it recursively inlinifies all of its in-flow children, so that no block-level descendants break up the inline formatting context in which it participates.

I think it makes more sense to transform the `flow` inner display type into `flow-root`. That is, transform `block` to `inline-block`. Then the box will be an [atomic inline](https://drafts.csswg.org/css-display-3/#atomic-inline), and thus block-level descendants won't break up the inline formatting context. Recursive inlinification is not needed. 

This seems what Firefox does for ruby. Chrome and Edge don't inlinify at all. https://jsfiddle.net/d1o5k7Ly/1/

It's worth noting that [CSS Ruby](https://drafts.csswg.org/css-ruby-1/#anon-gen-inlinize) says "directly contained"

> Inlinize block-level boxes: Any in-flow block-level boxes directly contained by a ruby container, ruby base container, ruby annotation container, ruby base box, or ruby annotation box are forced to be inline-level boxes, and their display value computed accordingly.

By the way, are inlinization and inlinification synonyms?



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1341 using your GitHub account

Received on Tuesday, 9 May 2017 16:16:07 UTC