17743 2012-07-11 12:12:15 +0000 When setting designMode to 'on', the selection should be moved to an empty selection at the start of body (or something like that). If there isn't a body yet, wait until there is. Don't do this for contenteditable. 2016-02-04 07:21:59 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified Other other NEW http://www.whatwg.org/specs/web-apps/current-work/#making-entire-documents-editable:-the-designmode-idl-attribute whatwg-resolved P3 normal --- 1 contributor ayg ayg ian mike Ms2ger philipj public-webapps zcorpan sideshowbarker+html-editing-api oldest_to_newest 69831 0 contributor 2012-07-11 12:12:15 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html Multipage: http://www.whatwg.org/C#making-entire-documents-editable:-the-designmode-idl-attribute Complete: http://www.whatwg.org/c#making-entire-documents-editable:-the-designmode-idl-attribute Comment: When setting designMode to 'on', the selection should be moved to an empty selection at the start of body (or something like that). If there isn't a body yet, wait until there is. Don't do this for contenteditable. Posted from: 2001:4c28:a030:30:3974:4eac:84c6:cfd6 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.289 Version/12.00 71054 1 contributor 2012-07-18 17:59:36 +0000 This bug was cloned to create bug 18294 as part of operation convergence. 71551 2 ian 2012-07-26 23:50:38 +0000 I don't disagree in principle, but can you elaborate? Is this to match implementations? (Are there tests I can look at?) For some other reason? 72114 3 zcorpan 2012-08-13 10:25:37 +0000 Opera sets caret for contenteditable, but other browsers don't, and this caused us some problems with some editors. Everybody sets the caret for designMode. Since some pages set designMode to 'on' before there is a <body>, we need to wait with setting the caret (but shouldn't wait for window.onload since that can take too long). Browsers do this but aren't fuilly interoperable. I don't have tests at hand currently. 75904 4 ian 2012-10-10 23:43:18 +0000 Aryeh, do you have any input here? Simon, my proposal is that when designMode is set to true, the root element (which is what becomes an editing host) be focus()ed, and the Selection is set to a collapsed range at the root element's start. (Will that result in content going into the <body> when the user types?) I'll put this in the HTML spec unless Aryeh wants it in the HTML Editing APIs spec, but I think HTML is the right place for it since that's where designMode is. 75942 5 ayg 2012-10-11 06:57:30 +0000 (In reply to comment #4) > Aryeh, do you have any input here? Not really. I never tested designMode much. For one thing, it's a pain, because some browsers refuse to run script after you set designMode to on, and if you do it in an iframe I don't know if the selection/focus behavior will be the same. > Simon, my proposal is that when designMode is set to true, the root element > (which is what becomes an editing host) be focus()ed, and the Selection is > set to a collapsed range at the root element's start. (Will that result in > content going into the <body> when the user types?) Per my current spec, no -- I have no special handling of root element vs. body at the moment, so it will go in the root element before the <head>. In practice, maybe yes, I don't know. I focused almost exclusively on contenteditable, so I didn't bother spending time on the case where the root element is editable (which is not how contenteditable is normally used). In real life, designMode predated contenteditable (I think -- at least in Gecko) and browsers may well have special cases for stuff like this. But I'm guessing that if Simon said you need to wait for the body to exist, he had a reason for wanting the extra complexity instead of just saying to put it in the root element (which will exist under any normal circumstances). > I'll put this in the > HTML spec unless Aryeh wants it in the HTML Editing APIs spec, but I think > HTML is the right place for it since that's where designMode is. Please feel free to take it. 75951 6 zcorpan 2012-10-11 09:40:10 +0000 The waiting behavior appears to be browsers' current behavior from my ad-hoc testing, however I don't mind putting the selection at the start of the root element and have the editing spec special case the root element. We need to handle <html contenteditable> anyway. The only problem I see with allowing editing before the body has been parsed is what should happen if the user starts typing before body exists? (This could happen with contenteditable too.) 76016 7 ian 2012-10-11 17:30:52 +0000 What happens today with <html contenteditable> if there's no <body>, or if one is added later? Maybe there's less magic here than we think. designMode can be set on a document without a body parsed yet; can the user not focus it manually in that case and start typing? e.g. if designMode is set during parse, and there's a minute delay between the </head> and the <body>. 76530 8 ian 2012-10-17 22:56:05 +0000 zcorpan: ping 76561 9 zcorpan 2012-10-18 07:40:17 +0000 http://simon.html5.org/dump/html-contenteditable-sleep.php http://simon.html5.org/dump/html-designMode-sleep.php Firefox/Chrome/Opera don't start rendering the page at all before there's a body element. http://simon.html5.org/dump/html-contenteditable-remove-body.html Firefox/Chrome/Opera don't allow editing at all when the body element is removed. (Firefox shows a caret but typing doesn't insert text.) 76605 10 ian 2012-10-18 19:02:50 +0000 Are you sure you're not getting server-side buffering? curl -N http://simon.html5.org/dump/html-contenteditable-sleep.php ...doesn't return anything for me. 76652 11 zcorpan 2012-10-19 06:51:57 +0000 Sigh. Well, http://simon.html5.org/dump/html-contenteditable-remove-body.html makes that moot anyway. 76750 12 ian 2012-10-19 20:18:05 +0000 http://simon.html5.org/dump/html-contenteditable-remove-body.html in Chrome lets me keep typing after the <body> is removed, so long as I focus it first. I think that's got more to do with focusing without <body> than contenteditable. Anyway, in conclusion, I think comment 4 is still the right solution. Aryeh's spec probably needs to handle the missing <body> case as well though. (Separate bug, probably.) 82186 13 ian 2013-01-26 05:44:37 +0000 Aryeh, do you want to use this bug to track how to handle editing when there's no <body>? Or do you want a new bug? (Either way, I recommend making it so that if the user tries to modify a doc with no <body>, nothing happens, and if they try to modify a document with a <body> while the caret or active range are outside the <body>, they get snapped to the <body> first.) 82187 14 contributor 2013-01-26 05:44:56 +0000 Checked in as WHATWG revision r7660. Check-in comment: Define designMode to set focus and selection. http://html5.org/tools/web-apps-tracker?from=7659&to=7660 82196 15 Ms2ger 2013-01-26 11:34:32 +0000 Simon, want to write some automated tests? :) 82473 16 ayg 2013-02-01 12:51:41 +0000 (In reply to comment #13) > Aryeh, do you want to use this bug to track how to handle editing when > there's no <body>? Or do you want a new bug? (Either way, I recommend making > it so that if the user tries to modify a doc with no <body>, nothing > happens, and if they try to modify a document with a <body> while the caret > or active range are outside the <body>, they get snapped to the <body> > first.) I'm not actively maintaining the editing spec now -- so incidentally, you can take it if you want. I specifically didn't pay much attention to edge cases like no <body> when writing the editing spec, because there's enough work to do on interop in important cases. I think that in the current spec, execCommand() will probably do nothing if the selection doesn't contain any editable visible nodes. 84870 17 ian 2013-03-22 18:17:32 +0000 Ok, I'll move this to the HTML Editing APIs component and whoever ends up taking that over (could be me, we'll see if I get out from under this pile of feedback) can deal with it.