Closed fantasai closed 1 year ago
@fantasai do we have a precedent of values that can't be explicitly defined? And only be declared as their default value if they're omitted?
Also, won't it be confusing if in the future we decide auto
to be parsed another property?
I guess we might as well reserve auto
for for duration
, which seems fine for now, unless I'm missing something.
do we have a precedent of values that can't be explicitly defined? And only be declared as their default value if they're omitted?
Yes, there are a number of them. Whole properties might not be specificiable ("reset-only sub-properties"), and within properties that are specificable, there are several where longhands can express a combination that can't be written in the serialization. (My brain refuses to cough up an example, but it's the whole reason we have the "serialize as empty string" behavior for shorthands in CSSOM.)
For the issue at hand, I'm not too concerned with the potential "auto" conflict for animation names (seems like a very unlikely name), but I am more concerned about this being the only property that currently takes an auto keyword, and it claiming that keyword in the shorthand for the future, when it doesn't even need it (due to that being the initial value).
I'm usually against values that can only be expressed via absence, but in this case I think it's fine.
I suggested to accept auto
for animation-duration
in a value for animation
because auto
can be declared for animation-duration
.
As far as I know, font
is the only other shorthand serialized as empty string because its syntax intentionally does not accept some values accepted in the syntax of a sub-property (font-stretch
and font-variant
). I do not know the historical reasons for this.
I do not really have a problem with serializing animation
omitting the initial value of animation-duration
.
Furthermore, when serializing, default values of other properties must be output in at least the cases necessary to distinguish an
animation-name
that could be a value of another property, and may be output in additional cases.
Even if the author declared animation-name: auto; animation-duration: auto; /* ...other animation longhand declarations */
, the declared value of animation-duration
must not be output.
For authors, this would be the only sub-property of animation
that they cannot declare explicitly.
+1 to @cdoublev's proposal.
I'm not too concerned with the potential "auto" conflict for animation names (seems like a very unlikely name)
It appears that auto
is indeed an unlikely name. Querying HTTP Archive, I found only a single case (out of ~12.9 million) with @keyframes
named auto
. So the estimated risk seems low, and any problems can be trivially fixed by the author anyway.
I am more concerned about this being the only property that currently takes an auto keyword, and it claiming that keyword in the shorthand for the future
That claim can be easily satisfied by explicitly specifying auto
(thus making other hypothetical auto's reachable)? I don't get why we need to introduce minor weirdness in this particular case, when "greedy claim" seems to be the default mode of any shorthand.
Also in favor of allowing auto
in the shorthand, setting the animation-duration
doing so.
It does seem simpler than having extra serialization complexity / oddness for the shorthand due to: the first value in each
I am more concerned about this being the only property that currently takes an auto keyword, and it claiming that keyword in the shorthand for the future
Restating to make sure I understand, the problem is if we want to allow auto for some of the other longhands we wouldn't be able to make them accept auto
before animation-duration
in the shorthand. This wouldn't be a problem for anything that accepts times as they already are assigned in order, but could be problematic for any of the non-time properties. It would be nice to come up with some general way to handle this, e.g. animation-duration: auto
becoming auto-duration
or some other unique keyword.
That said, these time-accepting properties are the only current form of measurement/length in the animation property. I think there's precedent in other shorthands, e.g. background
accepts auto
as the background-size
preventing auto
from being accepted for any other background longhands.
I think we currently have 2 scenarios that require duration: auto
:
For case 1 omitting seems fine, since delays are ignored anyway and ranges are used instead.
For case 2, this is still being considered, but AFAICT there won't be an option to set only delay
in such cases, which may become a problem.
duration: auto
is also very useful/important as a default for group and sequence effects. This is why it's the default value if unspecified for web animations. See the definitions for the intrinsic iteration duration (the duration used when auto
is specified for group effects and sequence effects. I could see delay
being quite useful for these cases.
The CSS Working Group just discussed [scroll-animations-1] Explicit `auto` for `animation-duration` in the `animation` shorthand.
, and agreed to the following:
RESOLVED: accept "auto" as an animation-duration in the animation shorthand
As a follow up to https://github.com/w3c/csswg-drafts/issues/6530, @cdoublev filed https://github.com/w3c/csswg-drafts/pull/8570 to allow
auto
to be parsed in as a value foranimation-duration
when listed in theanimation
shorthand. This issue is to discuss whether we want to do that, given the complications of parsinganimation
.Pros:
animation-duration
to be inlined into theanimation
property.Cons:
auto
. This is unlikely to be a cause problems with keyframes names (which are unlikely to be named “auto”), but it could prevent us from easily inlining some other longhand ofanimation
in the future.Notes:
auto
value foranimation-duration
in theanimation
shorthand by simply omitting the duration, since it's the initial value.Opening this issue to invite discussion about which way to go here.