W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2019

Re: [csswg-drafts] [selectors-4] Password reveal pseudo-element and pseudo-class (#3934)

From: Daniel Glazman via GitHub <sysbot+gh@w3.org>
Date: Thu, 14 Nov 2019 10:24:18 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-553823975-1573727056-sysbot+gh@w3.org>
Hello Greg. I have a few concerns I would like to share here. All of that comes from my experience as CTO of a company releasing a WebExtension containing a password manager. Disclaimer: I don't work there any more and my words represent my own opinion only.

The main issue with your proposal is the following one: as of today, "Show" buttons exposed on the Web in password fields are added through extra elements and these elements allow third-party tools - like password managers - to detect UI collisions with the UI thingies they want to add themselves to password fields. If we move to a pseudo-element added to `<input type="password">`, that will be extremely difficult for password managers to continue doing so. Furthermore, styling dynamic changes on that Show button is going to be tricky since pseudo-elements are always last in a selector, after pseudo-classes.

In short:

- it's limited to password fields while some other `<input>` fields could greatly benefit from added  "internal buttons"
- it's not extensible. `:revealed` and `::reveal` are nice but why should we limit this to one action only?
- dynamic styles will be an issue. `:hover::reveal` is possible but `::reveal:hover` is not
- it will severly harm all existing password managers since it won't be easy to detect the bounding rect of the pseudo-element. Because of that, extra buttons will often overlap with this new Show button because password managers will not be able to detect UI collisions
- the action attached is browser-defined only. There are two very different UXs for a reveal button: first statically switches the field value from obfuscated to readable and back, the second one does only when the button is maintained pressed/activated. This should remain possible.
- it raises pretty serious A11Y concerns because it's based on a pseudo-element

In my opinion, the requirements here should be the following ones:

1. the solution should be generic enough to apply to all `<input>` representing a text field, including `<input type="search">` and its omnipresent clickable mag-glass button.
2. input field buttons should allow all possible behaviours: simple buttons, dropdown menu, on-hover tooltip, etc.
2. it should be possible to add user-defined (JS-based) behaviours to an input field button
3. ability to fully style input field buttons
4. ability to add a localized tooltip to input field buttons
5. ability to query the DOM to retrieve the position/geometry of input field buttons
6. extensible solution allowing password managers to add their own input field buttons without UI collision with the existing ones (for instance added in reverse direction from the end edge of the input field)
7. it should allow to get rid of existing solutions absolutely positioning a button inside a text field and tweaking the `type` attribute of the input field. On some web pages, it's even worse: the reveal button switches between two different elements, one `<input type="password">` and another `<input type="text">`...

More about a potential proposal later.

-- 
GitHub Notification of comment by therealglazou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3934#issuecomment-553823975 using your GitHub account
Received on Thursday, 14 November 2019 10:24:19 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:56 UTC