Re: [editing] Should the caret move by default, and should we define this behavior? (#58)

That's not all what I'm saying at all.

I'm here to participate in the discussion to come up with a new editing API that __WORKS__.  It doesn't matter whether it "provides primitive" or "gives more power to JS".  Letting JavaScript see exactly where the caret is placed doesn't solve any problem on its own and IMO introduces more problems for bidi users because caret will show up at two different locations at boundaries of bidi levels.  Gecko, for exmaple, changes the location at which caret appears depending from which direction you moved the caret into.  I don't think Web apps want to have a bunch of if-else statements to check the preferences of Gecko and behave differently based on that.  The fact selection behaves differently in different browsers is not necessary a bug.  Some of the behavioral differences are intential and features.

So that's why I'm asking for you to list the problems you have with the current selection APIs and behaviors so that we can come up with the right set of APIs and spec's that address those issues without degrading user experience in CJK languages, bidirectional text, and platform-specific behaviors.

The reason editing API hasn't improved over the last decade or two isn't because we've been lazy. It's that HTML editing is really hard.  We can't just add a bunch of half-baked "primitives" and magically solve the problem.  If anything, that'll just exacerbate the problem we have today.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/58#issuecomment-108625982