Re: SearchBox API

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
>

Received on Monday, 28 March 2011 19:00:22 UTC