Skip to content

[css-grid][css-flexbox] Blockification section should use the computed value, not the box of the element #4065

Closed

Description

@emilio

Right now https://drafts.csswg.org/css-grid/#grid-item-display says:

The display value of a grid item is blockified: if the specified display of an in-flow child of an element generating a grid container is an inline-level value, it computes to its block-level equivalent. (See CSS2.1§9.7 [CSS21] and CSS Display [CSS3-DISPLAY] for details on this type of display value conversion.)

Similarly https://drafts.csswg.org/css-flexbox/#flex-items says:

The display value of a flex item is blockified: if the specified display of an in-flow child of an element generating a flex container is an inline-level value, it computes to its block-level equivalent. (See CSS2.1§9.7 [CSS21] and CSS Display [CSS3-DISPLAY] for details on this type of display value conversion.)

As @Loirooriol pointed out in https://bugzilla.mozilla.org/show_bug.cgi?id=1562039, this doesn't match browsers, and browsers use the computed display value of the closest non-display: contents ancestor, even if the element doesn't become a flex or grid container (due to it being replaced for example, or it being in a display: none subtree).

I think the spec in this case should match browsers in this case, in order to not make style of children depend on layout box construction. This also matches how the CSS 2 fixups work. The root element is blockified even if it's a replaced element or wouldn't generate an inline-level box otherwise.

Activity

  1. Loirooriol commented on Jun 29, 2019

    @Loirooriol
    Contributor

    Also for Houdini Layout with childDisplay = "block". https://drafts.css-houdini.org/css-layout-api/#layout-api-box-tree

  2. added a commit that references this issue on Nov 1, 2019
  3. tabatkins commented on Nov 1, 2019

    @tabatkins
    Member

    Agenda+ for WG resolution on the change. Before the call, do these edits work for you, @emilio?

  4. Loirooriol commented on Nov 1, 2019

    @Loirooriol
    Contributor

    If the computed display value of an element’s nearest ancestor element

    Are pseudo-elements considered to be elements? If you use display: grid on an element, its ::before is blockified. And once display: list-item grid is allowed, and you use it on a ::before, I guess ::before::marker will be blockified too.

  5. tabatkins commented on Nov 1, 2019

    @tabatkins
    Member

    Yes, tree-abiding pseudo-elements live in the element tree.

  6. emilio commented on Nov 13, 2019

    @emilio
    CollaboratorAuthor

    Yes, the edits work for me.

  7. css-meeting-bot commented on Nov 20, 2019

    @css-meeting-bot
    Member

    The CSS Working Group just discussed Blockification section should use the computed value, not the box of the element, and agreed to the following:

    • RESOLVED: Accept edit in https://github.com/w3c/csswg-drafts/issues/4065
    The full IRC log of that discussion <dael> Topic: Blockification section should use the computed value, not the box of the element
    <dael> github: https://github.com//issues/4065
    <dael> astearns: TabAtkins put this on?
    <dael> TabAtkins: This should be quick. We made edits to the issue a few weeks ago. Checked with emilio and he's good. Final call for objections from anyone that's reviewed. It's CR so we need resolution
    <fremy> Just took a look, LGTM
    <dael> TabAtkins: We rephrased blockifcation to talk about display values rather than rely on box tree. Behavior difference is miniscule but makes it easier for impl and more similar to other cases.
    <dael> TabAtkins: If someone hasn't reviewed we can delay now or revisit in future
    <dael> astearns: Looks like we have 3 reviews. Anyone want more time?
    <dael> oriol: Not an objection. I think Houdini custom layout has same problem and needs update.
    <dael> TabAtkins: Probably because Ian copied the text. Can you open an issue pointing at this one and we'll take care of that
    <dael> astearns: Proposed: Accept edit in https://github.com//issues/4065
    <dael> RESOLVED: Accept edit in https://github.com//issues/4065
  8. added
    Commenter SatisfiedCommenter has indicated satisfaction with the resolution / edits.
    on May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions