You're correct the making them flow-roots prevents the need for recursion, but that ignores that now you have a flow-root. That's not a meaningless change! In particular, it means they won't line-break anymore.

It's worth noting that CSS Ruby says "directly contained"

Which is unfortunate, and should be fixed. Ruby's last update in the relevant area was long before we defined inlinification (but fantasai and I definitely defined it for the purpose of Ruby).

Not a meaningless change, but converting whole subtrees of blocks to inlines seems also very drastic. Well, I don't really care about recursion, but then please update the ruby spec, otherwise it's confusing.

Yup. Pinging @fantasai for verification that Ruby needs updating.

Ruby boxes are supposed to be inline box, and they should share all the characteristic of inline box like kerning.

Recursion isn't really a big issue, because in general content in ruby is expected to be small and shallow, and actually block-in-ruby should be considered a wrong use, which means handling it should not affect normal usecases, and it should be as easy as possible for impl.

So, there are two definitions being considered here:

• Display's definition that blocks are recursively turned into inline boxes
• Ruby's definition that blocks are turned into inline-blocks.

I think either definition is reasonable. Agree with Tab that we should be consistent across ruby and run-ins, but I don't have a compelling reason to prefer one or the other.

So the core point of inlinification is to ensure that nothing can break the inline context it's working in. "block flow-root" elements become "inline flow-root" ("inline-block"), which is fine - they're atomic inlines. But "block flow" naively becomes "inline flow", which still allows descendant blocks to bubble up a break.

The current text solves this by recursing, so that a "block flow" becomes "inline flow", then its children inlinify as well, ensuring there's no visible block descendants.

Instead turning "block flow" into "inline flow-root" also solves this, by hiding any descendant blocks.

Either solution solves the problem. Are there any good use-cases or impl considerations suggesting that we go for one vs the other?

@fantasai points out a strong reason not to use "inline flow-root" - it means that any inline elements inside a ruby will become inline-blocks, unnecessarily preventing linebreaking from occurring on the children, and disrupting inline layout in general (breaks shaping and justification across boundaries, etc).

Okay, so afaict both the Ruby and Display definitions are pretty broken atm. :) Ruby fails to recurse into inlines, which it needs to do in order to suppress line breaks. The Display module turns 'display: block' into 'display: inline' and then recurses into it, which is also problematic because blocks should stay together as a unit.

The CSS Working Group just discussed inlinification, and agreed to the following resolutions:

• RESOLVED: inline-block because they're awesomeish

Cross-linked Ruby to the css-display 'inlinification' definition.

Also, to answer the original question, yes, it needs recursion, because inline boxes should remain untouched by this process.

Since inlinification doesn't affect layout-internal display types (expecting such boxes to be wrapped in an appropriate anonymous inline-level wrapper by the relevant box-fixup rules), I also added ec80a76 to address misparented internal table boxes inside ruby. (We were assuming they'd be considered inline-level due to fixup, but weren't really clear on that since if box fixup hasn't run yet, they aren't.)

CSS Tables L3 already recognizes ruby in determining anonymous table box types.