[css-align] `justify-items` and anonymous block boxes #11461

Loirooriol · 2025-01-08T23:05:33Z

<!DOCTYPE html>
<div style="width: 200px; justify-items: right; border: solid">
  foo
</div>
<div style="width: 200px; justify-items: right; border: solid">
  foo
  <div></div>
</div>

In Blink it looks like this:

In the 1st case, there is no block-level child to align. In the 2nd case, "foo" gets wrapped inside an anonymous block, which is then aligned by justify-items: right.

But it seems potentially unexpected that appending a block affects the alignment of the inline contents.

Maybe anonymous blocks should get assigned ~~justify-self: start~~justify-self: stretch (or normal)?

The text was updated successfully, but these errors were encountered:

gitspeaks · 2025-01-09T10:40:53Z

Maybe anonymous blocks should get assigned justify-self: start?

But how would you allow aligning 'anonymous blocks' to the end if that's the desired behavior?
If the goal is to align only the 'anonymous blocks' to the end, what other option would you have besides setting justify-items: right on the parent, keeping the current Blink behavior, and explicitly setting justify-self: left on each child div?

Loirooriol · 2025-01-09T11:17:43Z

But how would you allow aligning 'anonymous blocks' to the end if that's the desired behavior?

There is of course a trade-off, we need to think which option will be less confusing.
But the authors could just wrap the inline contents with a <div> rather than relying on an anonymous block, then the element-generated block would obey the justify-items of the parent.

gitspeaks · 2025-01-09T11:36:17Z

But the authors could just wrap the inline contents with a <div> rather than relying on an anonymous block, then the element-generated block would obey the justify-items of the parent.

That's beside the point since we're no longer dealing with anonymous block boxes in that case. I think keeping the justify-items behavior consistent for both anonymous and non-anonymous block boxes makes it simpler to reason about. That said, I recommend adding a note in the spec for justify-items as a helpful reminder of the existence of 'anonymous block boxes' and their conforming behavior, aligning with other block boxes.

Loirooriol · 2025-01-10T14:01:09Z

