- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Sep 2024 08:20:14 +0000
- To: public-css-archive@w3.org
> (Another way of looking at this is that global() just changes the way we construct a tree-scoped name/ref. Normally it's a (name, scope) pair with the scope being an automatically-filled-in tree reference; if you use global(), we instead set the scope to the given ident. Matching rules still work otherwise the same, requiring both names and scopes to match. ) Hmm, tree-scoped lookup works by traversing the tree-scope chain, looking for a match (at least for some @-rule cases). We'd now need to place the thing constructed by `@whatever global(--foo)` into a non-home tree-scope (for the first time), which might cause some issues. But even with that, this sounds straightforward. Regarding the `scope-name` parameter: is it wise to add _another_ scoping mechanism to the soup of (Shadow DOM, `@scope`, `timeline-scope`, `anchor-scope`)? Is `global(--foo, --wikipedia)` a huge improvement over `global(--wikipedia-foo)`? Maybe we can drop this parameter, and just rely on prefixing. If dynamic prefixing is needed, maybe consider #9141. > It's possible that the correct answer to these requests is that we need a way to opt a shadow tree out of being encapsulated, so it acts like it's part of the outer page as much as possible (no more event censoring, etc either). I'd expect many authors to prefer this. Related: #10420 -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10808#issuecomment-2324112426 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 September 2024 08:20:15 UTC