Re: [css-animations][css-values] More ambiguity questions with the animation shorthand

On Tuesday 2014-05-27 14:10 -0700, Tab Atkins Jr. wrote:
> At the F2F, we agreed to some principles for handling <custom-ident>
> when it can't be disambiguated positionally, based on the 'animation'
> shorthand.  Basically, values should be assigned to the longhands
> greedily, with the <custom-ident> longhand having the lowest priority
> when claiming a value.  That way, "animation: ease-in linear;" gets
> parsed with a timing-function or "ease-in" and a name of "linear".
> 
> This works fine when the value spaces that <custom-ident> might clash
> with contain *only* idents, but it's less clear what to do when they
> can contain other things, like functions.  In particular, how should
> we parse "animation: ease-in steps(2);"?  Should we greedily assign
> ease-in to timing-function, and then fail to parse the property when
> we hit the function?  Or should we allow new values to reassign
> things, so we get a name of "ease-in" and a timing-function of
> "steps(2)"?
> 
> The latter is basically the list-style behavior, where you can't tell,
> upon seeing a "none", whether it should be assigned to list-style-type
> or list-style-image until you see the rest of the property.

On Wednesday 2014-05-28 00:23 +0000, Sylvain Galineau wrote:
> Keeping track of animation shorthand parsing feedback in https://www.w3.org/Bugs/Public/show_bug.cgi?id=14805

On Friday 2014-12-19 11:34 -0800, Tab Atkins Jr. wrote:
> Ping dbaron?  We're trying to fix up V&U to match the intent expressed
> here, but it's unclear how to handle this case.

So I presume the face-to-face discussion in question was the part
minuted in
http://www.w3.org/mid/CADhPm3sD7HofSOrOw84CC7tgCqcOXwpq+0nN3P4sM5bKfbGygQ@mail.gmail.com
with Subject: [CSSWG] Minutes Seoul F2F 2014-05-19 Part IV: Values and Units


So, for a start, I don't think we should model other things on the
'animation' shorthand; it has a whole bunch of problems:

 * there are two times distinguished positionally,

 * it has a custom ident mixed with three keyword values, one
   keyword or function value, one keyword or number value, and two
   times, all distinguished only by order, and

 * animation-fill-mode and animation-name both take 'none' (in the
   latter case it's the non-custom value of the custom-ident)

(Note that implementations that incorrectly allow unitless '0' times
have quite a few more ambiguous cases.)

I think that in general we should avoid greedy assignment by not
needing it.  If values of a shorthand are ambiguous in their
assignment to longhands, the shorthand syntax should not allow those
longhands to appear in any order.  I'm inclined to think that there
should be a note in the custom-idents section of the syntax module
that specs should avoid falling back on greedy assignment whenever
possible.

However, we have a backwards-compatibility problem both with the
'animation' shorthand, and with 'list-style' resulting from the
addition of custom counter styles.

On the question you asked:  it's certainly easier from an
implementation perspective to reject values like:
  animation: ease-in steps(2);
  animation: infinite 2;
by assigning the first value to animation-timing-function or
animation-iteration-count and then rejecting the second value, even
though the first value could have been the animation-name.  I don't
think there's much of an argument for tools or libraries for
allowing such syntax, either, since they should tend towards the
pattern of putting 'animation-name' last to avoid this set of
problems.  That said, it does feel inconsistent with the rest of CSS
to reject a set of values that could reasonably be assigned to the
longhands.

I'm inclined to think that:

 (a) if we currently have good interop on the greedy behavior for
 'animation', we should stick to it, because I don't think it makes
 'animation' particularly worse than it is already

 (b) if we don't currently have interop, I don't have a strong
 opinion.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)