For some time now, we’ve been using various technologies to edit and store text within a web browser. Now with the contenteditable attribute, things have got a whole lot easier. In this article, I’ll tell you what this attribute is for, how it works, and how we can take things further.
The contenteditable attribute is an enumerated attribute whose keywords are the empty string, true, and false. The empty string and the true keyword map to the true state. The false keyword maps to the false state. In addition, there is a third state, the inherit state, which is the missing value default (and the invalid value default).
The contenteditable attribute was mainly intended for providing an in-browser rich-text or WYSIWYG experience. You’ve likely seen this sort of thing in blog-based authoring tools like Symphony or sites like Flickr where you can begin editing page content simply by clicking in a given area.
As mentioned above, contenteditable has three possible states:
contenteditable="" or contenteditable="true"
Indicates that the element is editable.
Indicates that the element is not editable.
Indicates that the element is editable if its immediate parent element is editable. This is the default value.
When you add contenteditable to an element, the browser will make that element editable. In addition, any children of that element will also become editable unless the child elements are explicitly contenteditable="false".
Chris Coyier of CSS-Tricks pointed out that you can let your users edit the CSS in real-time. Because the <style> element is set to display: none by the user agent, we need to set it to block for this code to work.
Try editing the CSS below:
Browser support for contenteditable is surprisingly good:
Browser Support for contenteditable
We have to give credit where it’s due and point out that Internet Explorer has supported this attribute since IE5.5. In fact, a very early iteration of contenteditable was .
For a more in-depth compatibility table, visit When Can I Use….
For this section, I went straight to Doctor Remy for help, as he is much more knowledgeable than me when it comes to storing your data everything.
Depending on the complexity of your editable block, your code could be listening for the enter key (keyCode 13) to save the changes, and the escape key (keyCode 27) to undo the changes.
When the user hits enter (assuming it’s a single line of editable content), it would grab the innerHTML of the editable field and send an Ajax post to your server with the change.
A simple example of this can be seen on JS Bin: contenteditable saving to Ajax
We’ve repeated the phrase “paving the cowpaths” all over this site, and I’m mentioning it again with the introduction of the contenteditable attribute. The spec finally makes official something that’s been implemented by browser makers for years.
Although this is one of the lesser-known new attributes, I bet you’ll find yourself using it more often than you would think.
Imagine being able to simply click a block of content and start making changes instantly: making quick corrections to an article in-place, allowing users to edit their comments, or even building spreadsheets within company applications that aren’t hooked up to any sort of back-end user interface.
If you can think of other uses for this attribute, then head on down to the comments section and tell us where else you think this could be implemented.