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

On Tue, Dec 16, 2014 at 8:38 PM, Olivier Forget <teleclimber@gmail.com>
wrote:
>
> On Tue Dec 16 2014 at 10:44:00 AM Johannes Wilm <johannes@fiduswriter.org>
> 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] https://github.com/w3c/editing-explainer/issues/28
>
> 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
http://www.fiduswriter.org