I was drawing a diagram to understand the CSS Display transformations after the F2F resolutions and how a hypothetical ruby-root could fit in there.
I noticed that it's not clear how run-in flow-root should blockify, and you didn't discuss this in the F2F.
It was resolved that inline flow-root blockifies to block flow because inline flow-root is syntactically equivalent to inline-block, and inline-block must blockify to block because of backwards compatibility.
A run-in flow-root is basically an inline-block with some special tree munging. So it could make sense to let run-in flow-root be consistent with inline-block and also blockify to block flow.
The other possibility would be to keep it simple and only change the outer display type, i.e. blockify to block flow-root.
In practice, the difference should not matter much because I expect blockifications to trigger becoming a formatting context. But it will affect getComputedStyle, of course.
I don't have a strong opinion, but maybe I prefer consistency with inline flow-root.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3