I don't think most authors know about anonymous block boxes, and we typically pretend that they aren't there (see percentage resolution, #2595, etc.)

So I think we should either

set justify-self: normal/stretch on anonymous blocks so that they ignore justify-items of the parent, or
wrap the inline-level contents of a block container inside an anonymous block even if there is no block-level content, at least when justify-items computes to something different than normal/stretch or lone legacy.

mirisuzanne · 2025-04-29T19:56:38Z

When you add display:grid to the demos above, the anonymous grid item boxes are both aligned. I don't know about the theoretical precedent for pretending there's no box, but I think consistency would point towards always allowing us to align anonymous boxes - and I think that's the more useful answer for authors as well.

Loirooriol · 2025-04-29T20:23:20Z

The big difference is that grid and flex formatting contexts create an anonymous box around each text run. Block formatting contexts only create an anonymous box when there is a mix of inline-level and block-level contents.

So saying that anonymous boxes can always be aligned is still not be enough for justify-items to have any effect here, since no anonymous block box is created:

<div style="width: 200px; justify-items: right; border: solid">foo</div>

mirisuzanne · 2025-04-29T20:31:40Z

I see, sure. I guess then I'm suggesting that a box should be generated in this case, in order to have consistency. Though I'll admit I don't fully know the side-effects of that.

gitspeaks · 2025-04-29T21:17:23Z

I might be missing something, but I think the use of justify-items or justify-self in an inline formatting context isn't meaningful. Inline-level content is laid out using text-align for horizontal alignment and vertical-align for vertical alignment - these are part of a different alignment model than what's used in grid or BFC.

According to 6.1. Inline-Axis (or Main-Axis) Self-Alignment: the justify-self property, justify-self applies to block-level boxes, absolutely positioned boxes, and grid items. With respect to the recent example above, since no anonymous block-level box is created in this case, it's expected that these properties would have no effect for (anonymous) inline boxes within an inline formatting context.

Loirooriol · 2025-04-29T22:25:41Z

Yes, that's the current situation, but it seems bad to me. Hence the 2 options I proposed in #11461 (comment): either prevent justify-items from affecting anonymous block boxes, or always create anonymous block boxes when justify-items is not initial.

Note in the 2nd option text-align and justify-items would still do different things, e.g.

<!DOCTYPE html>
<div style="justify-items: center; text-align: left; border: solid; width: 200px">
  lorem ipsum<br>sit amet
</div>

(avoiding the need to add an inner wrapper to get this effect)

gitspeaks · 2025-04-29T23:22:14Z

or always create anonymous block boxes when justify-items is not initial.

I don't follow. Per the spec:

Any text that is directly contained inside a block container element (not inside an inline element) must be treated as an anonymous inline element.

In particular, the text in <div style="width: 200px; justify-items: right; border: solid">foo</div> would be wrapped in anonymous inline box.

How does introducing an anonymous block box here align with the rules for inline formatting contexts? Are you proposing that justify-items implicitly "blockifies" these inline items - effectively changing the formatting context from inline to block? If so, that seems like a substantial semantic shift.

Note in the 2nd option text-align and justify-items would still do different things,

I suppose in cases where there are multiple lines of different lengths (e.g., due to a <br>), text-align can affect the alignment of shorter lines - like right-aligning a shorter second line within a shrink-to-fit box defined by the longer first line.

But that feels like a confusing corner case. The box is anonymous, unstyleable, and auto-sized, so people expect no room for alignment to matter.

I think discarding alignment properties like justify-items in inline formatting contexts including those defined by an anonymous text run is not a bad approach. It reduces ambiguity and preserve a clearer separation between inline and block layout behavior.

Loirooriol · 2025-04-30T15:31:25Z

I'm not proposing to blockify anything.

effectively changing the formatting context from inline to block?

Yes, the 2nd option avoids establishing an inline formatting context on block containers with justify-items (the inline formatting context will instead be established by the anonymous block). But it doesn't force a new block formatting context, the parent BFC can be continued.

I think discarding alignment properties like justify-items in inline formatting contexts including those defined by an anonymous text run is not a bad approach.

I'm not sure if you are arguing for no change, or for my 1st proposed option.

Loirooriol · 2025-04-30T15:43:36Z

<!DOCTYPE html>
<style>body { width: 250px } div { margin: 1em 0 }</style>
<div style="border: solid; justify-items: center">
  1st line<br>
  And another line
</div>
<div style="border: solid; justify-items: center">
  1st line<br>
  And another line
  <p style="border: solid cyan">Nested block</p>
  Foooo<br>
  Bar
</div>

Current	Option 1	Option 2

gitspeaks · 2025-04-30T15:44:49Z

I'm not sure if you are arguing for no change, or for my 1st proposed option

justify-items should be ignored on a block container that establishes an inline formatting context.
justify-items should apply to anonymous block-level boxes within a block formatting context.

Option: "Current"

bfgeek · 2025-04-30T16:37:22Z

IMO The current behaviour in Blink is a bug, and I'd prefer "Option 1"

gitspeaks · 2025-04-30T16:44:42Z

IMO The current behaviour in Blink is a bug, and I'd prefer "Option 1"

But "Option 1" is not compatible with the scenario described in #11461 (comment)

Alohci · 2025-04-30T16:55:39Z

IMO The current behaviour in Blink is undesirable, and I'd prefer "Option 2". As a web author, I always prefer the more control option.

mirisuzanne · 2025-04-30T18:55:46Z

I agree that:

the current behavior seems like a bug, and makes no sense as an author
at least option 1 is consistent
option 2 is my preference as an author because I like having alignment that works, and I don't need to create special boxes to do that in other formatting contexts

gitspeaks · 2025-04-30T19:03:14Z

How is the anonymous block in option 2 sized?

Loirooriol · 2025-04-30T19:18:39Z

How is the anonymous box in option 2 sized?

Yes, both the current Blink behavior and option 2 raise some questions about that. So from an implementation point of view I prefer option 1, which is what I implemented in Servo (I didn't have to do anything special, I just got this behavior due to how we implement anonymous block boxes).

Presumably the anonymous box would be sized as fit-content instead of stretch. But percentages in the block axis skip anonymous block boxes, should it be the same in the inline axis? And what about stretch?

<!DOCTYPE html>
<style>
div { float: left; width: 100px; height: 100px;justify-items: right; border: solid; margin: 1em }
div::before { content: ""; display: block }
span { display: inline-block; border: solid magenta }
</style>
<div> <span style="width: 100%; height: 100%"></span> </div>
<div> <span style="width: stretch; height: stretch"></span> </div>

So Blink breaks the axis symmetry by allowing percentages and stretch to resolve against anonymous block boxes in the inline axis. This inconsistency doesn't sound great, so it solidifies option 1 as the best option for me.

gitspeaks · 2025-04-30T23:21:53Z

IMO, option 2 feels like a hack. justify-items sets the default justify-self for items, but under the current suggestion, it ends up applying to an injected anonymous block container that wraps all inline content in an inline formatting context. This effectively aligns the group as a whole, rather than the individual elements. I can easily see authors getting confused when they try to set justify-self on the inline elements themselves to override the default as they would expect in other formatting contexts only to find it has no effect. It's a very confusing API, to be honest.

gitspeaks · 2025-05-01T23:27:51Z

Also, I don’t think whether the current Blink behavior is a bug is a matter of opinion but rather it’s a question of whether it conforms to the specification, which it does. While justify-items applies to any element, justify-self does not apply to inline elements. In fact, the specification text for justify-items is explicit:

This property specifies the default justify-self for all of the child boxes (including anonymous boxes) participating in this box’s formatting context.

So it should come as no surprise that an anonymous block box in Blink derives its default value from justify-items, whereas anonymous inline boxes do not since justify-self doesn’t apply to them in the first place.

Similarly, consider how the height property works, it applies to block elements but not to inline non-replaced elements. Authors have come to understand and expect this behavior. So the current Blink behavior is not only consistent with the specification, but also aligned with how block-specific properties generally interact with inline non-replaced elements.

See: w3c/csswg-drafts#11461 Our current behaviour is (IMO) a bug, so tentatively change it to "Option 1" in the issue. Adds a tentative test as well. Change-Id: I145d39d819347d3446dd08cdd98e055e40625b53

See: w3c/csswg-drafts#11461 Our current behaviour is (IMO) a bug, so tentatively change it to "Option 1" in the issue. Adds a tentative test as well. Change-Id: I145d39d819347d3446dd08cdd98e055e40625b53 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6512658 Reviewed-by: David Grogan <dgrogan@chromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1455957}

…k behaviour., Automatic update from web-platform-tests [align] Tentatively change our anon-block behaviour. See: w3c/csswg-drafts#11461 Our current behaviour is (IMO) a bug, so tentatively change it to "Option 1" in the issue. Adds a tentative test as well. Change-Id: I145d39d819347d3446dd08cdd98e055e40625b53 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6512658 Reviewed-by: David Grogan <dgrogan@chromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1455957} -- wpt-commits: 188831eade6393b09148089ea030a0e25ef33767 wpt-pr: 52347 Differential Revision: https://phabricator.services.mozilla.com/D248844

fantasai · 2025-05-13T22:19:40Z

In the 2nd case, "foo" gets wrapped inside an anonymous block, which is then aligned by justify-items: right.

You know, we could avoid this whole problem if we go with my earlier interpretation that justify-self does not affect sizing in block-level layout. :-)

…k behaviour., Automatic update from web-platform-tests [align] Tentatively change our anon-block behaviour. See: w3c/csswg-drafts#11461 Our current behaviour is (IMO) a bug, so tentatively change it to "Option 1" in the issue. Adds a tentative test as well. Change-Id: I145d39d819347d3446dd08cdd98e055e40625b53 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6512658 Reviewed-by: David Grogan <dgroganchromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrickchromium.org> Cr-Commit-Position: refs/heads/main{#1455957} -- wpt-commits: 188831eade6393b09148089ea030a0e25ef33767 wpt-pr: 52347 Differential Revision: https://phabricator.services.mozilla.com/D248844 UltraBlame original commit: e52b46cfe8133fe5c42a3cff2a2c795bbacf8710

css-meeting-bot · 2025-05-14T17:02:37Z

The CSS Working Group just discussed [css-align] `justify-items` and anonymous block boxes, and agreed to the following:

RESOLVED: Anonymous block boxes always stretch (go with option 1)

The full IRC log of that discussion

<oriol> https://github.com//issues/11461#issuecomment-2842434810
<emilio> oriol: since we resolve justify-self can force fit-content size, if you use justify-items on a block container, a block container with inline level contents, justify-items won't apply
<emilio> ... if you then add a block, you add an anonymous block level box and justify-self applies to it
<emilio> ... so it's very unexpected that adding a block-level sibling changes the alignment
<emilio> ... option 1 would be that anon block boxes would always stretch rather than using justify-items of the parent
<emilio> ... another option would be that justify-items other than initial you'd still wrap stuff
<emilio> ... IMO option 1 is the easiest to implement in servo, also avoids some questions about what to do with percentages and so on
<iank_> +1 Oriol - There is a whole can of worms involved w/ option (2)
<emilio> ... percentages in the block axis skips anon boxes, should we skip them in the inline axis if we consider the other option?
<emilio> ... miriam preferred option 2 since it's more useful for authors (no need to wrap in implicit elements)
<astearns> ack miriam
<iank_> q+
<astearns> ack fantasai
<emilio> miriam: oriol described what I think, alignment is one of the more common things to do and doing it easily makes sense
<fantasai> https://www.w3.org/TR/css-text-4/#text-group-align-property
<emilio> .. but either option feels better than the alternative
<emilio> fantasai: there's one property that allows you to wrap things, not sure it's implemented
<emilio> ... the behavior you want is not the behavior that would fall off from wrapping in anon boxes
<emilio> ... consider a paragraph with text, block level, then text
<emilio> ... if we wrap each in a box then they'd be independently aligned which I'm not sure is what you want
<astearns> ack iank_
<emilio> iank_: pretty against option 2
<emilio> ... quite a large can of worms
<emilio> ... probably big source of confusion for web devs too
<emilio> ... a little concerned about compat too
<emilio> ... so prefer option 1, authors ??? text-align
<emilio> astearns: we could resolve on updating the spec to option 1 with a note
<emilio> miriam: ok with that
<emilio> PROPOSED: Anonymous block boxes always stretch
<emilio> RESOLVED: Anonymous block boxes always stretch (go with option 1)

gitspeaks · 2025-05-14T21:17:01Z

Under the revised specification, to maintain the layout as it currently appears in Chrome:

<!DOCTYPE html>
<div style="justify-items: end;">
  A
  <div style="background-color: red; width: 50px;">A</div>
  B
  <div style="background-color: red; width: 50px;">B</div>
  C
  <div style="background-color: red; width: 50px;">C</div>
</div>

We will need to code:

<!DOCTYPE html>
<div style="justify-items: end; text-align: right;">
  A
  <div style="background-color: green; text-align: left; width: 50px;">A</div>
  B
  <div style="background-color: green; text-align: left; width: 50px;">B</div>
  C
  <div style="background-color: green; text-align: left; width: 50px;">C</div>
</div>

Because apparently, under the current behavior, text node alignment is an exercise in unpredictability, as seen in cases like:

When this:

<!DOCTYPE html>
<div>
  A
</div>

is mutated to:

<!DOCTYPE html>
<div style="justify-items: end;">
  A
  <div>B</div>
</div>

Or when this:

<!DOCTYPE html>
<div style="justify-items: end;">
  <div>B</div>
</div>

is mutated to:

<!DOCTYPE html>
<div style="justify-items: end;">
  A
  <div>B</div>
</div>

In both scenarios, A and B align the same way, which is, of course, totally not what everyone expected. Or not. Interesting.

Loirooriol · 2025-05-14T21:26:33Z

text-align can have other effects in general as I already mentioned. To keep the old Blink behavior (Canary already changed), better wrap text inside explicit blocks instead:

<!DOCTYPE html>
<div style="justify-items: end;">
  <div>A</div>
  <div style="background-color: red; width: 50px;">A</div>
  <div>B</div>
  <div style="background-color: red; width: 50px;">B</div>
  <div>C</div>
  <div style="background-color: red; width: 50px;">C</div>
</div>

CSSWG resolution on Option (1) - the behaviour we changed to in: https://chromium-review.googlesource.com/c/chromium/src/+/6512658 w3c/csswg-drafts#11461 (comment) Make test added in that patch non-tentative. Fixed: 417734173 Change-Id: I4af723d2b39764c77507be038c31214da42f1c69 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6548615 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Auto-Submit: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1460363}

…k behaviour., Automatic update from web-platform-tests [align] Tentatively change our anon-block behaviour. See: w3c/csswg-drafts#11461 Our current behaviour is (IMO) a bug, so tentatively change it to "Option 1" in the issue. Adds a tentative test as well. Change-Id: I145d39d819347d3446dd08cdd98e055e40625b53 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6512658 Reviewed-by: David Grogan <dgrogan@chromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1455957} -- wpt-commits: 188831eade6393b09148089ea030a0e25ef33767 wpt-pr: 52347 Differential Revision: https://phabricator.services.mozilla.com/D248844

Loirooriol added css-align-3 Current Work Agenda+ labels Jan 8, 2025

astearns added this to CSSWG January 2025 meeting Jan 22, 2025

astearns moved this to FTF agenda items in CSSWG January 2025 meeting Jan 22, 2025

astearns moved this from FTF agenda items to Regular agenda items in CSSWG January 2025 meeting Jan 22, 2025

emilio mentioned this issue Jan 29, 2025

[css-align] justify-items and block splitting inline #11462

Open

astearns moved this from Regular agenda items to Thursday morning in CSSWG January 2025 meeting Jan 29, 2025

astearns added this to CSSWG April 2025 meeting agenda Mar 27, 2025

astearns moved this to Regular agenda in CSSWG April 2025 meeting agenda Mar 27, 2025

This comment has been minimized.

Sign in to view

chromium-wpt-export-bot mentioned this issue May 5, 2025

[align] Tentatively change our anon-block behaviour. web-platform-tests/wpt#52347

Merged

css-meeting-bot removed the Agenda+ label May 14, 2025

astearns added Needs Edits Needs Testcase (WPT) labels May 14, 2025

mozilla-apprentice mentioned this issue May 14, 2025

[css-align] justify-items and anonymous block boxes mozilla/wg-decisions#1945

Open

chromium-helper mentioned this issue May 14, 2025

[css-align] justify-items and anonymous block boxes chromium-helper/csswg-resolutions#820

Closed

chromium-wpt-export-bot mentioned this issue May 14, 2025

[wpt] Make justify-items-anonymous non-tentative. web-platform-tests/wpt#52549

Merged

This comment has been minimized.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-align] `justify-items` and anonymous block boxes #11461

