I'm having a little trouble interpreting the spec. I can of course resolve this pragmatically, but I think there exists an ambiguity in the spec that I'm interested in teasing out to see if I am misinterpreting some fundemental aspect of parsing or if there is something more than can be done to shre up the spec...

The grammar for transition (and related grammars) are defined as:

<single-transition>*

<single-transition> = [ none | <single-transition-property> ] || <time> || <easing-function> || <time>

<single-transition-property> = all | <custom-ident> 

<easing-function> = <linear-easing-function> | <cubic-bezier-easing-function> | <step-easing-function>

<linear-easing-function> = linear | <linear()>

<cubic-bezier-easing-function> =   ease | ease-in | ease-out | ease-in-out | <cubic-bezier()>

<step-easing-function> = step-start | step-end | <steps()> 

....

The problem is that to parse in grammar order <single-transition-property> comes before the <easing-function> type, which would mean a property value like ease-in would first go to <single-transition-property> and then be swallowed by <custom-ident>.

<custom-ident> is defined as:

Some properties accept arbitrary author-defined identifiers as a component value. This generic data type is denoted by , and represents any valid CSS identifier that would not be misinterpreted as a pre-defined keyword in that property’s value definition. Such identifiers are fully case-sensitive (meaning they’re compared using the "identical to" operation), even in the ASCII range (e.g. example and EXAMPLE are two different, unrelated user-defined identifiers).

I think a resolution could be interpreted a few ways:

• The <custom-ident> of <single-transition-property> disallows all, but in the context of <single-transition> it disallows all idents in <easing-function>. This means nodes have some kind of dynamic disallow list dependant on their context?

• There is some kind of missing prose/spec for <single-transition-property> (or its <custom-ident> production) which stipulates that the allowed keywords are an unspecified subset, which engines are left up to define? Firefox certainly doesn't simply represent this as a custom-ident, but rather a more complex enum which includes enumerating is as a known vs unknown property.

• Perhaps parse order is implicitly different to grammar order? Again this is definitely the case for Firefox, which attempts to parse the easing-function before property, which avoids running into this ambiguity (it seems as though Firefox used to parse in grammar order but changed due to this very issue). Should we somehow make parse order more explicit? We already have a canonical serialisation order, so perhaps it would take much to tweak the grammar to put <easing-function> first and re-define the order in the canonical order field?

It would be great to get some clarity here.

/cc editors of css-transitions-1 @dbaron @grorg @birtles.
/cc @maraisr who discovered this issue with me.