Css animations for UA shadow DOM.

[Khushal Sagar]

Hello style-dev

I'm trying to add some UI to the shadow DOM that requires the use of css keyframe animations, which looks like is currently not supported. The details are on bug: 724975. A patch to workaround the issue currently under review is here: crrev.com/2895913002/.

The question on the review is regarding whether adding keyframe animations in UA stylesheet will pollute the namespace for author animations. The patch in question is avoiding this by making sure that keyframe rules from UA stylesheets are used only for animations on a UA shadow DOM element. The current behaviour which isolates the scope of rules for author animations from shadow DOM elements is also retained. I'm not sure if this implementation is the best way to achieve this or if there is an alternate approach I could be considering.

Any pointers would be appreciated. For reference, the patch that needs to add the css animation is here: crrev.com/2898543002/.

Thanks.
Khushal

[Takayoshi Kochi]

I was in conversation with Khushal on this matter.

The requirement is to define @keyframes rule in UA stylesheet, and apply it in user-agent shadow tree.

As @keyframes identifiers are scoped per-tree, if one is defined in UA stylesheet, it doesn't apply to shadow trees.

So probably the solution is to add

<style>

@keyframes -internal-media-controls-promo-throbbing { ... }

</style>

to each shadow tree attached to <video> element.

Looking up the keyframe name only for UA shadows sounds a very hacky workaround.

That said, for <progress> element or whatever element that uses UA shadow,

it would be nice if CSS animations in UA style can be used for animating them.

Duplicating the style for each element may not be very efficient in memory-wise,

if 1000s of such elements are used in a page.

--
You received this message because you are subscribed to the Google Groups "style-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to style-dev+unsubscribe@chromium.org.
To post to this group, send email to styl...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/style-dev/CAMLuWUz1UghmKTku5YE0Fa-J9eKO%3DuKVRiJe%2BZDaZ43EYjeTXw%40mail.gmail.com.

--

Takayoshi Kochi

[Takayoshi Kochi]

BTW, once I was assigned to a bug to add animation to <progress>'s

pseudo element (::-webkit-progress-value) crbug.com/486195

The resolution was WontFix, as @keyframes defined in author's stylesheet cannot affect

UA shadow tree.  On the other hand, Safari (I confirmed today) still allows user

to add @keyframes animation to progress::-webkit-progress-value.

See the demo in the linked crbug (for impatient, http://codepen.io/phosphoer/pen/VLemML).

--

Takayoshi Kochi

[Rune Lillesveen]

On Tue, May 23, 2017 at 8:33 AM, Khushal Sagar <khusha...@chromium.org> wrote:

Hello style-dev

I'm trying to add some UI to the shadow DOM that requires the use of css keyframe animations, which looks like is currently not supported. The details are on bug: 724975. A patch to workaround the issue currently under review is here: crrev.com/2895913002/.

The question on the review is regarding whether adding keyframe animations in UA stylesheet will pollute the namespace for author animations. The patch in question is avoiding this by making sure that keyframe rules from UA stylesheets are used only for animations on a UA shadow DOM element. The current behaviour which isolates the scope of rules for author animations from shadow DOM elements is also retained. I'm not sure if this implementation is the best way to achieve this or if there is an alternate approach I could be considering.

Ideally, I think we should do this by adding a style element in the UA shadow instead of continously adding more ::-internal pseudo elements to make this work from the document scope. This is the way it's done to encapsulate style for author shadow. As UA shadow trees are created in C++, we can make insertion of the UA sheet into the shadow cheap if the standard method of adding text children and use a text based cache turns out to be an issue.

I just re-discovered that we don't add ::-internal* or ::-webkit* explicitly as supported, but accept all variants as valid selectors, which means that we'll incorrectly accept them as valid selectors in author sheets. ::-internal-* should be easy to drop for author sheets, but some of the ::-webkit* ones need to be exposed for compat. We should get to the stage where we would standardize the ::-webkit-* pseudos which should be web-facing and explicitly allow those and drop all ::-internal- pseudos at parsing time.

Any pointers would be appreciated. For reference, the patch that needs to add the css animation is here: crrev.com/2898543002/.

This change will work, but it seems a bit backwards to work around what would naturally be handled with shadow encapsulation using non-standard shadow-piercing rules. At some point I think we should try fix that.

--

Rune Lillesveen

[Rune Lillesveen]

On Tue, May 23, 2017 at 11:09 AM, Takayoshi Kochi <ko...@chromium.org> wrote:

I was in conversation with Khushal on this matter.

The requirement is to define @keyframes rule in UA stylesheet, and apply it in user-agent shadow tree.

As @keyframes identifiers are scoped per-tree, if one is defined in UA stylesheet, it doesn't apply to shadow trees.

So probably the solution is to add

<style>

@keyframes -internal-media-controls-promo-throbbing { ... }

</style>

to each shadow tree attached to <video> element. 

Looking up the keyframe name only for UA shadows sounds a very hacky workaround.

Or even use a separate stylesheet for all of video controls inside the UA shadow where we instead of:

  video::-internal-media-controls-promo-animation {

    display: flex;

    ...

    animation: -internal-media-controls-promo-throbbing 2s infinite;

  }

  @keyframes -internal-media-controls-promo-throbbing {

    0% {transform: scale(0.5, 0.5);}

     ...

  }

would write:

  #promo-animation {

    display: flex;

    ...

    animation: promo-throbbing 2s infinite;

  }

  @keyframes promo-throbbing {

    0% {transform: scale(0.5, 0.5);}

     ...

  }

That said, for <progress> element or whatever element that uses UA shadow,

it would be nice if CSS animations in UA style can be used for animating them.

Duplicating the style for each element may not be very efficient in memory-wise,

if 1000s of such elements are used in a page.

I don't think this is any different than for instantiating the same component many times with author shadow dom. The StyleContents is shared for those cases. As I mentioned in my previous mail we can fast-path this for UA shadow if it turns out to be an issue.

--

Rune Lillesveen