[css-align] `justify-items` and anonymous block boxes #11461

Loirooriol commented Jan 8, 2025 •

edited

Loading

gitspeaks commented Jan 9, 2025 •

edited

Loading

Loirooriol commented Jan 9, 2025

gitspeaks commented Jan 9, 2025 •

edited

Loading

Loirooriol commented Jan 10, 2025

mirisuzanne commented Apr 29, 2025

Loirooriol commented Apr 29, 2025

mirisuzanne commented Apr 29, 2025

gitspeaks commented Apr 29, 2025 •

edited

Loading

Loirooriol commented Apr 29, 2025

gitspeaks commented Apr 29, 2025

Loirooriol commented Apr 30, 2025

Loirooriol commented Apr 30, 2025 •

edited

Loading

gitspeaks commented Apr 30, 2025 •

edited

Loading

bfgeek commented Apr 30, 2025

gitspeaks commented Apr 30, 2025

Alohci commented Apr 30, 2025

mirisuzanne commented Apr 30, 2025

gitspeaks commented Apr 30, 2025 •

edited

Loading

Loirooriol commented Apr 30, 2025

This comment has been minimized.

This comment has been minimized.

gitspeaks commented Apr 30, 2025

gitspeaks commented May 1, 2025

fantasai commented May 13, 2025

