- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Apr 2019 14:26:39 +0000
- To: public-css-archive@w3.org
> Right, but scoped() only solves this particular case, and only if the "source" and "target" elements are in the same tree. Which I think would be the overwhelming case, right? We built shadows for encapsulation, and made it rather awkward for scripts to reach into or out of a shadow tree. We *could* solve it fully with a TypedOM value, where the reified value has an actual object reference to the TreeScope the value is coming from, so that it correctly maintains its reference even if you move it between scopes. It's just the serialized value that won't be right. A possible compromise, then: could we agree on having TypedOM values be a special object that tracks the defining scope when relevant, and leave serialization alone? So when you get a CSSFontFamilyValue or whatever, it'll have both a `.name` and a `.scope` (or `.source`? other names?) property, with the latter being the appropriate Document or ShadowRoot object. Then we wouldn't introduce the `scoped()` function; interacting with values inherited across shadows via string-OM will just be possibly dangerous in rare situations. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-484912060 using your GitHub account
Received on Friday, 19 April 2019 14:26:40 UTC