On Sun, Mar 20, 2011 at 3:26 PM, Darin Adler da...@apple.com wrote:
On Mar 19, 2011, at 10:10 AM, Adam Barth wrote:
Sorry to resurrect this old thread, but what are the DOM APIs in Safari that
are accessible only to search providers?
Two functions on the window object, getSearchEngine and setSearchEngine. They
take and return strings that are the names of supported search engines. The
designs are a bit primitive in part because this is an old API that dates
back to the first iPhone.
Thanks. It makes sense to me that those functions are implemented by
the embedder and not by the engine itself because they're essentially
APIs for interacting with the user's preferences.
Experimenting with those APIs in the inspector, they have some of the
same properties that make me sad about the SearchBox API. For
example:
window.getSearchEngine.toString()
[object CallbackObject]
whereas,
window.postMessage.toString()
function postMessage() {
[native code]
}
In particular, these injected objects don't behave the same way as
built-in objects do. That means we're making visible to the web
platform the internal organizational structure of the folks who
implemented the platform.
For getSeachEngine / setSearchEngine, the differences appear
superficial. However, the situation with the SearchBox API is worse,
in a sense, because the SearchBox API is naturally expressed in terms
of DOM events. For example, when the user changes the contents of
search field, the SearchBox object receives a change event and when
the user submits a search query, the SearchBox object receives a
submit event, etc. When implemented by the embedder, the SearchBox
API can't really make use of all the event-related machinery in
WebCore. As an example, SearchBox isn't an EventTarget, as
implemented, and has fake events that don't behave like real events
(e.g., window.event doesn't have the proper behavior).
Maybe it's not worth fixing, but it bugs me that the API is contorted
because of the organizational structure of the project. For example,
if Mozilla had implemented a similar API in Firefox, I'm sure it would
have just used normal DOM events that behave like all the other events
in the platform. To me the cost of exposing a contorted API to the
web seems greater than the cost of implementing the API in WebCore
behind an ENABLE ifdef.
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
