Bugzilla

The 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.

I agree with the use case -- users need a way to temporarily disable the obscuring -- but I think they arrive at the wrong solution.
I'm guessing their intent is that the page author should build an unmasking button and set the `input-security` property 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.
That way the user only need to learn one way of doing the unmasking, the same way for all sites, and it will be available everywhere.
Also, an UA can likely implement a much better solution just in terms of usability/discoverability etc.  E.g.  putting the unmasking
button inside the password field itself etc.

I tend to think we should **not** implement this property. We should instead raise the concern that pushing the burden
of implementing this feature onto page authors has numerous problems. It will undoubtedly lead to numerous
incompatible implementations, some of which completely fail to work in some UAs.  I suspect most implementations
will also require JavaScript, so they will not work for NoScript users.

The 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 they arrive at the wrong solution.
I'm guessing their intent is that the page author should build an unmasking button and set the `input-security` property 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.
That way the user only need to learn one way of doing the unmasking, the same way for all sites, and it will be available everywhere.
Also, an UA can likely implement a much better solution just in terms of usability/discoverability etc.  E.g.  putting the unmasking
button inside the password field itself etc.

I tend to think we should **not** implement this property. We should instead raise the concern that pushing the burden
of implementing this feature onto page authors has numerous problems. It will undoubtedly lead to numerous
incompatible implementations, some of which completely fail to work in some UAs.  I suspect most implementations
will also require JavaScript, so they will not work for NoScript users.

The 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 they arrive at the wrong solution.
I'm guessing their intent is that the page author should build an unmasking button and set the `input-security` property 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.
That way the user only need to learn one way of doing the unmasking, the same way for all sites, and it will be available everywhere.
Also, an UA can likely implement a much better solution just in terms of usability/discoverability etc.  E.g.  putting the unmasking
button inside the password field itself etc.

I tend to think we should **not** implement this property. We should instead raise the concern that pushing the burden
of implementing this feature onto page authors has numerous problems. It will undoubtedly lead to numerous
incompatible implementations, some of which completely fail to work in some UAs.  I suspect most implementations
will also require JavaScript, so they will not work for NoScript users.

EDIT: this will very likely lead to abuse as well, e.g. `* { input-security: none; }`

The 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 they arrive at the wrong solution.
I'm guessing their intent is that the page author should build an unmasking button and set the `input-security` property 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.
That way the user only need to learn one way of doing the unmasking, the same way for all sites, and it will be available everywhere.
Also, an UA can likely implement a much better solution just in terms of usability/discoverability etc.  E.g.  putting the unmasking
button inside the password field itself, having a keyboard shortcut consistent with the platform etc.

I tend to think we should **not** implement this property. We should instead raise the concern that pushing the burden
of implementing this feature onto page authors has numerous problems. It will undoubtedly lead to numerous
incompatible implementations, some of which completely fail to work in some UAs.  I suspect most implementations
will also require JavaScript, so they will not work for NoScript users.

EDIT: this will very likely lead to abuse as well, e.g. `* { input-security: none; }`

The 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 build an unmasking button and set the `input-security` property 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.
That way the user only need to learn one way of doing the unmasking, the same way for all sites, and it will be available everywhere.
Also, an UA can likely implement a much better solution just in terms of usability/discoverability etc.  E.g.  putting the unmasking
button inside the password field itself, having a keyboard shortcut consistent with the platform etc.

I tend to think we should **not** implement this property. We should instead raise the concern that pushing the burden
of implementing this feature onto page authors has numerous problems. It will undoubtedly lead to numerous
incompatible implementations, some of which completely fail to work in some UAs.  I suspect most implementations
will also require JavaScript, so they will not work for NoScript users.

EDIT: this will very likely lead to abuse as well, e.g. `* { input-security: none; }`