14:57:17 <RRSAgent> RRSAgent has joined #css
14:57:21 <RRSAgent> logging to https://www.w3.org/2024/09/05-css-irc
14:57:29 <gregwhitworth> Zakim, start meeting
14:57:29 <Zakim> RRSAgent, make logs Public
14:57:31 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
14:57:57 <gregwhitworth> gregwhitworth has changed the topic to: Sep 5 agenda: https://github.com/whatwg/html/issues/10582
14:58:04 <gregwhitworth> chair: Greg Whitworth
14:58:07 <gregwhitworth> present+
15:01:21 <jarhar> jarhar has joined #css
15:02:10 <chrishtr> present+
15:02:28 <una> una has joined #css
15:02:39 <masonf> masonf has joined #css
15:02:42 <sanketj_> sanketj_ has joined #css
15:02:53 <gregwhitworth> Topic: Update on Specs
15:03:14 <chrishtr> jarhar: created an HTML spec PR for the content model of select, appreciate others reading it and providing feedback
15:03:33 <chrishtr> jarhar: there is also a spec PR for appearance: base in CSS, please take a loook
15:03:46 <dbaron> Present+
15:04:03 <una> present+
15:04:07 <chrishtr> jarhar: third, I'm working on one for ::picker, help appreciated. There are some open questions about how to structure it that would be great to get help with.
15:04:49 <chrishtr> emilio: if the idea is for picker to be feature-detectable for developers, then will be necessary to have unknown pickers fail to parse. Don't think that would be controversial?
15:05:16 <chrishtr> masonf: expect there is a way for this to be done but don't have experience specifying certain corner cases, e.g. empty picker()
15:05:19 <gregwhitworth> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10440
15:05:19 <github-bot> Topic: Styling form control pickers
15:05:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10440.
15:05:32 <chrishtr> gregwhitworth: please help out Joey & team if you can
15:06:04 <chrishtr> jarhar: have a comment proposing and linking back to Elika's proposed resolution, we'd like to resolve on that
15:06:14 <chrishtr> jarhar: is anyone against adopting this resolution?
15:06:27 <gregwhitworth> q?
15:06:44 <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
15:06:59 <Anne> Anne has joined #css
15:07:00 <lwarlow> lwarlow has joined #css
15:07:09 <una> q+
15:07:09 <fantasai> https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166
15:07:18 <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.
15:07:22 <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.
15:07:28 <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)).
15:07:32 <chrishtr> jarhar: the ::picker(...) function will opt overlay pickers to base style, parameterized by control
15:07:40 <emilio> present+
15:07:41 <emilio> q+
15:07:44 <emilio> ack una
15:07:52 <chrishtr> jarhar: appearance:base-<control> would opt in a specific in-page control if needed for incremental adoptoin
15:08:43 <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.
15:09:19 <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?
15:09:22 <chrishtr> una: yes.
15:09:45 <chrishtr> masonf: think this falls out of the existing definition, but yes need agreement
15:10:15 <chrishtr> una: second question: resolution says appearance: base will apply to all, but we don't  have a full list of controls
15:10:58 <chrishtr> fantasai: currently only have a specific opt-in for just base-select, but hopefully the rest in one go
15:11:13 <chrishtr> una: what about the date picker or color picker? would we have to block on that?
15:11:32 <chrishtr> fantasai: no, because appearance: base for non-picker opts in just the in-page aspects of the control
15:12:00 <chrishtr> fantasai: if you want the styleable version of the picker then then you'd need to separately opt in that
15:12:23 <jarhar> q?
15:13:20 <chrishtr> una: why can't we have appearance: base for pickers only?
15:13:22 <chrishtr> fantasai: for web compat reasons
15:13:30 <gregwhitworth> q+
15:14:58 <chrishtr> emilio: I think what Una was asking was opting in via appearance:base just on the picker because it requires ::picker
15:15:09 <sanketj_> q+
15:16:00 <chrishtr> emilio: what I understand Una saying is that if you restrict it to ::picker(select) then it'd be just for select anyway
15:16:30 <jarhar> q?
15:16:30 <chrishtr> fantasai: if we're introducing the base-select keyword anyway then it doesn't matter much
15:16:32 <chrishtr> emilio: agree
15:16:35 <gregwhitworth> ack emilio
15:16:51 <fantasai> s/then it doesn't matter much/then why would we risk the compat of making base valid at all/
15:17:45 <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
15:17:53 <chrishtr> chrishtr: correct, it does *not* opt in the picker alkso
15:18:16 <chrishtr> dbaron: there are only 3 modes: both auto, in-page base, and in-page + picker base
15:18:18 <fantasai> 1. Native styling of in-page and picker - do nothing (`appearance: auto`)
15:18:28 <fantasai> 2. in-page base, native picker -> input { appearance: base; }
15:18:31 <gregwhitworth> ack sanketj_
15:18:45 <tantek> present+
15:18:59 <fantasai> 3. in-page base, styleable picker -> input, ::picker(type) { appearance: base; }
15:19:04 <dbaron> s/both auto/both not base/
15:19:21 <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?
15:19:37 <chrishtr> sanketj_: will we able to incrementally opt in additional controls?
15:20:16 <chrishtr> fantasai: setting aside base-select as an exception, there would not be a per-control opt-in syntax
15:20:52 <chrishtr> fantasai: second part is that ::picker has a per-control syntax for all pickers
15:21:59 <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
15:22:19 <chrishtr> fantasai: because select is ready soon to ship we have a carve-out for it
15:22:28 <bkardell_> bkardell_ has joined #css
15:22:54 <chrishtr> fantasai: select also has a picker that is real DOM elements in base mode
15:22:57 <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}`.
15:23:11 <bkardell_> present+
15:23:18 <masonf> q+
15:23:26 <masonf> q+ to discuss my new proposed resolution text
15:23:56 <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
15:24:19 <argyle> argyle has joined #css
15:24:32 <una> q+
15:25:00 <chrishtr> fantasai: yes it doesn't allow that for that. but if in the future something big comes up then we can reconsider it
15:25:14 <chrishtr> fantasai: webkit representatives believe we can do it in one go for in-page controls
15:26:26 <gregwhitworth> ack masonf
15:26:26 <Zakim> masonf, you wanted to discuss my new proposed resolution text
15:26:26 <chrishtr> sanketj_: would prefer text in the resolution allowing future opt-ins
15:26:28 <fantasai> I think we should take the resolutions 1-by-1
15:26:55 <gregwhitworth> ack gregwhitworth
15:26:56 <fantasai> +1 masonf
15:27:33 <gregwhitworth> ack una
15:27:38 <chrishtr> mason: propose to resolve. resolutions never preclude future reconsideration
15:27:38 <dbaron> (maybe clarify in the last sentence that opting in the picker also requires opting in the in-page control)
15:28:10 <chrishtr> una: third point does seem to still be ambiguous?
15:28:24 <masonf> Proposed resolution: `select {appearance:base-select}` opts in the in-page <select> element.
15:28:41 <una> 👍
15:28:44 <chrishtr> fantasai: that's just an ambiguitity in my texxt, Mason's is clear
15:28:50 <astearns> +1
15:31:32 <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.
15:31:45 <masonf> +1
15:31:46 <fantasai> +1
15:31:50 <chrishtr> +1
15:31:53 <zcorpan> zcorpan has joined #css
15:32:30 <zcorpan> present+
15:32:57 <una> SGTM
15:33:04 <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.
15:33:18 <fantasai> +1
15:33:26 <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.
15:33:51 <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.
15:33:54 <masonf> +1 to the second proposed
15:33:54 <fantasai> +1
15:34:10 <chrishtr> +1
15:34:18 <zcorpan> +1
15:34:26 <una> SGTM
15:34:48 <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.
15:35:36 <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.
15:35:42 <masonf> (note the individually)
15:36:18 <masonf> +1
15:36:18 <fantasai> +1
15:36:20 <una> +1
15:36:21 <emilio> +1
15:36:23 <zcorpan> +1
15:36:24 <chrishtr> +1
15:36:27 <bkardell_> +1
15:37:34 <chrishtr> LINUX!
15:39:22 <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.
15:39:40 <chrishtr> sanket_: just want to make sure that we can come back later and reconsider things in general
15:39:41 <gregwhitworth> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10775
15:39:41 <github-bot> Topic: [css-ui] Should `::picker(select)` match `:popover-open`?
15:39:41 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10775.
15:40:24 <masonf> masonf has joined #css
15:40:33 <chrishtr> jarhar: this is a topic that was spun out of ::picker. There is disagreement about whether :popover-open should match. We already resolved that ::picker is a part-like pseudo element.
15:41:01 <jarhar> q?
15:41:13 <una> q+
15:41:18 <chrishtr> jarhar: there is the question of whether it should match :popover-element. I and some others think it should because that's the default for part-like pseudos. Others don't like it because it would reveal internal details
15:41:22 <masonf> q+ simon
15:41:38 <gregwhitworth> ack una
15:41:39 <chrishtr> una: clarifying question: would this match both open and popover-open, or just popover-open?
15:41:59 <chrishtr> jarhar: there is no contention about :open, discussion is just for :popover-open.
15:42:13 <chrishtr> una: so with your preferred resolution it'd match both?
15:42:15 <chrishtr> masonf: yes
15:42:25 <chrishtr> una: ok I agree with that, just checking
15:42:39 <chrishtr> dbaron: select matches open, and picker matches popover-open
15:43:22 <chrishtr> una: if you have appearance:base-select for both the in-page and picker, then select:open would be the same as picker:poover-open
15:43:52 <zcorpan> ack simon
15:44:06 <chrishtr> una: if you only have appearance: base on the select and not the picker, then you can only match select:open because the picker doesn't exist
15:44:24 <chrishtr> fantasai: seems like it has to exist
15:44:33 <chrishtr> annevk: exists but doesn't match because it isn't styleable
15:44:48 <chrishtr> annevk: isn't that the case for other pseudo-elements anyway?
15:45:07 <chrishtr> fantasai: exists but not styleable
15:45:45 <dbaron> (I'm not actually 100% sure that ::picker(select):popover-open doesn't work when ::picker(select) is appearance:auto... although I *think* that's the case
15:45:49 <chrishtr> fantasai: if we allow popover-open to apply to the picker then it won't apply if not in base mode?
15:46:09 <una> q+
15:46:58 <chrishtr> jarhar: the picker element exists but in auto mode it can't be opened as a popover because it never opens
15:47:02 <fantasai> ::picker(selecT) { appearance: base; } ::picker(select):popover-open { appearance: auto; }
15:47:20 <chrishtr> fantasai: what about applying appearance:auto if :popover-open, what will that do?
15:47:24 <chrishtr> annevk: would be a loop?
15:47:56 <chrishtr> masonf: which picker you open depends on timing. If it's already open then it wouldn't close?
15:48:06 <chrishtr> annevk: normally in CSS if the computed value changes then what you see changes
15:48:40 <chrishtr> masonf: if so then there would need to be some code to handle it
15:49:00 <gregwhitworth> ack una
15:49:29 <dbaron> (I think this is sort of exposing a problem with making `appearance` apply separately to `::picker(select)`... it probably normally would have been restricted.)
15:49:31 <chrishtr> una: maybe this is a difference between part-like and regular pseudo elements?
15:50:07 <chrishtr> fantasai: this was relaxed before for pseudos
15:50:08 <chrishtr> q+
15:50:57 <chrishtr> una: second question: just updated my demos when I updated them to the new syntax. e.g. focus-visible didn't apply any more. Wanted to see if this ok. Also is there an issue with specificity?
15:51:17 <zcorpan> Demo for ::before:hover (seems like this is not implemented) https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13060
15:51:21 <gregwhitworth> ack chrishtr
15:51:33 <fantasai> select:open ::picker() vs select ::picker():popover-open - same specificity
15:51:34 <chrishtr> fantasai: specificity would be the same
15:51:35 <gregwhitworth> chrishtr: wanted to bring us back, popover: open question jarhar originally raised
15:52:17 <gregwhitworth> masonf: the issue being discussed is their unique capabilities for this scenario
15:52:41 <jarhar> proposed resolution: don't create a special exception to not parse :popover-open on ::picker(select)
15:52:54 <masonf> +1
15:53:04 <una> +1
15:53:04 <chrishtr> +1
15:53:08 <dbaron> +1
15:53:10 <zcorpan> +1
15:53:10 <emilio> +1
15:53:17 <sanketj_> +1
15:53:33 <gregwhitworth> RESOLVED: don't create a special exception to not parse :popover-open on ::picker(select)
15:54:41 <keithamus> present+
15:54:43 <gregwhitworth> Zakim, end meeting
15:54:43 <Zakim> As of this point the attendees have been gregwhitworth, chrishtr, dbaron, una, emilio, tantek, bkardell_, zcorpan, keithamus
15:54:46 <Zakim> RRSAgent, please draft minutes v2
15:54:47 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/05-css-minutes.html Zakim
15:54:54 <Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent.  Goodbye
15:54:54 <Zakim> Zakim has left #css
16:50:43 <antonp> antonp has joined #css
16:56:04 <antonp> antonp has joined #css
16:59:22 <jamesn> jamesn has joined #css
17:26:06 <antonp> antonp has joined #css
17:27:46 <antonp> antonp has joined #css
18:02:09 <Penny> Penny has joined #css
18:04:49 <sanketj_> sanketj_ has joined #css
18:10:45 <una> una has joined #css