<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 https://github.com/w3c/csswg-drafts/issues/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.

[emilio]

IF the UA exposes its own UI for this, that UI MUST be implemented by setting the input-security property on the element

I think that might be a reasonable compromise, making sure it's !important or so.

[karlcow]

See also the current discussion on the compat spec for Document -webkit-text-security

[lukewarlow]

Apologies if this is better suited to the CSSWG issue.

Would people consider standardising the ::-ms-reveal pseudo element as a form of feature detection for the UA toggle password visibility button.

In MS Edge there's an ::-ms-reveal pseudo element that can be used to hide custom reveal buttons. See https://docs.microsoft.com/en-us/microsoft-edge/web-platform/password-reveal

In JS I run CSS.supports('selector(::-ms-reveal)') and show or hide my custom button accordingly.

If the spec could directly implement the MS prefixed pseudo element that would allow for developers to hide their custom buttons.

I understand this could have the added downside of allowing sites to hide the default browser button which isn't ideal (and to be clear isn't my aim for having access to this pseudo). Potentially you could ignore the CSS properties and only add it for the good case of detecting and hiding the custom button.

An alternative approach would be to add some read only property that allows for feature detection but doesn't allow for disabling the browser button. (Thinking something like https://developer.mozilla.org/en-US/docs/Web/API/Navigator/pdfViewerEnabled)

Using the ::-ms-reveal selector in addition to /instead of a standard one has the added benefit of just working on sites that already account for Microsoft Edge.

[karlcow]

The compat spec is really here to describe things which need to be implemented when there is no spec for them. Aka browsers have to implement them to be compatible with the Web. And very often it should be only a transitory specification until there's a right place for the feature to be specified.

in the case of ::-ms-reveal, do other browsers need to implement this to be compatible with the Web? Aka do websites stop working if it's not in Firefox, Safari and Chrome?

[lukewarlow]

If they offer a password reveal button in their password inputs I would suggest yes else it will lead to a broken user experience. But I understand if it's not considered bad enough to warrant requiring it. Where would you consider the best place to bring it up as an idea? Html spec or CSS working group?

[karlcow]

I would try the CSS WG.