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] 'flow' inner display type should never establish a BFC #1550

Closed
Loirooriol opened this Issue Jun 22, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@Loirooriol
Collaborator

Loirooriol commented Jun 22, 2017

The flow inner display type is completely overloaded, it can generate 4 (!!!) different kinds of boxes: inline box, block container that establishes inline FC, block container that integrates into the parent BFC, or block container that establishes BFC.

So I propose that flow never establishes a BFC. Instead, all cases which require a BFC are handled by switching the inner display type to flow-root at used value time via becoming a formatting context. This would disentangle flow and flow-root. This change should have no effect in practice.

Something like this:

flow

If its outer display type is inline or run-in, and it is participating in a block or inline formatting context, then it generates an inline box.

Otherwise it generates a block container box and integrates its contents into its parent block formatting context.

Note: certain circumstances, such as if the block container does not participate in a block formatting context, require the element to become a formatting context, and thus its inner display type is changed to flow-root.

And in Becoming a formatting context list these triggers:

  • Block containers that are not block boxes
  • Out-of-flow
  • overflow applies and is different than visible
  • The root element
@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Jul 19, 2017

Despite mentioning that a block container can establish an inline formatting context, in the proposed text I forgot about that 😆. Anyways, I think this possibility should also be removed (at least for element-generated block containers), see #1617.

@tabatkins

This comment has been minimized.

Member

tabatkins commented Aug 3, 2017

block container that establishes inline FC, block container that integrates into the parent BFC

I don't see the difference between these two.

inline box

Yup, inline box vs block box is the result of crossing {block, inline}x{flow}. That's fine.

block container that establishes BFC.

We resolved that this makes sense to set at used value; making things establish a formatting context will now resolve "block flow" to "block flow-root" at used-value time.

We're currently keeping "what happens if you make 'inline flow', 'inline ruby', or 'block ruby' establish formatting contexts?" undefined; we'll figure it out what 'contain' does on these elements separately.

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented Aug 3, 2017

I don't see the difference between these two.

  • block container that establishes inline FC

    This box establishes an inline formatting context. Its contents are all inline-level and participate in that inline formatting context.

  • block container that integrates into the parent BFC

    This box establishes no formatting context. Its contents are all block-level and participate in the parent block formatting context.

@tabatkins

This comment has been minimized.

Member

tabatkins commented Aug 4, 2017

We don't make a real distinction between "filled only with inline content" and "filled only with block content". That's all flow layout.

@fantasai

This comment has been minimized.

Contributor

fantasai commented May 7, 2018

Checked in edits to define that “a block container that establishes a new block formatting context is considered to have a used display value of flow-root.” This should be a purely editorial change.

@Loirooriol Let me know if that seems acceptable.
Agenda+ to double-check with the WG that this doesn't break anything. :)

@fantasai fantasai reopened this May 7, 2018

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented May 7, 2018

It's acceptable, but in fact I no longer have a strong opinion about this. I wanted the flow inner display type to never establish a BFC, and explain the cases in which a BFC is needed by saying that the used display value of the generating element has been changed to flow-root.

But this does not work well for display: block ruby, because the principal box may need a BFC due to e.g. overflow: hidden. I wanted to address this with a new ruby-root inner display type (#1700), which was rejected. This means that the establishment of a BFC can't be explained (not exclusively, at least) in terms of the element's display type.

Then, I don't mind noting that if an element with flow inner display type generates a block container that establishes a BFC, the result looks like if the element had a flow-root inner display type. But this doesn't seem to simplify things, which is what I initially wanted.

@Loirooriol

This comment has been minimized.

Collaborator

Loirooriol commented May 8, 2018

Wait, it's not correctly written. It seems to imply that, if you have display: list-item; float: left, display: list-item will behave like display: flow-root, losing the marker.

I think it should say "is considered to have a flow-root inner display type at used-value time".

fantasai added a commit that referenced this issue May 22, 2018

@fantasai

This comment has been minimized.

Contributor

fantasai commented May 22, 2018

@Loirooriol Fixed, thanks. :)

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented May 23, 2018

The Working Group just discussed 'flow' inner display type should never establish a BFC, and agreed to the following:

  • RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020
The full IRC log of that discussion <dael> Topic: 'flow' inner display type should never establish a BFC
<dael> github: https://github.com//issues/1550
<fantasai> https://github.com//issues/1550#issuecomment-387160020
<Rossen> chris, thx :)
<dael> fantasai: Comment ^
<dael> fantasai: We made an edit [reads]
<dael> fantasai: We believe this is editorial and we wanted to flag the WG to confirm it's editorial
<dael> [everyone reads]
<dbaron> I think this may be hard to know until somebody tries implementing this...
<dael> Rossen: You're saying a block container establishing a new fc inner display is flow root
<dael> fantasai: Used inner display of flow root
<dael> Rossen: Unless multicol?
<dael> fantasai: I don't htink we have a display type for multi col. It would presumably have same. We're not changing computed value, jsut used. Currently that's just a concept. Only effect of flow root is it establishes a BFC.
<dael> florian: I think multicol is desc as establishing BFC and I think I filed a bug saying that's weird.
<dael> Rossen: Editorial part seems fine
<dael> Rossen: I'll re-read the spec for multicol.
<dael> Rossen: This particular one seems good
<dael> fantasai: Multicol is difficult because it's a new type of FC. It's not really BFC but there's no display that aligns to it.
<dael> fantasai: I'm wondering what dbaron is concerned about
<dael> dbaron: I just think...I'm not aware of an impl and I think it's complicated and there will be side effects you discover once anybody tries to impl
<dael> fantasai: atm I think no effect on impl. Only time it will start to have an effect is if we start to expose used values through OM
<dael> Rossen: AS it stands...
<dael> fantasai: That's the intent. If there's a different effect on impl it's not editorial
<dael> Rossen: atm it's editorial because there's no impl
<dael> Rossen: Objections to accepting the proposal https://github.com//issues/1550#issuecomment-387160020
<dael> RESOLVED: Accept proposal in https://github.com//issues/1550#issuecomment-387160020
@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented May 23, 2018

The Working Group just discussed Used value of display should convert flow to flow-root for BFC roots.

The full IRC log of that discussion <dael> Topic: Used value of display should convert flow to flow-root for BFC roots
<dael> github: https://github.com//issues/1550#issuecomment-387160020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment