A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/w3c/csswg-drafts/issues/6788 below:

[css-ui] 'input-security' considered harmful · Issue #6788 · w3c/csswg-drafts · GitHub

The css-ui spec says:

Users may wish to temporarily disable this obscuring in order to confirm that they’ve typed their sensitive information correctly. The input-security property may be used by authors to enable or disable this obscuring.

https://drafts.csswg.org/css-ui-4/#input-security

I agree with the use case -- users need a way to temporarily disable the obscuring -- but I think the spec authors arrive at the wrong solution.
I'm guessing their intent is that the page author should add a separate button to the page which sets the input-security property on the password control to do the unmasking.
I think this is a bad solution to the problem. This feature is much better implemented in the UA by supporting it directly in the password field. E.g.


(I believe Edge and some other UAs already do this.)

That way the user only need to learn one way of doing the unmasking, the same way for all sites, and it will always be available for all password controls. A UA is much more likely to implement a good solution in terms of usability/discoverability/accessibility, keyboard shortcuts consistent with the platform etc.. Having the unmasking button directly inside the password field itself also makes it obvious what it's for.

I don't really see a use case for input-security on other form controls either. It could be used on <input type=text> to obscure the text there, but if there's a need for that then that's a strong indication the author should have used an <input type=password> in the first place.

We've already seen that relying on page authors to implement custom form control behavior leads to problems. It will undoubtedly lead to numerous incompatible implementations, some of which completely fail to work in some UAs. Typically such implementations will also require JavaScript, so they will not work for NoScript users. They usually also fail to have proper support for keyboard navigation, accessibility, high-contrast themes etc...

input-security could also be abused, e.g. * { input-security: none; }

I request that input-security is removed from the spec.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3