Re: Only Text Input and Intention Events

On Fri, Dec 5, 2014 at 5:57 PM, Koji Ishii <kojiishi@gmail.com> wrote:
...
>
>
> Regarding the cursor movements by cursor keys, it's a separate topic.
> I think it should follow the discussion of ENTER key; they're intents,
> not 'inserting characters'.
>
> I think there are 3 ways to answer to the Johanes's question:
>
> 1. Create a spec of a list of default handlers browsers handle. Cursor
> movement is included, and the spec defines the behavior in details
> enough to assure interoperability.
>
> 2. Define cursor movements very loosely.
>
> 3. Do not define cursor movements at all.
>
> What Johannes wanted is #1,


Indeed. We have started discussing this here:

https://github.com/w3c/selection-api/issues/27#issuecomment-65732595


> but I don't think it's the right way to
> go. Cursor movements is a quite complex task as Johannes pointed out,
> and writing a spec to assure interoperability for that would be a
> quite big task that'd take very long. Also, editors might want
> different behavior depends on situation, so the spec is likely to be a
> common denominator, which a good editor library would not want to use.
>
> If we go with #2 or #3, editor developers can intercept cursor
> movements intents, or trap beforeinput, and adjust where the caret
> should go. That way, anyone can develop his/her favorite ways to move
> carets.
>

Not defining caret movement at all is also a possibility. But in that case
it seems noone will be able to use the browser-builtin caret movement
logic, right? It seems like the answer then will have to be what it
currently is: to replace all or most of caret movement with Javascript, so
the only major parts of contenditable left then are:

1) drawing the blinking caret (which isn't that hard to replicate in
Javascript) and
2) multi-key character input

If one goes that way it seems to me it may be an idea to just focus on 2
and throw contenteditable entirely away.


>
> If there were common handlers for any specific intents, I would prefer
> to develop common JS library rather than defining precise spec and all
> browsers implement them. That'd save us a lot of time to discuss the
> best behavior, spec them, develop them, write tests, test them, and
> fix bugs. It has other benefits as well such as someone who doesn't
> like the common behavior can fork and modify for his/her purposes, or
> you can fix issues by yourself rather than filing a bug and waiting
> for a long time until problematic versions would be gone.
>

I think you are somewhat right about this, but somehow conditions haven't
been right so far. We editor developers are divided between several
different editors with somewhat diffeent approaches building on more or
less of the available (oftentimes broken) APIs that can be used for
editing; either entirely on currently contenteditable/designmode with
little modifications (and lots of stuff breaking), or with heavy
modifications to have things break less, or not with
designmode/contenteditable at all drawing your own caret with more or less
of a complex relation between DOM and data-representing JSON. Once one
chooses one approach, one can't really mix very well, and browsers often
all these half-working solutions and there hasn't been much of a signal
which way it's going.

If browser makers could agree that contenteditable and designmode will be
thrown out entirely, that would be a clear message and even though not the
best solution for us who work with editors, it would mean we would have a
clear picture of what we are looking at and possibly some common library
that "every" editor uses (type jquery) could evolve from that. Or
alternatively, as it was my understanding until now, that you guys go for
the contenteditable=minimal route or even for spec'ing and fixing entirely
the current contenteditable=true.

The worst of all situations seems to be to continue what we have now: no
specification on most editing-related things, yet two or more different
alternative ways of editing html in the browser that are implemented
differently in each browser and arbitrarily change in each browser with
versions.



>
> /koji
>
>
> On Fri, Dec 5, 2014 at 10:27 AM, Olivier Forget <teleclimber@gmail.com>
> wrote:
> > @Johannes: In this particular case I was referring to the bug in
> > webkit/blink that prevents you from programmatically setting the caret at
> > the beginning of a text node (offset=0). The spec clearly allows for
> this,
> > but in webkit/blink It jumps to the end of the previous node, even if
> it's
> > in a different element. Pretty bad bug, and it's been there since 2008!
> >
> > But anyways, I agree we need to provide a clear and concise spec for all
> > aspects of cE=insertText so we can then file bugs with browsers.
> >
> > On Thu, Dec 4, 2014 at 5:01 PM, Johannes Wilm <johannes@fiduswriter.org>
> > wrote:
> >>
> >> Well, and the lack of specs on how caret movement is to be handled. I
> have
> >> filed numerous bug reports with several of the browsers, and sent
> emails,
> >> etc., and the most common answer is that given that nothing can be done
> as
> >> long as there is no spec on this. In the case of contenteditable, for
> me the
> >> issue about the caret not being able to move certain places is the
> single
> >> most annoying item which is the main reason something has to be done in
> the
> >> field of contenteditable. Just about everything else one can work
> around,
> >> but getting around this requires the app developer to draw his own
> caret and
> >> give up on contenteditable entirely.
> >>
> >> The selection API currently doesn't say anything about caret movement as
> >> far as I can tell (@Oliver: Or maybe you read the selection Api spec
> >> differently?). And maybe it shouldn't be in the selection API, as this
> will
> >> only apply to contenteditable=true and contenteditable=typing. A second
> >> document related to the selection app may therefore make most sense. I
> don't
> >> care either way, as long as it goes into one document or the other.
> >>
> >> On Fri, Dec 5, 2014 at 1:13 AM, Olivier Forget <teleclimber@gmail.com>
> >> wrote:
> >>>
> >>> On Thu, Dec 4, 2014 at 9:39 AM, Ben Peters <Ben.Peters@microsoft.com>
> >>> wrote:
> >>>>
> >>>> On Wed, Nov 26, 2014 at 12:03 PM, Olivier Forget <
> teleclimber@gmail.com>
> >>>> wrote:
> >>>> >
> >>>> > Caveat: there are existing issues with setting selection at offset 0
> >>>> > of text
> >>>> > nodes, or in empty text nodes which become more pronounced if text
> >>>> > nodes
> >>>> > become so central to editing. Should we try to address these here?
> >>>>
> >>>> I'm not aware of these issues, but they should be solved. Can you
> file a
> >>>> bug on Selection API for this?
> >>>>
> >>> It appears the issues are with the way some browsers handle selections
> >>> rather than the spec itself, at least as far as I can tell.
> >>
> >>
> >>
> >>
> >> --
> >> Johannes Wilm
> >> Fidus Writer
> >> http://www.fiduswriter.org
> >
> >
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org