> 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.
Yes, I'm not arguing that the selection behavior using input devices needs to change. > 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. Again, this is outside the scope of my question (and yes, I agree that platform specific selection behavior is the correct thing to implement here). > This seems like a WebKit bug. Is there a bug filed for this? I don't know, but first let's see if we can agree on which behavior is desired... :-) > 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. I agree that for the "日本語" example, the language properties should be taken into account. But including word separators such as spaces makes it problematic, I think. If we define selection.modify with granulatity set to "word" as extending the selection to the start/end of the current word (or for that matter, to the start/end of the next/previous word!) we would have a consistent result for calls on this API. For example, if somebody is writing a spell correction UI, they would want to replace the currently selected word with another word. Even if we choose the latter definition for the API (which I find less intuitive), the author knows that they need to deal with word separator characters separately. But with the behavior of the API changing based on the platform, the author can either choose to sniff the UA string, or check what the API did after calling it. The scarier scenario is the author testing their application on one platform, and deploying it without realizing that it will break in other platforms. I think if we want to have the platform specific word selection capability in the API, we should have a different granularity value which points out that its results are platform specific. Otherwise, it's just too easy to assume that the result of calling this API is the same across all platforms, just like almost all other Web APIs. Cheers, -- Ehsan Akhgari [email protected] http://ehsanakhgari.org/
