W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: SearchBox API

From: Sean Eagan <seaneagan1@gmail.com>
Date: Thu, 31 Mar 2011 09:39:16 -0500
Message-ID: <AANLkTinW6VpC2ovZ9Waj84pxY6xiVZhC=G50hhqUG+7w@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT