[css-display] Blockification doesn't seem backwards-compatible for inline-blocks

What happens if I absolutely position an inline-block? Per current browser behavior it becomes a "block". Per the css-display-3 draft it becomes a "flow-root", if blockification only affects display-outside. Is that a purposeful behavior change?

Not an intentional change. :(

I believe this is fixed in 4d50007

Please re-open if that's not the case and there's something I missed.

I think one of us is missing something, but I'm not sure whether it's me or you. ;)

Per the table at https://www.w3.org/TR/css-display-3/#legacy-display 'inline-block' "behaves as 'inline flow-root'". But per https://www.w3.org/TR/css-display-3/#the-display-properties the computed value of 'display' is the specified value... So if I have 'inline-block' specified, it computes to 'inline-block', not 'inline flow-root'. OK, fine.

But then https://www.w3.org/TR/css-display-3/#transformations talks about just changing the outer display to 'block' and does not change the inner display. What does that actually mean in terms of the computed value? I see a few options:

The precomposed value is decomposed to two keywords, the outer display is changed to 'block', and the new computed value is the resulting two-keyword value. That would give 'block flow-root'.
The precomposed value is decomposed to two keywords, the outer display is changed to 'block', and the new computed value is the precomposed value that corresponds to the new two-keyword value. That would give 'flow-root'.
The computed value is 'block'. This is what browsers do right now, but I see no way to get there via the spec as currently written.

Note that the used value is likely 'block flow-root' in all cases, because things that cause blockification also lead to flow-root behavior. The question is what the computed value is.

The spec says "Computed value: as specified". So the display property sets the display type, but transformations of the display type don't affect the computed value of display. That's how I read it, but clearly it's not what browsers do.

The spec also explicitly says that the transformations transform the computed value. Yes, the spec is kinda self-contradictory; not the first time.

Okay, so, there are two ways we can handle this:

Treat inline-block and inline flow-root as syntactically equivalent. Make both of them blockfy as display: block.
Treat inline-block and inline flow-root as syntactically distinct. Make inline-block blockify as display: block; inline flow-root will blockify as flow-root.

The advantage of the first approach is that the various inline-foo models are all syntactic equivalents of their two-keyword inline foo forms. This is a nice consistency to have.

The advantage of the second approach is that, aside from the inline-block keyword itself, everything maintains its display type as specified with the mere substitution of block for inline or run-in (and shortening of serialized output per normal CSSOM rules).

Is there a reason to prefer one solution over the other?

Note that the used value is likely 'block flow-root' in all cases, because things that cause blockification also lead to flow-root behavior.

I believe that the quoted part is really important. Before flow-root value was introduced, using block as a value to use/report and describing that it also establishes the new BFC in prose was the only option. Now, when we have the value that describes both things, what stops us from using flow-root for both computed and used values in all the relevant cases (except legacy reasons)?

The computed value affects not just what's "reported", but also what's inherited.

So if you have a thing that gets blockified and a child that has "display: inherit", should that child end up as a flow root or not? Why or why not?

(And of course "legacy reasons" might trump everything else in practice.)

Inheritance isn't even a big deal, honestly (who the hell writes display: inherit? don't tell me, it'll just depress me).

The big deal is serialization; things that used to serialize to "block" have to continue to do so, but if they become block flow-root they'll serialize to "flow-root" instead.

Future things that blockify might want to explicitly FC-ify as well, which can change the serialization just fine, but we have a lot of legacy to think about.

Thinking about this more, I have some very strong reservations to the resolution recorded here. Specifically, because we do some automatic transformations (as when 'writing-mode' or ruby fixup turns things into inline blocks), and a) it's not clear to me which serialization we choose or why and also b) it creates an opportunity for inconsistencies across the specs, if different ones choose different serializations here.

WG resolution: https://lists.w3.org/Archives/Public/www-style/2017Aug/0042.html

if an inline flow-root box is blockified, it becomes a block box (losing its flow-root nature).

I think blockifications should trigger becoming a formatting context to ensure that flow-root is not really lost (at used value time).

Navigation Menu

Repository navigation

[css-display] Blockification doesn't seem backwards-compatible for inline-blocks #1246

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-display] Blockification doesn't seem backwards-compatible for inline-blocks #1246

Description

Activity

fantasai commented on Apr 19, 2017

fantasai commented on Apr 19, 2017

bzbarsky commented on Apr 19, 2017

Loirooriol commented on Apr 20, 2017

bzbarsky commented on Apr 20, 2017

fantasai commented on May 15, 2017

3 remaining items

SelenIT commented on Jun 1, 2017

bzbarsky commented on Jun 1, 2017

tabatkins commented on Jun 1, 2017

fantasai commented on Jul 5, 2017

fantasai commented on Mar 19, 2018

Loirooriol commented on Mar 19, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions