3 ms·
I don't see why contenteditable should be better than form elements. contenteditable is meant for formatted text, not plain text entry. For example, if you cut
by ot 14y ago
I don't see why contenteditable should be better than form elements. contenteditable is meant for formatted text, not plain text entry.
For example, if you cut&paste formatted text into a contenteditable, it will keep the formatting [1]. Then you have to intercept the paste event and sanitize the text. Also, the selection model is a mess and slightly incompatible among browsers (although this might be fixed in modern browsers, I haven't looked into it for a while).
What are the benefits of contenteditable that justify to go into all this trouble?
[1] http://stackoverflow.com/questions/3306205/how-to-avoid-webkit-contenteditable-copy-paste-resulting-in-unwanted-css http://stackoverflow.com/questions/3306205/how-to-avoid-webk...
- masklinn 14y ago> contenteditable is meant for formatted text, not plain text entry. contenteditable is meant for editing content, what kind of content you edit with it is up to you. > What are the benefits of contenteditable that justify to go into all this trouble? Coherent and simple styling and integration, avoidance of reflow (especially when toggling between editable and non-editable)
- jazzduck 14y agoAs a developer, why the hell do I need stylized text when I'm having a user fill out, say, a shipping form? Why should I have to worry about whether someone applied italics to their zip code? Should I really have to try to make the thermal label printer print out Zapf Dingbats if someone pastes that in there? Also, forms go far beyond text input. Are you seriously suggesting that dropdown menus, multi-select boxes, sliders, radio buttons, datepickers, etc. should all be reimplemented on top of a rich text element?