25908 2014-05-28 08:35:09 +0000 Is element editable if it's hidden 2014-07-01 01:56:14 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified PC Linux RESOLVED WORKSFORME P2 normal --- 1 p.koszulinski ayg annevk m.lewandowski+w3c-bugs mike public-webapps rniwa sideshowbarker+html-editing-api oldest_to_newest 106896 0 p.koszulinski 2014-05-28 08:35:09 +0000 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. 106899 1 annevk 2014-05-28 08:46:23 +0000 This should be true. We don't want isContentEditable to have to do synchronous style resolution. 106900 2 p.koszulinski 2014-05-28 08:53:29 +0000 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 106901 3 p.koszulinski 2014-05-28 09:02:28 +0000 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? 106902 4 annevk 2014-05-28 09:09:32 +0000 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 107022 5 ayg 2014-05-30 10:01:09 +0000 (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. 108539 6 rniwa 2014-07-01 01:56:14 +0000 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