I find it sad (to annoying) that these projects still use actual form elements instead of `contenteditable`, even though they're quite obviously full-JS (and probably not going to be submitted through HTML forms), given the difficulty of correctly styling, integrating and interacting with form elements.
The web is in dire need of a library correctly reimplementing "form behaviors" (events, mostly) on top of contenteditable, and allowing those behaviors to be applied to arbitrary (to the extent that browser implementations allow) elements on the fly.
edit: just in case, don't take me wrong, HTML forms should stay and I'm an advocate of less javascript everywhere as it tends to be mandated in places where it has no reason to be (and to ultimately decrease usability rather than enhance it), but if you're going to do "edit in place" and rich web applications which require javascript to run — and using the library linked above would probably qualify as you can't do anything without JS enabled and a fairly recent browser running it. And in those cases, HTML form elements tend to be a hindrance more than a help.
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?
As 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?
So it seems that a user agent detection and fallback for Android < 3.0 devices is still a great necessity, and it is difficult to say just how many other devices fall into this category.
This next link is the most comprehensive list of support I could find, and although the support does seem widespread at this point, there are probably still too many user agent unknowns for someone wanting to make a mobile friendly library around the feature:
http://caniuse.com/#feat=contenteditable
>> I find it sad (to annoying) that these projects still use actual form elements instead of `contenteditable`, even though they're quite obviously full-JS (and probably not going to be submitted through HTML forms), given the difficulty of correctly styling, integrating and interacting with form elements.
I think this is because of performance. form elements are rendered differently and actions mostly result in a limited repaint and a couple events fired. contenteditable DOM elements are a lot more work to update.
I'm not sure about this hypothesis, when making a field editable requires inserting a bunch of dom nodes and trying to position your brand new input at the right place, it should be way more repaint that the NOOP of adding an attribute to the element.
Aloha is not a traditional WYISWYG editor contained in a textarea. You can apply it to any HTML element in a page, which would turn them in to editables (check this example of math editing - http://wysiwhat.github.com/Aloha-Editor/cnx.html)
> Aloha is not a traditional WYISWYG editor contained in a textarea.
Did you miss the part where I said I wasn't talking about RTE?
I don't care that it's implemented using something which was introduced to build RTEs in the first place and has been used for exactly that for the past 12 years or so (which does happen to make contenteditable-based RTEs traditional, as are designMode-based ones, despite your apparent assertion to the contrary), my original comment is not about rich text edition.
It took me a minute to figure out how to edit the field.
You're creating new behavior which is counter to how we all understand links. Underlined words take us to other places. And dashed words unfortunately have the stigma of opening up some crappy add referencing the word.
Consider instead a little edit carrot next to the word and clicking anywhere in the cell makes it editable.
I don't really understand why this interaction model is a good thing. The inline and popup versions require me to confirm every single action. It's forcing me to perform two actions (select, confirm) when a regular form uses just one (select).
I use it for cases where the public display page can have some displayed fields that an admin can — if they notice a little typo or something to change - quickly click and fix it.
But not for doing editing where you need to change many or most of the fields.
I think in a common Content Management System (CMS) while editing content this is a very good interaction model. In that case you have bunch of fields but you only need to edit one or two.
I can see this being used most effectively as an enhancement in a display/view context rather than replacing traditional forms.
Take the example of a table of employee information where you have the standard edit/delete/view buttons on each row and you notice a typo in one row. To me it's a better user flow to just edit that one field inline than have to pull up the whole form through a modal or page load. Both for speed (in the case of the page load) and forcing the user to re-locate the field they wanted to change.
Agreed. To get around this but keep the per-field editability, a toggle to make all fields editable should be available, as well as expose an atomic aggregate save trigger.
What gets me is that it breaks quick editing by tabbing between the fields. I now have to keep switching back to my mouse to get to the next field. (Yes I could navigate the links with the keyboard, but it is a lot more work).
The only improvement I would suggest would be to change the height of the form element so that it does not alter the height of the row (shifting later elements downward). Nice job.
Useful, thank you for posting. Obviously, this isn't a user interaction that you want to use everywhere, but there are plenty of situations where editing individual fields via mini-modals like this will make lots of sense.
For one thing, I can see where having this in the toolbox might enable one to bang out a fast admin-type view quickly--and sometimes being able to implement some relatively "utilitarian" view quickly is what lets you spend the proper amount of time on views that you want to implement more traditionally/fancily.
The use of "links" to launch the little dialogs doesn't personally bother me for whatever reason. (Though I get that sometimes it's just preference--for instance I have always disliked the use of drop-downs as navigation controls, but re-purposing the link element as shown in these x-editable demos doesn't--not sure I can defend why).
I have one project with Foundation at the moment, I like it quite a lot. I think it has a nice clean look and isn't as ubiquitous as Bootstrap. I don't use anything else with it at the moment, but this is something I wanted to do for it anyway, so I will definitely be using it!
The web is in dire need of a library correctly reimplementing "form behaviors" (events, mostly) on top of contenteditable, and allowing those behaviors to be applied to arbitrary (to the extent that browser implementations allow) elements on the fly.
edit: just in case, don't take me wrong, HTML forms should stay and I'm an advocate of less javascript everywhere as it tends to be mandated in places where it has no reason to be (and to ultimately decrease usability rather than enhance it), but if you're going to do "edit in place" and rich web applications which require javascript to run — and using the library linked above would probably qualify as you can't do anything without JS enabled and a fairly recent browser running it. And in those cases, HTML form elements tend to be a hindrance more than a help.