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 16095 - Element with contenteditable=true shouldn't be considered as an editing host if it's already in an editable region
Summary: Element with contenteditable=true shouldn't be considered as an editing host ...
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Deadline: 2015-07-30
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-23 22:00 UTC by Ryosuke Niwa
Modified: 2015-07-30 23:47 UTC (History)
2 users (show)

See Also:


Attachments

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.