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 w...@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 seaneag...@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 w...@adambarth.com wrote:
On Mon, Mar 21, 2011 at 11:16 AM, Edward Lee edi...@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
