Repository navigation
[css-display] Should all the inline-foo and inline foo forms be distinct? #1486
Description
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:
- Leave
inline-block/inline flow-rootthe only pair that is distinct in computed value. (Weird exception for legacy reasons.) - Make all the pairs distinct. (The only effect of this distinction in the other pairs is that they'll serialize differently in computed value.)
- Revert [css-display] Blockification doesn't seem backwards-compatible for inline-blocks #1246 to the other option, so that
inline-block/inline-flow-rootare back to being identical, and both blockify toblock flow. (This fails to preserve the flow-root-ness ofinline flow-root, which might be unwanted.)
Activity
FremyCompany commentedon Jun 1, 2017
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>isnormalorlegacy. Values likeinline-foowould transform tolegacy inline foowhileinline foowould be equivalent tonormal 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 commentedon Jun 1, 2017
Again, that changes existing behavior for
inline-blockthat gets blockified. It would no longer blockify toblockbut toflow-root, which affects both computed style (possibly breaking existing scripts) and inheritance (possibly breaking existing layouts that usedisplay: inherit).SelenIT commentedon Jun 1, 2017
@bzbarsky, thanks, I realized this after your answer in #1246 and deleted my previous comment as erroneous.
Loirooriol commentedon Jun 2, 2017
I agree with @FremyCompany that this should be solved by adding a new subpart to the
displayproperty. But I would not usenormalorlegacy, I would makeflow-rootan independent keyword outside of<display-inside>. This also solves various other problems.Then,
inline-blockwould be syntactically equivalent toinline-level blockand blockify toblock. Andinline-level flow-rootwould behave likeinline-blockbut would blockify toflow-root. Bothflow-root-ness and syntactically equivalence can be preserved this way.See the details of my proposal in #1496 and my proposed spec.
tabatkins commentedon Jun 2, 2017
And I've proposed a slightly different way to handle this in #1496, that also preserves the "all
inline-fooforms are equivalent toinline foo" property.tabatkins commentedon Aug 3, 2017
This is now moot, as we figured out how to keep "inline-block" and "inline flow-root" acting identically.