Open jfkthame opened 1 year ago
Ah, interesting. If Mozilla is willing to land this, we should totally spec it here. Thanks for the report @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.
Yeah, sadly usage is much higher than the typical threshold for a deprecation: https://chromestatus.com/metrics/css/timeline/popularity/322
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.
I suspect the former, given that <input type=password>
usage is much higher (4.5%) https://chromestatus.com/metrics/feature/timeline/popularity/192
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"
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 https://github.com/w3c/csswg-drafts/issues/6788 and https://github.com/whatwg/html/issues/7293.
Mozilla just resolved it as fixed. https://bugzilla.mozilla.org/show_bug.cgi?id=1826629
Cool, we should document it then. Patches welcome, etc.:)
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 https://github.com/webcompat/web-bugs/issues/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-4input-security
property.