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

The behaviour described by @rniwa is what currently happens in all browsers for the `@keyframes` global name (See I think this is the most expected and reasonable behaviour, and `@font-face` should probably behave in a similar way.

Regarding inheritance and variables leaking outside the shadow tree; this is already the case currently. Custom Elements are able to style direct descendants from styles defined in the shadow root, and they can add any style to a direct child, including styles that are inherited. (e.g. `font-family: monospace`). I don't think this is considered 'leaking out' of the shadow tree, otherwise the ability to style descendants would not be part of the spec in the first place. It makes sense that for any styles that are inherited, the complete style is inherited, which in this case includes the correct reference to the correct `@font-family`. 

There is still the question of what happens to slotted content. Currently this is the only feature that exhibits inconsistent behaviour between browsers. The complexity is that when the element is assigned a style (say, `animation`) that refers to a global variable (in this case `@keyframes`), it is not clear which scope it should find this variable.

In my opinion the only reasonable behaviour is to look up that variable in the scope _where the original style was assigned_ (in this case wherever the `animation` style was assigned). Safari correctly does this, but Chrome and Firefox look up the variable in the scope _of the element itself_ which is always outside the shadow root.

The most obvious argument why the behaviour implemented by Chrome and Firefox is wrong, is that it is literally impossible to animate slotted content using `@keyframes` definitions without polluting the global scope.


Personally I never understood the need for a `scoped()` function. The only purpose would be to allow a global variable to be used in a shadow tree instead of the local one, but since the Custom Element implementer has full control over the shadow tree, this can effectively already be done by naming the local variable differently.

GitHub Notification of comment by ruphin
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 16 April 2019 22:01:17 UTC