Created attachment 345935 [details] testcase According to http://www.w3.org/html/wg/html5/#contenteditable if an element has contentEditable=false then it should not be editable, even if the rest of the document has designMode='on'. This testcase proves that Firefox, Safari and Opera fail to disable the editing in such situation.
The designMode isn't same as contenteditable="true" on root element. designMode property of the *document* makes all contents editable. You can think that desingMode emulates HTML editor, contenteditable attribute makes a part of static document editable. # I think that the spec should explain more.
The steps detailed in the spec states that given that condition the element shouldn't be editable, and it explains how to handle both contentEditable and designMode. It clearly states that if an element is marked as contentEditable=false then the user shouldn't be able to edit it, no matter if the surrounding content is made editable due to setting in a higher node contentEditable = true or designMode = true in the document. Without this feature it's not possible to create non-editable blocks in a document with designMode, so in the end it means that it isn't useful to use designMode at all because people sometimes want the ability to mark some sentence/word/html as block that it's a single entity that can't be edited in the normal way, and the solution for those situations is to use contentEditable=false. Until the spec is changed to remove this sentence this is a bug. "or if it and its ancestors all have their contenteditable attribute set to the inherit state but the Document has designMode enabled, then the UA must treat the element as editable (as described below)."