Closed fantasai closed 7 years ago
Note: We edited Proposal A into the latest ED for comparison.
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.
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.
CSSWG Resolution: Publish a new WD of the draft
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).
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)
@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. :)
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.
In the
align-self
andjustify-self
properties, theauto
keyword looks up to the parent'salign-items
orjustify-items
property. That's fine.On
justify-items
we also have anauto
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 alegacy
keyword alongside an alignment keyword.It would be equally plausible to just use
legacy
as this magic-computing keyword, and leaveauto
out of the property entirely. Note thatalign-items
doesn't have anauto
keyword, because it doesn't havelegacy
.Proposal A is to rename
auto
tolegacy
. Proposal B is to removelegacy
entirely and leave the handling of<CENTER>
and friends to UA-specific magic and/or a separate (Yet Another) alignment property.