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

Okay, thinking thru scoping @property. The big problem, which I cite in the spec, is the idea that an inheriting value can cross a boundary and suddenly be subject to a different registration. If the shadow didn't *realize* that it was going to be receiving this value (it intended the property only for internal use), this could be really weird.

Noam suggested having a scoped registration cause the property's inheritance to be *blocked*, so it can't accidentally receive a confusing value from the outside when it didn't intend it. I think this sounds pretty good; the big question is what to do *on the host element* - it exists in both trees and could be reasonably styled using either registration.

I suspect we should apply the scoped registration to the host element, and have it block inheritance from its parent. This allows (a) the shadow to set a value on the host element and have it inherit to everything (otherwise it has to set the value on all the top-level elements of the shadow, which is harder and odder), and (b) still allows the outer page to set the property *on* the host element to send a value into the shadow. It prevents the page using its own registration *anywhere else* from accidentally sending a weird value into the shadow.

It does mean that the outer page can't use its own property registration *on* the host element, but *someone's* gonna lose that tug-of-war; I think letting the shadow tree take it is better.

--------

(This all assumes we're going with the simple mechanism of "a property only has one registration at a time on a given element", not something more complex like implicitly making custom properties a (tree-scope, property name) tuple.)

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10541#issuecomment-2378190279 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 00:44:19 UTC