W3C home > Mailing lists > Public > www-style@w3.org > April 2016

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

From: Brady Duga <duga@google.com>
Date: Sun, 10 Apr 2016 18:54:03 +0000
Message-ID: <CAH_p_eUF4soMND8LqB0ynsrnUbxro0g5dp+A9nPpKJdvWgwcBg@mail.gmail.com>
To: Koji Ishii <kojiishi@gmail.com>, Xidorn Quan <quanxunzhen@gmail.com>
Cc: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>, Yoshifumi Inoue <yosin@chromium.org>
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
>
Received on Sunday, 10 April 2016 18:54:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC