[w3c/selection-api] `Selection.direction`'s behavior should be based on the node's position (Issue #334)

**The main use cases where the `direction` can be useful:**

1. When we have an "in-range" selection (so it's not collapsed), and we press `Shift` + `ArrowKey` to navigate, it extends the focus boundary point.

2. During the Selection, the engines handles the focus boundary point differently.
For example, in Chromium, if the anchor is an editable, the focus boundary point has to be an editable as well, meanwhile Gecko allows the focus boundary-point to end in a non-editable node, therefore we may have to extend the focus to an editable node.

There may other use cases, but at the end, all that matters that we know which one is the anchor and the focus boundary-point.

With the current behavior of the `direction` that mainly relies on the user's interaction and changes the direction accordingly, is very confusing from the developer perspective, because the selection can be collapsed even if the `direction` is `backward` or `forward`, or it can be "in-range" even if the `direction` is `none`, so it's much harder to figure out which one is the anchor and focus boundary-point.

I'd like to discuss here that what's the purpose of the `direction` property with the current implementation, and what's the advantage of setting the `direction` based on the user's interaction instead of the node's position in the document.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/334
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/selection-api/issues/334@github.com>