- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Sat, 26 Mar 2011 13:22:29 -0700
On Sat, Mar 26, 2011 at 9:38 AM, Ehsan Akhgari <ehsan at mozilla.com> wrote: > > Well, it depends on what you want to do. If you want to implement the > spell correction UI I talked about before, for example, you really want to > ask the browser to give you the boundaries of the word, not including any > word separators. Right? > I'm not even sure. Spell correction code can certainly deal with that sort of differences so I don't see it as a critical problem. > Our implementation of modify() is already platform-specific in many > > ways. I personally don't see a point in making this specific case > > platform-independent. > > If I'm not mistaken, Webkit already implements this in a > platform-independent way (at least Chrome does) as far as the user of the > API is concerned. > I'm not talking about this specific case but saying that window.getSelection().modify() in general have platform specific behaviors. The thing that bothers me about making the behavior platform-dependent is > that almost all other web APIs are agnostic to the underlying platform, > which makes web authors automatically expect that from all APIs, which may > cause unexpected surprises if the author doesn't test their application in > all platforms. Don't you think that is a problem which we should address > somehow? > What do you mean by "agnostic to the underlying platform"? Regardless of whether eating space or not, modifying selection by word does emulate the selection behavior that can be otherwise invoked by users. So in that sense, this API is agnostic to the underlying platform. It'll NOT be agnostic to the underlying platform if window.getSelection().modify()'s behavior didn't match that of selection changes made by user on some but not all platforms. I'd also point out that queryCommandValue and queryCommandState in WebKit return different values depending on platforms. - Ryosuke
Received on Saturday, 26 March 2011 13:22:29 UTC