10 ms·
X-editable: In-place editing with Twitter Bootstrap, jQuery UI or pure jQuery
- asher_ 14y agoThis is quite neat, thanks a lot!
- sarbogast 14y agoAwesome stuff! Now the next step is to integrate that with AngularJS and it will be perfect for my current project :P
- dotmanish 14y agoThis is a lazy comment. Is it possible to include both popup and inline JS of this at once? (the demos are mutually exclusive)
- masklinn 14y agoI 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.
- laktek 14y agoHave you seen Aloha Editor(http://aloha-editor.org http://aloha-editor.org)? Its behavior is built on `contenteditable`.
- gidan 14y agoAloha editor is 1MB in size..
- masklinn 14y agoAloha 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.
- laktek 14y agoAloha 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 http://wysiwhat.github.com/Aloha-Editor/cnx.html)
- scribu 14y agoDoesn'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.
- deleted 14y ago[deleted]
- ot 14y agoI 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?
- csulok 14y ago>> 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.
- masklinn 14y agoI'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.
- waskosky 14y agoPerhaps the main issue lies with the relative inability to detect the presence of support: https://github.com/Modernizr/Modernizr/wiki/Undetectables 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 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 http://caniuse.com/#feat=contenteditable
- zerovox 14y agoI 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 http://foundation.zurb.com/docs/elements.php
- Benferhat 14y agoFoundation support would be great. What else do you currently use with foundation?
- zerovox 14y agoI 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!
- marcamillion 14y agoLove this...can't wait for a Rubygem.
- IceyEC 14y agoYou can just include this in your views...no need to wait for a gem.
- BaconJuice 14y agoThis is very cool, thanks for sharing.
- revetkn 14y agoI can't find any info on browser support (maybe I'm looking in the wrong place). Anyone know?
- rbcb 14y agoIt 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.
- dfguo 14y agoAgree on this. Took me some time to figure out clicking on the link-like text enables the editing mode.
- lowboy 14y agoSolid 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.
- cocoflunchy 14y agoThis doesn't work for me: http://vitalets.github.com/x-editable/demo.html http://vitalets.github.com/x-editable/demo.html (Chrome 23.0.1271.64 m) whereas Editable works just fine. Am I the only one?
- danek 14y agoi'm on the same version of chrome (win7) and it works for me
- cocoflunchy 14y agoII 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...
- TommyDANGerous 14y agoI like a lot.
- TommyDANGerous 14y agoThis is fun, HTML5 is so powerful.
- pacomerh 14y agoYou're confused, the main technology here is not html5, it's a combination of javascript and css.
- bookcasey 14y agoDoesn't work with tab.
- rhplus 14y agoI 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).
- mcgwiz 14y agoAgreed. 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.
- glomph 14y agoIn some specific cases it is the preferred system. For example editing a comment.
- ya3r 14y agoI 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.
- crucialfelix 14y agoI 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.
- lowboy 14y agoI 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.
- flipchart 14y ago
- elchief 14y agoThe 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.
- chmike 14y agoDoesn't work on ipad
- nateweiss 14y agoUseful, 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).
- ppadron 14y agoThis is really good. A great addition would be Aviary support for images. If I come up with something good I'll send a PR.