17743 – 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.

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17743 - 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.

Summary: When setting designMode to 'on', the selection should be moved to an empty se...

Status:	NEW

Alias:	None

Product:	WebAppsWG
Classification:	Unclassified
Component:	HISTORICAL - HTML Editing APIs (show other bugs)
Version:	unspecified
Hardware:	Other other

Importance:	P3 normal
Target Milestone:	---
Assignee:	Aryeh Gregor
QA Contact:	HTML Editing APIs spec bugbot

URL:	http://www.whatwg.org/specs/web-apps/...
Whiteboard:	whatwg-resolved
Keywords:

Depends on:
Blocks:

Reported:	2012-07-11 12:12 UTC by contributor
Modified:	2016-02-04 07:21 UTC (History)
CC List:	7 users (show)

See Also:

Attachments

Description contributor 2012-07-11 12:12:15 UTC

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

Comment 1 contributor 2012-07-18 17:59:36 UTC

This bug was cloned to create bug 18294 as part of operation convergence.

Comment 2 Ian 'Hixie' Hickson 2012-07-26 23:50:38 UTC

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?

Comment 3 Simon Pieters 2012-08-13 10:25:37 UTC

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.

Comment 4 Ian 'Hixie' Hickson 2012-10-10 23:43:18 UTC

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.

Comment 5 Aryeh Gregor 2012-10-11 06:57:30 UTC

(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.

Comment 6 Simon Pieters 2012-10-11 09:40:10 UTC

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.)

Comment 7 Ian 'Hixie' Hickson 2012-10-11 17:30:52 UTC

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>.

Comment 8 Ian 'Hixie' Hickson 2012-10-17 22:56:05 UTC

zcorpan: ping

Comment 9 Simon Pieters 2012-10-18 07:40:17 UTC

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.)

Comment 10 Ian 'Hixie' Hickson 2012-10-18 19:02:50 UTC

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.

Comment 11 Simon Pieters 2012-10-19 06:51:57 UTC

Sigh. Well, http://simon.html5.org/dump/html-contenteditable-remove-body.html makes that moot anyway.

Comment 12 Ian 'Hixie' Hickson 2012-10-19 20:18:05 UTC

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.)

Comment 13 Ian 'Hixie' Hickson 2013-01-26 05:44:37 UTC

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.)

Comment 14 contributor 2013-01-26 05:44:56 UTC

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

Comment 15 Ms2ger 2013-01-26 11:34:32 UTC

Simon, want to write some automated tests? :)

Comment 16 Aryeh Gregor 2013-02-01 12:51:41 UTC

(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.

Comment 17 Ian 'Hixie' Hickson 2013-03-22 18:17:32 UTC

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.