- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Aug 2024 16:05:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Styling form control pickers`.
<details><summary>The full IRC log of that discussion</summary>
<emilio> jarhar: last time we talked about appearance: base and base-select and applying it to `::picker()`<br>
<emilio> ... looks like both me and fantasai proposed some text we can resolve on<br>
<emilio> ... I think we have some subtle differences between the proposals<br>
<emilio> ... we don't want to burden the dev to force them to apply appearance: base to put appearance in two different places<br>
<emilio> ... I think that's the fundamental disagreement<br>
<emilio> annevk: I think it's hard to go into this with this discussion without knowing Google's longer-term vision<br>
<jarhar> q?<br>
<masonf> q+<br>
<emilio> ... on our vision the picker and the controls are individually styleable<br>
<emilio> ... but Google has mostly focused on select<br>
<jarhar> q+<br>
<astearns> ack masonf<br>
<emilio> masonf: few things, I think we really like the idea of doing it all at once, but it sounds difficult<br>
<jarhar> would putting appearance:base on ::picker() also apply to the main element work?<br>
<emilio> ... I'm glad it seems ok to do appearance: base-select to carve out of that<br>
<emilio> ... I think we should do the same for other controls<br>
<emilio> ... one thing we've discovered with <select> is that they're not independent<br>
<emilio> ... it's difficult to allow customization of the in-page thing<br>
<emilio> ... without accounting for the whole popup and everything<br>
<emilio> ... e.g. for date pickers the most common use case is displaying something else along the date<br>
<dandclark> q+<br>
<emilio> annevk: that feels like a new semantic capability for that control<br>
<una> q+<br>
<emilio> ... we're just talking about styling the page controls as they are today<br>
<emilio> masonf: our opinion is that for most things styling the picker is the main wanted feature<br>
<emilio> ... e.g. if you want a flag on a `<select>` option<br>
<emilio> annevk: we might be seeing different feedback<br>
<emilio> ... I've seen feedback where authors are just trying to get basic form styling working accross UAs and that's hard<br>
<emilio> ... it has been hard for a long time, even just having full control of the box<br>
<emilio> q+<br>
<jarhar> q?<br>
<emilio> masonf: I've heard the same feedback for stuff like checkboxes<br>
<jarhar> q-<br>
<emilio> ... but it's possible, people do it, they put that work<br>
<ntim> `::picker(select) { appearance: base }` is pretty straightforward to write honestly, and you can already write whatever styles you want on `select`<br>
<emilio> ... the things that are impossible are the things people complain about<br>
<emilio> ... and are the things we should focus<br>
<emilio> ... if we just did some of the work for the date picker for example then we'd have complains about not having done the work for the popup<br>
<emilio> annevk: that seems it'd need additional markup which could be the opt-in<br>
<emilio> ... we will continue to add new features to these controls<br>
<emilio> ... to me the sooner we get the appearance: base stylesheet<br>
<emilio> ... the better, then we have the infra for new markup features we can opt them into that<br>
<emilio> masonf: I think that might be too optimistic, devil is in the details<br>
<emilio> ... I want to have the appearance-<control> fallback plan in place<br>
<astearns> ack dandclark<br>
<emilio> dandclark: echoing what masonf said, the feedback we get is about styling the control<br>
<emilio> ... the thing that worries me is the long-term dev experience<br>
<emilio> ... if we do base-{select,range,...} there's a path to make appearance: base apply to anything<br>
<chrishtr> q+<br>
<astearns> ack una<br>
<emilio> ... if we have the different picker stylability, do we have the same long-term possibility of not having the double opt-in?<br>
<emilio> una: echoing a lot of what dandclark mentioned<br>
<emilio> ... one thing that hasn't been brought up is how intrincate the picker and the buttons are<br>
<emilio> ... splitting that opens a can of worms for a lot of the controls<br>
<masonf> Anne: british airways uses native <select> and therefore *can't* style the popup<br>
<emilio> ... even for annevk's example, they don't do it because they can't<br>
<annevk> q+ To say that discoverability as to whether appearance:base applies to a picker would also be lost if it's not toggled separately.<br>
<emilio> ... I think that's a testament of why they need to be tied together<br>
<emilio> ... the more that we dig into it the most nuances we find<br>
<emilio> ... the pickers are very tied to their controls<br>
<ntim> I think people tie the pickers more to modals rather than their in-page controls when it comes to writing design systems<br>
<astearns> ack dbaron<br>
<emilio> dbaron: there was something annevk said about the complaints developer have being things about simple styling<br>
<emilio> ... I think one of the things that happens when you focus on the complaints that people have is you focus on things that people could /almost/ do<br>
<emilio> ... there's another way to look at it<br>
<emilio> ... why are authors building their own widgets rather than using the native?<br>
<masonf> Great viewpoint. Developers build their own: selects, date pickers, color pickers, etc...<br>
<emilio> ... I think that's an important q because using the built-in has a lot of advantages<br>
<emilio> ... and when you ask that you get to different conclusions<br>
<chrishtr> q?<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<emilio> ... hard for me to say what the Google strategy is, but I think there's a lot of thinking about figuring out what to do about these users and making them possible<br>
<emilio> ... and I think that explains some of the different conclusions about why tying them together is important<br>
<emilio> ... that might involve other semantic changes, like what masonf mentioned about date pickers<br>
<astearns> ack emilio<br>
<dbaron> ScribeNick: dbaron<br>
<jarhar> q?<br>
<dbaron> emilio: I think I also added myself to the q to react about styling in-page buttons being difficult.<br>
<dbaron> emilio: I think that's true of many controls, such as range.<br>
<dbaron> emilio: but others are fairly consistent<br>
<dbaron> emilio: and to be honest the ones I'm aware are difficult to style are the ones that don't have pickers, like range and slider and progress etc.<br>
<dbaron> emilio: people want to do cool stuff with them<br>
<dbaron> emilio: I think I'm with una that splitting customizability, esp. if we allow pages to use appearnce:base only on the picker, that seems like a can of worms we don't want to get into.<br>
<dbaron> ScribeNick: emilio<br>
<astearns> ack chrishtr<br>
<emilio> chrishtr: I'd like to focus on the points of agreement<br>
<emilio> ... looking at the latest comments<br>
<ntim> emilio: I brought this up last time, but using the native picker can be a design choice<br>
<emilio> ... fantasai rephrased everything to three bullet points<br>
<emilio> ntim: that's the opposite of what I meant tho<br>
<emilio> ... the main disagreement is about whether the select keyword would apply to both or just the select<br>
<emilio> ... I wonder if we can resolve on what fantasai commented on the issue, then discuss about having a single or two opt-ins<br>
<emilio> annevk: I think you can get it in one line :)<br>
<dbaron> fantasai's comment was https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166 (I assume)<br>
<ntim> This is the opt-in in how we ideally see things: `::picker(select) { appearance: base }`<br>
<ntim> or `select, ::picker(select) { appearance: base }` if you the base stylesheet on the select<br>
<emilio> annevk: I still don't have a satisfactory answer on how to make appearance: base apply to everything without tackling all pickers<br>
<emilio> ... like color<br>
<emilio> ... I like the focus on the individual controls<br>
<emilio> ... but it misses looking at the whole<br>
<emilio> ... which is what leads to this clash<br>
<una> q+<br>
<emilio> ... for the color thing you need to know "is there a picker", opt in the picker, did the UA decide to honor my request for custom picker<br>
<Zakim> annevk, you wanted to say that discoverability as to whether appearance:base applies to a picker would also be lost if it's not toggled separately.<br>
<emilio> ... so appearance base would end up computing to auto on the picker for e.g. color inputs on a watch<br>
<ntim> Then in the future once all the pickers are styleable, people can just use `::picker`, along `dialog` and whatever modal-like things exist<br>
<emilio> astearns: any reservations on fantasai's comments<br>
<emilio> emilio: I think the second point is the concern una and myself were talking about, which would allow a base-appearance picker without a base-appearance control<br>
<emilio> una: I think we don't want to block <select> on figuring out the color picker for example<br>
<emilio> chrishtr: it's not blocking, we would just not support the ::picker(color) syntax<br>
<emilio> emilio: not sure we want the ::picker() { appearance: base } unconditionally<br>
<emilio> astearns: let's bring this back to the issue and try to get consensus there<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2305134763 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 August 2024 16:05:46 UTC