- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Feb 2021 16:09:17 +0000
- To: public-css-archive@w3.org
> The combination of these two things means you can write any selector you would use :const() for using an attribute instead. In terms of expressive power, both have the same benefits. Yes, when you scope the benefits to "can I write a selector that responds to this quality", you're right. But as I said, one of the big benefits is being able to *apply* the quality via CSS; using attributes means you instead have to do it with static markup or with JS; in the limit, where you're adding/removing/mutating things that would affect the selector you're applying it with, reproducing this in JS requires some pretty subtle and non-trivial MutationObserver work. That's the *benefit* of Selectors, tho. So, losing that is a significant blow. (Reading Lea's reply now, they hit on the same argument.) > I just realized one more reason to make this an @property option instead of new syntax: It promotes better encapsulation. Oh I agree that this is a benefit, yeah. I just, currently at least, think the benefits of having these *completely behaviorally different* properties have a syntactic difference as well outweighs the downsides of authors having to decide which of the two styling methods they want to use. In particular, the fact that you can't set a const property according to a const selector is important, and much harder to see what's going wrong if the property looks the same as all your other custom properties. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5624#issuecomment-773422438 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 February 2021 16:09:19 UTC