[Chris McElligott]

I'd love this too, its one of the things I miss from Camino. /-type something would be nice :)

[Nutrimentia]

This is my highest rated request as well. It makes me happy to know that you plan on implementing it, but I just wanted to let you know that there are more people who really like it. I love just being able to hit a letter or two in 5.1.3 and have it jump to a link.

[bethkatz17582]

For instance, I'm trying to use speech to navigate these forum pages, and it would be nice to be able to spell links.

Edit: Correct that request to just be a type to find. The speech part is supposed to work by saying the link, but that isn't working.

[rorya]

Ken,

Wouldn't this feature conflict with Document input? Seems like, especially with some of these new wiz-bang AJAX apps, having this feature would prevent certain kinds of input at the document level. I believe I ran into this very issue when trying an AJAX SSH client on OW, recently. How would the browser discern between "find as you type" and document input? This might be an issue all browsers might have to deal with.

Is it really safe to assume that the only time input is sent to a document, when you've focused on an HTML document input element? Actually, when I noticed this feature was gone in 5.5, I thought it was due to WebKit not offering this feature, and it may be for good reason.

Another example.. earlier today, on this very forum I was doing a post, and I think these messages are typed in <textarea>'s.. anyhow, I have gotten used to using the Emacs key bindings offered in Cocoa apps, so expecting to behave as usual, I pressed Ctrl-p I think it was, and instead of moving up oneline, OW ended up triggering the "preview post" button at the bottom. I assume it did this because this forum system bound that key somehow, but of course I had no way of knowing it was bound. So, it seems to me that now with these more interactive web applications being deployed, the issue of "input focus" is becoming a bigger concern with web browsers. So should the line be drawn between browser and document input? What's your opinion?

[edenwaith]

Oh, yesyesyesyes. Please.

One of the best features since Firefox 0.9.x. I love the find as you type searching, it keeps things a lot cleaner than the Find window disappearing behind other windows.

[Forrest]

I would just like to say, since the difference was made clear to me and I use FF quite a bit lately (specifically because of a toolbar) I would really like this feature now.

[Jesse the K]

Incremental find as you type is a must if you're not using a mouse!

Using keyboard only (and mousekeys when I must) is much more accessible for me, because I have mobility impairments.
The good news is: "Next" button on the Enter key is back!

[Forrest]

Originally Posted by Jesse the K

Incremental find as you type is a must if you're not using a mouse!

Using keyboard only (and mousekeys when I must) is much more accessible for me, because I have mobility impairments.
The good news is: "Next" button on the Enter key is back!

Just hit command+g.

[Jesse the K]

Originally Posted by Forrest

Just hit command+g.

Well, no.

Because the command-F find doesn't move the system cursor (usually appears with blue highlight). With Safari+Saft or Firefox's find, the found object is immediately selectable. That is, when I do spacebar or return on the found text and it's also a link, I move to that link.

But OW's current (5.1.3) implementation of command-F requires me to route the pointer to that location and then click.

The good news with 5.1.3 is that I can move the "system cursor" with command-option-Up / command-option-Down. That's broken in SP14. I assume the 5.5 release will at least fix this.

[Forrest]

So command+g isn't finding next for you?