Please define how the various box tree fixups interact (original) (raw)

There are now multiple CSS specs that define various computed display and box tree fixups. For example (this is probably not an exhaustive list):

• https://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level defines a fixup that happens if an inline box contains a block box; note that this does NOT create any anonymous boxes other than ones inlines create anyway.
• Various blockification fixups for flex, grid, being floated, positioned
• Fixups for mismatched writing-mode.
• Fixups for ruby as defined at https://drafts.csswg.org/css-ruby/#box-fixup
• Fixups for tables as defined at https://www.w3.org/TR/CSS21/tables.html#anonymous-boxes

The ordering of this stuff needs to be defined. And yes, it matters, apparently. Some examples of it mattering:

1. Gecko code has comments about how the ruby bits have to come after the grid bits, for certain tests to pass.
2. If you have a block-inside-inline all inside a ruby container, what happens? The ruby things say they happen "after any intermediary anonymous-box fixup", but it's not clear to me whether the anonymous-block thing above counts as "intermediary anonymous-box fixup". If it does, then it seems like the output should be three inline-block boxes, the first containing the first inline, the second being the inlinized block, and the third containing the third inline. If it doesn't, then the output should be a ruby container with a block child.

For the second item, I tested what some UAs do. Testcase:

  <ruby>
    Start
    <span style="border: 10px solid green">
      <div style="background: yellow">Text</div>
    </span>
    End
  </ruby>

Observed behavior: Chrome, Safari, and Edge don't inlinize as far as I can tell, no matter whether the <span> is there. Firefox does inlinize, but does that in some sort of deep traversal and before doing the block-inside-inline fixup, so ends up with a green box around "Text".