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

[css-display] Should 'run-in flow-root' blockify to 'block' or 'flow-root'? #1715

Closed
Loirooriol opened this Issue Aug 10, 2017 · 5 comments

Comments

Projects
None yet
6 participants
@Loirooriol
Collaborator

Loirooriol commented Aug 10, 2017

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.

diagram-small

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.

@tabatkins

This comment has been minimized.

Member

tabatkins commented Mar 19, 2018

Agenda+ to verify making "run-in flow-root" blockify to "block flow", to match the behavior of "inline flow-root" (aka "inline-block").

@tabatkins tabatkins closed this in 4a8afc5 Mar 19, 2018

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Mar 20, 2018

+1 to the above change.

Incidentally, the full table make sense to me, and I'd like to use it as a basis to close #1457. Following up in that issue.

@astearns

This comment has been minimized.

Member

astearns commented Apr 3, 2018

reopening for the agenda+

@astearns astearns reopened this Apr 3, 2018

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Apr 4, 2018

The Working Group just discussed Blockifying 'run-in flow-root' to 'block' (for consistency with inline-block), and agreed to the following resolutions:

  • RESOLVED: Run-in flow-root blockifies to block and not flow root
The full IRC log of that discussion <dael_> Topic: Blockifying 'run-in flow-root' to 'block' (for consistency with inline-block)
<dael_> github: https://github.com//issues/1715
<dael_> florian: Was an alternative considered? I can't think of one.
<dael_> TabAtkins: It's the question in the title. Should it blockify to flow-root. It shouldn't.
<dael_> TabAtkins: An inline flow root blockifies to an ordinary block. This is for legacy reasonings. A run-in flow-root needs to blockify somehow. The general rule for run-in they're identical to inlines. Thus it shoudl blockify the same as inlines.
<dael_> TabAtkins: Alternative is if blockifies to flow-root which makes sense in abstract, but we'd loose the connection to inline.
<dael_> florian: Consistancy argument wins or theoretical purity
<dael_> astearns: Run in flow root blockifies to block and not flow root
<dael_> astearns: Obj?
<dael_> RESOLVED: Run-in flow-root blockifies to block and not flow root

@css-meeting-bot css-meeting-bot removed the Agenda+ label Apr 4, 2018

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Apr 4, 2018

Just for reference, this is the updated table:

diagram-small2

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