- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Nov 2021 15:46:36 +0000
- To: public-css-archive@w3.org
MatsPalmgren has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-ui] 'input-security' considered harmful ==
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.
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6788 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 November 2021 15:46:38 UTC