6 ms·

Ah, but remember, it's the letter of the law, not the spirit, that matters. So in this case the author has tackled that abomination that is ContentEditable and

Ah, but remember, it's the letter of the law, not the spirit, that matters. So in this case the author has tackled that abomination that is ContentEditable and likely aged himself ten years in the process so that you can edit text on a page with no <textarea> tags in sight. As anybody who's had the misfortune of being sucked into the ContentEditable TimeSink Vortex will tell you, that's probably not a very good idea when all you're trying to do is edit text. But from a purely technical standpoint, he has indeed done what the title describes.

jasonlotito 16y ago
I think it's also fair to say that even the spirit was met. The idea, I gathered, was to not having your typical form page where you do your creation like most typical applications have. Their is a big difference in inline editable functionality and your typical forms for add/edit/delete functionality.
bergie 16y ago
The pain of contentEditable is quite nicely removed by using http://aloha-editor.org/ http://aloha-editor.org/
- jasonkester 16y ago
  Have you actually used that editor in a project? I ask, because I tried to once. After a bunch of unsuccessful shoehorning, and marveling at how they could write an entire megabyte of javascript and still not end up with a working editor, I gave up and rolled my own. It actually made diving into ContentEditable seem like the less painful choice.
  - bergie 16y ago
    Yes, we use Aloha. It is a bit big now, mostly because it depends on ExtJS. But that is bound to change: http://aloha-editor.org/wiki/Migration_to_jQuery_UI http://aloha-editor.org/wiki/Migration_to_jQuery_UI
  - balupton 16y ago
    Hi Jason, Benjamin here from the Aloha Editor Team. You are completely right that Aloha Editor is pretty big right now; as Bergie as mentioned this is due it's ExtJS dependency. The Aloha Team has now partnered with the jQuery UI team and development is underway to shed this dependency and use the much lighter jQuery UI framework as the default. You can follow the status here http://aloha-editor.org/wiki/Roadmap http://aloha-editor.org/wiki/Roadmap and we're totally open to as much feedback you'd like to throw at us :-) We're here to help! Cheers, - Benjamin (Aloha Editor Team Member)
Semiapies 16y ago
Sorry, meant to upvote, not down.
masklinn 16y ago
Hasn't the WhatWG done a lot of work trying to formalize the workings of ContentEditable in order to include it in the HTML5 spec?
- jasonkester 16y ago
  Possibly. In the current crop of browsers, it's a complete mess. IE surprisingly has the best implementation, measured by how often you have to write specific code to insert/remove/re-insert/manually move the caret, etc. just to make a simple command work on a piece of selected text. Actually, it might not be such a surprise since they had it working back in IE5. Webkit is quirky, but at least you can generally hack things into working. Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. It's completely unusable, and many trivial things simply throw non-catchable exceptions at you and refuse to work. Bugzilla is full of open bugs on the most basic things, with comments from, for instance, the Google Docs team about how they simply can't support certain features until Firefox finishes implementing ContentEditable.
  - jessedhillon 16y ago
    > In the current crop of browsers, it's a complete mess. I don't think this accurate. The Facebook status update box, and other inputs, have been implemented content editable for years now. A good example of this is the field you see when composing a message, where you enter recipients' names. When you add a recipient, their name becomes a badge in the field and you can continue typing as if it were an input. Some pretty mature JS frameworks have relied on content editable for a while too, including Ext JS. > Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. Which functions don't work?
    - jasonkester 16y ago
      Do a quick View Source on that facebook box, or better still download the source of any of the wysiwig dhtml editors on the market. Note that it's half a megabyte. All hacks to make ContentEditable work at all. So yes, it's technically possible to do. That's not at issue. The problem is that it's implemented in five completely separate ways by five different browser vendors. Many things are implemented in mutually exclusive ways. The goal of the standard is to have a single easy way to flip a switch on a piece of content and have it editable in a way that you can quickly hook up your "bold" button, etc. It's a long way away from that today. Try implementing a simple WYSIWYG editor for yourself, then note the large bald patches on your head and corresponding clumps of hair in your white-knuckled fists. That's not something that you get with other areas of the HTML5 spec.
