W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2021

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, 14 May 2021 22:57:01 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-841540498-1621033020-sysbot+gh@w3.org>
@rniwa I want to make sure that y'all have the correct "inheritance" behavior, because I know we've discussed this in the past and you described your behavior as *always* looking up the tree for the nearest defining construct, even if the value is inherited. That is, in [Example 5](https://drafts.csswg.org/css-scoping/#shadow-names), according to what I understood from your previous descriptions both .inner-default and .inner-styled would use the "inner.woff" font, rather than .inner-default using "outer.woff" as the spec requires.

I can't easily test Safari right now; is that still y'all's behavior? Or do you match the spec here?

(The behavior I described is broken, because it violates encapsulation in an important way - if the inner component ever defines a @font-face or similar construct with the same name as one in the outer page, it'll break any property that inherits in *completely by accident*, with no way for the component author to predict that this'll happen ahead of time, or fix it. The only way around it is to always author your components to use UUIDs for their @font-face and similar constructs, to guarantee that a 'font-family' inheriting in won't accidentally change meaning to suddenly refer to your @font-face. I'm not willing to spec that behavior, as it's just broken from an authoring point of view.)

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 May 2021 22:57:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:23 UTC