[go: nahoru, domu]
Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[css-display] 'flow' inner display type should never establish a BFC #1550

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

[css-display] 'flow' inner display type should never establish a BFC #1550

Loirooriol opened this issue Jun 22, 2017 · 10 comments
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-display-3 Current Work Tracked in DoC

Comments

@Loirooriol
Copy link
Contributor

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
@tabatkins tabatkins added the css-display-3 Current Work label Jul 12, 2017
@frivoal frivoal mentioned this issue Jul 19, 2017
Closed
@Loirooriol Loirooriol mentioned this issue Jul 19, 2017
Closed
@Loirooriol
Copy link
Contributor Author

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

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

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

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

@w3c w3c deleted a comment from Roman0308 Aug 14, 2017
@fantasai
Copy link
Collaborator
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
Copy link
Contributor Author

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.

@fantasai fantasai added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels May 7, 2018
@Loirooriol
Copy link
Contributor Author

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
[css-display-3] Used *inner display type* of flow-root; used 'display…
7214150 
…' might have other values. #1550 (comment)
@fantasai
Copy link
Collaborator

@Loirooriol Fixed, thanks. :)

@css-meeting-bot
Copy link
Member

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

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
Assignees
No one assigned
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-display-3 Current Work Tracked in DoC
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tabatkins @fantasai @Loirooriol @css-meeting-bot