[css-forms-1] Password visibility toggle

[kbabbitt]

https://drafts.csswg.org/css-forms-1/#field-pseudos has the following inline issue:

Define something for the password visibility toggle for user agents implementing it?

I'd like to see this. We currently have ::-ms-reveal implemented in Edge Chromium for compat with Edge Legacy and Internet Explorer. It would be great to get it on a path to standardization.

See also: whatwg/html#7293

[hober]

See also #6788

[lukewarlow]

for user agents implementing it.

I'm also slightly concerned by this phrasing? Is this more talking about the appearance: auto case?

Base appearance controls should either implement this or not across UAs. (My preference is for it to be included as part of the base appearance).

[nt1m]

My main reason for not initially including it initially was because of compat concerns (some sites would end up with two password icons when Mozilla tried adding this).

One thing that could be considered is including it for appearance: base, but I don't think this approach makes a lot of sense, given that users should be able to benefit from this by default without needing sites to opt-in.

@kbabbitt Is Chromium planning to ship this by default anytime soon? On hindsight, it's probably quirkable, but
I think it would alleviate some of the compat concerns to have Chrome ship some version of this initially.

I'd be happy to add something like this to the draft though.

[lukewarlow]

I suspect the two toggle issue can be mostly solved by aliasing to ::-ms-reveal which many sites detect and act appropriately (either setting display to none or hiding their own UI).

For some reason Firefox never seemed to try this (though I may have missed it).

[mfreed7]

Chromium also encountered compat issues with trying to add ::reveal about 5 years ago, but I think the compat issues are alleviated by the appearance:base opt-in, correct? I'm also in favor of supporting a "reveal" button - this is a very common pattern on the web.

@kbabbitt Is Chromium planning to ship this by default anytime soon? On hindsight, it's probably quirkable, but

For the compat issues mentioned, I don't believe there are plans to ship this, without the opt-in.

[lukewarlow]

Out of interest did chrome's compat analysis look into the ::-ms-reveal pseudo element and how that might change things?

It's somewhat a chicken and egg problem because without a pseudo to target sites can't feature detect and do the right thing here. The only browser that did/does have that is IE/Edge. How does Microsoft handle that compat issue currently?

[kbabbitt]

For ::-ms-reveal the author can set display: none to suppress the built-in button. I'm not sure whether that was considered for the standardized version. cc @sanketj who might have more context.

[lukewarlow]

I think it should definitely be doable even if we don't encourage it (because the browser can probably better handle various mechanics I know the MS one has a lot of thought put into the behaviour). But in the thing of fully stylable we should definitely allow it to happen.

I personally have always feature detected it and hidden my custom one when it existed. But others equally might hide the built-in one. Either situation would alleviate compat issues with double buttons.

It would be unfortunate to gate it on appearance: base but if that's necessary then so be it.

[sanketj]

+1 that a reveal button for <input type='password'> should be supported - it is a very popular pattern on the web! I like the idea of having a standardized version be a part of appearance: base. We'd need this standardized password reveal button to be easily customizable and also easily turned off, I can see developers wanting to do both.

[nt1m]

My take is that it's unfortunate to gate this behind appearance: base. This is an UX improvement that would generally be good for all users, so I'd rather have this be opt-out rather than opt-in. Other than that, yes, I agree we should do this, and that there should be a way to disable this (perhaps ::reveal { display: none } is fine for that.

[lukewarlow]

I guess ultimately appearance: auto is UA defined so it's kinda up to browsers to decide what to do.

One issue with having it in only one mode is it would break feature detection such as the one I've previously used, leading to neither the UA button NOR my custom one. (From memory)

@supports selector(::-ms-reveal /*::reveal*/) {

}

[mfreed7]

So in 2020 Blink did a "form controls refresh" which was a joint project between Chrome and Edge. As part of that project, we did actually add a ::reveal pseudo element for <input type=search> and we tried to ship it. However, we got several compat bugs reported (e.g. this one), enough that we decided to re-disable the ::reveal pseudo element. Microsoft was able to successfully ship it as ::ms-reveal at that point.

The compat problems all stem from (existing) sites that have their own "reveal" button. The UX is very confusing to users when two separate reveal buttons are present. It's a relatively-easy fix for such sites, just setting display:none on the pseudo element to hide it. But still there were enough of them that we weren't comfortable shipping the feature back then. But I think with an opt-in like appearance:base, it should be a great addition to the platform.

[lukewarlow]

Microsoft was able to successfully ship it as ::-ms-reveal at that point.

Sorry to be really specific here, did chrome try with that alias and Google ultimately had a different risk appetite to Microsoft? Or did Google not try to use that. If we can have that as a compat alias and it solve the issue that feels like a great way to go.

Failing that yes having it in appearance: base and maybe in appearance: auto but with a default display: none; (so it can be opted into without all of appearance base), seems like an okay tradeoff.

[mfreed7]

Sorry to be really specific here, did chrome try with that alias and Google ultimately had a different risk appetite to Microsoft? Or did Google not try to use that. If we can have that as a compat alias and it solve the issue that feels like a great way to go.

No, Chrome has a policy of not shipping vendor prefixes, so it was ::reveal or nothing. And due to compat (and general risk reduction to be able to ship the rest of the project), we went with nothing. I'm still very supportive of a ::reveal pseudo, as long as we can do it compatibly.