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

Great, thank you Brady for quick reply after your vacation, if it's not
useful, let's not bother.

So it looks like Xidorn, Brady, and I are in consensus with:

* Range.getClientRects() extends the start/end of the range to include full
grapheme cluster before it computes.
* The extended range is internal for computing the rects, not visible to JS.
* Range.getBoundingClientRect() invokes getClientRects(), so the same
applies.

Did I describe this correctly?

/koji



On Mon, Apr 11, 2016 at 3:54 AM, Brady Duga <duga@google.com> wrote:

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