- From: Clar Fon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Mar 2023 07:22:05 +0000
- To: public-css-archive@w3.org
Mostly just to solidify the argument, we already have two things decided by the standard: 1) Since CSS doesn't have the concept of namespaces, stylesheets have to handle name conflicts on their own. Yes, variables can be narrowed in scope to specific selectors, but if multiple different stylesheets included on a single page all define their own variables on the `:root` element, they have to handle name conflicts among themselves. 2) The standard *already* makes the distinction between vars and environments, where vars are defined in selectors and only are usable in selector scopes, whereas environments are defined globally and are usable anywhere, including places that variables aren't allowed like in media queries. You could argue that there are shortcomings of this approach, but that would require a completely separate proposal, rather than just one that lets you define environments. Really, the only question is syntax, since CSS has a few standard things that we can work off of: 1) In the same scope (and since environments are all global, they have the same scope), multiple definitions just override each other in the order they're found in the stylesheet. So, if someone defined an environment twice, it would just override the existing value. 2) Variables use the `--` prefix to define properties, meaning that all variables have the `--` prefix. It would make sense for user-defined environments to have the same convention. Additionally, although it's not *strictly* required, it makes the most logical sense to simply borrow the syntax for defining variables as properties and instead define a block syntax that makes these properties turn into environments instead of variables. So, it would make sense to have something like `@env { --property: value }` rather than `const --property: value`, although both are technically allowed. There could be a separate proposal to allow modules or namespaces which could later be expanded to include environments, but this wouldn't be part of environments themselves. It's a separate problem that people have tried to solve, but IMHO it's orthogonal to the concern of defining custom environments. -- GitHub Notification of comment by clarfonthey Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2627#issuecomment-1473287328 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 17 March 2023 07:22:07 UTC