You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-grid][css-flexbox] Blockification section should use the computed value, not the box of the element #4065
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.)
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.
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.
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
Activity
Loirooriol commentedon Jun 29, 2019
Also for Houdini Layout with
childDisplay = "block". https://drafts.css-houdini.org/css-layout-api/#layout-api-box-tree[css-grid-1][css-flexbox-1] Per #4065, rephrase the grid/flex blockif…
tabatkins commentedon Nov 1, 2019
Agenda+ for WG resolution on the change. Before the call, do these edits work for you, @emilio?
Loirooriol commentedon Nov 1, 2019
Are pseudo-elements considered to be elements? If you use
display: gridon an element, its::beforeis blockified. And oncedisplay: list-item gridis allowed, and you use it on a::before, I guess::before::markerwill be blockified too.tabatkins commentedon Nov 1, 2019
Yes, tree-abiding pseudo-elements live in the element tree.
emilio commentedon Nov 13, 2019
Yes, the edits work for me.
css-meeting-bot commentedon Nov 20, 2019
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/4065The 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