Re: Only Text Input and Intention Events

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