X-editable: In-place editing with Twitter Bootstrap, jQuery UI or pure jQuery | Hacker News Reader

X-editable: In-place editing with Twitter Bootstrap, jQuery UI or pure jQuery

vitalets.github.com

195 pointssohamsankaran49 comments

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.

Have you seen Aloha Editor(http://aloha-editor.org)? Its behavior is built on `contenteditable`.

Aloha editor is 1MB in size..

Aloha is an RTE, I'm not talking about RTEs in my comment I'm talking about bare, basic fields. Such as the one I'm typing/editing this comment in.

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)

Doesn't work in Firefox.

OT: Am I the only one annoyed by this "viewed best in Chrome" trend? Reminds me of those old "Best in IE" badges.

No, you are not alone. And I am sad to miffed at lack of support for Opera too.

There was a jquery fundamentals website that had the same problem. To compound matters, Chrome font rendering is godawfully bad on my machine.

Works fine in Firefox 17, try updating your browser.

I was running Firefox 16.0.2. I updated to Firefox 17 and it still doesn't work; I can't edit or change anything.

I am also beginning to find this browser update treadmill very tedious.

> 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.

I really love Hallo.js http://hallojs.org/ It's based on contenteditable and it's very lightweight

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-webk...

> 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)

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?

>> 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.

Perhaps the main issue lies with the relative inability to detect the presence of support: https://github.com/Modernizr/Modernizr/wiki/Undetectables

Android Gingerbread devices do not support it, and they are still the largest percentage of Android devices accessing Google Play: http://developer.android.com/about/dashboards/index.html

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

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.

Agree on this. Took me some time to figure out clicking on the link-like text enables the editing mode.

Solid underlined words take us to other places. Dashed is less defined outside of people who find CSS novel, or just want to be different.

If a site uses solid underlines for its links, that frees it up to use dashed for these inlines IMO.

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).

In some specific cases it is the preferred system. For example editing a comment.

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.

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.

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 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.

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 can't find any info on browser support (maybe I'm looking in the wrong place). Anyone know?

Awesome stuff! Now the next step is to integrate that with AngularJS and it will be perfect for my current project :P

I would definitely use this if it had Foundation tooltip support. How easy would it be to adapt this for other tooltip systems?

http://foundation.zurb.com/docs/elements.php

Foundation support would be great. What else do you currently use with foundation?

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!

This is quite neat, thanks a lot!

This doesn't work for me: http://vitalets.github.com/x-editable/demo.html (Chrome 23.0.1271.64 m) whereas Editable works just fine. Am I the only one?

i'm on the same version of chrome (win7) and it works for me

II see where this comes from: jQuery fails to load and they're not using $(document).ready().

It happens on my school's network, jquery.com is painfully slow...

This is a lazy comment. Is it possible to include both popup and inline JS of this at once? (the demos are mutually exclusive)

This is really good. A great addition would be Aviary support for images. If I come up with something good I'll send a PR.

Doesn't work with tab.

This is very cool, thanks for sharing.

Doesn't work on ipad

I like a lot.

Love this...can't wait for a Rubygem.

You can just include this in your views...no need to wait for a gem.

This is fun, HTML5 is so powerful.

You're confused, the main technology here is not html5, it's a combination of javascript and css.

Reply on news.ycombinator.com