Re: Only Text Input and Intention Events

There are two separate topics discussed in this thread.

If you can't set the caret to a specific position by API, it's a bug
in browser. Please file bugs to browser vendors. I'd be curious to
know Blink bugs. I think it'd be great to share the bug number on this
ML unless someone thinks it's a noise.

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, 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.

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.

/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
>
>

Received on Friday, 5 December 2014 16:57:59 UTC