I use the following definitions right now:

"An editing host is a node that is either an Element with a contenteditable attribute set to the true state, or the Element child of a Document whose designMode is enabled."

"Something is editable if it is a node which is not an editing host, does not have a contenteditable attribute set to the false state, and whose parent is an editing host or editable."

An important note in my spec:

"Barring bugs, the algorithms here will not alter the attributes of a non-editable element; will not remove a non-editable node from its parent (except to immediately give it a new parent in the same editing host); and will not add, remove, or reorder children of a node unless it is either editable or an editing host. An editing host is never editable, so authors are assured that editing commands will only modify the editing host's contents and not the editing host itself."

The idea of an editing host not being editable is that authors should be able to grab the innerHTML of the editing host and not have to worry that anything added attributes or whatnot (which some browsers do).  Also, we want to make sure nothing is going to remove or relocate editing hosts themselves, only change their descendants.

Another notable difference is that I allow any node to be editable, not just HTML elements.  (Well, not Documents or DocumentFragments or DocumentTypes.)  It's often important to know whether a text node or such is editable, and there's no reason the concept shouldn't apply to elements other than HTML elements.

mass-moved component to LC1

Can we just move the definitions entirely over to your spec? I want to just drop all the stuff that's best put in your spec, first to reference it, and then later when you've moved on to other things just to merge it back in. Seems like this is something that you need control over to do a good job .

The problem is that there's currently still stuff in the HTML spec that depends on the concepts of editable/editing host: :read-only/:read-write, spellcheck, drag-and-drop.  I think it's better if you keep that stuff for now, although I don't object to the possibility of taking it over at some point if it can be cleanly separated (at least :read-only/:read-write seems like it would be awkward).  Or were you thinking of just having a two-way normative dependency between the specs?

I was intending to make this a two-way dependency. There's no value in avoiding it here; neither part can really be implemented in isolation anyway.

BTW, the editing APIs spec doesn't use the "formatBlock candidate" category, which means that "formatBlock" doesn't handle the new elements. Instead it has a hard-coded list called "formattable block name" that only includes the legacy blocks. Is this intentional?

isContentEditable depends on the previous definition of "editable". Should it now simply be "editable or editing host"?

Same question with :read-only and :read-write; should they be switched to matching both?

Same question with the logic in the drag-and-drop section.

Same question for spell-check. I presume though that while for text nodes I should talk about text nodes of elements that are either editing hosts or editable, for the spelling checking of attributes, that should only apply to editable elements, because editing hosts' attributes aren't themselves editable, right?

This is done; leaving the bug open for now so that I can see Aryeh's responses to the questions above.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: Factored out all the stuff the editing spec now defines.
Rationale: Concurred with reporter's comments.

Looks good to me.

(In reply to comment #5)
> I was intending to make this a two-way dependency. There's no value in avoiding
> it here; neither part can really be implemented in isolation anyway.

Okay, then I'm fine with taking the definitions.

(In reply to comment #6)
> BTW, the editing APIs spec doesn't use the "formatBlock candidate" category,
> which means that "formatBlock" doesn't handle the new elements. Instead it has
> a hard-coded list called "formattable block name" that only includes the legacy
> blocks. Is this intentional?

Yes.  See the mailing list discussion:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031765.html

formatBlock, by its nature, doesn't work well with anything you'd want to nest.  Thus it should not work for any of the new wrappers, since those are things you want to nest <p> etc. inside.  Nor should it work for <blockquote>.  It really shouldn't work for <div> either, but I don't think we can avoid that.

So you can remove this definition.  There are some other definitions that would be good to move to HTML, though, like "prohibited paragraph child".

(In reply to comment #7)
> isContentEditable depends on the previous definition of "editable". Should it
> now simply be "editable or editing host"?

isContentEditable should probably be true for editing hosts, yes, just because it'd be really weird if <div contenteditable> were reported to not be isContentEditable.

(In reply to comment #8)
> Same question with :read-only and :read-write; should they be switched to
> matching both?

:read-write applies to inputs and textareas, which are not themselves editable but whose contents are, so it makes sense that it applies to editing hosts too.

(In reply to comment #9)
> Same question with the logic in the drag-and-drop section.

Editing hosts should definitely be valid DND targets.

(In reply to comment #10)
> Same question for spell-check. I presume though that while for text nodes I
> should talk about text nodes of elements that are either editing hosts or
> editable, for the spelling checking of attributes, that should only apply to
> editable elements, because editing hosts' attributes aren't themselves
> editable, right?

For text nodes you should just talk about editable text nodes.  A text node is editable precisely if its parent is editable or an editing host.  For attributes, yeah, it should only be editable elements, not editing hosts.

Checked in as WHATWG revision r6587.
Check-in comment: kill the 'formatBlock candidates' category
http://html5.org/tools/web-apps-tracker?from=6586&to=6587

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given above, amongst others
Rationale: Ok, I think we're good here.