Skip to content

[css-align] justify-items: legacy fails to fulfil its only purpose of explaining <center> and align #11463

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
Open
Loirooriol opened this issue Jan 9, 2025 · 6 comments
Open

[css-align] justify-items: legacy fails to fulfil its only purpose of explaining <center> and align #11463

Loirooriol opened this issue Jan 9, 2025 · 6 comments
Labels
css-align-3 Current Work

Comments

@Loirooriol
Copy link
Contributor

https://drafts.csswg.org/css-align/#valdef-justify-items-legacy

This keyword causes the value to effectively inherit into descendants.

If the legacy keyword appears on its own (without an accompanying left, right, or center keyword): if the inherited value of justify-items includes the legacy keyword, this value computes to the inherited value; otherwise it computes to normal.

When justify-self:auto references the value of justify-items, only the alignment keyword, not the legacy keyword, is referenced by it. It exists to implement the legacy alignment behavior of HTML’s <center> element and align attribute.

Well, it fails to fulfill its only purpose, because <center> and align allow automatic sizes to stretch.

https://drafts.csswg.org/css-align/#justify-self-property

Values other than stretch cause a width/height of auto to be treated as fit-content.

<!DOCTYPE html>
<div align="center">
  <div style="border: solid">foo</div>
</div>
<div style="justify-items: legacy center">
  <div style="border: solid">foo</div>
</div>

In Blink:
@astearns astearns moved this to FTF agenda items in CSSWG January 2025 meeting Jan 22, 2025
@astearns astearns moved this from FTF agenda items to Regular agenda items in CSSWG January 2025 meeting Jan 22, 2025
@astearns astearns moved this to Regular agenda in CSSWG April 2025 meeting agenda Mar 27, 2025
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-align] `justify-items: legacy` fails to fulfil its only purpose of explaining `<center>` and `align` , and agreed to the following:

  • RESOLVED: Drop the legacy keyword, assuming that's Web-compatible
