Re: [selection-api] caret-based selection movement (#27)

I agree with @rniwa for not to define caret movements in the spec, especially word/sentence boundaries. Instead, beforeSelectionChange event in Ben's proposal could carry the original intent that caused the selection change. If a framework would like to ignore platform-standard behavior but its own standard behavior, it can trap such events and adjust selections as needed. I suppose framework is easier if the original intent is known, no?

Are we also going to define:
1. What are the conditions the "proposed positions" has to meet?
2. What would browsers do if APIs set selections to non-editable, non-selectable, atomic (e.g., img) etc.?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/27#issuecomment-67805895