Re: [css-houdini-drafts] [css-properties-values-api] Should property registration be scoped? (#939)

I strongly agree that it would be great to scope these, in the same way as we intend to scope other CSS values. (And on that point, will someone *please* [either commit to this proposal or offer a credible alternative](https://github.com/w3c/csswg-drafts/issues/1995)?)

This means scoping to tree scopes, and the registration you use depends on the scope the stylesheet is in. (Tho this has some issues, which I'll discuss in a sec.)

> What happens when the property inherits from one scope into another, and the registration details change between scopes?

I think inheritance should happen with the synthesized token stream, as if you'd just set that token stream directly in the new context. Syntax has only a relatively small effect on registered properties, just making it go iacvt if necessary, and affecting how it reifies in Typed OM.

> What does it mean to use constructable style sheets, where the one CSSStyleSheet object could be inserted into multiple shadow trees, and the registration differs between shadow trees?

You already have to track the stylesheet separately in each location it's inserted into, as the separate locations can already clash and have to be resolved based on document order/shadow origin/etc. (Eg a stylesheet can be inserted into both the outer page and a shadow, targeting the same element with a `.foo` rule from the light side and a `:host` rule from the shadow side.)

------

I think the *biggest* conflict here is: what registration does an element use when it's a shadow host? That is, if the main page registers `--foo` with `syntax:"<length>"`, and the shadow registers it with `syntax:"<color>"`, if you set "--foo: red;" on a shadow host is it iacvt or a valid red?

Perhaps it matters based on where that rule comes from? Aka, a custom property's value carries the value's scope with it, and once you run the cascade and figure out which value wins, you know how to process it as a computed value? I think this matches with the proposed behavior in <https://github.com/w3c/csswg-drafts/issues/1995> for other properties -- setting `font-family: foo` can refer to either the light or shadow `@font { font-family: foo; }` based on whether the declaration is from the light or shadow tree.

However, it does mean that a script trying to use the Typed OM to interact with the property might be confused by what it gets! In my example, if the outer page asks for the value, it'll be expecting a CSSNumericValue, but it might instead get a CSSColorValue if the declaration from the shadow wins. Maybe that's okay?

An alternative is that the element uses the declaration of the tree it's in, always. This means that a shadow tree can't reliably register a property and then use that property on the `:host` element, because if the outer page has a conflicting registration, the property will become iacvt if the shadow rule wins the cascade. I guess we'd then document that shadows should never use custom properties on `:host` for any reason (whether you register the property or not!), and instead only use them on top-level elements actually in the shadow tree.

I don't think there's any completely ideal answer here.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/939#issuecomment-531628630 using your GitHub account

Received on Monday, 16 September 2019 03:09:33 UTC