This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable What if element has contenteditable=true attribute but it's hidden. E.g.: <div style="display:none"> <div contenteditable="true">Am I editable?</div> </div> AFAIK Blink and Webkit sets isContentEditable to false on such attributes and in my opinion it makes sense - especially for editing hosts. Firefox and IE leaves isContentEditable true and therefore it would be good if this case was explained in specification.
This should be true. We don't want isContentEditable to have to do synchronous style resolution.
If you could include this information in the spec I could ask Blink and Webkit team to fix it. Currently, they made a conscious decision: https://code.google.com/p/chromium/issues/detail?id=313082#c4
Just to clarify. So isContentEditable is meant to be a faster alternative to traversing DOM tree down to the first element with contenteditable attribute set or document in design mode. Is this correct?
Yes, HTML defers to HTML editing APIs for the definition of isContentEditable and there it is quite clear: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable
(In reply to Anne from comment #4) > Yes, HTML defers to HTML editing APIs for the definition of > isContentEditable and there it is quite clear: > https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable Don't put much stock in this definition, I made it up on a whim and didn't consider this issue. That said, making it depend on CSS properties doesn't seem desirable to me offhand. The reason given on the Chromium bug is > Since users can't edit elements not rendered, Blink considers > such elements aren't editable. This is reason why > isContentEditable returns false for elements which have > contenteditable="true" attribute but hidden. I don't find this convincing. You can't access the inside of the element because you can't put the cursor there, but I wouldn't say that means it's not editable, just that you don't have any way to tell the UA to do anything to it. It's perfectly editable if, say, script places the cursor there -- which is very relevant, since we're talking about a script-accessible property here. Per spec, the editor doesn't treat hidden elements the same as non-editable elements at all. (In reply to Anne from comment #1) > This should be true. We don't want isContentEditable to have to do > synchronous style resolution. Ryosuke once told me that contenteditability is implemented by a CSS property in WebKit anyway, so they have to. (In Gecko, it's implemented by a flag bit that's set and unset recursively as needed with special code. This has caused bugs that the WebKit approach would probably have avoided.) But I agree that this is another reason not to have it this way in the spec. So in the absence of anyone actively editing the editing spec, I'll call this RESOLVED.
Note that we've recently fixed this bug in WebKit (http://trac.webkit.org/changeset/160966) so that isContentEditable returns true even inside an element with display:none: https://bugs.webkit.org/show_bug.cgi?id=133371