- From: Koji Ishii <kojiishi@gmail.com>
- Date: Sun, 10 Apr 2016 19:10:25 +0900
- To: Xidorn Quan <quanxunzhen@gmail.com>
- Cc: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>, Brady Duga <duga@google.com>, Yoshifumi Inoue <yosin@chromium.org>
- Message-ID: <CAN9ydbVW4sSpdZz6mc0eM7KR8iK6=s_4n91jr862-C0q-79bhg@mail.gmail.com>
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 10:11:13 UTC