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

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