Re: [csswg-drafts] [css-properties-values-api] "Property registration cannot be scoped" differs from all implementations in a consistent way (#10541)

> > * a shadow tree that wants to register a custom property _for the outer page to use on it_ is _required_ to do so via a global stylesheet, communicated in a side channel.  (or leave the property unregistered) If they register it in the shadow, the outer page won't be allowed to set it.
> 
> Isn't this true for both variants of this proposal? I wonder if we can solve it using the import/export mechanism we discussed on #10808 where we have an import/export semantic for those names to avoid the side-channel.

Yes, I think having some sort of export mechanism or maybe an attribute when you register the property would be ideal here. The nice thing about tree scoping the names in some way is that it would support simple aliasing to a different name outside.

> > no idea how we'd expose these distinctions via the OM. The methods only take a property name.

Yeah I think by default these methods would have to assume main frame (since the majority of legacy content would expect this), but maybe having an option to specify the scope so that you could get the expected property types and values for your component.

> > OK I understand what proposal means now. It's flexible which is good, but I think this will be extremely confusing. You can have the following be true:
> 
> ```css
> /* in outer scope */
> my-element { background: var(--accent )}
> 
> /* in inner scope */
> :host { color: var(--accent) }
> ```
> 
> In dev-tools or other reflection , it would look like:
> 
> ```css
> background: var(--accent);
> color: var(--accent);
> ```
> 
> But the colors could be different based on where they're set.

Yeah, this is a feature which I think wouldn't be too bad in dev tools since these rules would come from different style blocks in which scope the variable would have different values due to the different scope.

> Note that when you have a `:host` or `::part` (which is where this matters), collisions are anyway an issue in the CSS properties themselves, so keeping that behavior for custom properties is consistent (though less flexible).

If the property was not exported to the top frame though, it is clearly unintended that they would conflict, so it is nice if they can be effectively isolated.

> Its somewhat easier to grasp a model where custom properties are like ordinary properties - an element can only have one `--background-color` in the same way that it has only one `background-color`, and authors should be careful when they use custom properties in `:host` and `::part` just like they need to be careful with ordinary properties in these interface points.

Even if a developer controls both scopes and is really careful, which scope's type / default value would you use on these elements?

The other question which is still a bit unclear to me, is would we be able to inherit a value on the outer scope set on the host in the parts if these conflict?

TLDR, not saying that we have to go with this more complex option, but I think it could have some nice flexibility to manage the conflict. I think we should consider some real use cases or find some means to work out whether it's worth the complexity of custom properties being tree scoped.

Note that making it a tuple on registered scope could be internally handled by some hash of the scope on the name which is internally removed before exposing the property name to the developer which could reduce the implementation complexity.

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


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

Received on Friday, 27 September 2024 03:40:53 UTC