Bug 114791 – Contenteditable issues related to backspace handling

• Component: HTML Editing
• Status: NEW

[Piotrek Koszuliński (Reinmar)]

Crossposted on http://code.google.com/p/chromium/issues/detail?id=226941

Chrome Version       : 25.0.1364.172
Other browsers tested:
       Safari 6: TC1&TC2 OK, TC3&TC4 BAD
   Firefox 19.x: TC1 OK, TC2 :|, TC3 OK, TC4 mostly OK
           IE 9: TC1&TC2&TC3 OK, TC4 mostly OK

Hi,
I'm a CKEditor core developer. Our users reported few issues for how backspace works. They complain mainly about undesirable <span> elements, but also about other aspects.

I gathered four test cases in backspace.html (which I'm attaching). It contains scenarios, expected and actual outputs.

I'm aware that these are separate issues, but I report them together because I noticed that they are related to the same concept. When handling backspace (and other actions too) Webkit/Blink, instead of working on DOM, works on internal representation of editable element contents which seems to be something like "unstructured styled text".

E.g. in TC2 Webkit does not merge <h1> and <p> elements, but text having big font size and text having small font size and the result is <span> element which keeps the style of removed paragraph.

TC3 is another interesting example. Webkit removes <strong> element, but internally keeps information about the style and when user starts typing again it tries to recreate this style... which gives us <b> element or even worse <font> elements in other cases. TC4.2 is another interesting case - even if entire paragraph is deleted, Webkit recreates the style.


Conclusion

From our (CKEditor's) and most of our users' POV current behaviour is undesirable. Webkit pays attention to visual result, but HTML it produces is terrible. It's impossible to create decent WYSIWYG editor for people that care about semantically correct HTML without writing custom backspace (and other keys) handling from scratch.

Two most important proposals:

* Webkit should not keep internally information about styles - everything should be "on paper". In DOM there is a <strong> element, then we are editing <strong> element, not bold text. The <strong> element has been removed from DOM, then it's gone forever. When I press delete between header and paragraph, paragraph should be merged to header, not small text to big text.
* All actions should be done from DOM POV. As an operations on DOM, not on visual representation of editable element contents.

[Piotrek Koszuliński (Reinmar)]

Created attachment 198690 [details]
Test cases

[Hai-Nam Nguyen]

Quick description of the problem:

<p>line1<br />
line2</p>

=>

<p>line1</p>
<p><span style="line-height: 1.6em;">line2</span></p>

instead of 

<p>line1</p>
<p>line2</p>

Any news about this? There is a lot of people complaining about this in the CKEditor side and people ofc don't care that this is a WebKit issue.

The only option we would have is creating custom handlers for BACKSPACE and DEL, but this would be extremely hard and pointless, as keyboard handling is one of the basic features one expect from the browser implementation of contenteditable.

We'll be waiting for your opinion to take a decision on what to do here. Thanks!

It would be great if this could be fixed. It all effects Raptor Editor and is very frustrating to users.

[Alexey Proskuryakov]

<rdar://problem/15077939>

[Ryosuke Niwa]

It appears to me that we almost need two modes: visual and semantic.

It's impractical to satisfy both needs simultaneously.

[Piotrek Koszuliński (Reinmar)]

> It appears to me that we almost need two modes: visual and semantic.

> It's impractical to satisfy both needs simultaneously.

I'm not sure if I understand. Excluding TC1 and TC2 which are not reproducible on Safari (they are only reproducible on Chrome, so I guess it's a Blink's thing only) - how're TC3 and TC4 "visible"? There's semantic broken (but that's mostly under the hood for non-technical end users), and even if some behaviour is broken, then... why forking? Why not fixing it?

For example - in the TC3 user deletes text, text gets removed - it's already correct for the user. What's broken is under the hood - there's no <strong> tag in the DOM, but when user starts typing again it's recreated. So, why is it recreated if there was nothing in the DOM and why isn't it <strong> again, but <b>? Non-technical users won't notice if this was fixed, but technical users will be pleased that weird span/font/b/i tags are not created.

The TC1 and TC2 are different though, because they heavily affect UX. For example, end users are reporting us that they find it strange that paragraph merged into header still looks like a paragraph. More technical ones also don't like the fact that there's span with inline styles created, because it completely breaks the cleanliness of the code. But fortunately it doesn't happen on Safari.

[Andrew Ozz]

This also happens on InsertUnorderedList, InsertOrderedList, and possibly other contenteditable commands. Also on dragging selected text from one node to another. We've been dealing with these spans in WordPress for a while now.

TinyMCE (the default editor in WordPress) includes several DOM level fixes, but these spans still get inserted sometimes. The only sure way to stop them is to remove all text styling inside the editor. Of course this is the exact opposite of what WYSIWYG is all about.

[BJ Homer]

Note that Safari 7.0.3 fails TC2 as well, though Safari 6 was reported to pass it.