Document -webkit-text-security

[jfkthame]

The non-standard -webkit-text-security property exists in both webkit and blink, but does not seem to be mentioned in the compatibility standard.

We've seen real-world webcompat issues because this property is not implemented in Firefox; see https://bugzilla.mozilla.org/show_bug.cgi?id=1826629 and webcompat/web-bugs#114591.

(There's some information about -webkit-text-security on MDN, but note that it is not entirely complete or accurate at present.)

Note also that -webkit-text-security is entirely distinct from the (questionable) CSS-UI-4 input-security property.

[miketaylr]

Ah, interesting. If Mozilla is willing to land this, we should totally spec it here. Thanks for the report @jfkthame.

[jfkthame]

I don't think Mozilla is exactly "keen" on this -- but we felt it unlikely that webkit and blink would be prepared to drop it, given existing usage. If you think that's a possibility, though, that'd be great.

[miketaylr]

Yeah, sadly usage is much higher than the typical threshold for a deprecation: https://chromestatus.com/metrics/css/timeline/popularity/322

[jfkthame]

Do you know whether that reflects only "direct" usage by authors, or does it also include the use of <input type=password>, which at least in blink appears to set -webkit-text-security via the UA stylesheet?

If the latter gets counted as "use of this feature", that could substantially change the picture.

[miketaylr]

I suspect the former, given that <input type=password> usage is much higher (4.5%) https://chromestatus.com/metrics/feature/timeline/popularity/192

[karlcow]

Let's see online: Github Search for -webkit-text-security

it seems also used for fingerprinting, I wonder how it might break firefox in another way, by selecting codepath which was not meant to be seen, but most of the time it seems to be used by itself.

There are some interesting usage patterns in terms of UI on why people are using it or more exactly why in some circumstances people do not want to use type="password"

1. want to have a hidden PIN code, but do not want the browser to prompt for saving it.
2. The fact to be able to get a UI widget to enter numbers.
3. Usage of specific fonts to hide the code.

Some hacks people rely on to try to get what they want, aka revealing/hiding the input.

Also the intent to ship from Mozilla for [css-ui-4] Implement "input-security" CSS property

BUT

CSS-UI-4 seems to want to remove the feature.

The CSS-WG has agreed that while be believe that providing this piece of functionality to users is important, doing it via CSS+JS is the wrong approach, and that instead it should be built into user agents: this needs to work consistently from site to site for it to be discoverable and understandable by users, this needs to work even when JS is turned off, this needs to have consistenly solid accessibility… We therefore intend to remove this from the specification and instead, we would like to see this behavior specified in the HTML specification as part of the interaction model of password fields. Holding off deleting until the situation with HTML is clarified. See w3c/csswg-drafts#6788 and whatwg/html#7293.

• [css-ui] 'input-security' considered harmful
• should provide UI to show/hide its value

[karlcow]

Mozilla just resolved it as fixed.
https://bugzilla.mozilla.org/show_bug.cgi?id=1826629

[miketaylr]

Cool, we should document it then. Patches welcome, etc.:)