[css-align] Rename auto to legacy for justify-items

[fantasai]

In the align-self and justify-self properties, the auto keyword looks up to the parent's align-items or justify-items property. That's fine.

On justify-items we also have an auto keyword, but it's not there for the general case: it's just there to handle some special computation in case the parent’s value contains a legacy keyword alongside an alignment keyword.

It would be equally plausible to just use legacy as this magic-computing keyword, and leave auto out of the property entirely. Note that align-items doesn't have an auto keyword, because it doesn't have legacy.

Proposal A is to rename auto to legacy.
Proposal B is to remove legacy entirely and leave the handling of <CENTER> and friends to UA-specific magic and/or a separate (Yet Another) alignment property.

[fantasai]

Note: We edited Proposal A into the latest ED for comparison.

[rachelandrew]

A preference for Proposal A from me. Where you do see people getting <CENTER> into their markup is where they are using some horrible WYSIWYG CMS editor that lets content editors add it. It seems that having the ability to deal with this in a known fashion from CSS is going to be helpful to authors trying to do modern web development while having to cope with this kind of thing.

I like legacy as a keyword as that is a good way to explain it, this isn't behaviour that we want to be using for any other purposes than to deal with an old way of formatting that still lurks around.

[css-meeting-bot]

The CSS Working Group just discussed Rename `auto` to `legacy` for `justify-items` Pending this resolution we could go to CR, and agreed to the following resolutions:

• RESOLVED: rename auto to legacy.
• RESOLVED: Move CSS Alignment to CR with the added legacy value defined as at-risk. The action of starting the CR process will start in 2 weeks (May 27) unless we heard elsewise.

The full IRC log of that discussion

