textarea inserts return when activated
textarea inserts return when activated
finsight-ak
Posts: 19Questions: 5Answers: 0
in Editor
When a textarea field is instantiated by keys navigation with an enter key press, a carriage return is inserted into the editable field in front of any existing value--or just inserted at the beginning if no current value. The textarea should just allow edit and not insert the navigation key used to initiate the edit. Please advise?
This discussion has been closed.
Answers
This occurs because KeyTable allows the editing to start immediately on key press - for example when you focus on a cell you can start typing the value you want and the editing will immediately reflect that.
Interestingly a
textareaappears to be slightly different it is inserting the value at the start of the input rather than replacing the current value - I'm not sure why it would do that but I'll look into and address that.The return key is perhaps a special case - it is a valid input, so it is perfectly possible for someone to want to put a return character in there - even starting the textarea with a return character.
That aspect I probably won't change at the moment since it is valid, but it will have it replace the existing text like it does for a regular input.
Allan
I've just committed the fix to have the textarea behaviour match that of a regular input element. That will be int he next release and the nightly will rebuild shortly.
The return key behaviour is still the same - I'll look into how I might provide an option to disable that.
Allan
Thanks Allan, I would ask that you consider "Principle of Least Surprise"? ALL other fields,when the user hits return key the editing begins with the current value intact. I can see how subsequent return keys should be considered valid textarea input, and require a different nav out of edit mode. I am using inline edit with bubble edits only on textarea fields, so as to not disrupt the datatable layout on multiline edit. This provides UI cues for cancel and submit with textarea. Also, consider: likely a user does not want to lose all the current value when editing a textarea--just my thoughts...
Thanks for the feedback. I will consider this in future!
The KeyTable / Editor integration is based on Excel's behaviour. The return key does actually behaviour different at the moment - in Excel it will move on to the next row while in KeyTable it starts editing - I've been considering changing this to match Excel and probably will for the next release.
Regards,
Allan
Hi @allan is there any update on this?
Not yet sorry. I will post back here when I've had a chance to look at it.
Allan
Hi Allan!
I've got the same problem. My table is fully editable by keyboard navigation.
It's no problem to overwrite the contents of a field by just starting to type. But this doesn't always make sense, the user might just want to correct a typo or - in case of textareas - add more information. So I need the return key as a way to start inline editing without overwriting the current cell data.
Excel might behave differently here - but I don't think it is a good idea to adopt this behaviour, at least not without the option to switch it off.
And in any case, I dare say: effectively overwriting the whole existing text with a single newline is not what any user expects nor wants.
What are your thoughts about a regular
<input type=textelement? Presumably it should match the behaviour of a<textarea>. I wonder if just selecting all text in the input / textarea would be the best approach...Allan
Yes. Ideally all fields (regular text fields, textareas, dropdowns, …) should behave similar in inline editing mode with KeyTables. Arrow keys move cell focus. Return key activates editing of the field (with its content selected). Tab key submits and moves cell focus to the next/previous field. Typing letters/numbers activates editing and overwrites the content of the selected field.
I also try to support the return key to submit regular text fields and dropdowns. Textareas are the only deliberate exception in this case because if I present the user a multi-row text box (resizeable in many browsers), he wants to enter more text and certainly expects the return key to produce new lines instead of submitting (analog to the default behaviour in HTML forms).
Users know that browser applications are different from Excel and if they see a familiar input element of web browsers (like a textarea) they have mixed expectations even if keyboard navigation mimics Excel in other cases.
Apart from that exception: Selecting (not overwriting with new line) the content in regular
<input type=textelement and in a<textarea>after pressing the return key on a selected cell would be great. :-)Makes sense - thanks for your thoughts on this. I will look into this and will probably introduce it in the next version of KeyTables.
Allan
Thank you, Allan, that's great news!
Committed here and will be in the nightly in just a few minutes.
Allan