- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Aug 2018 17:49:36 +0000
- To: public-css-archive@w3.org
We tried the deep combinator; what it ended up with in practice (that is, based on experience from real developers writing real code with it) was fragile and error-prone code. You end up losing the nice "I know exactly what I'm targetting" quality that shadow DOM's encapsulation is supposed to provide, because you can write a rule deep-targetting a particular class you know about, and accidentally hit *other* components that happen to use that same class internally, which isn't a detail you should normally need to worry about. And that's not even getting into the fact that you're now relying directly on internal structure of things that you aren't supposed to care too much about the internal structure of, so any updates to the component are likely to break your code. Switching to ::part means that component authors get to publish a reliable, stable styling API that's robust to changes they make in the future, and they aren't exposing more details than necessary about the internal state of their component. For component users, it means that they know exactly what's safe to target, and it's *completely impossible* to accidentally over-target unrelated elements in other components. This is more limited, yes, but this is the level of limitation that appears to hit the sweet spot. It's intentionally *very* similar to any class-based programming language using private state, or JS using closure-variables, to hide internal variables from outside code - if you have to reach into the internals of a class, either you're doing something very wrong, or the class author wrote a bad API for their class. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2963#issuecomment-409662508 using your GitHub account
Received on Wednesday, 1 August 2018 17:50:11 UTC