<dael> Topic: Rename `auto` to `legacy` for `justify-items` Pending this resolution we could go to CR
<dael> Github topic: https://github.com//issues/1318
<fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/saved/5143
<dael> fantasai: we've got different behavior on different browsers (still on previous issue).
<dael> fantasai: Alignment spec has a bunch of keyword magic with justify-items. It sets default value of justify self for any children. We tried to figure out how to incorporate center tag and did it with a special set of keywords called legacy with an intial value of auto. All auto does is this magic, but we could just uselegacy keword by itself
<dael> fantasai: Proposal is rename auto to legacy so all it does is if you have legacy keyword on parent it pulls the parent alignment, else does normal thing.
<dael> fantasai: Alternate is drop t his thing.
<dael> fantasai: We haven't gotten any significant comments. Apperently style stuff is implin chrome. Not sure how people are imple center and align attributes in HTML.
<dael> fantasai: If impl don't want to implement center and align attributes through this we should drop. If we want to keep it we recommend the rename.
<dael> fantasai: Did that make sense or do we need more explination?
<dael> Rossen: Your explination was great. In ourimpl we handle center a little magic. Rename would be okay. Trying to kill itwould be better.
<dael> Rossen: I'm in favor of mostly everything you proposed.
<zcorpan> https://html.spec.whatwg.org/#align-descendants is the magic explained in html
<dael> fantasai: Reason to keep it would be i f we want to standardize. Alternative would be add yet another property to control magic.
<dael> fantasai: We can't unimplement center tag.
<dael> TabAtkins: Benefit of another alignment property is we can make it actually inherit. It might be better structurally.
<dael> fantasai: But then you have a weird thing where you have to figure out, I inheritied this, alignment is this, what wins?
<dael> fantasai: We can't resolve with cascade.
<dael> fantasai: Incorperating it has the benefit that the cascade is understandable.
<dbaron> For what it's worth, I'd probably have an opinion on this if I had ten minutes to think about it...
<dael> TabAtkins: There' definitely problems either way, I agree.
<dael> fantasai: I'm happy to defer
<dael> Rossen: reoslve on rename
<dael> Rossen: Any objections on renaming auto to legacy?
<dael> RESOLVED: rename auto to legacy.
<dael> Rossen: Was that the only hting keeping us from CR on alignment?
<dael> fantasai: Yes...I think we should add legacy to at-risk list. All the issues are closed. I would like to initiate transition.
<dael> Rossen: That would be great.
<dael> fantasai: While we process that we can look at dropping. If it's at-risk we can drop later.
<dael> dbaron: I'll try and start asking this: Is there someone other then the editor that has read the draft and thinks it's ready?
<dael> fantasai: We've had a lot of comments from Igalia & Matt. There have been detailed reviews of the draft. I think it has been impl...this was the reference spec of grid. I think it's gotten decent amount of review.
<dael> dbaron: There's bunches not related to grid and I worry those aren't ready.
<dael> fantasai: I think they're striaght forward. We kept asking for review and no one has so TabAtkins and I have done two line by line reviews of the spec.
<dael> fantasai: If someone wants to review the spec I'm happy to delay 2 weeks, but if it'll be more no response and no review it's not useful.
<dael> fantasai: I've been asking for review for years.
<dael> dbaron: I submitted comments a year or two ago.
<dael> dbaron: I wouldlike the bar for CR to involve someone other then the editors say they think it's ready.
<dael> fantasai: I totally agree with that.
<astearns> we're meant to show wide review before CR
<dael> dbaron: I can prob look, but not this week.
<rachelandrew> Does this review need to be from an Implementor? I've spent a lot of time reading it, I'd be happy to do a more formal review.
<dael> Rossen: I agree dbaron. We can action the WG to review Alignment spec in the following two weeks. I also sympathize with fantasai saying she has asked for review. Let's use the resolution forcing function. Would you agree two weeks is enough before we call for resolution? Or three?
<dael> dbaron: 2 is fine.
<astearns> rachelandrew: does not have to be from an implementor - your formal review would be great
<fantasai> gsnedders, we don't want to advance specs to CR that nobody cares about
<dael> Rossen: prop: Move CSS Alignment to CR with the added legacy value defined as at-risk. The action of starting the CR process will start in 2 weeks unless we heard elsewise.
<fantasai> gsnedders, that's a recipe for bad news
<dael> Florian: Have we asked for horizontal review? We could bundle the two.
<dael> Rossen: Let's see. Who do we need for horizontal review? a11y folks.
<rachelandrew> ok, I have some very long airplane flights in the next 2 weeks :D
<dael> ChrisL: i18n, privacy, security
<dael> fantasai: I think for privacy & security we should send them a note saying we don't think there's anything that would effect you, but feel free to read the spec.
<dael> Rossen: That's good.
<dael> Florian: Is 2 weeks short for horizontal?
<dael> ChrisL: It is. i18n watnts 4 weeks.
<dael> ChrisL: I think for psecs we're prepping for CR we should in the future schedule earlier.
<dael> fantasai: I don't think we'll g et feedback on horizontal review. Maybe generalthis could b e better written.
<dael> fantasai: i18n wanted flow relative directions which is what we did. We have self-start vs start so there's all kinds of writing mode control. a11y issues are ones that effect everything.
<dael> Rossen: I think we should stick to 2 weeks. IF someone starts screaming we can be flexible.
<dael> RESOLVED: Move CSS Alignment to CR with the added legacy value defined as at-risk. The action of starting the CR process will start in 2 weeks (May 27) unless we heard elsewise.
<fantasai> s/everything/everyone, e.g. if stuff overflows it could be bad/

[atanassov]

CSSWG Resolution: Publish a new WD of the draft

[MatsPalmgren]

FYI, the "Computed value" description also needs to be updated, it currently says:

specified value, except for auto (see prose)

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

BTW, have you considered restricting the order of the legacy keyword? It seems a bit odd now that <overflow-position>? <self-position> has an order that legacy does not. (I don't mind, I just want to make sure you intentionally want to continue allowing both legacy left and left legacy etc).

[MatsPalmgren]

Fwiw, I just implemented this and I noted that place-items: center legacy (etc) is now a valid value. There's no ambiguity (it specifies align-items:center; justify-items:legacy), but since center legacy is also a valid justify-items value it might look a bit confusing at first. Not sure whether only allowing legacy center in justify-items would help much though... (also depends on the outcome of issue #1002)

[fantasai]

@MatsPalmgren Fixed the Computed value line. Wrt fixing the order... we try not to fix the order of values unless there's a parsing ambiguity, and as you point out here, there isn't. So unless you think it might be a problem in the future, let's leave it unfixed. :)

Wrt allowing legacy in place-items, the current set of edits leave it out, but there's an open discussion in #1449 on that topic; if you have an opinion either way please let us know. :)

[MatsPalmgren]

My opinion on this issue, and issue #1449, depends on the outcome of issue #1002.
If we adopt slash as the separator (between block/inline-axis values), then I see no problem in supporting the full set of values. If we continue to use space, then there will be severe ambiguities with fallback values in shorthands. If we're going to change the syntax for these shorthands from using space to slash then I think that needs to happen now if it's going to happen at all.