Re: SearchBox API

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.


On Mon, Mar 28, 2011 at 1:59 PM, Adam Barth <> 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 <> 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]
>> On Mon, Mar 21, 2011 at 1:38 PM, Adam Barth <> wrote:
>>> On Mon, Mar 21, 2011 at 11:16 AM, Edward Lee <> 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
>>>> "", 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:
>>>> 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