Bug 16095 - Element with contenteditable=true shouldn't be considered as an editing host if it's already in an editable region
Element with contenteditable=true shouldn't be considered as an editing host ...
Status: NEW
Product: WebAppsWG
Classification: Unclassified
Component: HTML Editing APIs
unspecified
PC All
: P2 normal
: ---
Assigned To: Aryeh Gregor
HTML Editing APIs spec bugbot
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-23 22:00 UTC by Ryosuke Niwa
Modified: 2012-12-04 03:10 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2012-02-23 22:00:04 UTC
This is a request to match the original HTML5 spec definition of the editing host.

Elements with contenteditable=true shouldn't define a new editing host unless the element is in a non-editable region (i.e. it doesn't have an editing host of its own). This matches the way CSS inheritance and computed value works.

WebKit can't implement the current definition of editing host since we use CSS style resolver to decide whether a given element is an editing host or not.
Comment 1 Aryeh Gregor 2012-02-24 14:02:15 UTC
I'm not going to necessarily restrict my spec to only things WebKit can do with its current implementation of editability.  WebKit can't do :read-write correctly either right now, but we aren't going to say :read-write doesn't match editable elements just because selectors can't depend on computed values.

However, the behavior you describe makes sense.  It seems to match Gecko too.  It does prevent some possible use-cases I had in mind, but you can emulate them with an extra contenteditable=false wrapper if you want.  So I'm okay with changing the spec here.