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

Hi again. I gave myself a bit more time to confront the requirements above to the ecosystem, and in particular to the design of the 100 most visited web sites of the world and the main WebExtensions available. After careful review, I don't think that the original proposal above based on `:revealed` and `::reveal` is a desirable solution. Let me explain:

1. the only opt-in/opt-out option is to use `display: block` or `display: none` on the `::reveal` pseudo-element. That seems to me pretty hacky.
2. it's going to be extremely hard to attach anything, and in particular a page-defined localized tooltip or a specific behaviour, to the pseudo-element.
3. the behaviour of the reveal "button" will be browser-defined while I deeply think it should be user-defined.
4. it's not extensible to other buttons/actions
5. the burden on web sites and WebExtensions is a bit too high since the position of the reveal button will be extremely painful to detect

So I think a better option is to completely change the point of view and simplify the proposed solution:

- add a new `helpers` attribute to all `<input>` elements being a text field
- this `helpers` attribute should carry a coma-separated list of IDs
- if an ID in the coma-separated list in a `helpers` attribute corresponds to an element in the document, that element is fully extracted from the normal flow of the document and rendered inside (we need to discuss what it precisely means) the text field, from the end edge of the field and in order of appearance inside the `helpers` attribute.
- add a new attribute `revealed` to `<input type="password">` matching a new DOM boolean read-write `revealed` attribute to let both JS and CSS deal with revealing the value of a password input field. After all, this will be a intrinsic behaviour of password fields, not a rendering thing only, so that deserves to be in the DOM.
- no need for a pseudo-element since the component (not using the word "element" on purpose here) representing a given helper is in the DOM
- no need for a dedicated pseudo-class. No need to think of a functional pseudo-class if we want to make it extensible.
- allows localized tooltips, user-defined behaviours and all the powah of the Web
- no more security risk than a WebExtension changing the `type` attribute of an input field from `password` to `text`...

With the above, web sites and extensions implementing a Show button in password fields will be able to drop their existing hacky code easily; web sites and extensions adding extra UI elements to text fields will be able to do so in a way that does not collide with existing UI (and that's a VERY big plus), getting rid of usually hacky and very expensive code; extensions willing to "disable" the Show button will be able to do it; the solution works for mag-glass in search fields, powerful dropdown menus in combos, etc.

Looking forward to reading your opinions.

-- 
GitHub Notification of comment by therealglazou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3934#issuecomment-555905594 using your GitHub account

Received on Wednesday, 20 November 2019 08:55:52 UTC