<input type=password> should provide UI to show/hide its value

[MatsPalmgren]

<input type=password> obscures its value by default, however users may wish to temporarily disable this obscuring in order to confirm that they’ve typed their sensitive information correctly. I propose that the password control should provide built-in UI for this function. For example:

(There is a proposed CSS input-security property to enable web authors to provide this function, but I think that would be harmful to users and thus I strongly believe input-security should not be added to the web-platform, as I've explained in w3c/csswg-drafts#6788.)

The right solution to fulfill this user need is for password controls to have built-in UI for it. I think the HTML spec should at least recommend that UAs implement it as a best practice.

I hope other UA vendors will join me in adding this feature for all users on all platforms. It would be great if we could converge on similar behavior and iconography for it.
(Microsoft Edge already provides this UI by default. The work to add this feature to Gecko is done in bug 502258 and I'm making it look/behave roughly as in Edge.)

[annevk]

Safari also has UI inside a password control. We should at least mention in the specification that this is allowed.

cc @whatwg/forms

[tabatkins]

I very much enjoy this UI, and appreciate it when websites add it themselves, so while we don't generally specify UI in the spec, at least recommending it would be nice.

[smaug----]

How do Safari and Edge deal with the case when the page also provides a button to show the value?

[mfreed7]

So we just discussed this at the spec triage meeting. Chromium actually already implements this behavior, but it is disabled by default due to compat issues we encountered. Essentially, sites that already provide such a button are "broken" by the appearance of another show/hide button. The appearance is funny, with either two visible buttons, or partially overlapping buttons. Also the behavior could be broken, because the buttons are doing different things (e.g. changing the type to text).

I'm supportive of allowing this type of button, but I think we need to add a pseudo element for it, so sites with their own show/hide buttons can hide the builtin one.

[MatsPalmgren]

@mfreed7 I don't think breaking a few sites should block us from implementing nice features that helps our users on all sites that has a password field.

but I think we need to add a pseudo element for it, so sites with their own show/hide buttons can hide the builtin one.

I am strongly opposed to allowing page authors disable this built-in feature. Instead, we can add some feature detection they can probe to inhibit their custom button. (e.g. a read-only hasShowPasswordButton boolean, or whatever)
That way we discourage hacks to add a custom button, and when all major UAs eventually have it built-in, they will notice that their custom code is redundant and can be removed. (I doubt sites do this because they love designing custom UI, they do it simply because some UAs don't support it natively -- in other words, they basically agree with our analysis that this is a useful feature!)

[Yay295]

It can be hidden in Internet Explorer and Edge with ::-ms-clear {display:none}. The button takes up space in the input, and it can cover up the end of the password if you don't account for it being there.

[MatsPalmgren]

it can cover up the end of the password if you don't account for it being there

That's not what I'm seeing. The scroll box for the text value ends at the edge of the button, as expected. What sometimes happens in Edge though is when you toggle between the masked/unmasked values the scroll position unexpectedly moves so that the end of the value is scrolled out of view. This seems to happen when the characters are wider than the "bullet" characters used for the masking. I tested with characters that are the same width (or narrower) such as "i" and "I" then the end of the value stays visible when toggling between masked/unmasked. I think what you're describing is just a bug in Edge.

[mfreed7]

@mfreed7 I don't think breaking a few sites should block us from implementing nice features that helps our users on all sites that has a password field.

Unfortunately, we don’t get the luxury of this position. Breaking the internet is something we work pretty hard not to do. You can see a few examples of the very real (and very bad for users) breakages we encountered when we tried this before, here.

I’m not suggesting we can’t implement this type of feature, and I share your feeling that it would be generally helpful to users. But we do need to do it in a careful way to avoid doing harm. Part of that is allowing sites a way to opt out if they are able to provide a better experience for users.

[Yay295]

Why not add this as an opt-in feature instead?

[hober]

Safari already presents some UI inside <input type=password> for autofill. It would be challenging to also squeeze in some other UI while retaining usability, especially on small form fields. I'd generally prefer the spec not mandate UI here.

Maybe the spec could say something like "IF the UA exposes its own UI for this, that UI MUST be implemented by setting the input-security property on the element." That way we could at least ensure browser-provided UI and page-provided UI didn't fight each other.