Re: [web-annotation] (model) vague definition of charactor position for text position selector

I really don't know how to handle this for the model or vocabulary, but for
client APIs I've been thinking of "strict" and "loose" modes for a while
now.

I've had an issue for this on my dom-seek library [1] for a year now. In
it, I suggest using a library, punycode, to get arrays of code points and
normalization to make the representation consistent, but if we say "code
points" rather than "symbols" we probably shouldn't normalize but take the
code points _as serialized_. Being explicit about normalization would be
nice.

However, in JavaScript, this would likely dramatically impact performance
for a text position anchor.

[1] https://github.com/tilgovi/dom-seek/issues/1

On Mon, May 16, 2016 at 1:47 PM Takeshi Kanai via GitHub <sysbot+gh@w3.org>
wrote:

> At this moment, HTML APIs and Javascript do NOT support Code Point
> base String indexing at all. Then, what I get from the recommendations
>  is that web annotation client systems which work on browsers need to
> walk through text from the beginning for both indexing and text
> selection purposes. Is my understanding correct?
>
> Here is what I have pointed out in [FindText API Issue
> #4](https://github.com/w3c/findtext/issues/4).
>
>
> --
> GitHub Notification of comment by tkanai
> Please view or discuss this issue at
> https://github.com/w3c/web-annotation/issues/206#issuecomment-219542493
>  using your GitHub account
>
>