Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tabatkins opened this issue May 31, 2017 · 6 comments
Closed

Comments

@tabatkins
Copy link
Member

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.)
@tabatkins tabatkins added the css-display-3 Current Work label May 31, 2017
@FremyCompany
Copy link
Contributor

FremyCompany commented 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> 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
Copy link

bzbarsky commented Jun 1, 2017

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
Copy link
Collaborator

SelenIT commented Jun 1, 2017

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

@Loirooriol
Copy link
Contributor

Loirooriol commented Jun 2, 2017

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
Copy link
Member Author

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants