On Mon, Mar 28, 2011 at 7:09 PM, Ehsan Akhgari wrote:
> I was talking about the way that the spell checking dialog works in
> OpenOffice Writer, for example. The selection would be visible on the
> screen, and its contents might get changed if the user chooses to. But spell
> checking is just
On Mon, Mar 28, 2011 at 3:57 PM, Ehsan Akhgari wrote:
>
> > I'd also point out that queryCommandValue and queryCommandState in
> > WebKit return different values depending on platforms.
>
> Do you know more details on this? Which commands have this platform
> specific behavior? And why does Web
> Why would an author want to use Selection.modify() to implement a
> spellcheck API? Wouldn't that imply that they'd have to save the
> user's selection somewhere, create a new one, modify() it to the right
> place, do whatever they want to do with the resulting range, then
> remove the ranges and
> 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.
For sure, whether the API behaves in a platform specific manner or not, web
applications can get the other behavior if they need it. I suggested the spell
check
On Sat, Mar 26, 2011 at 1:46 AM, Ehsan Akhgari wrote:
> 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
> call
On Sat, Mar 26, 2011 at 9:38 AM, Ehsan Akhgari 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 separator
> I'm not sure why we need to provide a consistent behavior all
> platforms. I think the whole point of modify() function is so that
> scripts can emulate selection operations user can initiate. Imagine an
> app that intercepts user actions such as key down and manually sets
> selection using modif
On Fri, Mar 25, 2011 at 10:46 PM, Ehsan Akhgari wrote:
>
> 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 pl
> 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
On Thu, Mar 24, 2011 at 12:31 AM, Ehsan Akhgari wrote:
> This is what Gecko does in Firefox 4. Webkit, however, implements the
> "non-space-eating" approach on all platforms. I think this is an advantage,
> because it means that the consumers of the API can rely on the behavior of
> the API with
On Wed, Mar 23, 2011 at 9:31 PM, Ehsan Akhgari 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 ge
Hi all,
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.
For example, on Windows, word selection "eats spaces" in between words.
That is, if you have "f|oo bar" (the pip
12 matches
Mail list logo
