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

> Frankly speaking, I do not understand this move (stripping even caret movements), but I'll perhaps post a separate question about that. (Were there any discussions that would explain this decision?)

@Reinmar Well, there were two proposals (including them and not including them) and I went back and forth between including and removing those from the draft as opinions seemed to be in favor or against including it. We all noticed that standardizing caret movement would not be that easy as some browsers have very specific historic setups that they may not want to lose, and your boss @fredck came up with the idea to leave the typing module for now and instead just have this very basic intentions spec and later on add modules, including `caret`, `typing` and `return`. The discussions should all be on old tickets and the mailing list. Maybe this is something you guys want to discuss internally?


I personally don't care as much, as long as this issue doesn't end up meaning we won't get any further on the approval process at the F2F. If we don't approve anything, it may be another decade or two before someone else dares try.

>> In the meantime we need to be sure that the primitives are in place so that caret movement can be fully handled through JavaScript.

> So perhaps the primitives are exactly as I described – selection methods simulating intentions of arrow keys? As they are supposed to replace the native default actions the most convenient for us, developers, would be if usage of them didn't require any additional tinkering. In 99% cases a developer using cE=events will try to recreate the native behaviour (that's also why I'm not sure if stripping this makes sense).

Well, as some people pointed out earlier here, the browsers behave differently (for example with BiDi in Firefox), and most likely JS editors will try to create a uniform behavior rather than behavior that differs from UA to UA.

Making UAs behave the exact same way would require a lot of speccing of how that would be that hasn't been done yet and which currently seems to have been postponed until a future `caret`-module, unless we change that inofficial plan.

I notice that Aloha Editor has implemented its own caret movement system. The Aloha editor doesn't use contentEditable, but selections. It cannot differentiate between end of line and beginning of line. That issue we have addressed through the proposals to the Selection API. 

I also see that ProseMirror hardly uses any of contentEditable, but keeps it in because it helps with the caret movement. 

So I wonder whether we should make a test where we just catch the arrow keys on contentEditable=true and preventDefault them and see how much is missing for implementing those entirely in Javascript, especially the arrow up/down keys would be of interest.

> BTW. What about making a selection on touch screen devices and using mouse? So far the discussion was about caret movements and I can see that the input events explainer also describes only caret-related events. Have other cases been discussed already?

Well, there was a ticket open for a long time asking for all the actions we may need. You can reopen it if you think there are things not mentioned. Some of these things are not only related to keyboard inputs but available through the right click menu. But check the ticket and discussion here:  https://github.com/w3c/editing/issues/52


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