[css-animations] Consider accepting string as animation name

[upsuper]

WebKit's implementation supports using a string after @keyframes and animation-name. Blink supports this syntax for prefixed stuffs but not for unprefixed ones.

We've seen a website depends on this syntax (webcompat/web-bugs#2337). Not sure how widely this kind of thing is used, but in general, I guess it is not a bad idea to accept string as animation name.

I raised this for the compat spec (whatwg/compat#43) but it'd probably better to be discussed in CSSWG.

[tabatkins]

I'm fine with allowing this. Ignoring compat, it lets authors provide animation names without risk of them being misparsed for accidentally coinciding with one of the other animation keywords.

[birtles]

I started working on the edits for this but I'm wondering, is this sufficient?
https://github.com/w3c/csswg-drafts/compare/birtles/allow-strings-for-animation-name

[upsuper]

It seems there is a grammar in section 4 just before 4.1, which is not updated.

[upsuper]

And I think it would also be good to make it clear whether there is any difference between rules defined with a string name and those with an identifier name.

I guess (but not verified carefully) that current implementations which support it would treat ident and "ident" identically. If so, we should probably write that into the spec explicitly.

[tabatkins]

We resolved in the telcon to accept this.

[yisibl]

I'm going to fix the error that esbuild's CSS parser warning when parsing @keyframes <string> { }. So, I've spent a lot of time sorting out this change.

$ esbuild test.css --minify
▲ [WARNING] Expected identifier but found "\"foo\""

    m.css:1:11:
      1 │ @keyframes "foo"  {
        ╵            ~~~~~

1 warning
@keyframes ""{0%{background:#00f}to{background:green}}

• Firefox 53 started supporting animation-name: <string>, but WPT was not updated?
• Chrome doesn't seem to have noticed this change in the spec, and has instead deliberately removed string support in bug 423424. So I'm not sure which versions of Chrome support the animation-name: <string> without the prefix(@andruud, @lilles can you help confirm?) This in turn increases the cost of implementing tools like Autoprefixer( see Chrome does not support animation-name: <string> postcss/autoprefixer#1450).
• Safari I haven't investigated yet.

This is really messed up. I hope that such compatibility issues can be avoided or reduced in the future, and that the addition of string brings a greater cost to other parsers.

[yisibl]

@nt1m Says: #6405 (comment)

I agree supporting both string and ident is not ideal in the long run. It's typically the type of thing that becomes a quirk on the web platform and small maintenance burden for the engine (which accumulate).

[birtles]

• Firefox 53 started supporting animation-name: <string>, but WPT was not updated?

Per that bug, looks like CSS wasn't using WPT at that point in time:

Once the CSSWG moves its tests to web-platform-tests we can work on splitting that mammoth test up into smaller (cross-browser) tests.

[yisibl]

@birtles Thank you for the additional information, do you have plans to update WPT?

[yisibl]

The <string> syntax also seems to make browser serialization more difficult, leading to inconsistencies across browsers, see also: #5846

[birtles]

@birtles Thank you for the additional information, do you have plans to update WPT?

I'm afraid I don't, at this stage. I was working on rewriting the WPT for CSS Animations before I left Mozilla but ran out of time to finish it.