- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Sep 2024 15:39:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Styling form control pickers`, and agreed to the following:
* ``RESOLVED: `appearance:base` will apply to the in-page parts (only) of all form controls (including `<select>`), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.``
* ``RESOLVED: `::picker(keyword) { appearance: base }` will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.``
* `RESOLVED: If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)), individually.`
<details><summary>The full IRC log of that discussion</summary>
<chrishtr> gregwhitworth: please help out Joey & team if you can<br>
<chrishtr> jarhar: have a comment proposing and linking back to Elika's proposed resolution, we'd like to resolve on that<br>
<chrishtr> jarhar: is anyone against adopting this resolution?<br>
<gregwhitworth> q?<br>
<chrishtr> jarhar: first: appearance: base will apply to the in-page parts of form controls, and to avoid compat problems must be shipped for all controls<br>
<una> q+<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166<br>
<fantasai> appearance:base will apply to the in-page parts (only) of all form controls (including <select>), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.<br>
<fantasai> ::picker(keyword) { appearance: base } will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.<br>
<fantasai> If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)).<br>
<chrishtr> jarhar: the ::picker(...) function will opt overlay pickers to base style, parameterized by control<br>
<emilio> q+<br>
<emilio> ack una<br>
<chrishtr> jarhar: appearance:base-<control> would opt in a specific in-page control if needed for incremental adoptoin<br>
<chrishtr> una: currently the implementation / discussion then opting in the picker without the base, then nothing will happen. Want to make sure we have consensus on that behavior.<br>
<chrishtr> fantasai: are you saying that you want to make sure that if the picker is opted in but not the base element, then the picker opt-in will have no effect?<br>
<chrishtr> una: yes.<br>
<chrishtr> masonf: think this falls out of the existing definition, but yes need agreement<br>
<chrishtr> una: second question: resolution says appearance: base will apply to all, but we don't have a full list of controls<br>
<chrishtr> fantasai: currently only have a specific opt-in for just base-select, but hopefully the rest in one go<br>
<chrishtr> una: what about the date picker or color picker? would we have to block on that?<br>
<chrishtr> fantasai: no, because appearance: base for non-picker opts in just the in-page aspects of the control<br>
<chrishtr> fantasai: if you want the styleable version of the picker then then you'd need to separately opt in that<br>
<jarhar> q?<br>
<chrishtr> una: why can't we have appearance: base for pickers only?<br>
<chrishtr> fantasai: for web compat reasons<br>
<gregwhitworth> q+<br>
<chrishtr> emilio: I think what Una was asking was opting in via appearance:base just on the picker because it requires ::picker<br>
<sanketj_> q+<br>
<chrishtr> emilio: what I understand Una saying is that if you restrict it to ::picker(select) then it'd be just for select anyway<br>
<jarhar> q?<br>
<chrishtr> fantasai: if we're introducing the base-select keyword anyway then it doesn't matter much<br>
<chrishtr> emilio: agree<br>
<gregwhitworth> ack emilio<br>
<fantasai> s/then it doesn't matter much/then why would we risk the compat of making base valid at all/<br>
<chrishtr> emilio: want to make sure that we're not resolving that appearance:base-select on the in-page element would opt in the picker also<br>
<chrishtr> chrishtr: correct, it does *not* opt in the picker alkso<br>
<chrishtr> dbaron: there are only 3 modes: both auto, in-page base, and in-page + picker base<br>
<fantasai> 1. Native styling of in-page and picker - do nothing (`appearance: auto`)<br>
<fantasai> 2. in-page base, native picker -> input { appearance: base; }<br>
<gregwhitworth> ack sanketj_<br>
<fantasai> 3. in-page base, styleable picker -> input, ::picker(type) { appearance: base; }<br>
<dbaron> s/both auto/both not base/<br>
<chrishtr> sanketj_: clarifying question: we're saying that appearance:base applies to all controls but only applies to in-page. then we have appearance-<name> that opts in just one thing?<br>
<chrishtr> sanketj_: will we able to incrementally opt in additional controls?<br>
<chrishtr> fantasai: setting aside base-select as an exception, there would not be a per-control opt-in syntax<br>
<chrishtr> fantasai: second part is that ::picker has a per-control syntax for all pickers<br>
<chrishtr> sanket_: worried we'd get into a state where if we did one more control we wouldn't be able to add it incrementally<br>
<chrishtr> fantasai: because select is ready soon to ship we have a carve-out for it<br>
<chrishtr> fantasai: select also has a picker that is real DOM elements in base mode<br>
<masonf> Proposed resolution: `select {appearance:base-select}` opts in the in-page <select> element. `::picker(select) {appearance:base-select}` opts in the picker for <select>. Future in-page controls will be opted in together, via `* {appearance:base}`. Future pickers will be opted in individually, via `::picker(controltype) {appearance:base}`.<br>
<masonf> q+<br>
<masonf> q+ to discuss my new proposed resolution text<br>
<chrishtr> sanketj_: arrangement I would prefer is that until appearance:base is available for all controls then we'd have per-control opt in via the dashed syntax<br>
<una> q+<br>
<chrishtr> fantasai: yes it doesn't allow that for that. but if in the future something big comes up then we can reconsider it<br>
<chrishtr> fantasai: webkit representatives believe we can do it in one go for in-page controls<br>
<gregwhitworth> ack masonf<br>
<Zakim> masonf, you wanted to discuss my new proposed resolution text<br>
<chrishtr> sanketj_: would prefer text in the resolution allowing future opt-ins<br>
<fantasai> I think we should take the resolutions 1-by-1<br>
<gregwhitworth> ack gregwhitworth<br>
<fantasai> +1 masonf<br>
<gregwhitworth> ack una<br>
<chrishtr> mason: propose to resolve. resolutions never preclude future reconsideration<br>
<dbaron> (maybe clarify in the last sentence that opting in the picker also requires opting in the in-page control)<br>
<chrishtr> una: third point does seem to still be ambiguous?<br>
<masonf> Proposed resolution: `select {appearance:base-select}` opts in the in-page <select> element.<br>
<una> 👍<br>
<chrishtr> fantasai: that's just an ambiguitity in my texxt, Mason's is clear<br>
<astearns> +1<br>
<gregwhitworth> Proposed Resolution: `appearance:base` will apply to the in-page parts (only) of all form controls (including `<select>`), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.<br>
<masonf> +1<br>
<fantasai> +1<br>
<chrishtr> +1<br>
<una> SGTM<br>
<gregwhitworth> Proposed Resolution: ::picker(keyword) { appearance: base } will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.<br>
<fantasai> +1<br>
<gregwhitworth> RESOLVED: `appearance:base` will apply to the in-page parts (only) of all form controls (including `<select>`), and, to avoid forwards-compat problems, must ship simultaneously on all form controls.<br>
<gregwhitworth> Proposed Resolution:` ::picker(keyword) { appearance: base }` will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.<br>
<masonf> +1 to the second proposed<br>
<fantasai> +1<br>
<chrishtr> +1<br>
<zcorpan> +1<br>
<una> SGTM<br>
<gregwhitworth> RESOLVED: `::picker(keyword) { appearance: base }` will apply to form control pickers as an opt-in to styleable pickers of the named control type, with the control-type keyword allowing per-control-type incremental shipping of styleable pickers. To avoid forwards-compat problems, we will consider a keywordless variant only once all form controls can be opted in.<br>
<masonf> Proposed resolution: If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)), individually.<br>
<masonf> (note the individually)<br>
<masonf> +1<br>
<fantasai> +1<br>
<una> +1<br>
<emilio> +1<br>
<zcorpan> +1<br>
<chrishtr> +1<br>
<bkardell_> +1<br>
<chrishtr> LINUX!<br>
<gregwhitworth> RESOLVED: If appearance: base on all in-page controls is not ready in time for <select>, we may add appearance: base-select whose behavior is equivalent to appearance: base, but only applies to <select> and its picker (::picker(select)), individually.<br>
<chrishtr> sanket_: just want to make sure that we can come back later and reconsider things in general<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-2332063450 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 September 2024 15:39:45 UTC