- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Sat, 12 Oct 2019 17:02:41 +0000
- To: public-css-archive@w3.org
> But to me that just means that in your calendar widget example, the weekend/holiday status should be a class, rather than a pseudo class (or a part). I mean, yes, but we purposely don't expose the classes of a shadow element to the light dom, so the component can freely use classes internally for its own purposes without worrying about the component-user relying on them. And that's why I designed part names to have class semantics in the first place, rather than tagname semantics. ^_^ > You didn't address the differences in specificity between the examples. Correct; I don't feel it's a very important difference. This is generally always going to be "CSS in the small", where specificity doesn't matter as much and you can lean a lot harder on "just put them in the order you want". Especially now that we have the `:where()` escape hatch when necessary. > At the end of the day, yes, we can mix in the notions of class into parts, but the question here is: should we? I really want ::part to just be a custom pseudo element, that acts like a built in pseudo element, and explains the built in pseudo elements, not something new with its own magic and its own rules. Especially when the 'new magic' is something authors already have via other existing mechanisms. If we don't, we'll still need to expose a class-like semantic *somehow*. CSS made an early awkward choice for pseudo-element syntax that we're stuck with now; I'm just working within those bounds to expose the semantics we need. The tagname limitation isn't doing any useful work here, imo; the class semantic is actually something we need. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4412#issuecomment-541343094 using your GitHub account
Received on Saturday, 12 October 2019 17:02:42 UTC