Re: [csswg-drafts] [css-scoping] Handling global name-defining constructs in shadow trees

I think we are actually seeing a different issue here. All browsers with Web Component support use local definitions by default (including Chrome), at least for @keyframes definitions (I will check @font-face behaviours and report back) but there is an inconsistency in how slotted elements are treated.

Chrome uses local definition in the scope where the DOM node the animation is targeting is defined, as per this example:

```html
<my-component>
  <div id="one"></div>
  <::shadow>
    <style>
      @keyframes some-animation { ... };
      div {
       animation-name: some-animation;
      }
      ::slotted(div) {
        animation-name: some-animation;
      }
    </style>
    <div id="two"></div>
    <slot></slot>
  </>
</>
```

In this case, `div#one`  is attached inside the lightdom (outside `my-component` shadow tree), so Chrome will look for a definition in that scope, fail to find, and do nothing. `div#two` is attached inside the shadow tree of `my-component` so Chrome will look there for `some-animation` and apply the animation correctly.

Safari will apply the animation correctly in both cases, because it uses the scope of the CSS reference (the `animation-name: some-animation`).

I feel like the correct scope to use should be the scope where the CSS reference is made, and not the scope where the affected node is attached to the DOM.

A more complete reproduction with comments can be found here: https://codepen.io/ruphin/pen/zPQvXw

Both browsers are in agreement on the scoping rules of @keyframes definitions except for the case of slotted elements styled from within the shadowroot. Chrome renders a red and two green squares, and Safari renders a blue and two green squares.

-- 
GitHub Notification of comment by ruphin
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-367170832 using your GitHub account

Received on Wednesday, 21 February 2018 00:30:35 UTC