[css-display] Should all the `inline-foo` and `inline foo` forms be distinct?

[tabatkins]

In #1246 we are provisionally deciding that inline-block and inline flow-root are syntactically distinct (for a legacy reason), so that they can blockify differently. This means that, in particular, writing display: inline flow-root and then asking for the computed value will give you inline flow-root. This no longer matches the other inline-ish values; in pairs like inline-flex/inline flex, they're equivalent, and writing either will get you inline-flex in the computed value (because it's the shortest version of the value).

So the additional question then is whether we're okay with inline-block/inline flow-root being the exception here. There are three options:

1. Leave inline-block/inline flow-root the only pair that is distinct in computed value. (Weird exception for legacy reasons.)
2. Make all the pairs distinct. (The only effect of this distinction in the other pairs is that they'll serialize differently in computed value.)
3. Revert [css-display] Blockification doesn't seem backwards-compatible for inline-blocks #1246 to the other option, so that inline-block/inline-flow-root are back to being identical, and both blockify to block flow. (This fails to preserve the flow-root-ness of inline flow-root, which might be unwanted.)

[FremyCompany]

Not sure if that is smart or not because it's late but maybe we can divide display in three instead of two: <display-outside> <display-inside> <display-mode> where <display-mode> is normal or legacy. Values like inline-foo would transform to legacy inline foo while inline foo would be equivalent to normal inline foo. Then we can use legacy as a parameter for display transforms like blockification and inlinification to accomodate the legacy exceptions we need.

[bzbarsky]

If this is right, maybe it would be better to blockify both to block flow-root

Again, that changes existing behavior for inline-block that gets blockified. It would no longer blockify to block but to flow-root, which affects both computed style (possibly breaking existing scripts) and inheritance (possibly breaking existing layouts that use display: inherit).

[SelenIT]

@bzbarsky, thanks, I realized this after your answer in #1246 and deleted my previous comment as erroneous.

[Loirooriol]

I agree with @FremyCompany that this should be solved by adding a new subpart to the display property. But I would not use normal or legacy, I would make flow-root an independent keyword outside of <display-inside>. This also solves various other problems.

Then, inline-block would be syntactically equivalent to inline-level block and blockify to block. And inline-level flow-root would behave like inline-block but would blockify to flow-root. Both flow-root-ness and syntactically equivalence can be preserved this way.

See the details of my proposal in #1496 and my proposed spec.

[tabatkins]

And I've proposed a slightly different way to handle this in #1496, that also preserves the "all inline-foo forms are equivalent to inline foo" property.

[tabatkins]

This is now moot, as we figured out how to keep "inline-block" and "inline flow-root" acting identically.