a character for an unknown character

[Philippe Verdy]

you only get a hint that some character has been hit because you see an
additional bullet or asterisk. This is per design. Such input field should
be limited to short input that is easy for you to type from your keyboard.
But many input forms will also include a clickable icon/button that can be
used to view temporarily you input, and that will hide immediately if you
release that icon/button Once you're trained to enter the password, you
know how to type it, and you just need a visual hint that you have
effectively pressed a key and a character was added to the input.
On all devices I know for entering a PIN code (payment terminals, cash
dispensers... these input are hidden and there's not even any way to view
the actual code (because the code is short and the keyboard is simple,
there's little risk of error on , unless you don't know that code at all
and there's an unlimited number of trials authorized). On most OSes, the
logon screen also hides the password by default. It is a critical need for
accessing some secured/private environments/applications. It is of course
not needed for every other kind of input.
Note: this discussion is no longer is scope. We were just talking about
plaeholders usable to replace some text. Not about if and when placeholders
or actual text should be rendered in applications

2016-12-24 2:33 GMT+01:00 Richard Wordingham <
richard.wordingham at ntlworld.com>:

> On Sat, 24 Dec 2016 00:44:00 +0100
> Philippe Verdy <verdy_p at wanadoo.fr> wrote:
>
> > If IBus cannot hide the input (i.e. generate the entered characters
> > to the application without displaying it, and let the output hints
> > (bullets/asterisks) be generated only by the application, then iBus
> > has a problem and may not be usable for compliant password inputs.
>
> The problem is that I can't tell what characters are being entered!
> I'm not even sure the problem is related to IBus - IBus-dependnent
> keyboards are not offered when entering passwords.
>
> Richard.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20161224/08ce6428/attachment.html>