- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 17 Sep 2025 16:36:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] Password visibility toggle`, and agreed to the following: * `RESOLVED: Go with ::clear-icon and ::reveal-icon` <details><summary>The full IRC log of that discussion</summary> <ntim> (It should be element.pseudoElement)<br> <TabAtkins> scribe+<br> <TabAtkins> kbabbitt: in April we resolved to add a pseudo-element for password vis toggle on input type=password<br> <TabAtkins> kbabbitt: left name to be bikeshedded<br> <TabAtkins> kbabbitt: have been some discussion in the issue, especially about naming form control pseudos in general<br> <TabAtkins> kbabbitt: as a general principle, use the word "icon" to indicate graphical indicators, "button" to indicate clickable<br> <TabAtkins> kbabbitt: from that, suggests we call it ::reveal-button<br> <TabAtkins> kbabbitt: and as an additional proposal, should rename the other Forms 1 pseudos to be consistent with this pattern<br> <lwarlow> +1<br> <TabAtkins> +1<br> <lwarlow> q+<br> <TabAtkins> fantasai: things get a little ambiguous with, sya, ::picker-icon, which is both clickable and an icon<br> <TabAtkins> fantasai: do we really want to be so clear about which is a button and which is an icon in our naming?<br> <TabAtkins> kbabbitt: I think there is some inconsistency in the naming, yes in some cases the picker would be a button in others it's an icon...<br> <masonf> q+<br> <TabAtkins> fantasai: I think that would be confusing for authors, yeah. should be consistent<br> <TabAtkins> fantasai: but that brings up whether we want to be so explicit in the names, or if we do want to lean into being unambiguous about whether it's an indicator or button<br> <ntim> q+<br> <fantasai> s/unambiguous/ambiguous/<br> <TabAtkins> kbabbitt: personally id' lean toward consistency when possible<br> <ydaniv> q+<br> <Rossen4> ack lwarlow<br> <TabAtkins> lwarlow: I've been thinkinga bout this for a bit, think I mentioned the step-up/down buttons<br> <TabAtkins> lwarlow: ideally something that's a button we'd call a button, I think<br> <TabAtkins> lwarlow: there are some weird cases tho<br> <TabAtkins> lwarlow: in a select element the picker icon is an icon, it's not actually a button. it's not really clickable, the select itself is what's clickable. so picker-icon makes sense there<br> <TabAtkins> lwarlow: but in a date input, the picker would be an actual button; you can click on the element but only the button actually summons the picker<br> <TabAtkins> lwarlow: file-selector is the other case - it looks like a button, acts like one. but really the whole element is clickable. so arguably that's not a "button" either....<br> <TabAtkins> lwarlow: agree that making authors write ::picker-icon sometimes and ::picker-button sometimes isn't ideal<br> <TabAtkins> lwarlow: but for new names, I do recommend having button in the name if it's a button<br> <TabAtkins> fantasai: for date picker, it depends on the platform, some pop it when you click anywhere<br> <TabAtkins> fantasai: so there's some ambiguity on whether it's an icon or button<br> <lwarlow> We'd probably want to specify that though ideally?<br> <Rossen4> q<br> <TabAtkins> fantasai: we have things that act differently between controls, and things that act differently on a single control depending on time or paltform<br> <TabAtkins> fantasai: so that raises the question - if these aren't really two distinct categories, should we even lean into categorizing everything, or lean away and not categorize them?<br> <TabAtkins> masonf: was gonna say a lot of that too<br> <TabAtkins> masonf: agree it's very ambiguous<br> <Rossen4> ack masonf<br> <TabAtkins> masonf: picker-icon was chosen because it was indeed not a button (the whole control is)<br> <lwarlow> q+<br> <TabAtkins> masonf: so i'd lean towards using -icon for everything because whether it's a button or not is ambiguous, but it's always an icon in some way<br> <Rossen4> ack ntim<br> <TabAtkins> ntim: I lean toward simplicity, like ::step-up (no suffix)<br> <TabAtkins> ntim: but in this case I think simplicity would be using the -icon suffix everywhere<br> <TabAtkins> ntim: making the distinction is really hard, yeah<br> <Rossen4> ack ydaniv<br> <TabAtkins> ydaniv: from what I know in UIs, button is something you activate with a click/keypress, and icon is activated by hover/focus, so I lean towards button<br> <Rossen4> ack lwarlow<br> <TabAtkins> lwarlow: wanted to push back on "it's always an icon", not sure that's always true<br> <kbabbitt> q+<br> <masonf> It's an icon with the words "choose a file" ... :-)<br> <TabAtkins> lwarlow: file-selector-button is actually a button, not an icon. step-up/down can be arguable, but they're rendered as a button. does depend on stylesheet to some extent<br> <TabAtkins> lwarlow: I do agree ::reveal should have a suffix, ::reveal on its own isn't clear enough<br> <TabAtkins> lwarlow: it even reads more as a pseudo-class on its own, not right as a pseudo-element<br> <TabAtkins> lwarlow: so id' be okay with ::reveal-icon if the group likes it. but i'd be a bit more against ::step-up-icon<br> <JakeA> `revealer`?<br> <Rossen4> ack kbabbitt<br> <ntim> I like ::reveal-icon because it also opens the possibility for other things than just an interactive button<br> <TabAtkins> kbabbitt: I just need a name so I can write down a spec, can explore the more general case in another issue. fine with either icon or button<br> <Rossen4> ack fantasai<br> <lwarlow> It's not an icon with words though... it's just some text in all 3 engines.<br> <TabAtkins> fantasai: we should focus on the author experience and what they'll have to memorize, and how we can reduce the memory load. so staying away from categorizing too much is best<br> <ntim> +1 to fantasai<br> <lwarlow> +1 I'd be okay with that<br> <TabAtkins> fantasai: for this issue, seems like we might just say ::clear-icon and ::reveal-icon (and leave the other pseudos undecided for now)<br> <TabAtkins> +1 for me too<br> <kbabbitt> +1 I'd be happy with that<br> <fantasai> s/undecided/alon/e<br> <fantasai> s/undecided/alone/<br> <masonf> +1<br> <TabAtkins> RESOLVED: Go with ::clear-icon and ::reveal-icon<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11845#issuecomment-3303781278 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 September 2025 16:36:56 UTC