- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Sep 2022 21:20:34 +0000
- To: public-css-archive@w3.org
> But maybe this is a problem that should be fixed on the selector side (maybe a class suffix/prefix selector?) instead of by the semantics of scoping. I would likely do it by using a `data-theme` attribute, and then scoping `([data-theme=light]) to ([data-theme])`. ----- Chrome has a prototype for the `@scope` rules using 'weak proximity' behind the 'Experimental Web Platform features' flag (navigate to `chrome://flags` and search). In my experimentation so far, I agree with the majority of responses here that 'weak proximity' is the best way to go. At this point, it would be helpful if anyone arguing for 'strong proximity' could provide examples where it really is preferable. In my mind, to be preferable, proximity has to be the important factor in comparing two unequal selectors. It's possible to invent cases where a weaker selector should override a more powerful one, and where they are also scoped - but that's often a problem to be solved either at the selector level, or with explicit layering. I haven't yet seen a case where scope proximity should be the deciding factor between otherwise properly-unequal selectors. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6790#issuecomment-1239900403 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 September 2022 21:20:36 UTC