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.
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.
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.
> 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.
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.
Writing your own wrapper on contenteditable is like rewriting jQuery. Yes it's a messy complicated problem. That's why you don't do it yourself.
Something like TinyMCE is incredibly configurable and has had years to work around the browser quirks in contenteditable. Use it wherever possible.
On a side note I recently exchanged some emails between the lead dev on TinyMCE and the person working on the Webkit implementation of contenteditable. I had very little luck persuading them to communicate. The fault was mainly on the webkit end of things. I find it astonishing there isn't better communication between people at this level. The number of people using TinyMCE via Wordpress must be in the millions. You'd think people working on Webkit would be seeking them out for advice on implementation bugs.
Not only is it technically possible, but it's being used reliably in production environments.
> ... have it editable in a way that you can quickly hook up your "bold" button, etc.
Today in any current browser you can do execCommand("bold") to embolden text.
> 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.
Implementing a unified XHR wrapper could also make someone aggravated, as there are different -- sometimes completely incompatible -- implementations across browsers. Having varying implementations comes with the territory and is not an indication of brokenness.
You keep making these blanket statements without providing any examples. Can you give one example of actual code that needs major workaround? Your off-the-cuff example of a bold button makes me wonder if it wasn't five years ago when you last tried to make this happen.
If anyone is interested in a more disciplined understanding of the various levels of support across browsers, here's Quirksmode's take on it: http://www.quirksmode.org/dom/execCommand.html
Today in any current browser you can do execCommand("bold") to embolden text.
Indeed. And it will work, provided you haven't used Backspace to collapse your selection to the start of a DIV in IE. And you haven't selected your text by SHIFT+Left Arrow such that it oversteps the beginning of an editable paragraph and enters the no-mans-land between it and the non-editable div before it in Firefox. And you haven't previously issued an "insertorderedlist", causing the known issue in IE. And that you didn't issue your contentEditable=true as the result of the mouse click that placed the caret inside the text of a H1 tag.
And dozens of other tiny things that continually jump out to bite you that need to be worked around in every single browser just to get it to work.
So yes, I'll grant you "technically possible", but not anything beyond that.
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.
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 and we're totally open to as much feedback you'd like to throw at us :-) We're here to help!
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.
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.