Re: [w3c/selection-api] Fix selection.modify() to use resolved text direction instead of inline base direction (PR #357)

@dandclark commented on this pull request.



> @@ -731,6 +731,15 @@ <h2>
             selection by <var>granularity</var>.
             </li>
           </ol>
+          <p>
+            The <dfn>resolved text direction</dfn> at a <a>boundary point</a>
+            is <a data-xref-type="css-value"
+            data-xref-for="direction">ltr</a> if the bidi embedding level of
+            the character at that position is even, and <a

The "character at that position" is possibly ambiguous if the position is at the border between runs of rtl and ltr text. Do we look at the logical character before or the logical character after? Does it depend on which side is the rtl side?

> @@ -731,6 +731,15 @@ <h2>
             selection by <var>granularity</var>.
             </li>
           </ol>
+          <p>
+            The <dfn>resolved text direction</dfn> at a <a>boundary point</a>
+            is <a data-xref-type="css-value"
+            data-xref-for="direction">ltr</a> if the bidi embedding level of

The string "bidi embedding level" doesn't appear in https://www.unicode.org/reports/tr9/tr9-51.html. Is there a term we can use here that will make it easier to find in the other spec, or maybe even link to directly? As someone unfamiliar with the unicode spec it's non-obvious how to find what this means.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/pull/357#pullrequestreview-4198751239
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/selection-api/pull/357/review/4198751239@github.com>