26

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 Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.

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 Firefox4 and can crash the page in Chrome5.

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:

  1. Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
  2. Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
  3. Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
  4. Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
  5. Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.

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>
  <p>
    <strong>Some adjacent content</strong>
    <span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
  </p>

  <div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
doppelgreener
  • 4,809
  • 10
  • 46
  • 63
  • 1
    In HTML5 any element can be editable. – j08691 Jun 19 '13 at 01:13
  • 1
    @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 '13 at 01: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 '13 at 01:42
  • @redditor Posted, there you go. It still produces the bugs I described, except losing focus doesn't happen. I'm not sure why that isn't happening there. – doppelgreener Jun 19 '13 at 02:07
  • Interesting. I cannot recreate error2 but error 5 just happened. – redditor Jun 19 '13 at 02:19
  • EXCELLENT EXAMPLE OF PASTING INTO CONTENTEDITABLE http://jsfiddle.net/erikwoods/Ee3yC/ (i could not find the source for this, but - as stated in url/fiddle - erikwoods is the creditor of this code) – redditor Jun 19 '13 at 02:25
  • @redditor For error 2, try copying and pasting several times. Vary your selections and copies + pastes if it helps - then inspect the element's contents. Also, thanks, that could be turned into a nice workaround for uncooperative elements - it inserts text nicely into spans and headings. – doppelgreener Jun 19 '13 at 02:36
  • 2
    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 '13 at 08:01
  • 8
    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 '13 at 08:29
  • +1 for AlfonsoML and Tim Down. The short answer is "none". There are dozens (or rather hundreds) of bugs and even reporting them to browsers' vendors doesn't help. Read more here http://stackoverflow.com/questions/16074358/content-editable-text-editors/16085789#16085789 – Reinmar Jun 20 '13 at 07:30

2 Answers2

2

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!

Graham Robertson
  • 808
  • 5
  • 10
0

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.

Jonas Schubert Erlandsson
  • 3,910
  • 1
  • 24
  • 37
  • 3
    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: http://code.google.com/p/chromium/issues/detail?id=226941 – AlfonsoML Jun 24 '13 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 '13 at 03: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 '13 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 '15 at 06:08
  • 1
    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 '15 at 14:47