Re: Only Text Input and Intention Events

On Sun, Dec 7, 2014 at 5:55 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>
> On Sun, Dec 7, 2014 at 1:06 AM, Koji Ishii <kojiishi@gmail.com> wrote:
>>
>> On Sat, Dec 6, 2014 at 8:06 AM, Johannes Wilm <johannes@fiduswriter.org>
>> wrote:
>> >
>> > Indeed. We have started discussing this here:
>> >
>> > https://github.com/w3c/selection-api/issues/27#issuecomment-65732595
>>
>> Thank you for the link, it looks like we were discussing two different
>> things. The link is talking about an issue of inserting characters when
>> multiple DOM ranges belong to the same visual point. I agree that this issue
>> needs to be throughly discussed and solved.
>
> The first post there mentions two issues related to carets. Subsequently we
> have then discussed one of those issues. If we had a specific document to
> only talk about carets, then that's probably where those two posts would go.
>
> Or where else would you suggest for this to go?

Just replied to Olivier in the split thread, but in principle, I'd
like to split "move and set carets/selections" and "adjust for editing
and typing". Even for horizontal move, moving caret to the next
character isn't easy when i18n is taken into account, and there are
lots of unknowns and possible innovations even for browser developers.
I'm scared how long writing such spec would take, and also scared of
the efforts to keep it updated.

All that bother both browser and editor developers are the unspecified
magic between carets were moved/set and carets are displayed, no?

>> But this is not specific to cursor movements.
>
> Well, it depends. If Olivier suggests that the text input is exact where the
> selection/caret is, but that with moving the carets using arrow keys (or
> mouseclicking) it will always be put in a "default" position when in a
> certain place (for example when the caret is at the end of a link it will
> always be "outside" the link and not "inside of it).

Are you talking about current behavior of existing browsers, or about
what you want?

I'm guessing, what users and/or editor developers want vary by favor,
or by the type (link v.s. bold), etc., that it'd be better to have an
open and modifiable source code rather than spec and buried into
browser code.

>> In my understanding, this is part of the bigger issue where DOM ranges and
>> visual points are n:n. This could happen, for instance, when user clicked a
>> point in a document and starts typing. On the other hand, the opposite case
>> (multiple visual point mapping to the same DOM range) exists. Imagine the
>> range you set selection is at line wrapping. Should the caret displayed at
>> the end of line, or at the beginning of the next line? This could also occur
>> in bi-di text.
>>
>> The "n:n" could also be "n:0" if the element has display:none,
>> contenteditable=false, or user-select:none. "0:n" cases include generated
>> content such as list markers.
>
> Sorry, I am not familiar with that n:n terminology,  but I think I
> understood your point. Maybe from the perspective of someone programming a
> browser issues of carets really belong together with a lot of other things
> and don't need their own definition. From the perspective of an editor
> developer, they seem like something quite unique that need their own
> definitions.
>
> What's your suggestion we should do?

As above and as in the other thread, browser developers could provide
what are the situation when we need a magic to happen as of today.
Then an open source project could build a JS library to handle all
such situations. I don't have clear idea how such an open source
project could kick off, could be just a github project of ours, and
could ask if W3C can host, but that can probably be discussed later.

>> What I was talking about was more like UX. Where carets should when user
>> pressed the down arrow key for instance, e.g., which visual X should caret
>> move to.
>
> Down and up arrow key movements are somewhat more complicated to implement
> in Javascript, indeed, although some (like Aloha) are it anyway. I agree
> that moving up and down may not have have to be done the same in all
> browsers as long as all browsers follow common sense rules (like "don't move
> the caret inside a noneditable area", etc.).

Thanks for the info, it's quite not easy to know what's hard for
editor JS and what's not.

The "common sense rules" should probably be spec'ed out, but it looks
to me that we're close to consensus and I'm glad to that.

> Indeed. The idea is to have it more modularized and  for the browser to
> generally do less, as I understand it. But if the browser does something
> (for example caret drawing and movement), it should do it well and according
> to specs so that we an depend on this behavior, at least for simple editors.
> Advanced editors can always add their own behavior on top if they want to do
> something even more interesting.

Understood and agreed.

>> Interesting, I was thinking just opposite; if editor developers could
>> agree to want browsers to handle just typing, we can do that. I understood
>> Ben's proposal that way.
>
> If it's spec'ed and implemented in most major browsers the same way, there
> seems to be a good chance that editors will switch to this. If you remove
> contenteditable=true, chances are even higher. :)

Ah! I'd love to, but it's likely to have a transition period. This
needs to be discussed among the community I guess.

>> You listed 3 options:
>> 1. contenteditable and designmode will be thrown out entirely
>> 2. contenteditable=minimal route
>> 3. Spec'ing and fixing entirely the current contenteditable=true
>>
>> My impression was 1 and 2 are the same, renamed to contenteditable=typing.
>> What did I miss?
>
> Well, there are many other options of course, those just examples. Under 1,
> they would be thrown out and removed entirely without replacement. It was
> from my impression at the web summit that the browser people felt that
> contenteditable=true would stay around additionally to
> contenteditable=minimal for a good while because they believed many legacy
> systems depend on it.

Yeah, I guess so.

What about execCommand()? Do editor developers want it to work against
contenteditable=typing? Sorry if this was already discussed.

/koji

Received on Monday, 8 December 2014 17:50:37 UTC