warrenwilkinson 16y ago
I've been wrestling with the idea of using contentEditable in my project for a while now. On one hand it's a great way to let users edit text, very friendly. On the other hand, you'll need a javascript toolbar, and you're limited to things that are expressible as HTML.

jasonlotito 16y ago

I think it's also fair to say that even the spirit was met. The idea, I gathered, was to not having your typical form page where you do your creation like most typical applications have. Their is a big difference in inline editable functionality and your typical forms for add/edit/delete functionality.

bergie 16y ago

The pain of contentEditable is quite nicely removed by using http://aloha-editor.org/ http://aloha-editor.org/

jasonkester 16y ago
Have you actually used that editor in a project? I ask, because I tried to once. After a bunch of unsuccessful shoehorning, and marveling at how they could write an entire megabyte of javascript and still not end up with a working editor, I gave up and rolled my own. It actually made diving into ContentEditable seem like the less painful choice.
- bergie 16y ago
  Yes, we use Aloha. It is a bit big now, mostly because it depends on ExtJS. But that is bound to change: http://aloha-editor.org/wiki/Migration_to_jQuery_UI http://aloha-editor.org/wiki/Migration_to_jQuery_UI
- balupton 16y ago
  Hi Jason, Benjamin here from the Aloha Editor Team. You are completely right that Aloha Editor is pretty big right now; as Bergie as mentioned this is due it's ExtJS dependency. The Aloha Team has now partnered with the jQuery UI team and development is underway to shed this dependency and use the much lighter jQuery UI framework as the default. You can follow the status here http://aloha-editor.org/wiki/Roadmap http://aloha-editor.org/wiki/Roadmap and we're totally open to as much feedback you'd like to throw at us :-) We're here to help! Cheers, - Benjamin (Aloha Editor Team Member)

Semiapies 16y ago

Sorry, meant to upvote, not down.

masklinn 16y ago

Hasn't the WhatWG done a lot of work trying to formalize the workings of ContentEditable in order to include it in the HTML5 spec?

jasonkester 16y ago
Possibly. In the current crop of browsers, it's a complete mess. IE surprisingly has the best implementation, measured by how often you have to write specific code to insert/remove/re-insert/manually move the caret, etc. just to make a simple command work on a piece of selected text. Actually, it might not be such a surprise since they had it working back in IE5. Webkit is quirky, but at least you can generally hack things into working. Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. It's completely unusable, and many trivial things simply throw non-catchable exceptions at you and refuse to work. Bugzilla is full of open bugs on the most basic things, with comments from, for instance, the Google Docs team about how they simply can't support certain features until Firefox finishes implementing ContentEditable.
- jessedhillon 16y ago
  > In the current crop of browsers, it's a complete mess. I don't think this accurate. The Facebook status update box, and other inputs, have been implemented content editable for years now. A good example of this is the field you see when composing a message, where you enter recipients' names. When you add a recipient, their name becomes a badge in the field and you can continue typing as if it were an input. Some pretty mature JS frameworks have relied on content editable for a while too, including Ext JS. > Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. Which functions don't work?
  - jasonkester 16y ago
    Do a quick View Source on that facebook box, or better still download the source of any of the wysiwig dhtml editors on the market. Note that it's half a megabyte. All hacks to make ContentEditable work at all. So yes, it's technically possible to do. That's not at issue. The problem is that it's implemented in five completely separate ways by five different browser vendors. Many things are implemented in mutually exclusive ways. The goal of the standard is to have a single easy way to flip a switch on a piece of content and have it editable in a way that you can quickly hook up your "bold" button, etc. It's a long way away from that today. Try implementing a simple WYSIWYG editor for yourself, then note the large bald patches on your head and corresponding clumps of hair in your white-knuckled fists. That's not something that you get with other areas of the HTML5 spec.

warrenwilkinson 16y ago

I've been wrestling with the idea of using contentEditable in my project for a while now. On one hand it's a great way to let users edit text, very friendly. On the other hand, you'll need a javascript toolbar, and you're limited to things that are expressible as HTML.