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

> Variables (that is, custom properties) have no relevance here. They're already correctly element-scoped+inherited, so there's no sense in which `scoped()` can apply to them.

I was using the shorthand term of variables to refer to global name-defining constructs, which I incorrectly assumed was clear from the context of this discussion, but I digress :)

Perhaps it is a good idea at this point to summarise the current proposal in its entirety, which I will attempt below.

## Proposal summary

### Definition of Terms
_Name-defining construct_
Any CSS rule that creates a new 'name' that values can refer to, such as `@font-face` or `@keyframes`.

_Named value_
Any CSS property value that refers to a 'name' that can be defined using a name-defining construct, such as values of `font-family` and `animation-name`.


### Rules
CSS name-defining constructs (`@font-face`, `@keyframes`, etc) define those names in the nearest enclosing `ShadowRoot` or `Document` of the `<style>` node or constructed stylesheet that contains the name-defining construct.

CSS named values should resolve by looking up the name in the nearest enclosing `ShadowRoot` or `Document` of the `<style>` node or constructed stylesheet where the name was used.

If a CSS named value is set through the `.style` property of a Node, the nearest enclosing `ShadowRoot` or `Document` of that node shall be used to look up the value instead.

If a name is not defined in a scope, a recursive lookup should find that name through the containing shadow tree hierarchy up to the document (similar to CSS variables).

The internal representation of a named value consists of a `name` and `scope`. The `scope` is a `ShadowRoot` or `Document` object and refers to a shadow tree or document where the name should be looked up.

Serialising a named value (through `getComputedStyle` or other methods) is unchanged, which means it returns only the name, and scope information is lost.

When retrieving a named value through TypedOM, both the name and scope component will be available through `name` and `scope` properties.

When setting a named value through TypedOM, a specific scope can be provided, which overrides the default of the nearest enclosing `ShadowRoot` or `Document` of the element.

For CSS properties that are inherited through shadow tree boundaries (such as `font-family`) the inherited value retains the original scope.

### Open questions

 - What happens when CSS documents are loaded in through `<link rel="stylesheet">` elements inside a shadow tree?
   - Do name-defining constructs in that CSS document re-define the name inside that shadow tree?
   - Do properties using named values look up the names again in the context of that shadow tree?

 - How to name the property that refers to the lookup location of a CSS named value in a TypedOM CSS property value
   - Candidates: `.scope`, `.source`, `.context`

 - What happens when an element has a style with a named value set with the default scope of the nearest enclosing `ShadowRoot` or `Document`, and that element is moved to another document or shadow tree? Does the named value retain it's original scope, or does the scope change to the new location?

### Known issues

When using traditional (non-TypedOM) methods to retrieve a named value, some information is lost. This means that reading and setting the same value may have the side-effect of changing the `scope` component of an element's style, e.g. `el.style.fontFamily = el.style.fontFamily` is not side-effect free.

----------------------------

In order to make sure we are not missing some edge cases, it would be nice to have complete lists for:

 - All name-defining constructs 
   - `@font-face`, `@keyframes`, ...?

 - All CSS properties that use named values
   - `font`, `font-family`, `animation`, `animation-name`, ...?

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

Received on Monday, 22 April 2019 15:34:37 UTC