Do everything needed to do block direction movement of the caret when in cE=Events?

[johanneswilm]

We need this to be resolved in the Selection API: https://github.com/w3c/selection-api/issues/32

Anything else? What about BiDi text?

[rniwa]

Everything should be defined in the selection API spec instead.

[johanneswilm]

@rniwa What else do we need described in the Selection API in order to allow caret movement in the block direction in cE=Events?

[johanneswilm]

I have tried to implement basic caret movement in pure JS in the block direction, and it turns pretty hackish pretty fast. This is barely working for text content in Chrome: http://jsbin.com/tepado/edit?html,console,output . Trying to get it to work with other browsers and with extra content (think of images, SVGs, canvas elements, etc.) will be quite a nightmare.

[kojiishi]

How about using getClientRects() to get bounds of lines and find next one from ClientRectList? An example here.

[johanneswilm]

Interesting! I had a good nights sleep and now it seems somewhat less problematic. We can do caret movement in the block direction with not more than just a few hours of programming. This could easily be a library for caret movement and one could easily adjust the library if one wants to have somewhat different caret movement. Your example code makes it even more easy.

Nevertheless, as the editor people in #71 said, there is no good reason to take away the default caret movement. We just don't have to specify exactly how it works and a future spec can do that (or a future version of this spec).

@kojiishi Or will this be problematic for browsers?

[kojiishi]

Or will this be problematic for browsers?

That's fine with me, as long as the expectations such as #68 are clearly defined.

[Reinmar]

Interesting! I had a good nights sleep and now it seems somewhat less problematic.

I can't agree even after having more coffee ;). I started considering cases like floated blocks (multiple columns of text), CSS multi-column cases (which should be navigable in source order), or stuff like:

<p>foo<img src="x" width="50" height="50"><img src="x" width="50" height="50" style="margin-left:50px"></p>

which creates a gap between images that doesn't have a rect, so an algorithm based on rects would not reach it, while e.g. Chrome does.

A demo: http://jsfiddle.net/92s48f87/3/

Besides, this is still only caret movements, while the scope is much wider.

Or will this be problematic for browsers?

That's fine with me, as long as the expectations such as #68 are clearly defined.

Great to hear this! I feel that we should focus our energy on defining such topics as #68 instead of opening the pandora's box of selection movements.

[johanneswilm]

Clearly, a caret moving library would need to be somewhat more complex than what I hacked together on evening or what Koji put together quickly for an example. Situations with floats are somewhat problematic anyway, as it may seem unpredictable for the caret suddenly to disappear to some strange other place. One may have one library that makes the caret move up/down strictly as the physuical direction on the screen indicates and another that takes content order into consideration, and a third that does some of each, etc. .

At any rate, now we have the best of both worlds, so everyone can be happy.

[johanneswilm]

@Reinmar Actually, trying your fiddle in Chrome: http://jsfiddle.net/92s48f87/3/ works fine. But trying it in Firefox means that one cannot reach the red part by moving the caret up down. So at least for Firefox, you need to implement the movement in JS anyway.

[Reinmar]

So at least for Firefox, you need to implement the movement in JS anyway.

I will be happy to be able to, but I can leave with the current behaviour. If there was no default native behaviour, I would be forced to implement this algorithm myself and that's a different situation.

[johanneswilm]

Well, but the current behavior doesn't allow for what you want (move the caret to both boxes by going up/down), so if you want that kind of design and want to be able to go everywhere using up/down keys on all browsers, you are forced to reimplement that anyway.