Re: [editing-explainer] What browser internals can be exposed to help us move the caret in (and against) the block direction? (#56)

I'm not sure I follow this discussion properly, but for examples @johanneswilm and @ctalau raised, my understanding is browsers do some internal logic to do the work, which is not interoperable, but will raise events so that JS can change.

Is the request to expose currently hidden info so that JS can determine where to change? If my understanding is correct, I think what it should be is JS keeps such info by itself, because what info JS would need depends on how it wants to move. How caret moves when pressing up/down arrow key is I think part of the UX and one of the factors that determines how people likes the editor. One may want to keep X and flush it when left/right/mouse are used. Another may want to keep column and use different criteria to flush. One may want to use the behavior recommended for each OS, while someone else believes that consistent behavior across platform is the best.

So what API should define is to give enough opportunities (events) to JS to keep and flush such info, and access to X or column or whatever it wants to keep. The responsibility of when and what to keep is up to JS.

If we add an API to read "X of when up/down move started", and if an editor JS wants different behavior, the JS must wait until what s/he wants is defined in the spec, implemented, tested, and the spec goes CR/REC. We all would like to avoid that. Giving current info and events should give more flexibilities to editors.

So the question is, in order to build the behavior you editor JS developers want, are there enough events (left/right/up/down/home, ...) and properties (x, column, what else?)? Are they designed well enough so that such development is easy (e.g., if we have physical key events only, JS might need to list up all keys that moves caret to determine when to flush)?

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