Re: SearchBox API

Why not just build this on top of web messaging[1] by having a
browsing context associated with the search box (or entire browser
chrome) that can communicate with a SERP or any page that wants to
accept input from a search box or otherwise communicate directly with
a user agent?

[1] http://dev.w3.org/html5/postmsg/

On Mon, Mar 21, 2011 at 1:38 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, Mar 21, 2011 at 11:16 AM, Edward Lee <edilee@mozilla.com> wrote:
>>> enables "instant" style interaction between the user agent's search
>> Assuming the user agent automatically loads a url that is triggered by
>> a user key stroke, e.g., typing "g" results in
>> "http://www.google.com/", the instant-style interaction is almost
>> there already for certain urls. These instant-style urls would include
>> what the user typed -- perhaps as a query parameter.
>>
>> For example, a user agent might request these pages as the user types:
>> http://www.google.com/search?q=g
>> http://www.google.com/search?q=go
>> http://www.google.com/search?q=goo
>>
>> Here, the results page shows the new query and updated results on
>> every user keystroke.
>>
>> These instant-style urls can also avoid refetching and rerendering the
>> whole page if the user's input shows up in the #fragment and the page
>> detects onHashChange.
>
> That's true, but you can only transmit one event that way.  In this
> design, you've chosen to map the "change" event to hashchange.  How
> should the user agent communicate that the user is done typing (i.e.,
> the "submit" event, which triggers when presses the enter key)?
> Similarly, the communication in that approach is unidirectional, which
> means the page can't suggest search completions.
>
> Adam
>
>



-- 
Sean Eagan

Received on Monday, 28 March 2011 18:20:49 UTC