This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=23507 Example: <ol><li><p>foo[]bar</ol>. Does hitting Enter create <ol><li><p>foo<p>[]bar</ol> or <ol><li><p>foo<li><p>[]bar</ol> ? The latter makes much more sense in this case, IMO, because visually the <p> is invisible. Probably if a <p> or <div> is nested inside a single-line container at any depth, we should make the outer container the one we split, if we'd normally split it at all.
I want both behaviors at different times, unfortunately.
When would you want to not create a new list item here? Keep in mind that you can always hit Shift-Enter or Ctrl-Enter or whatever to insert a <br> instead of splitting the current block, regardless of whether there's a <p> inside the <li>. Also note that generally, the editing spec will not nest <p> or <div> inside <li> or similar. E.g., if you run insertorderedlist on a <p> or <div>, it will be transformed into an <li>; and if you then run outdent, it will become a <p> again. So this situation shouldn't normally come up in contenteditable-created content anyway, once everyone follows the spec. But if you have use-cases or more explanation to offer, I'd love to hear them!
I write pages with multiple paragraphs in a list item all the time, but I agree that an editor should start a new list item when you try to break a paragraph in one. That's what editors do.
Ah, if you can reliably insert a <br> with a chord, then the behavior of just hitting Enter should indeed be to start a new list item. (Sorry for the noise - I'm not totally familiar with the assumptions of the editting spec.)
What do you mean by single-line containers? You mean containers which appear on a single line on the screen? If yes, I don't think we should differentiate based on whether the container gets any line breaks or not. If, however, you're talking about block elements, then the second behavior in comment 0 would make sense to me.
"Single-line container" is a term I made up: http://aryeh.name/spec/editing/editing.html#single-line-container The current list is: address, div, h1, h2, h3, h4, h5, h6, listing, p, pre, xmp, li, dt, dd. They're basically used for formatBlock and inserting line breaks, with some of the salient points being * formatBlock converts all selected single-line containers to the given type. If something isn't nested in one, it adds one around it. * Hitting Enter (= insertParagraph) usually finds the nearest ancestor single-line container, clones it, sticks the clone after the original, and moves the cursor and anything after it to the new container. There are a bunch of exceptions to this, though. The idea is to adjust the second point in the event single-line containers are nested. The spec algorithms avoid nesting single-line containers, but we still have to deal sensibly with cases where they came pre-nested.
(In reply to comment #6) > "Single-line container" is a term I made up: > > http://aryeh.name/spec/editing/editing.html#single-line-container Ah yes, sorry I missed that. I have a note written somewhere that I think we need another name for this concept, and this is an example why! :-) Given that, I think your second proposal makes sense to me.
http://dvcs.w3.org/hg/editing/rev/8578618a74e6