Aryeh Gregor <> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #5 from Aryeh Gregor <> ---
(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:

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

You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to