- From: Sean Eagan <seaneagan1@gmail.com>
- Date: Mon, 28 Mar 2011 13:20:02 -0500
- To: Adam Barth <w3c@adambarth.com>, public-webapps@w3.org, Edward Lee <edilee@mozilla.com>
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