Re: Should we take CSS into consideration? (was: Re: attribute or CSS property?)

On Tue, Dec 16, 2014 at 8:38 PM, Olivier Forget <>
> On Tue Dec 16 2014 at 10:44:00 AM Johannes Wilm <>
> wrote:

>> [A] The caret can go into a contenteditable element inside of a
>> "display:none;"-styled element only if it is placed there by Javascript.
>> Once it is placed there though. the caret/selection behaves like any other
>> caret/selection, right? So it reacts to keyboard input, arrow keys, etc. .
>> If it doesn't react to any of this, wouldn't that take the "typing" out of
>> "contenteditable=typing"?
> Sorry I should have been more clear, but it looks like you got it. User
> can't navigate to the inside of a display:none (or any of its descendants)
> using either mouse or arrow keys.
> However Editor Dev can set the selection programmatically but there is no
> visible manifestation of the caret.
> The question then is: should typing intent events fire when the selection
> is inside editable content that is CSS-hidden? What about caret movement
> intents?
> Let's start with caret movement. Are these even possible? Where does
> "up-arrow" go when the characters themselves have no defined position? And
> that's just the start of it. Our rules for moving caret around invisible
> elements become nonsensical when everything is invisible. I think enabling
> caret-movement intents on hidden content will be problematic.
> What about typing intents? At first glance it seems this should not be a
> problem. However I worry that there may be situations where it breaks down.
> One open question about typing is what to do in "overwrite" mode [1]? It
> seems cE=typing should support this. However that may mean moving the caret
> forward on each new character insert. That implies caret movement. But as
> we have seen above caret movement inside an invisible content is
> problematic.
> [1]
> That was just one situation. There could be others. We could spend a long
> time defining editor behavior of hidden content. But does it make any
> sense? Who does it help?

Ok, that makes sense and it seems like this can simplify dealing with
display:none; a lot. In that case, contenteditable=typing inside of
display:none simple does not allow typing, caret movement, etc. . So all we
can do is place ranges programmatically, right?

Shouldn't range placement, etc. also be available to any other element
inside of display:none? Now given that contenteditable=typing has most
other things turned of, what else do we then have available that is
specific to contenteditable=typing and that we would not have with any
other element?

It is my understanding that currently some editors create a temporary and
hidden contenteditable area, mainly related to paste (and possibly copy?),
to let the browser do at least a part of the job of getting the new text
integrated correctly with the already existing text. But with
contenteditable=typing we won't handle paste, so it seems like that use
case of a hidden contenteditable=typing may not be that useful.

Maybe Piotr or Frederico could mention some other common scenarios in which
one would want a hidden, but functional contenteditable=typing?

Johannes Wilm
Fidus Writer

Received on Tuesday, 16 December 2014 20:40:45 UTC