- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Sat, 05 Mar 2022 00:04:48 +0000
- To: public-css-archive@w3.org
> Its as wrong as not having scoped element registries from the start, or not enabling font-face in shadow dom... same rubbish. Yes, not having @font-face work *at all* in shadows was broken, but it wasn't intentional either. Handling it correctly was just more subtle and complex than originally expected. The spec for this *is* now well-defined and correct, and browsers are catching up, and it correctly hides information defined in the shadow. Like I said, the *intention* of shadow DOM, the reason it was created, was as an info-hiding mechanism to enable third-party components to exist without having to worry about coordinating with the outer page; it was "let's make jQuery UI suck less". (I know, I was there as part of the group defining it.) Shadow DOM is *also* useful for corraling HTML and CSS within a page, but its design is a bit restrictive if used in this way. The solution is not to make individual features less restrictive in an inconsistent manner, but rather to either add a mode to Shadow DOM that is designed for first-party code and generally "transparent" to the outer page, or achieve similar complexity-hiding benefits via new, less restrictive features. I understand that you're frustrated because you're attempting to use Shadow DOM for first-party content (or at least, third-party content that's designed to explicitly cooperate with the outer page). That's just a use-case that is, currently, explicitly not handled well. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1059614675 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 5 March 2022 00:04:50 UTC