css-meeting-bot commented May 14, 2025

gitspeaks commented May 14, 2025

Loirooriol commented May 14, 2025

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

[css-align] justify-items and anonymous block boxes #11461

[css-align] justify-items and anonymous block boxes #11461

Comments

Loirooriol commented Jan 8, 2025 • edited Loading

gitspeaks commented Jan 9, 2025 • edited Loading

Loirooriol commented Jan 9, 2025

gitspeaks commented Jan 9, 2025 • edited Loading

Loirooriol commented Jan 10, 2025

mirisuzanne commented Apr 29, 2025

Loirooriol commented Apr 29, 2025

mirisuzanne commented Apr 29, 2025

gitspeaks commented Apr 29, 2025 • edited Loading

Loirooriol commented Apr 29, 2025

gitspeaks commented Apr 29, 2025

Loirooriol commented Apr 30, 2025

Loirooriol commented Apr 30, 2025 • edited Loading

gitspeaks commented Apr 30, 2025 • edited Loading

bfgeek commented Apr 30, 2025

gitspeaks commented Apr 30, 2025

Alohci commented Apr 30, 2025

mirisuzanne commented Apr 30, 2025

gitspeaks commented Apr 30, 2025 • edited Loading

Loirooriol commented Apr 30, 2025

This comment has been minimized.

This comment has been minimized.

gitspeaks commented Apr 30, 2025

gitspeaks commented May 1, 2025

fantasai commented May 13, 2025

css-meeting-bot commented May 14, 2025

gitspeaks commented May 14, 2025

Loirooriol commented May 14, 2025

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

[css-align] `justify-items` and anonymous block boxes #11461

[css-align] `justify-items` and anonymous block boxes #11461

Loirooriol commented Jan 8, 2025 •

edited

Loading

gitspeaks commented Jan 9, 2025 •

edited

Loading

gitspeaks commented Jan 9, 2025 •

edited

Loading

gitspeaks commented Apr 29, 2025 •

edited

Loading

Loirooriol commented Apr 30, 2025 •

edited

Loading

gitspeaks commented Apr 30, 2025 •

edited

Loading

gitspeaks commented Apr 30, 2025 •

edited

Loading