- From: Una Kravets via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Jul 2024 17:48:41 +0000
- To: public-css-archive@w3.org
Just catching up on the latest status on this. I want to advocate for simplicity for this feature from a user perspective. It doesn't seem like there is a benefit to developers (or a difference) between `select { appearance:base; }` and `select::picker(select) { appearance:base; }`. Why force developers to remember both selectors that they will need to target, degrading the developer experience? The most likely and straightforward developer experience would be to name these selects, i.e. with a class, and access them like `.account-dropdown { appearance: base; /* styles */ }`. Ideally that is all that would be needed to enter into this new behavior, and we wouldn't require an additional pseudo class. With the picker proposal, developers would need to write: ``` .account-dropdown { appearance: base; /* styles */ } .account-dropdown::picker(select) { appearance: base; } ``` *(As an aside, would styles need to be duplicated? Where would they live, on the select itself or on the `::picker` pseudo?)* Similarly, I would prefer not to have custom identifiers with specified names for each type of select. `::picker(form-control-identifier)` is a more roundabout developer experience than just targeting your element via a class or other developer-owned identifier. This requires developers to remember the custom identifier for each type of picker in addition to the custom class name they have likely selected to target the picker. In reality, developers will likely need to be looking up these identifier values to make sure they're getting them right. A natural developer experience would be to connect their custom code like: ``` .profile-color { appearance: base; /* rest of your styles */ } ``` Rather than connect it and then look up the correct picker to sync with: ``` .profile-border-color { appearance: base; /* rest of your styles */ } .profile-border-color::picker(color) { appearance: base; } ``` Is it possible to infer the types here to prevent this additional lookup and code for a more seamless developer experience? -- GitHub Notification of comment by una Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2237160607 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 18 July 2024 17:48:42 UTC