[whatwg] selection.modify behavior across platforms

On Wed, Mar 23, 2011 at 9:31 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
>
> Usually, when the user is using the keyboard to extend or move the
> selection in a document, the result of the keyboard commands vary depending
> on the underlying platform.
>

I think that's a correct assumption.  Selection behavior in general depends
on the underlying platform, and I don't see any benefit of matching the
behaviors for the end users.

If we incorporate this behavior into selection.modify, its behavior can be
> different depending on the platform the UA is rendering the web page on (if
> using the "word" granularity, of course).


I think that's the correct approach.  Even without selection.modify,
WebKit's selection behavior is different based on the underlying platform.
 For example, selection created by pointing devices will result on Mac will
be directionless whereas selection will always has a direction on non-Mac
platforms.

This is what Gecko does in Firefox 4.  Webkit, however, implements the
> "non-space-eating" approach on all platforms.


This seems like a WebKit bug. Is there a bug filed for this?

I think this is an advantage, because it means that the consumers of the API
> can rely on the behavior of the API without having to resort to User-Agent
> sniffing.  So, I modified the behavior of Gecko today[1] to match that of
> Webkit (i.e., not eating spaces between words).
>

I disagree. I think selection behavior should be implemented in accordance
to the native platform. To begin with, the concept of the word itself maybe
vague in some languages.  For example, extending selection at the beginning
of "???" results in selecting "?" on Safari whereas Chrome selects the
entire "???".  With this in mind, the benefit of matching this edge case
only relevant to alphabetic languages that uses a space as a word separator
is highly questionable.

- Ryosuke

Received on Thursday, 24 March 2011 20:06:28 UTC