Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
MatsPalmgren opened this issue Nov 3, 2021 · 16 comments
Open

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

MatsPalmgren opened this issue Nov 3, 2021 · 16 comments

Comments

@MatsPalmgren
Copy link

<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
Copy link
Member

annevk commented Nov 3, 2021

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

cc @whatwg/forms

@annevk annevk added the agenda+ To be discussed at a triage meeting label Nov 3, 2021
@tabatkins
Copy link
Contributor

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----
Copy link

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

@mfreed7
Copy link
Contributor

mfreed7 commented Nov 4, 2021

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
Copy link
Author

@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
Copy link
Contributor

Yay295 commented Nov 5, 2021

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.

@past past removed the agenda+ To be discussed at a triage meeting label Nov 5, 2021
@MatsPalmgren
Copy link
Author

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
Copy link
Contributor

mfreed7 commented Nov 20, 2021

@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
Copy link
Contributor

Yay295 commented Nov 20, 2021

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

@hober
Copy link
Contributor

hober commented Dec 7, 2021

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
Copy link
Contributor

emilio commented Feb 3, 2022

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
Copy link
Member

karlcow commented Apr 16, 2023

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

@lukewarlow
Copy link
Member

lukewarlow commented Jul 14, 2023

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
Copy link
Member

karlcow commented Jul 15, 2023

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
Copy link
Member

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
Copy link
Member

karlcow commented Jul 19, 2023

I would try the CSS WG.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests