W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 13424] [editing] Align the definitions of "editable" and "editing host" with the editing spec or move them entirely to the editing spec

From: <bugzilla@jessica.w3.org>
Date: Sun, 28 Aug 2011 16:30:19 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QxiFX-00012f-Lg@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13424

--- Comment #12 from Aryeh Gregor <ayg@aryeh.name> 2011-08-28 16:30:18 UTC ---
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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 28 August 2011 16:32:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:17 UTC