Re: [csswg-drafts] [css-forms-1] Password visibility toggle (#11845)

The CSS Working Group just discussed `[css-forms-1] Password visibility toggle`, and agreed to the following:

* `RESOLVED: Adopt a pseudo-element representing the password reveal icon control. Make it 'display: none' by default in 'appearance:none'; match platform convention in 'appearance:auto', and displayed in 'appearance:base'. Name TBD.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> ntim: MSFT Edge ships a password visibility toggle. It's an icon that reveals the password in plain text<br>
&lt;ntim> https://github.com/w3c/csswg-drafts/issues/11845#issuecomment-2760207097<br>
&lt;fantasai> ntim: I proposed adding a standardized pseudo for this<br>
&lt;fantasai> kbabbitt: The Edge feature is a vendor extension, would like to standardize<br>
&lt;fantasai> kbabbitt: We tried to implement in Blink , but ran into compat problemns<br>
&lt;fantasai> kbabbitt: Would like sites to be able to opt into it<br>
&lt;fantasai> kbabbitt: One change I might want to suggest ot Tim's proposal is the `display: block` but can leave to future discussion<br>
&lt;fantasai> ntim: Thoughts?<br>
&lt;fantasai> dholbert: Is this the first case where appearance:base provides a component not available in default styled component?<br>
&lt;fantasai> ntim: The button would always be present in the pseudo-element tree<br>
&lt;fantasai> ntim: Just, depending on 'appearance', the default 'display' would be different.<br>
&lt;fantasai> astearns: But some implementations don't have this button at all?<br>
&lt;fantasai> dholbert: feels strange that 'appearance:base', at least visually, *adds* something.<br>
&lt;fantasai> dholbert: it does seem like a nice way to go back and add something that should have been there in the first place<br>
&lt;fantasai> dholbert: website with existing control might be surprised to get the new control when applying 'appearance: base'<br>
&lt;dbaron> (as a user, I want reveal buttons on all password fields whether or not the site wanted it)<br>
&lt;astearns> +1 dbaron<br>
&lt;fantasai> fantasai: I'm not too worried about that particular scenario. 'appearance: base' causes changes, should be checking your site to see if you're happy with those changes<br>
&lt;dbaron> (particularly when entering passwords on my phone)<br>
&lt;lea> agreed with fantasai<br>
&lt;fantasai> ntim: I wanted to leave 'appearance: auto' to the UA, to match platform conventions. And some platforms don't have this button.<br>
&lt;fantasai> ntim: I have less strong opinions about 'appearance: none'; but for compat we might want to hide it by default.<br>
&lt;fantasai> lea: This pseudo would not be present if the UA doesn't implement the functionality<br>
&lt;fantasai> ntim: Ideally it would be present in all the UAs.<br>
&lt;lea> q?<br>
&lt;lea> q+<br>
&lt;fantasai> ntim: Just that in 'appearance: auto', up to UA whether to show or not<br>
&lt;fantasai> ntim: but in 'base' it's consistent -- always get the button by default<br>
&lt;fantasai> lea: 2 things. Whether impl has password reveal or not. And whether visible or not.<br>
&lt;fantasai> lea: if impl doesn't impl, then pseudo shouldn't exist<br>
&lt;astearns> ack lea<br>
&lt;fantasai> ntim: Problem with different UAs doing different things is lack of consistency. Not interoperable.<br>
&lt;fantasai> ntim: developer tests in one browser, works; other browser doesn't work, this is bad<br>
&lt;lea> q?<br>
&lt;lea> q+<br>
&lt;fantasai> ntim: If they start by building site on browser without password reveal, and add a custom one, and suddenly a browser changes to add by default -- now have double reveal icons, also not great<br>
&lt;fantasai> ntim: So we want to be consistent at least for 'appearance:base'<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: if the UA doesn't implement the reveal button, then obviously it should not claim to support the pseudo<br>
&lt;TabAtkins> fantasai: but we're saying that all UAs *should* implement this, it's a required part of the spec<br>
&lt;TabAtkins> fantasai: and to match paltform conventions, appearnace:auto (the default), the UA would be able to hide the reveal<br>
&lt;TabAtkins> fantasai: but the pseudo exists and is implemented<br>
&lt;TabAtkins> fantasai: and Tim is proposing that in the defaults, appearance:auto gives you platform convention, appearance:none has it turned off for compat, and appearance:base has it turned on. this makes it obvious to authors that it exists in the first place.<br>
&lt;astearns> ack lea<br>
&lt;TabAtkins> fantasai: otherwise it's more likely that authors will design a custom version that they dont'a ctually need<br>
&lt;lea> No objection to hiding it in auto if the capability is implemented. I don't think there is a precedent where UAs must add something even for standards they don't implement. E.g. what does a UA do if they actively oppose a certain standard? Still implement the pseudo? What about pseudos that were added after appearance: base? Of course the trees will be different.<br>
&lt;dholbert> (For reference, I've got screenshots of double 'reveal' icons from when Firefox tried to ship a reveal icon by default (for `appearance:auto`) a few years back: https://bugzilla.mozilla.org/show_bug.cgi?id=1754086 .  Based on experience there, I think backwards-compat definitely likely requires UAs to hide the button with `appearance:auto` and `appearance:none`)<br>
&lt;TabAtkins> fantasai: it's a violation fo the css spec to treat syntax as valid for a featur eyou don't support<br>
&lt;TabAtkins> lea: oh, i thought that's what tim was proposing<br>
&lt;TabAtkins> fantasai: nope<br>
&lt;TabAtkins> lea: sorry, misunderstood<br>
&lt;fantasai> astearns: Are we resolving on Tim's proposal?<br>
&lt;bkardell> s/ featur eyou / feature you /<br>
&lt;fantasai> astearns: further litigate details in future?<br>
&lt;fantasai> ntim: Add also to make visible by default, not in the comment.<br>
&lt;fantasai> astearns: proposed to adopt Tim's proposal, and define it as visible in 'appearance: base'<br>
&lt;kbabbitt> q+<br>
&lt;fantasai> ntim: Might want to decide on a name. `::reveal` or `::reveal-icon`<br>
&lt;fantasai> ntim: Many pseudo elements in the current draft that are -icon<br>
&lt;lea> q+<br>
&lt;astearns> ack kbabbitt<br>
&lt;dholbert> q+<br>
&lt;astearns> ack lea<br>
&lt;fantasai> kbabbitt: prefer ::reveal because similar to MS-prefixed version, but no objection either way<br>
&lt;fantasai> lea: How does someone detect whether the password is revealed or not?<br>
&lt;fantasai> fantasai: This doesn't tell whether revealed or not, just is a pseudo-element for the icon<br>
&lt;fantasai> lea: I suspect in many cases authors will want to style the icon differently based on whether in revealed state or not<br>
&lt;fantasai> lea: we should decide names together<br>
&lt;jensimmons> +1 for not deciding in isolation!<br>
&lt;fantasai> ntim: so :reveal?<br>
&lt;astearns> ack dholbert<br>
&lt;ntim> :revealed<br>
&lt;lea> `:revealed::reveal` then doesn't really work<br>
&lt;fantasai> :password-show :password-hidden<br>
&lt;dbaron> +1 to `:revealed` as a pseudo-class name<br>
&lt;fantasai> dholbert: So having computed value of 'display' depends on computed value of 'appearance'<br>
&lt;fantasai> dholbert: I don't like computed value dependencies very much... defer to emilio<br>
&lt;fantasai> dholbert: action at a distance is not great<br>
&lt;fantasai> dholbert: but maybe it's fine<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: since we have a bunch of -icon we should be consistent and use ::reveal-icon<br>
&lt;TabAtkins> fantasai: for the pseudo-class, hadn't thought of it before<br>
&lt;fantasai> PROPOSED: Adopt a pseudo-element representing the password reveal icon control. Make it 'display: none' by default in 'appearance:none'; match platform convention in 'appearance:auto', and displayed in 'appearance:base'<br>
&lt;fantasai> (Name TBD)<br>
&lt;fantasai> PROPOSED: Adopt a pseudo-element representing the password reveal icon control. Make it 'display: none' by default in 'appearance:none'; match platform convention in 'appearance:auto', and displayed in 'appearance:base'. Name TBD.<br>
&lt;fantasai> RESOLVED: Adopt a pseudo-element representing the password reveal icon control. Make it 'display: none' by default in 'appearance:none'; match platform convention in 'appearance:auto', and displayed in 'appearance:base'. Name TBD.<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-2770494974 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 1 April 2025 19:34:47 UTC