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