[csswg-drafts] [css-cascade-6] change lower boundary keyword for @scope to "until" (#7943)

grncdr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-cascade-6] change lower boundary keyword for @scope to "until" ==
The current proposed syntax for `@scope` rules with a lower bound is:

> ```css
> @scope ([data-scope='main-component']) to ([data-scope]) {
>   p { color: red; }
> 
>   /* only the outer section is part of the outer scope */
>   section { background: snow; }
> }
> ```
>
> https://drafts.csswg.org/css-cascade-6/#at-ruledef-scope

A smaller change that was proposed in #6577 but did not get explored further (as far as I know) was using the keyword `until` instead of `to` for an exclusive lower bound. I'd like to request that "until" be considered as a more suitable keyword.

* it clearly communicates that the lower bound is exclusive (which is great, I 1000% agree with that resolution).
* it is less likely to be misread as the second selector being the container.

The above might require a bit of explanation: when discussing scope in other programming contexts (e.g. JavaScript) the statement "X is scoped to Y" designates Y as the container of X. A rule like `@scope (.x) to (.y)` does **not** have a similar meaning, despite looking superficially identical.

When searching for examples I found [this article](https://devblogs.microsoft.com/oldnewthing/20120410-00/?p=7893) by Raymond Chen on this exact subject. While his article is about Microsoft, the usage is common across the internet.

There are many more examples on MDN: https://developer.mozilla.org/en-US/search?q=%22scoped%20to%22

---

I recognize this issue is a bit "bikesheddy" but I think it's a big improvement in readability for what is going to be a high-profile feature.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7943 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 23 October 2022 19:43:49 UTC