[Webkit-unassigned] [Bug 114791] New: Contenteditable issues related to backspace handling

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=114791

           Summary: Contenteditable issues related to backspace handling
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: HTML Editing
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pkoszulinski at gmail.com


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.