EditContext: selection direction missing? about msedgeexplainers HOT 3 CLOSED

I'm open to adding selection direction if it serves a purpose for the text input services that the EditContext integrates with.

As far as I know, however, selection direction determines which end of the selection is the focus and which is the anchor; and the usefulness of knowing which end is the focus comes when the browser responds to user input (e.g. shift+click or shift+arrow). Since the selection properties of textareas and inputs affect the browser's selection, and authors want control over which end of the selection moves when user input is received, those elements also require a selection direction.

In contrast, the EditContext does not change the browser's selection, it only changes the data reported to OS text input services. I don't see in iOS or Android APIs a place where selection direction could be provided. It's possible it could be implied when the end is less than the start, but on Windows I know that's an error and will fail fast (crash the caller).

I suspect that like Windows, the selection is generally provided on all platforms to produce suggestions, and for that the selection direction seems unnecessary. Looping in some others in case they can say definitively whether Android and Mac text input APIs can accept an end less than the start offset for selection and if so whether than impacts the experience.

@whsieh any chance you know the answer to the question about whether the Mac / iOS text input APIs can accept or will benefit from knowing whether selection is reversed?

@mustaqahmed any chance you know the same for Android and Chrome OS?

from msedgeexplainers.

Given that EditContext is about input data and nothing else, I would propose we do not include selection direction. If @domenic you agree with the reasoning, I would like to close the issue.

from msedgeexplainers.

Assuming @domenic agrees. Closing.

from msedgeexplainers.