You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expose with which bidi-level caret is affiliated as well as API to set it #57
We need to expose information as to which bidi-level (LTR or RTL or both) the caret is associated with visually, as well as an API to specify it (e.g. add an optional argument to setPosition and collapse).
I support this idea.
Can we unify this to beforeLineWrap#32?
In Blink/WebKit, there is TextAffinity = {Downstream, Upstream}. Upstream means beforeLineWrap.
When I work on LTR in RTL case, I found TextAffinity helps explaining caret position.
For example: <div dir=rtl style="padding: 50px">abcdef</div>
When clicking left edge, each browser sets selection as caret to:
Chrome: abcdef@6 |abcdef
Edge: abcdef@0 |abcdef
Firefox: abcdef@0 |abcdef
All UAs display caret before a, like |abcdef, where | denotes caret.
Note: This is as same as collapse("abcdef", 0) except for Chrome.
When typing "X", after clicking left edge:
Chrome: abcdefX@7 |abcdefX
Edge: Xabcdef@1 X|abcdef
Firefox: Xabcdef@1 X|abcdef
If we have TextAffinity, Chrome can use abcdefX@7/Upstream, to place caret after X, e.g. abcdefX|,
and left edge clicking as abcdef@0/Downstream as Edge/Firefox.
One thing we have to keep in mind is that different browser engine assigns different offsets at bidi-level boundary. So depending on what the use cases are, we may need to specify where the visual location would be vs. between which logical characters the caret will be placed.
Firefox has exposed Selection.caretBidiLevel for a while, which helps a lot with this, in that it allows scripts to figure out where a caret actually is, and create a selection at precisely that position. I was not able to find any effort to standardize this, but having it portably available would be extremely valuable.
What would be the steps required to get discussion going on this? Opening an issue doesn't seem to have done a lot, judging by this one's progress.
Activity
yosinch commentedon Apr 13, 2017
I support this idea.
Can we unify this to
beforeLineWrap#32?In Blink/WebKit, there is TextAffinity = {Downstream, Upstream}. Upstream means
beforeLineWrap.When I work on LTR in RTL case, I found TextAffinity helps explaining caret position.
For example:
<div dir=rtl style="padding: 50px">abcdef</div>When clicking left edge, each browser sets selection as caret to:
|abcdef|abcdef|abcdefAll UAs display caret before
a, like|abcdef, where|denotes caret.Note: This is as same as
collapse("abcdef", 0)except for Chrome.When typing "X", after clicking left edge:
If we have TextAffinity, Chrome can use
abcdefX@7/Upstream, to place caret afterX, e.g.abcdefX|,and left edge clicking as
abcdef@0/Downstream as Edge/Firefox.For
collapse("abcdef", 0),collapse("abcdef", 6)abcdef||abcdef|abcdefabcdef||abcdefabcdef|Other examples found in https://goo.gl/A5yhvl
rniwa commentedon Apr 13, 2017
We definitely don't want to expose downstream/upstream. They're contrived concepts.
rniwa commentedon Mar 23, 2019
One thing we have to keep in mind is that different browser engine assigns different offsets at bidi-level boundary. So depending on what the use cases are, we may need to specify where the visual location would be vs. between which logical characters the caret will be placed.
marijnh commentedon Jan 23, 2020
I strongly support this.
Firefox has exposed
Selection.caretBidiLevelfor a while, which helps a lot with this, in that it allows scripts to figure out where a caret actually is, and create a selection at precisely that position. I was not able to find any effort to standardize this, but having it portably available would be extremely valuable.What would be the steps required to get discussion going on this? Opening an issue doesn't seem to have done a lot, judging by this one's progress.