W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2019

Re: [csswg-drafts] [css-scoping] Handling global name-defining constructs in shadow trees (#1995)

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Fri, 19 Apr 2019 04:21:27 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-484763069-1555647686-sysbot+gh@w3.org>
> It will be impossible to write an inline style declaration that refers to a variable that exists in an outer scope 

Variables (that is, custom properties) have no relevance here. They're already correctly element-scoped+inherited, so there's no sense in which `scoped()` can apply to them.

> Perhaps you're talking about the case where you'd get the computed style of an element then assigning it via element.style?
>
> If so, making that kind of an oddly specific scenario work

Yes, that's the sort of case I'm referring to.

It's not that I find this case particular compelling in and of itself. I just don't like the idea that it would be *literally impossible* to reproduce a shadow-tree element's style *from within the shadow tree* by assigning `.style`. That feels like the sort of frustrating footgun that will annoy authors and cause them them to cuss us in the future. Instead, you have to manually note which properties must be *explicitly kept unset* if you want them to retain their values in all cases; the fact that the cases where this matters are *rare* (only when there's a name collision between the value inherited from the outer page and the new value introduced in the shadow) makes it very likely that it won't be correctly handled, and will be a constant low-level source of bugs for authors.

> or satisfying some kind of conceptual purity doesn't strike as anywhere near as important as making a seemingly very common scenario of using font-face defined outside one's shadow tree work.

We agree that an inherited font-face value needs to work correctly, regardless of name collisions.  We're just disagreeing over whether it's useful for the serialized/reified value to correctly reflect the value, such that re-assigning it is a no-op, or if it's unimportant and it's okay for two identical-serialization values in a tree to secretly refer to two completely different values (only one of which an author can reproduce themselves from within the shadow).

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-484763069 using your GitHub account
Received on Friday, 19 April 2019 04:21:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:07 UTC