- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Nov 2024 17:27:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base `<select>` ``, and agreed to the following:
* `RESOLVED: Name the pseudo-element ::checkmark`
* `RESOLVED: go with ::picker-icon`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> fantasai: just 2-3 straw polls<br>
<TabAtkins> fantasai: we've been discussing the pseudos for parts of form controls<br>
<TabAtkins> fantasai: first is the pseudo that represents the checkmark in form controls. check in checkbox, dot in radio button, indicator in selector<br>
<TabAtkins> s/selector/select/<br>
<TabAtkins> fantasai: the checkmark pseudo is always there, it's just not visible when not checked<br>
<TabAtkins> fantasai: so you can style it to an x when unchecked, etc, because it's still there, you just have to style it visible<br>
<TabAtkins> fantasai: so the options are ::checked and ::checkmark<br>
<jarhar> ::check and ::checkmark<br>
<JakeA> Checkbox contains a check, so `::check`<br>
<TabAtkins> it contains a check mark in my idiolect ^_^<br>
<fantasai> :checked pseudo-class also exists<br>
<TabAtkins> (but i'm good with ::check)<br>
<fantasai> input[type=checkbox]:checked::check?mark? { style; }<br>
<JakeA> I'm also fine with ::checkmark fwiw<br>
<jarhar> option::check(mark)<br>
<schenney> +1 to :checkmark, as this is the thing that is being drawn, not the verb "to check".<br>
<TabAtkins> lea: what is the pseudo on in a <select>? the <select> or the <option>?<br>
<TabAtkins> fantasai: the <option><br>
<TabAtkins> lea: have we considered ::marker?<br>
<jarhar> ::marker has been avoided in several conversations due to property limitations and other baggage<br>
<TabAtkins> fantasai: that's used for list-items already<br>
<argyle> ::checkmark<br>
<lea> q?<br>
<fantasai> POLL: A) ::check B) ::checkmark<br>
<TabAtkins> JakeA: the idea is that we'd use this as the base rendering of a checkbox input?<br>
<lea> q+<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to discuss after this discussion<br>
<TabAtkins> lea: have we considered anything that doesn't imply a particular rendering?<br>
<fantasai> ::checkedmark<br>
<fantasai> :checked<br>
<TabAtkins> lea: this implies it'll always look like a checkmark<br>
<TabAtkins> fantasai: we could call it a checked-mark<br>
<jfkthame> ::indicator ?<br>
<TabAtkins> TabAtkins: since the pseudo-class is already :checked, i don't have a big problem with the name possible being non-representative of the actual appearance<br>
<lea> +1 for ::indicator<br>
<TabAtkins> fantasai: i'm still going with the two options unless someone has a strong feeling<br>
<fantasai> I object to ::indicator because it is too generic<br>
<TabAtkins> fantasai: "indicator" is super generic, a million things could be an indicator. this is specifically about the mark on form elements that can be checked<br>
<TabAtkins> lea: i agree indicator is too generic, marker is about for list-items, check/checkmark are too specific... i dunno<br>
<TabAtkins> JakeA: since :checked is the pseudo-class, does that sway you at all? i agree with you, but i think that pushes me to support ::check<br>
<argyle> `:checked::checkmark` vs `:checked::check`<br>
<noamr> I thought this is time-boxed to straw polls. This discussion doesn't seem like either time-boxed or a straw poll<br>
<masonf> Straw poll could be 1) ::check, 2) ::checkmark, or 3) something else?<br>
<TabAtkins> lea: if anything, :checked indicates we need something more generic, :checked::check is funky<br>
<lea> 3<br>
<schenney> (2)), because I agree that almost any other word like indicator or active, or selected is overloaded.<br>
<florian> 1<br>
<TabAtkins> fantasai: we have a lot of pseudos that are specific to form elements, they won't be reused. discussion of what this pseudo *is* shoudl be another issue<br>
<TabAtkins> astearns: trying to timebox, i think we should go with Mason's strawpoll.<br>
<bramus> 2<br>
<kbabbitt> 2<br>
<astearns> 2<br>
<jfkthame> 2<br>
<TabAtkins> 1, 2<br>
<noamr> 2<br>
<stepheckles> 2<br>
<argyle> 2<br>
<kizu> 2<br>
<dbaron> 2<br>
<masonf> 2<br>
<joshtumath> 1 or 2<br>
<fantasai> 2, 1<br>
<futhark> 2<br>
<jarhar> 2<br>
<chrishtr> 2<br>
<JakeA> 2<br>
<florian> 1 prefered, 2 ok<br>
<TabAtkins> astearns: 2 is obviously the winner<br>
<TabAtkins> astearns: proposed resolution is ::checkmark<br>
<TabAtkins> RESOLVED: Name the pseudo-element ::checkmark<br>
<TabAtkins> fantasai: Next is the dropdown arrow on select. proposal is to use the smae pseudo for that and other pop-up controls (like date picker, time picker)<br>
<TabAtkins> fantasai: "this is the thing that indicates you can trigger a popup"<br>
<schenney> expander<br>
<TabAtkins> fantasai: for some form control that's the only targetable area, other form controls can cause it in a larger area<br>
<TabAtkins> fantasai: current thinking is a single pseudo representing an icon that can be clicked to open things<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/10908#issuecomment-2455470313<br>
<TabAtkins> fantasai: long list of things that have been proposed<br>
<argyle> q+<br>
<jarhar> i like ::picker-icon<br>
<astearns> ack lea<br>
<TabAtkins> JakeA: I don't like the ones that suggest it's the thing you click on to open it<br>
<TabAtkins> like ::picker-opener, etc<br>
<TabAtkins> JakeA: If it's just referring to that little arrow...<br>
<lea> q+<br>
<astearns> ack argyle<br>
<TabAtkins> argyle: do we have a list of affected elements?<br>
<masonf> +1 to that logic: it's just the "icon", and it *might* be inside a button.<br>
<JakeA> sorry, I'm out of practice for queue usage. I'll fix myself<br>
<TabAtkins> argyle: we have ::picker(), can we involve that? ::picker-picker?<br>
<masonf> Pickers are (typically): select, input text with datalist, color picker, date/time picker<br>
<TabAtkins> fantasai: this is on the form element, select::bikeshed<br>
<TabAtkins> argyle: and details summary? same or different?<br>
<TabAtkins> fantasai: totally separate<br>
<astearns> ack lea<br>
<TabAtkins> lea: the current use-case - is this always an arrow in every platform? or other displays?<br>
<TabAtkins> fantasai: the icon will probably differ between form controls<br>
<TabAtkins> fantasai: but the current proposal is appearance:base, it'll probably be a disclosure triangle of some kind<br>
<schenney> q+<br>
<TabAtkins> fantasai: author would be able to change it<br>
<masonf> But on a date picker, it's usually a calendar icon<br>
<TabAtkins> lea: yeah, just asking about default styling, any case where this isn't an arrow/caret?<br>
<TabAtkins> fantasai: we might ahve seen a + sign before?<br>
<argyle> will this always invoke a picker? or can it also expand inline?<br>
<lea> I quite like `::opener`. `::expander` could also work. `::picker-opener` is too long<br>
<astearns> ack dbaron<br>
<TabAtkins> dbaron: if we're gonna do something here we reuse for date pickers, there are some differences<br>
<fantasai> lea, the reason for the ::picker- prefix is to tie it to the ::picker() pseudo-element which it opens<br>
<fantasai> or indicates opening<br>
<TabAtkins> dbaron: like how jake mentioned, how the entire control is clickable in <select> isn't always true in date pickers, the popup is separate from the individual bits with other controls<br>
<TabAtkins> dbaron: don't think there's necessarily a hard requirement that this is the same thing we use on date picker<br>
<astearns> ack schenney<br>
<masonf> It's a down-arrow icon on select and color, and a calendar icon on the date picker. So always an "icon".<br>
<dbaron> s/is the same/is or isn't the same/<br>
<TabAtkins> schenney: in this discussion people keep saying "icon", think this strongly argues for icon<br>
<TabAtkins> lea: "icon" could be decorative<br>
<TabAtkins> ::picker-icon<br>
<TabAtkins> sounds reasonable to me<br>
<joshtumath> +1<br>
<TabAtkins> argyle: "serach" has several icons, one for datalist, one for clearing<br>
<JakeA> +1 for `::picker-icon`<br>
<lea> I would rather name it after its purpose, rather than a specific rendering<br>
<TabAtkins> argyle: inputs that have a list become picker-invokers also<br>
<schenney> q+<br>
<dbaron> `::picker-icon` was one of the 2 most popular options in the prior poll referenced in jarhar's comment<br>
<TabAtkins> masonf: in search, the icon doesn't open a picker, it does something else<br>
<TabAtkins> argyle: so i imagine if i did ::icon in a search, i'd expect it to selecto both? ::picker-icon is clearly about the picker, makes sense<br>
<astearns> ack schenney<br>
<lea> `::picker-trigger`? `::picker-invoker`? `::picker-opener`? They're long, but not that much longer than `::picker-icon`<br>
<dbaron> masonf: for search, `::clear-icon` for the one that clears<br>
<TabAtkins> argyle: do we need to separate "picker button" from "picker icon"? one wrap the icon, can be styled, etc; the other is the content<br>
<fantasai> TabAtkins: You would use 'content' to insert a string or whatever<br>
<TabAtkins> astearns: so main diff between the firs titme on the popular list (picker-icon) and the next three is the rendering vs what it does<br>
<JakeA> But it isn't the only thing that does what the thing does :D<br>
<TabAtkins> astearns: want to go into some reasoning?<br>
<TabAtkins> fantasai: in some controls, the icon is the only clickable thing. in others it's an indicator, but you can click in multiple places. varies between controls, and has varied over time.<br>
<TabAtkins> astearns: suggest poll between icon and action?<br>
<TabAtkins> fantasai: suggest everyone put their favorite, we take the top few<br>
<dbaron> (I'm not sure if "button" is purpose or rendering...)<br>
<TabAtkins> lea: i like alan's suggestion. don't feel strongly about the name, but do feel strongly about it describing the action<br>
<masonf> +1 to just jumping to names<br>
<TabAtkins> fantasai: unsure the naming is reasonable. could collect into two sets...?<br>
<fantasai> s/naming/grouping/<br>
<TabAtkins> astearns: I'm convinced by David's statement that my categorization isn't correct.<br>
<lea> dbaron: I would think purpose. `::picker-button` seems better than icon as well<br>
<TabAtkins> astearns: let's straw-poll on the first four options.<br>
<argyle> 1<br>
<dbaron> s/dbaron:/dbaron,/<br>
<TabAtkins> 1) ::picker-icon 2) ::picker-button 3) ::picker-opener 4) ::picker-trigger<br>
<fantasai> 1<br>
<masonf> 1<br>
<schenney> 1<br>
<TabAtkins> 1<br>
<stepheckles> 1<br>
<kbabbitt> 1<br>
<noamr> 1<br>
<jarhar> 1<br>
<astearns> 1<br>
<ydaniv> 1<br>
<dbaron> 1<br>
<JakeA> 1<br>
<bramus> 1<br>
<futhark> 1<br>
<florian> 1<br>
<JakeA> Because it's iconography within the picker/opener/trigger<br>
<joshtumath> 1<br>
<oriol> abstain<br>
<lea> anything other than 1<br>
<ChrisL> 1<br>
<flackr> 1<br>
<TabAtkins> astearns: straw poll seems clear. Let's resolve on picker-icon. Objections?<br>
<TabAtkins> RESOLVED: go with ::picker-icon<br>
<TabAtkins> astearns: third straw poll?<br>
<TabAtkins> fantasai: that's it<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10908#issuecomment-2489173316 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 November 2024 17:27:08 UTC