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 <w...@adambarth.com> wrote: > On Mon, Mar 21, 2011 at 11:16 AM, Edward Lee <edi...@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