- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 31 Mar 2011 17:39:36 -0700
- To: Sean Eagan <seaneagan1@gmail.com>
- Cc: public-webapps@w3.org, Edward Lee <edilee@mozilla.com>
I'm not sure there's any particular coupling between the syntax of the API (IDL v. postMessage protocol) and how the API is implemented by the user agent. We could implement either syntax using either native or JavaScript code. For consistency with the rest of the platform, IDL seems like a better choice at the moment. Adam On Thu, Mar 31, 2011 at 7:39 AM, Sean Eagan <seaneagan1@gmail.com> wrote: > 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 Friday, 1 April 2011 00:40:47 UTC