The full IRC log of that discussion <TabAtkins> oriol: this is a problem i ran into when i was implementing justify/align-self on blcoks in Servo
<TabAtkins> oriol: initial value of justify-self is `auto`, which takes from justify-items on parent
<TabAtkins> oriol: justify-items ahs an value of "legacy" which is combined with left/right/center
<TabAtkins> oriol: these have special behavior when you inherit to jsutify-self where you jsut use left/right/center
<TabAtkins> oriol: this was designed to explain the weird behaior of html's <center>/<left>/<right> and its align="" attribute
<TabAtkins> oriol: problem is if you're using justify-items:legacy center, children will resolve justify-self:auto to center.
<TabAtkins> oriol: and center prevents auto widths from stretching
<TabAtkins> oriol: that is different from the HtML behavior
<iank_> q+
<TabAtkins> oriol: so it doesn't work
<TabAtkins> oriol: i think to address this we shoudl either say this legacy combination allow auto sizes to still stretch
<TabAtkins> oriol: or we should do this some other way
<bkardell> "whoops"
<iank_> https://github.com//issues/10388#issuecomment-2233714476
<TabAtkins> oriol: because browsers currently implement them with text-align, which doesn't make sense
<astearns> ack iank_
<TabAtkins> iank_: i posted a link to the issue
<TabAtkins> iank_: i think we already have a reoslution from last year that we handle the html alignmetn as -webkit prefixed text-aling values
<TabAtkins> iank_: so do we need legacy justify-items at all?
<TabAtkins> oriol: my understanding from the previous resolution is that even tho <center> was setting text-align:-webkit-center
<TabAtkins> oriol: it was still possible for these special keywords to force the computed value of justify-items to these legacy combos
<TabAtkins> oriol: but since they don't work either maybe we just do text-align
<TabAtkins> iank_: yeah, also people have been using text-align:-webkit-center manually
<astearns> ack fantasai
<TabAtkins> iank_: so my pref is to drop the justify-items values
<TabAtkins> fantasai: looking at the example here, it shows that justify-self property on block boxes causes it to size differently
<TabAtkins> fantasai: i'm not sure that's what we we meant when we wrote the spec
<TabAtkins> fantasai: just the overconstrained comps are replaced with alignment
<TabAtkins> fantasai: i don't think we meant for it to change how boxes are sizes
<TabAtkins> fantasai: we could do that, just it wasn't my original intent. i originally was just trying to fix the overconstrainted situation
<TabAtkins> oriol: i'm pretty sure shrinkwrapping the sizing is alreayd working in grid and flexbox
<TabAtkins> oriol: so i dont' know that blocks being inconsistent woudl be good
<bkardell> s/alreayd/already
<bkardell> s/woudl/would
<TabAtkins> fantasai: othe rpoint. the legacy stuff *was* designed to replace the html alignment. if that's not working, we should remove it.
<bkardell> s/othe rpoint./other point.
<TabAtkins> fantasai: i don't think this sizing issue is why to remove it. but if sites are relying on text-align disabling the html alignment behavior, then it means the only property that can be used for html alignment has to be text-aling
<TabAtkins> fantasai: so then we do need to standardize on that, and we can drop this from alignment
<fantasai> TabAtkins: I agree with Elika
<iank_> +1
<bkardell> s/ text-aling/text-align
<fantasai> https://github.com//issues/10388#issuecomment-2254475149
<TabAtkins> astearns: so are you proposing to see if we can remove the property?
<TabAtkins> astearns: or remove it now?
<TabAtkins> fantasai: here's the example from the other issue. if that is working, i suspect people *are* relying on it, and we'r elocked into text-align
<TabAtkins> iank_: yeah i'd be hesitant to change the parent behavior with text-align. just asking for a lot of pain
<TabAtkins> iank_: given how old these values are
<TabAtkins> iank_: we still might have a compat problem if we remove 'legacy'
<TabAtkins> iank_: people depending on it working in grid/flex
<fantasai> TabAtkins: And ultimately we can list is as valid but ignored
<TabAtkins> iank_: but i'm willing to risk it
<fantasai> fantasai: does anyone actually use this value?
<fantasai> TabAtkins: proposal to remove 'legacy' values, relying on text-align for HTML alignment
<fantasai> TabAtkins: and if compat impact, we can redefine it as a useless keyword
<fantasai> astearns: and see if that's compatible
<fantasai> PROPOSED: Drop the legacy keyword, assuming that's Web-compatible
<fantasai> RESOLVED: Drop the legacy keyword, assuming that's Web-compatible
<TabAtkins> fantasai: on this issue, if we're using text-aling for html alignment
<TabAtkins> fantasai: then i think we should take that as an explicit reoslution, and give the webkit values actual names
<bkardell> s/text-aling/text-align
<TabAtkins> fantasai: i suggest appending -items to each keyword
<TabAtkins> fantasai: text-align: start-items
<TabAtkins> astearns: we ahve a resolution to put the -webkit keywords in compat
<fantasai> TabAtkins: We also have a standing resolution to remove things from compat spec when we can
<fantasai> TabAtkins: These are long-deprecated features supported for legacy reasons. I don't see a good reason to give them a good name.
<fantasai> TabAtkins: This is nasty value
<fantasai> fantasai: If you want the effect, then why give users the ability to specify without -webkit-prefix
<iank_> +1 to tab
<TabAtkins> astearns: agree with Tab, keep them named clearly as back-compat
<TabAtkins> astearns: if there's a reason for similar functionality that doesn't have to exactly match, we can introduce new values
<fantasai> fantasai: we tried with the legacy keywords
<fantasai> s/fantasai/Tab/
<fantasai> TabAtkins: But ...
<fantasai> TabAtkins: if we were doing it on purpose, wouldn't have called it 'legacy'.
<fantasai> TabAtkins: call it 'match-text-align' or something
<fantasai> fantasai: But it doesn't inherit
<TabAtkins> TabAtkins: we were not defining this behavior on purpose
<fantasai> fantasai: If people are using -webkit- keywords then that means they want the behavior
<fantasai> fantasai: so we should give it reasonable keywords
<ntim> q+
<TabAtkins> TabAtkins: if people want this, we can define it *propertly*. we would *never* have put this on text-align if we designed it on purpose
<TabAtkins> iank_: i think in most cases people don't really need full inheritance anyway
<astearns> ack ntim
<TabAtkins> ntim: if we're doing in the path TAb is suggesting, would we bea ble to use the new css design adn apply it to the html tags?
<TabAtkins> ntim: and get rid of the text-align properties/
<TabAtkins> fantasai: that's what I'm saying, people are using text-align to override an inherited value set by the html element
<TabAtkins> fantasai: if we did this with something other than text-align it would change the behavior
<fantasai> fantasai: they are using text-align and HTML alignment laternating, assuming they cascade and inherit as a single thing
<fantasai> fantasai: so we wouldn't be able to change the attribute mapping
<fantasai> TabAtkins: I think we shouldn't give these values real names.
<dbaron> (I think if we wanted to design the feature "right" we'd probably want something reasonably close to the "legacy" keyword that we just resolved to remove...)
<TabAtkins> dbaron, yes, but not named "legacy"
<TabAtkins> fantasai: I don't thinkl -webkit prefixes should be in the web platform for any reason other than supporting pages using webkit prefixes
<TabAtkins> astearns: we're out of time, we'll discuss this in a future meeting

@mozilla-apprentice mozilla-apprentice mentioned this issue Apr 3, 2025
Open
@chromium-helper chromium-helper mentioned this issue Apr 3, 2025
Closed
@fantasai
Copy link
Collaborator

fantasai commented Apr 6, 2025

The other question raised in this discussion was about the sizing impact of justify-self on block-level boxes. The current spec only applies it in the overconstrained case, i.e. it doesn't trigger shrinkwrapping.

@Loirooriol
Copy link
Contributor Author

What? The spec literally says

Values other than stretch cause a width/height of auto to be treated as fit-content.

This is not limited to overconstrained cases.

@fantasai
Copy link
Collaborator

Fair. I interpreted this clause as restrictive:

In terms of CSS2.1 block-level formatting [CSS2], the rules for “over-constrained” computations in section 10.3.3 are ignored in favor of alignment as specified here and the used value of the margin properties are therefore not adjusted to correct for the over-constraint.

If it's Web-compatible, though, your interpretation is probably more useful.

@Loirooriol
Copy link
Contributor Author

I interpret that clause as dropping the CSS2 logic in favor of the css-align logic, rather than restricting the css-align logic.

AFAIK only Blink supports justify-self on block-level boxes, so changing the behavior may still be web compatible. But Blink follows my interpretation, and I think it would be very inconsistent if e.g. justify-self: center still allowed block-level elements to stretch, given that it prevents stretching flex items, grid items and abspos.

@Loirooriol Loirooriol mentioned this issue Apr 18, 2025
Open
@Loirooriol
Copy link
Contributor Author

Filed #12102

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-align-3 Current Work
Projects
CSSWG April 2025 meeting agenda
Status: Regular agenda
CSSWG January 2025 meeting
Status: Regular agenda items
Milestone
No milestone
Development

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