16095 2012-02-23 22:00:04 +0000 Element with contenteditable=true shouldn't be considered as an editing host if it's already in an editable region 2015-07-30 23:47:09 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified PC Linux NEW P2 normal --- 1 rniwa ayg mike public-webapps 2015-07-30 sideshowbarker+html-editing-api oldest_to_newest 64507 0 rniwa 2012-02-23 22:00:04 +0000 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. 64537 1 ayg 2012-02-24 14:02:15 +0000 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.