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. [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
Re: SearchBox API
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
Re: SearchBox API
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. Ed
Re: SearchBox API
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
Re: SearchBox API
On 03/20/2011 01:36 AM, Tony Gentilcore wrote: Hi all, Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. When I tried instant search on Chrome, it did something only when I was typing an url. It preloaded possibly right url before I pressed enter. It didn't seem to utilize the coordinate information of SearchBox API at all. (Perhaps I wasn't testing it correctly) A browser could certainly preload pages similarly even without the API. So, why does the search page need any data? Couldn't browser interact with the web search in the background and show (and possibly preload) results the way it wants to. That way there wouldn't be an API which fits in to only one kind of UI. I think I'm missing some of the reasoning for the API. Could you perhaps clarify why Google ended up with such API? Also, would be great to see some examples where all of features of the API are being used. -Olli Since then it has been implemented by Google web search and Chrome. You can demo it by checking Enable Instant for faster searching and browsing in Chrome's preferences. Some suggested this list might be a better place to poll for interest and discuss the API. Are there any user agents or search providers who are interested in working to standardize this interface[2]? Any feedback is welcome as well. -Tony [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-October/028818.html [2] http://dev.chromium.org/searchbox
Re: SearchBox API
[Re-sending to the correct list.] On Sun, Mar 20, 2011 at 2:34 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 03/20/2011 01:36 AM, Tony Gentilcore wrote: Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. When I tried instant search on Chrome, it did something only when I was typing an url. It preloaded possibly right url before I pressed enter. It didn't seem to utilize the coordinate information of SearchBox API at all. (Perhaps I wasn't testing it correctly) A browser could certainly preload pages similarly even without the API. The instant search feature has a bunch of different components. One aspect is URL preloading, which happens when the browser thinks you're typing something navigational (like a URL) into the omnibox and is not related to the SearchBox API. Another aspect is what happens when the browser thinks you're tying something search-like (like potato) into the omnibox. In that case, the browser displays a search engine results page. So, why does the search page need any data? The SearchBox API has a two-way flow of information between the search engine results page (SERP) and the browser's search field. (In Chrome's case, that's the omnibox, but it would work just as sensibly for browsers with a dedicated search box.) Essentially, the browser tells the SERP various information about what the user has typed in the search field (much like the web site would learn if the user typed into a text input field in the web site) and the SERP tells the browser some suggested completions for what the user has typed so far (e.g., so the browser can display those suggestions to the user). Additionally, the browser can tell the SERP about the geometry of the search field (if it overlaps the SERP), which lets the SERP move its UI out from underneath the search field, if desired. Couldn't browser interact with the web search in the background and show (and possibly preload) results the way it wants to. That way there wouldn't be an API which fits in to only one kind of UI. I wasn't involved in the design, but I suspect there are latency and synchronization challenges with that approach. Most modern browsers use that approach for showing search suggestions in their search fields today, but with this UI, it's important to synchronize the browser's search field with the SERP. Using JavaScript events to communicate removes some of the network latency. I think I'm missing some of the reasoning for the API. Could you perhaps clarify why Google ended up with such API? As a general principle, Chrome shouldn't have an special integrations with google.com. For example, bing.com should be able to use any Chrome feature, and other browsers, such as Safari and Firefox, should be able to use any google.com feature. Now, the project doesn't always live up to that principle, but that's the reasoning behind implementing and specifying a general-purpose API. Also, would be great to see some examples where all of features of the API are being used. My understanding is that Google's SERP uses all the features of the API. Tony designed the API in coordination with the folks who work on Google's SERP. For example, if you enable the instant feature in Chrome and type potato in the omnibox, you should see similar search suggestions in the autocomplete dropdown as you'd see if you typed potato into the google.com search box (assuming you have Google set as your default search provider). Similarly, if you type a character, the SERP should react immediately to the change event instead of waiting for network latency. Finally, you'll notice that the autocomplete dropdown does not overlap with the search results because of the geometry information provided by the SearchBox API. Adam
Re: [public-webapps] SearchBox API
On Sun, Mar 20, 2011 at 5:26 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 03/21/2011 01:23 AM, Adam Barth wrote: On Sun, Mar 20, 2011 at 2:34 PM, Olli Pettayolli.pet...@helsinki.fi wrote: On 03/20/2011 01:36 AM, Tony Gentilcore wrote: Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. When I tried instant search on Chrome, it did something only when I was typing an url. It preloaded possibly right url before I pressed enter. It didn't seem to utilize the coordinate information of SearchBox API at all. (Perhaps I wasn't testing it correctly) A browser could certainly preload pages similarly even without the API. The instant search feature has a bunch of different components. One aspect is URL preloading, which happens when the browser thinks you're typing something navigational (like a URL) into the omnibox and is not related to the SearchBox API. Another aspect is what happens when the browser thinks you're tying something search-like (like potato) into the omnibox. In that case, the browser displays a search engine results page. So, why does the search page need any data? The SearchBox API has a two-way flow of information between the search engine results page (SERP) and the browser's search field. (In Chrome's case, that's the omnibox, but it would work just as sensibly for browsers with a dedicated search box.) Essentially, the browser tells the SERP various information about what the user has typed in the search field (much like the web site would learn if the user typed into a text input field in the web site) and the SERP tells the browser some suggested completions for what the user has typed so far (e.g., so the browser can display those suggestions to the user). Additionally, the browser can tell the SERP about the geometry of the search field (if it overlaps the SERP), which lets the SERP move its UI out from underneath the search field, if desired. Couldn't browser interact with the web search in the background and show (and possibly preload) results the way it wants to. That way there wouldn't be an API which fits in to only one kind of UI. I wasn't involved in the design, but I suspect there are latency and synchronization challenges with that approach. Most modern browsers use that approach for showing search suggestions in their search fields today, but with this UI, it's important to synchronize the browser's search field with the SERP. Using JavaScript events to communicate removes some of the network latency. One of the problems with this API I have is that either browser implements the UI the API expects (rectangular dropdown list) or just doesn't support the API. AFAIK, every user agent occludes the content area with a rectangular (or roughly rectangular) region as part of the search field interaction. If you've got examples of non-rectangular occlusion, I suspect Tony would be willing to update the API to support other geometries. Of course, you could implement the API to always report no occlusion and still make use of the other features. I think I'm missing some of the reasoning for the API. Could you perhaps clarify why Google ended up with such API? As a general principle, Chrome shouldn't have an special integrations with google.com. For example, bing.com should be able to use any Chrome feature, and other browsers, such as Safari and Firefox, should be able to use any google.com feature. Now, the project doesn't always live up to that principle, but that's the reasoning behind implementing and specifying a general-purpose API. Sure, but that isn't still the reasoning for the API design. (Btw, I sure hope the API is still somehow prefixed.) Perhaps I misunderstood your question. As described on http://dev.chromium.org/searchbox, the API is exposed on the window.chrome object, but likely a better long-term place for the API is on window.navigator. So, yes, it is currently vendor-prefixed. Also, would be great to see some examples where all of features of the API are being used. My understanding is that Google's SERP uses all the features of the API. Tony designed the API in coordination with the folks who work on Google's SERP. For example, if you enable the instant feature in Chrome and type potato in the omnibox, you should see similar search suggestions in the autocomplete dropdown as you'd see if you typed potato into the google.com search box (assuming you have Google set as your default search provider). The only difference I can see when enabling instant search in Chrome and typing potato is that the current web page gets dimmed somehow. The web page is not updated in any way (it doesn't matter if the current web page is the default search or some other page). The dropdown list under omnibox contains exactly the same entries
SearchBox API
Hi all, Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. Since then it has been implemented by Google web search and Chrome. You can demo it by checking Enable Instant for faster searching and browsing in Chrome's preferences. Some suggested this list might be a better place to poll for interest and discuss the API. Are there any user agents or search providers who are interested in working to standardize this interface[2]? Any feedback is welcome as well. -Tony [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-October/028818.html [2] http://dev.chromium.org/searchbox
