- From: Sean Eagan <seaneagan1@gmail.com>
- Date: Thu, 31 Mar 2011 09:39:16 -0500
- To: Adam Barth <w3c@adambarth.com>, public-webapps@w3.org, Edward Lee <edilee@mozilla.com>
The reason I suggested web messaging is that more and more browser UI is being built on top of the web platform with things like chromeless [1] and chrome's WebUI [2], and this will likely include search boxes at some point. This would give the search box a natural endpoint browsing context for web messaging based communication with web apps. Now that I think about it, few if any changes would be needed to the Search Box specification to support this, as the SearchBox interface could be implemented as a javascript library that uses web messaging behind the scenes. The only way to observe the difference between this and a host object implementation would be by overriding window.postMessage which doesn't seem to be a problem. My main observation would be that javascript implementations using web messaging should be considered as potential alternatives to host objects in specifications involving communication between browser UI and web apps. [1] https://mozillalabs.com/chromeless/ [2] http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/webui/ On Mon, Mar 28, 2011 at 1:59 PM, Adam Barth <w3c@adambarth.com> wrote: > Sure, that syntax would work, but we'd still need to specify the > postMessage protocol, just like we need to specify the IDL interface. > It's not clear what moving to postMessage would buy us. > > Adam > > > On Mon, Mar 28, 2011 at 11:20 AM, Sean Eagan <seaneagan1@gmail.com> wrote: >> 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 >> > -- Sean Eagan
Received on Thursday, 31 March 2011 14:39:49 UTC