Re:Chrome 56 will mark HTTP pages with password fields as no...
by dTal on Sunday January 22, 2017 @04:56PM
(#13457794)
More broadly: a text input box is in fact a small but surprisingly comprehensive text editor. It supports a cursor with insert, delete, and overstrike; highlighting, undo/redo, cut/copy/paste; and shortcut keys for all that. It supports every keyboard layout and every input method. It obeys standardized focus rules. It's even got word wrap and spell checkers these days.
So, you want to go your own way? How much of that do you need to reimplement? And how confident are you that the subset you choose doesn't completely ignore some vital use case you forgot about?
You certainly can't get away with just wiring keystrokes to a field.
Re:Chrome 56 will mark HTTP pages with password fields as no...
by eru on Sunday January 22, 2017 @06:15PM
(#13458263)
You can: you'll just get a buggy half-assed implementation. In a corporate envirnonment with bad politics, that might still be the only way to go. (Apart from quitting.)
Re:Chrome 56 will mark HTTP pages with password fields as no...
by skybrian on Sunday January 22, 2017 @03:00PM
(#13457045)
CodeMirror has figured this out. When you type it's actually into a hidden input, and it updates a separate display.
Reimplementing CodeMirror (including highlighting, etc) is hard enough that most web developers probably can't do it. But it only takes one person to create a library.
For anyone who is wondering what these ways are, here are a couple:
1) Backspace is a crufty special case
2) What happens when someone highlights text in the input box and types over it?