#366DailyCode #Day14 — Input type password
--
I thought a lot about today’s code, if I would post it or not, because it’s more like a tip than an algorithm. But I conclude that it’s a nice tip and a cool thing to do with JavaScript+DOM manipulation. So, how to deal properly with input type password?
It’s pretty cool (and it causes a little confusion in some people with no computer knowledge) fill this input type password. I was teacher for elderly once and they always were intrigued because they typed normal characters and it appeared just little black balls in the screen. But with the popularization of smartphones this practice has to be changed
It doesn’t mean that the input type password have to be abandoned, because it prevent who ever whose is beside you to see your password. But in the smartphone this type of field isn’t practical because of two basic reasons:
- The user almost always commits typo on smartphone, and in the input type password he/she doesn’t have the option to check the password.
- It’s not that safe because to the curious person beside the user, because when he/she press the keyboard, the raw letter appears in the screen for a bit while before it turn into a little black ball.
So the solution simpler and most used for this issue is to keep the input type password just the way it is, and include an option to show the password. So the user can type the password more comfortable and check if its right later. This practice became so common that microsoft adopted it as a pattern of all input type password’s fields of Windows 8.
#366DailyCode #Day14 — Input type password [github]: https://github.com/sheldonled/366DailyCode/blob/master/day/14.html
#366DailyCode #Day14 — Input type password [codepen]:
