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: Wed, 17 Apr 2019 23:34:51 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-484299843-1555544090-sysbot+gh@w3.org>
> I agree with @rniwa that off-hand I don't think scope() is necessary to solve this. Carrying the name and scope should be enough here.

The purpose of `scoped()` is to express this relationship explicitly in the CSS. If the tree-origin is instead just *implicit and hidden* it means that if you gCS() on two elements in a shadow, they can *appear* to have the same `.fontFamily` value, but *actually* one is magically referring to the outer scope's family of that name, while the other is referring to the shadow's family of that name. This means that reading and writing the value back into `.style` is *not* a no-op; it will change the used font *if and only if* there's a name collision in font families.

That seems unfortunate and weird; I prefer being able to stringify/reify (for TypedOM) the actual value that is being used, rather than lying and reporting a value that will *not* produce the same behavior when you reassign it to the element.

Are y'all willing to explicitly confirm that you're okay with the "reading and reassigning is *not* a no-op and can change behavior when there's a name collision" behavior? If so, then I'll back off and deal with the fact that the underlying value keeps track of scope but the stringified/reified version of the value can't.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-484299843 using your GitHub account
Received on Wednesday, 17 April 2019 23:34:52 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:46 UTC