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

Hey, I agree on your first point -- one should jump in to the cE=true when moving carets. If we were talking delete/backspace into it, I would however disagree and think it's poorly handled in Webkit/Blink currently, but luckily we will not have to worry about that any more if we don't handle backspace/delete.

On your last point: I agree it would be confusing if the caret doesn't move because there is a display:none element there. But it would also be problematic if it would be completely impossible to move the caret either directly before or after it (at least programmaticly). Maybe we should start out by looking at possible use cases for this? The one example I can think of are when using a system to "track changes" but currently hiding them: http://nytimes.github.io/ice/demo/ (click on "Show/Hide changes"). In that case it would indeed make sense to do as you suggest. However, I would probably generally think this is quite advanced usage and possibly should be handled by cE=typing at all.

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