- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Aug 2024 16:01:05 +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>
<keithamus> jarhar: I'd like to get to the second issue because it can affect how we name the pseudos.<br>
<keithamus> jarhar: Proposal to have incremental opt in for elements with pickers using ::picker psuedo which you could add appearance:base on to get the new styling for the picker itself.<br>
<keithamus> ... so this would be alternative for e.g. appearance: base-select opt in for each rule<br>
<keithamus> ... one problem is that Chrome is looking to ship select first, so opt in for page pickers is not that helpful<br>
<keithamus> ... on top of that Una posted a comment about it being more of a developer burden for developers to do this on each picker<br>
<keithamus> ... IMO we should have appearance:base on root element for everything without incremental opt in<br>
<keithamus> ... the push back was incremental opt in but una and anne are talking about the same issue regarding opt in<br>
<keithamus> ... ???<br>
<keithamus> ... the author has to remember more things for each element.<br>
<keithamus> ... the whole thing is brought up as a need for incremental opt in<br>
<una> q+<br>
<keithamus> ... but we can add support for supported elments, tweak style to show it didnt apply properly or isn't supported on this element yet.<br>
<gregwhitworth> q+<br>
<keithamus> ... I think it simplifies it.<br>
<gregwhitworth> ack fantasai<br>
<gregwhitworth> ack gregwhitworth<br>
<jarhar> q?<br>
<jarhar> q+<br>
<keithamus> fantasai: the issue isn't can we feature detect, incremental opt in is for compat reasons. Authors will use a more general selector than is needed then opt in, but then we end up with "we cant ship appearance: base" on, say, date controls. Now we need a _new_ keyword appearance: base-no-really including date pickers. That's _why_ we need an opt in.<br>
<keithamus> ... the reason we split into in page and not-in-page. We believe we can pull together the necessary standardisation/implementation work to do this within a reasonable amount of time, but styling pickers is a multi year project. Something we'll have to do incrementally<br>
<keithamus> ... it may be that developers are find with not-in-page pickers but want to style in-page<br>
<keithamus> ... ???<br>
<keithamus> ... thats why its incremental on the picker. to enable incremental styling of the in-page then add the picker<br>
<keithamus> ... The reason we have picker with a bunch of identifiers is that we don't anticipate being able to tackle handling all of the pickers consistently and thoroughly in a single ship.<br>
<keithamus> ... We can make the picker identifier optional after a certain point, authors can just use ::picker without the keywords, but this gives us a gradual transition towards that.<br>
<keithamus> ... Allowing us to ship in pieces.<br>
<gregwhitworth> ack una<br>
<masonf> q+<br>
<gregwhitworth> q+<br>
<keithamus> una: thanks for the explanation fantasai. I've been playing with it quite a bit, the biggest aversion to the current proposal is having to do this in multiple places and remembering the names of all the pickers, in order to get this to work properl<br>
<keithamus> ... ideally authors would not have to remember that and just do it in one place<br>
<fantasai> Totally agree that this would be better. We just think it's not possible due to anticipated compat restrictions.<br>
<keithamus> ... I think jarhar mentioned doing @supports to incrementally adopt. We cant use @supports to detect outside of CSS. What are your thoughts there?<br>
<fantasai> But at least this gets us to a world where that can be possible in the future.<br>
<keithamus> jarhar: @supports whether appearnace: base supported on specific elements. If we ship select first and you put it on input type=range that'll still be auto. We add an @support and we can say that works, we still need a unique identifier for that.<br>
<keithamus> ... then we make a new @supports for each one<br>
<keithamus> ... in your @supports rule you could style each one.<br>
<keithamus> ... then if you put html in your select is a separate html thing, it would still support the new structure just render in the native browser way<br>
<ntim> q+<br>
<jarhar> q?<br>
<keithamus> una: so would this work with the picker opt in?<br>
<keithamus> ... so Anne mentioned putting appearance:base on both the base element and the ::picker(type-of-picker). Is it possible to make it just in one place, e.g. the pseudo element<br>
<keithamus> fantasai: that would only select the picker, you could apply styles to the picker only. Setting appearance base on that would make the picker base, but the in-page control still auto<br>
<keithamus> ... even before pickers are stylable we want the in-page control to opt into appearance:base. We think authors want in-page styling _the most_, over the pickers.<br>
<keithamus> ... obviously they want both but in-page seems to be the most desired.<br>
<keithamus> ... could we have it magically propagate? Maybe but that would be super weird<br>
<keithamus> una: and the other way around, base on the in-page propagating to picker doesn't resolve the issue you're brining up?<br>
<keithamus> fantasai: yeah. Its possible authors don't want to put in the effort to style pickers, just in-page, so it's useful to have the difference, but it also allows us to incrementally ship these features. So we don't run into compat issues<br>
<keithamus> una: I'm curious if you've had feedback from authors about if they don't want to style pickers vs in-page?<br>
<ntim> I could see developers wanting a native picker and base-styled in-page<br>
<keithamus> fantasai: we haven't heard that specifically but the main thing driving the design is how to opt things in with minimal impact without memorising weird keywords, which we agree is undesirable but we need some way to handle opt in<br>
<masonf> q?<br>
<ntim> native picker have special capabilities such as expanding outside of the window bounds for instance<br>
<keithamus> jensimmons: we've not done specific research for e.g from big corporate partners but remembering what it's like to be a web designer on a smaller budget, everything in-page needs to be represented in brand but budget restricts from designing every single thing, so we might want to style the select but not be able to style the picker.<br>
<keithamus> ... bigger projects will, e.g. delta really wants their calendar to look like a delta calendar<br>
<fantasai> +1 jensimmons<br>
<keithamus> ... but where budgets are much smaller I think it'll be common that they want in-page styles but no budget to worry about styling the picker<br>
<keithamus> una: I see where you're coming from. I'd like to do more research. I've heard it's currently hard to style the picker, not the button<br>
<chrishtr> q?<br>
<una> q+<br>
<keithamus> jensimmons: asking for select menu, asking for calendars, this is what we hear a lot but thinking through styles - it's difficult. Styling buttons can be styled however you want but oh, unless its input type=file.<br>
<keithamus> ... it would be very annoying to roll out changes to all controls one-by-one. It's a better project to do all at once.<br>
<keithamus> ... but its impossible to do ALL in-page and pickers all at once.<br>
<keithamus> ... tackle all in-page controls all at once and pickers one by one<br>
<gregwhitworth> ack jarhar<br>
<keithamus> jarhar: fantasai mentioned ::picker for compat for incremental opt in. All in-page first, then incrementally with pickers. masonf & chrishtr - correct me if I'm wrong but we can't do all in-page at once? And we want to ship select first? Still seems best for developers to me to have appearance base on root element, or ::picker(select) apply its<br>
<keithamus> value to the root element, to ship select first.<br>
<gregwhitworth> ack masonf<br>
<keithamus> masonf: important to remember this is compat. We can do appearance:base and eat the risk, or two options: appearance:base-something or ::picker(something). Both are ugly but both work<br>
<keithamus> ... but working on select for 5 years and talking to developers. All in-page controls are pretty stylable. The really tricky bits are stuff like select where there's a picker<br>
<keithamus> ... for example putting rich content in the picker shows up in the base control.<br>
<keithamus> ... I find it really unlikely well be able to ship all in-page in a year. I think each will have to be shipped hollistically, in its entirety, picker and all.<br>
<keithamus> ... having said all that, if that's all true it seems to me that we should make it easy for developers to opt in to each control.<br>
<keithamus> ... let's make it as easy as we can for developers<br>
<chrishtr> opt-out is a good idea<br>
<keithamus> gregwhitworth: I think there's 3 options. I haven't heard not caring about the picker a ton, but I personally lean towards... we all want appearance:base, I want to do *{appearance:base}. But to go to una's point, if I did that on select I'd expect it to apply to picker. Doesn't mean picker pseudo can't exist, we don't have to throw the premise of<br>
<keithamus> opt-in/out for pickers, but I agree with masonf<br>
<keithamus> ... so before we even talk about base we have to talk about the parts,e.g. file. How do we lay them out? Whats the base styles for that/<br>
<keithamus> ... some may go faster than others but there is such disparity between even UAs as to what they do<br>
<keithamus> ... so I think there are 3 options, appearance:base being north star, but same for gap, flex-gap grid-gap sucks let's just use gap...<br>
<gregwhitworth> ack gregwhitworth<br>
<keithamus> ... but we'll need that for appearance:base<br>
<gregwhitworth> ack ntim<br>
<chrishtr> opt-out gives a way to get a native picker<br>
<keithamus> ntim: I want to emphasize on the value of the pickers having a different appearance. A native picker could be a design choice. e.g. on visionOS you might want the nice native picker going out of system bounds. There's value in picker being native.<br>
<keithamus> ntim: having appearance:base toggling on everything goes against that.<br>
<keithamus> ... from a design systems view pickers will likely be different going control-by-control.<br>
<keithamus> gregwhitworth: most design systems to have base foundationals<br>
<keithamus> ntim: yeah I am saying most design systems wouldn't want to style a specific control, in-page and picker. They'd separate by in-page vs picker.<br>
<keithamus> ntim: you dont want 1 control to have native, and others to have base-styled. You want consistency.<br>
<jarhar> q?<br>
<gregwhitworth> ntim I want to +1 that the picker feature possibly being useful, I think I disagree with them being native by default<br>
<keithamus> ... like in the future I would see systems libraries doing *::picker{appearance:base} or *{apperance:base} for in-page. This is the future I see.<br>
<gregwhitworth> ack una<br>
<jarhar> we could make select { appearance:base; } imply select::picker(select){appearance:base} and then you could also apply select::picker(select){appearance:auto} to make the picker go back to the native appearance<br>
<jarhar> there are also existing ways to style the in-page part of select with appearance:none which we could extend with the new content model that allows an author button<br>
<keithamus> una: +1 to appearance:base being north star. Changing way to opt into form controls. Theoretically users would be able to connect any button to the picker using invokers, that would give them control for any page control, whatever control that is. We talked about selectoption linking to any form control, e.g. outside of select, controlling the<br>
<keithamus> control<br>
<keithamus> ... this gives users more capability to customise in-page control vs pickers<br>
<keithamus> ... right now we don't give users choice on picker<br>
<keithamus> ... currently there is some styling with appearance:base-select. Users don't necessarily need to customise it<br>
<jensimmons> q-<br>
<keithamus> ... this could open the door for new controls having custom styles for appearance:base. We could do more there, e.g. 3d...<br>
<jensimmons> q+<br>
<keithamus> ... ???<br>
<gregwhitworth> ack fantasai<br>
<gregwhitworth> q+ fantasai<br>
<keithamus> jensimmons: what's great about appearance:base is it switches the very different operating system controls - per platform - its very hard to override those. appearance:base gives everyone a consistent control, same in each browser<br>
<ntim> gregwhitworth: it's already the current default though<br>
<keithamus> ... I'm responding to hearing people say it's not hard to design in-page controls. Putting your own styling on e.g. checkboxes right now is annoying. Doing it across all would be very valuable to all developers<br>
<gregwhitworth> ack jensimmons<br>
<gregwhitworth> ack fantasai<br>
<jensimmons> And Apple is working on in-age controls now, coming up with a proposal to share when it's ready.<br>
<jensimmons> *in-page<br>
<keithamus> fantasai: I think we at apple generally disagree we can't ship apperance:base all at once. We think its doable within the next year or two, and not take as long as doing all of the pickers. In terms of select specifically, it's special, google's been working hard on it but it's also a form control where the picker and all components can be<br>
<keithamus> represented as elements in the page.<br>
<keithamus> ... most other form controls have pickers with UA magic<br>
<keithamus> ... it might be reasonable to ship appearance:base-select just for selects, while we work on the rest, then ship appearance:base for everything<br>
<jarhar> agree<br>
<keithamus> ... so we can split the difference<br>
<masonf> +1 to that approach!<br>
<chrishtr> +1 to base-select<br>
<keithamus> ... we dont want values foe every form control but a short-term phase for select seems reasonable and acceptable.<br>
<gregwhitworth> Zakim, end meeting<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-2276173845 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 August 2024 16:01:06 UTC