Re: [cssom-view] Range.getClientRects() when the range contains part of a grapheme cluster

Sorry, back from vacation and catching up here. I don't think c requires
cluster detection in the JS, at least for my use of it. From a "least
surprise" perspective, it seems to make sense for all of this to be
internal only. So selecting part of a cluster would return the bounds of
the entire cluster, but not adjust the range offsets. However, either a or
b would also be workable.

On Sun, Apr 10, 2016 at 3:10 AM Koji Ishii <kojiishi@gmail.com> wrote:

> On Sun, Apr 10, 2016 at 1:19 PM, Xidorn Quan <quanxunzhen@gmail.com>
> wrote:
>
>> On Sun, Apr 10, 2016 at 2:05 PM, Koji Ishii <kojiishi@gmail.com> wrote:
>>
>>> On Sat, Apr 9, 2016 at 10:28 PM, Xidorn Quan <quanxunzhen@gmail.com>
>>> wrote:
>>>
>>>> On Sat, Apr 9, 2016 at 1:11 AM, Simon Pieters <simonp@opera.com> wrote:
>>>>
>>>>> On Thu, 07 Apr 2016 13:29:34 +0200, Koji Ishii <kojiishi@gmail.com>
>>>>> wrote:
>>>>>
>>>>> We recently figured out that the spec[1] isn't clear when the range
>>>>>> contains part of a grapheme cluster. Our behavior for the case was
>>>>>> recently
>>>>>> changed due to some other improvements, which lead to a discussion of
>>>>>> the
>>>>>> right behavior of getClientRects() and getBoundingClientRect().
>>>>>>
>>>>>> Could we define cases such as:
>>>>>> 1. What to do when the range contains part of a grapheme cluster.
>>>>>> 2. What to do when the range contains part of a surrogate pair.
>>>>>>
>>>>>
>>>>> I think these two should cover the whole grapheme cluster.
>>>>>
>>>>
>>>> In my opinion, a range should never contain only part of a surrogate
>>>> pair. I'd suggest that browsers should force the range to be either cover
>>>> the whole pair, or none of the parts. Containing part of surrogate pair
>>>> makes no sense to me.
>>>>
>>>
>>> Agreed, I wish us to define when and how.
>>>
>>> 1. var range = document.createRange();
>>> 2. range.setStart(node, 0);
>>> 3. range.setEnd(node, 1);
>>> 4. var rects = range.getClientRects();
>>>
>>> When the first code unit of the node is part of a grapheme cluster, when
>>> do we extend the range? I can think 3 options:
>>>
>>> a. Range is always adjusted to cover grapheme cluster, so at step 3.
>>> b. Adjusted when particular operations are invoked, so at step 4.
>>> c. Adjusted when particular operations are invoked, at step 4
>>> internally, but does not change the range itself.
>>>
>>> I prefer option b at this moment, but I'm fine with option c if that
>>> looks more useful. I'm not a big fan of option a because it's expensive.
>>>
>>
>> I was not talking about grapheme cluster, because that's hard... I think
>> allowing range to contain only part of a grapheme cluster may make sense
>> for some use cases, unlike surrogate pair, so probably c for grapheme
>> cluster is sensible.
>>
>
> Makes sense to me.
>
> Between b and c is a concern that, if author wants to iterate over
> grapheme clusters and their boundaries, c might require JS to implement the
> same grapheme cluster detection as browsers. I need Brady and other authors
> input whether this concern is real or not.
>
> If this concern is real, we could still choose c by having a separate
> method to extend the range to begin/end of the boundaries to help JS to
> enumerate grapheme clusters. Does that look better to you?
>
> /koji
>