14578 2011-10-27 21:00:24 +0000 Figure out how to behave if editing host is an inline element 2012-12-04 02:03:27 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified All All NEW P2 normal --- 1 ayg ayg ehsan mike public-webapps rniwa sideshowbarker+html-editing-api oldest_to_newest 59103 0 ayg 2011-10-27 21:00:24 +0000 Currently I generally just don't test this case. Example: what happens if you run insertOrderedList on <span contenteditable>foo[]</span>? IE9: <span contentEditable=""><p>foo</p></span> Firefox 9.0a2: Throws NS_ERROR_FAILURE Chrome 16 dev: <span contenteditable=""><ol><li>foo<br></li></ol></span> Opera 11.50: Throws NOT_FOUND_ERR How about <div contenteditable><span contenteditable>foo[]</span></div>? IE9: <div contentEditable=""><span contentEditable=""><p>foo</p></span></div> Firefox 9.0a2: <div contenteditable=""><ol><li><span contenteditable="">foo</span></li></ol></div> Chrome 16 dev: <div contenteditable=""><ol><li>foo<br></li></ol></div> Opera 11.50: <div contenteditable=""><ol><li><span contenteditable="">foo</span></li></ol></div> <span contenteditable><ul><li>foo[]</ul></span>? IE9: <span contentEditable=""><ol><li>foo</li></ol></span> Firefox 9.0a2: NS_ERROR_FAILURE Chrome 16 dev: <span contenteditable=""><ol><li>foo<br></li></ol></span> Opera 11.50: <span contenteditable=""><ol><li>foo</ol></span> I see three sensible options: 1) Pretend the editing host isn't inline, and give it block children. 2) Silently refuse to add new block elements if there's no ancestor in the same editing host that they're allowed children of, but otherwise execute the commands normally. E.g., insertOrderedList should refuse to insert lists but should change existing <ul>s. 3) Bail out of all block-level commands unconditionally if the editing host is inline. I'm leaning toward (2). Opinions?