FAQ entry on scoped animations is not accurate

[jonrimmer]

The FAQ says that the inability to use keyframe and font-face @-rules within element stylesheets is due to a spec limitation. This is not correct: the linked mailing list post by David Baron is only a suggestion, and has not in fact been implemented in the relevant part of the spec, which at present only says @page rules should be ignored. The fact that they do not work is an implementation issue, one that there has already been some effort to address within Webkit. Even if David Baron's suggestion is eventually adopted, Tab Atkins has indicated that there will still be some mechanism to scope these @ rules to components.

It would be more accurate to say simply that @keyframe and @font-face do not work at present within element stylesheets, but that this will eventually be addressed, and in the meantime it can be worked around by including the definitions globally.

This might seems like a small thing, but the fact that animations do not work within elements is likely to be one of the first problems authors encounter (it was the first I came across), and it will only contribute to the negativity already felt by some authors towards standards groups by suggesting that this is a restriction imposed by spec fiat, when it is not, and the use case for components has been recognised and will be addressed.

[TedDriggs]

I just tested this and found that only Chrome doesn't support @Keyframes in scoped style blocks. Is this because Firefox and IE 11 don't support scoped styles, or are they exhibiting the desired behavior?

[ebidel]

This section was removed from the docs a while back because the underlying Blink issue was fixed: https://code.google.com/p/chromium/issues/detail?id=229345. However in testing this again, I'm not seeing @keyframes work correctly in shadowRoots. I've reopened https://code.google.com/p/chromium/issues/detail?id=244914.

Closing this issue as it's no longer relevant for the docs.