Does this really need to be Hotlist-Interop? Web authors cannot add, change or affect those anyway (in a standard way, at least), so it seems like an implementation detail.

I don't think I'm the person to work on fixing it - can someone in CSS
animations take ownership of this?

For interop (re comment 3), if UA stylesheet defines some keyframes rule
with some identifier, it may collide with one in author's stylesheets.

#4 - that (a resulting bug of the implementation details) would be an interoperability issue, yes, but it sounds like you are already anticipating that an interoperability issue will be introduced (a new bug), because right now, there is none, regardless of the issue at hand.

#0: Could you land your with a failing test case? That will give us something concrete to work on.

alancutter@ in the meantime the discussion is ongoing at style-dev.
https://groups.google.com/a/chromium.org/d/topic/style-dev/lzBBmDFvwag/discussion

Specifically, in the CL
https://codereview.chromium.org/2898543002/diff/60001/third_party/WebKit/Source/core/css/mediaControls.css
has a keyframe definition

L639: @keyframes -internal-media-controls-promo-throbbing 

but that name doesn't apply to UA shadow (selected via ::-internal-* pseudo id).

@alancutter in short, in UA stylesheet (or could be in author stylesheet)
user cannot put animation with its own @keyframes rule to -webkit-*
pseudo elements.

e.g. (quoting from   issue 486195  ) the following animation doesn't work:

@keyframes progress
{
  0% {left: 0; width: 25%;}
  50% {left: 75%; width: 25%;}
  100% {left: 0; width: 25%;}
}

progress::-webkit-progress-value
{
  position: relative;
  background-color: red;
  animation: progress 5s infinite;
}

All non-animation properties (in this case, "position" and "background-color")
apply, though.

The reason is that the @keyframe rule and ::-webkit-progress-value are in
different DOM trees (document vs user-agent shadow).  However using UA shadow
for -webkit-progress-value is an implementation detail in Blink, therefore
for users the tree distinction doesn't make much sense.
(I haven't tested, but such animation should work for non-ua-shadow pseudo
elements like ::after, right?)

The same issue was once closed as wontfix (see  issue 486195  ).

From shadow dom's point of view, the current behavior is expected
for the reason stated above. But for this issue, it's up to
animations team or style team whether to decide whether to close this as
working as intended, or fix this if you think this is a valid use case.

I think it should work given those shadow DOMs are implementation details.

Should this work in userspace? I'm not familiar with how shadow DOM scoping works exactly.
Example: http://jsbin.com/lonikavovu/edit?html,css,js,output

If it shouldn't work in userspace then I think some kind of escape hatch will need to be made for internal shadow DOMs to help hide the implementation detail that they are in fact shadow DOMs.

No (answering "Should this work in userspace?), @keyframes rule name is
scoped within each shadow tree. So as you said we need something
implemented to allow that leak for UA styles (and maybe author styles,
 issue 486195 ).

BTW, a bit orthogonal from what's going on here, but the jsbin uses
Shadow DOM v0 APIs (createShadowRoot() and ::shadow). Chrome
and Safari implements Shadow DOM v1 APIs.

Especially, v1 API removed a shadow-boundary piercing (from outside to
inside) combinators (namely /deep/ and ::shadow), and use of CSS custom
properties is the recommended way to use.  A CSS selector in the
document tree's stylesheet never matches any element in shadow tree,
but because style inherits from shadow host, custom property works
(--* variables are inherited, thus var() can refer to it).

Here's my rewrite in v1 APIs (moved the shadow style completely in
shadow):
http://jsbin.com/nojiciyime/edit?html,css,js,output

There's also a proposal to add user-defined pseudo element for shadow DOM:
https://tabatkins.github.io/specs/css-shadow-parts/
I'll file an issue for clarification for ::parts() there.

For the record, issue for ::parts() is
https://github.com/w3c/csswg-drafts/issues/1516

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this something we want to support?