Re: [csswg-drafts] [css-properties-values-api] enhance @property with access-scope control (#9587)

@tabatkins One use case could be if a 3rd-party CSS lib you pull in sets some style like this

```css
button {
  --spacing: 10px;
  padding: var(--spacing);
  margin-block: var(--spacing);
}
```

but then in your own local styles, you have something like this:

```css
button {
  --spacing: 2px;
  letter-spacing: var(--spacing);
}
```

The two rules, having the same specificity, would conflict and either you would override the 3rd-party CSS lib's value, or it would override yours.

Of course, this should be avoidable, and I would hope most libraries would use more unique selectors so they don't cause issues like this, but access scoping feels like it could only help to avoid any issues like this in the future.

Yes, issues like this are not as common, but I've definitely run into them occasionally and often have to increase my selector specificity as a result. It would be great to be able to set up our values so they aren't affected by outside styles.

One difficult consideration here is— if styles for the same element are coming from two different sources, like in the above example, but then you wanted to check the value of the custom property on that element using JS, which would get returned?

```js
getComputedStyle(document.querySelector('button')).getPropertyValue('--spacing')
```

My gut feeling is it should return whichever value—if any—is publicly facing. DevTools would need to account for this with a note about the source for the custom property value in context, if it's not public.

---

What may also be helpful is a way to set `style` elements and external stylesheets to private so that they do not affect our own styles. In many cases, like when using a CSS file for its variables, as is the case with [Open Props](https://open-props.style/), you certainly would not want to take this approach, but when you do, you could do something like this:

```html
<style private>...</style>
```

```html
<link private rel="stylesheet" href="styles.css">
```

```css
@import private "https://.../some-file.css";
```

☝🏼 this, if deemed useful, could probably be handled via a separate proposal.

---

Any of these three other approaches is helpful in putting the power of variable privatization in the hands of developers who want to ensure the variables do not conflict with their site.

Conversely, the original method I proposed would be most useful for library authors who want to use variables for ease of reusability in managing their own styles, but without risking conflicting var names with any apps that import the styles.

This is the primary purpose of this PR and arguably more valuable.

-- 
GitHub Notification of comment by brandonmcconnell
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9587#issuecomment-1804902939 using your GitHub account


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

Received on Friday, 10 November 2023 00:49:26 UTC