Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.

I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox ¹ and Chrome ² . However, making a div or section contenteditable appears completely safe ³ .

A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements , and making a heading element contenteditable is buggy in Firefox ⁴ and can crash the page in Chrome ⁵ .

I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely , I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.

So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?

Bug notes:

Demo code

Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.

[contenteditable=true] {
  border: 1px dotted #999;
<article style="width: 100px">
  <h1 contenteditable="true">Heading</h1>
    <strong>Some adjacent content</strong>
    <span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
  <div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
                @j08691 If that's the case in theory, it's not the case in practice. The above bugs all occurred on a html5 page.
– doppelgreener
                Jun 19, 2013 at 1:14
                Can you post your code? @j08691 is right in that any element can be editable, however desired results can vary because contenteditable is, naturally, up to the user not the coder. Having said that, it is theoretically possible to place a contenteditable element inside a 'hard coded' element to prevent OTT use - one example would be allowing the user to increase the size of an image, but you don't want them to increase it too much, put the image inside a 'locked' div that is not contenteditable, however that style of coding would be extremely inefficient.
– redditor
                Jun 19, 2013 at 1:42
                Is it a surprise that the browsers have bugs handling contentEditable? There are no real rules to state which elements are safe or not, you have to find out by yourself and file bugs on each browser when you find a problem.
– AlfonsoML
                Jun 19, 2013 at 8:01
                If you're hoping for non-buggy/quirky browser behaviour for contenteditable on any element then you're going to be disappointed.
– Tim Down
                Jun 19, 2013 at 8:29
In my opinion, I'd say div is the safest bet across the board.  Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element.  Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
                Actually, giving the element :before and :after pseudo-elements stopped the focus bug! :)
– doppelgreener
                Jun 27, 2013 at 14:00
                Nice!  Glad you were able to figure something out.  Just beware of :before since IE 8 and earlier aren't big fans of that pseudo-class :)
– Graham Robertson
                Jun 27, 2013 at 14:02
  
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
                With regards to contentEditable the browsers are almost static. They are very slow fixing this kind of bugs and most of them have been known and reported for years, but as they don't count to things like the Acid tests they are ignored. Of course over time things change, but not always in the right direction: code.google.com/p/chromium/issues/detail?id=226941
– AlfonsoML
                Jun 24, 2013 at 19:48
                Since contenteditable's development isn't progressing much at all at the moment, it's not going to face an issue of the answer being out of date after 4 weeks, let alone before the bytes have dried. In any case, this is the web, and HTML5, and stuff does change, so the answer will go out of date eventually, but so do many things: answers about how to vertically align content in CSS, which go out of date as CSS is improved.
– doppelgreener
                Jun 25, 2013 at 3:39
                AlfonsoML is right. I'm working on a daily basis on WYSIWYG editor for 1.5 years (and Alfonso is following this feature for muuuch longer) and I don't remember anything that would a least significantly improved situation. In fact, I remember a lot more new bugs (like that whole topic linked by Alfonso), although usually they are more visible for us than fixed ones. Anyway - five years is a whole era in Web-world, but unfortunately that doesn't include contenteditable.
– Reinmar
                Jun 27, 2013 at 14:31
                Answers about CSS will still apply to that version of the CSS spec, even if there is a newer version where it can be done differently. The whole point of SO is to build up a database of canonical questions and answers. In it's current form the question is not fixed against anything, a spec, a date, a browser version, and will get out of date so quickly that it will be irritating for visitors just a year from now. @AlfonsoML what answer to that question two years ago would still be fully applicable today? If you know it write it ...
– Jonas Schubert Erlandsson
                May 19, 2015 at 6:08
                I don't have the time or will to create such support tables, but you can bet that nothing has really changed, so I don't understand why are you mentioning me after all this time. From the list of bugs in the question I can find only that Chrome no longer crashes, but it seems that the rest  of issues are there and the chromium bug that I linked it's still alive and kicking so time shows that browsers aren't working on contentEditable. As Reinmar said, the only real answer would be "none". All elements are buggy in some degree no matter the browser tested.
– AlfonsoML
                May 19, 2015 at 14:47
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.