Re: [w3c/editing] Different browser behaviors when moving the caret by one word. (#278)

I was [tasked](https://www.w3.org/International/track/actions/1159) by the I18N WG with adding our thoughts to this issue.

Word-based cursoring/selection is complicated in that it not only involves the platform interface, but is influenced by language. Many languages can use fairly simple heuristics to accomplish this (when words are separated by spaces and/or certain punctuation), but other languages present multiple difficulties. UAX#29 enumerates a few of these and outlines a _default_ implementation. Of specific interest are these two notes:

> * It is not possible to provide a uniform set of rules that resolves all issues across languages or that handles all ambiguous situations within a given language. The goal for the specification presented in this annex is to provide a workable default; tailored implementations can be more sophisticated.
> * For Thai, Lao, Khmer, Myanmar, and other scripts that do not typically use spaces between words, a good implementation should not depend on the default word boundary specification. It should use a more sophisticated mechanism, as is also required for line breaking. Ideographic scripts such as Japanese and Chinese are even more complex. Where Hangul text is written without spaces, the same applies. However, in the absence of a more sophisticated mechanism, the rules specified in this annex supply a well-defined default.

I will note that a number of non-browser implementations (such as a certain ebook reading application I am familiar with) have implemented improvements to word-based selection/navigation for many of these languages. The I18N WG wouldn't want to forcibly standardize selection behavior in a way that prevents this sort of improvement, but to various people's point, it would be sensible to describe consistent behavior or patterns of behavior regarding e.g. cursor placement.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/278#issuecomment-1159193423
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/278/1159193423@github.com>

Received on Friday, 17 June 2022 20:06:02 UTC