Bugzilla – Bug 16095
Element with contenteditable=true shouldn't be considered as an editing host if it's already in an editable region
Last modified: 2012-12-04 03:10:46 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.
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.