RESOLVED CONFIGURATION CHANGED 57149
Ending a list in contentEditable/designMode with enter produces a div
https://bugs.webkit.org/show_bug.cgi?id=57149
Summary Ending a list in contentEditable/designMode with enter produces a div
Moxiecode Systems
Reported 2011-03-26 07:33:20 PDT
Description: Ending a list in contentEditable/designMode with enter produces a div it should produce a BR element like Gecko. Steps to reproduce: 1. Open the attached url. 2. Place caret behind the X inside editable area below. 3. Press enter twice. 4. Click the Dump HTML link observe the HTML produced. Expected result: <ul><li>X</li></li><br> Actual result: <ul><li>X</li></li><div><br></div>
Attachments
Annie Sullivan
Comment 1 2011-05-18 17:57:38 PDT
Generally when the user presses enter WebKit uses <div> to separate lines, instead of <br> like Gecko. Are you asking to change it just in this specific case, or in all cases? If it's just this case, what's the reasoning? FYI, there is a thread about the html that is generated when pressing enter on the whatwg mailing list: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031577.html
Aryeh Gregor
Comment 2 2011-08-19 09:03:16 PDT
The result of that discussion was that we should converge on the behavior of IE/Opera, which is to use <p>'s; and to wrap every line in a <p>, even the first (see bug 31678). That's what I wrote in the spec: http://aryeh.name/spec/editing/editing.html#the-insertparagraph-command In practice, this is one of the most annoying interop issues with contenteditable: IE/Opera uses <p>, Gecko uses <br>, WebKit uses <div>. The big issue here is that this affects even authors who don't use execCommand() at all, which lots of authors don't because it's too unreliable. They still have to use contenteditable, and this is one of the biggest differences between browsers for contenteditable. They also behave differently for delete and so on, but this difference affects every contenteditable region where the user ever pressed Enter, which is almost all of them. So IMO, this would be a good thing to prioritize. That way at least browsers would produce similar markup for the case where the user just types text in contenteditable without running execCommand().
Ahmad Saleem
Comment 3 2022-08-11 15:20:20 PDT
Latest Test Results from all browsers: *** Safari 15.6 on macOS 12.5 *** <ul> <li><br></li><li><br></li><li>X</li> </ul> *** Firefox Nightly 105 *** <ul> <li><br></li><li><br></li><li>X</li> </ul> *** Chrome Canary 106 *** <ul> <li><br></li><li><br></li><li>X</li> </ul> __________ All browsers output same HTML, it might be something fixed along the way, I am going to mark this as "RESOLVED CONFIGURATION CHANGED". Thanks!
Note You need to log in before you can comment on or make changes to this bug.