[csswg-drafts] Ambiguity in transition shorthand property as defined by grammar (#12494)

keithamus has just created a new issue for https://github.com/w3c/csswg-drafts:

== Ambiguity in transition shorthand property as defined by grammar ==
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 <custom-ident>, and represents any valid [CSS identifier](https://drafts.csswg.org/css-values-4/#css-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](https://infra.spec.whatwg.org/#string-is)" 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](https://searchfox.org/mozilla-central/source/servo/components/style/values/specified/animation.rs#25-33).

- 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](https://searchfox.org/mozilla-central/source/servo/components/style/properties/shorthands/ui.mako.rs#56-62), which avoids running into this ambiguity ([it seems as though Firefox used to parse in grammar order but changed due to this very issue](https://searchfox.org/mozilla-central/diff/42086632ef77028d59a9152e56b2b51a40c28610/servo/components/style/properties/shorthand/box.mako.rs#100-106)). 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12494 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 17 July 2025 20:07:24 UTC