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
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
On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote:
On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote:
In any case, are there objections to beginning to land this under flag guard
and vendor prefix?
Yes, I do have an objection.
Browser-specific API can be injected by the
Sorry to resurrect this old thread
I presume you resurrected for other reasons, but I'll take the
opportunity to give a brief update. The API is now implemented as a V8
extension in Chromium and documented here:
http://dev.chromium.org/searchbox
___
Hi All,
We are working on adding instant search integration to Chrome. This requires
a DOM API which only the default search provider has permission to
access. As some of you may have seen, earlier this week I sent a proposal
for such an API to the WHATWG [1].
Is this something that other ports
On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote:
In any case, are there objections to beginning to land this under flag guard
and vendor prefix?
Yes, I do have an objection.
Browser-specific API can be injected by the browser and doesn’t need to be
built into WebKit. Safari already has
http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html
would be more compelling with a video. :)
I agree with Darin, this sounds like Browser-exposed DOM API. Not
something that WebKit has any business adding.
-eric
On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler
I think we're just coming at this from the point of view of trying to avoid
UA-specific APIs exposed to web content. It seems risky to build APIs
outside of WebKit that may be adopted by other UAs. We can certainly
revisit this if that ever becomes reality.
(Our current implementation exists on
On Fri, Oct 15, 2010 at 10:28 AM, Darin Fisher da...@chromium.org wrote:
I think we're just coming at this from the point of view of trying to avoid
UA-specific APIs exposed to web content. It seems risky to build APIs
outside of WebKit that may be adopted by other UAs. We can certainly
Please correct me if I'm wrong, but I can't think of any features
WebKit exposes which touch things outside of the WebView (the renderer
view in Chrome). I guess window location and size? Maybe history?
In general WebKit's job is limited to the box in which the web page is
drawn. This feature
I guess this particular feature may follow similar logic to the
find-in-page support in WebKit. Although I think the browser still
does most of the heavy-lifting for find-in-page.
http://www.youtube.com/watch?v=tefRwthQaes seems to suggest this is
entirely a browser feature. I'm not even sure
That's not really true. The whole network stack doesn't have anything
to do with the box in which the web page is drawn. Neither do things
like localStorage, but they all have DOM APIs.
Adam
On Fri, Oct 15, 2010 at 10:46 AM, Eric Seidel e...@webkit.org wrote:
Please correct me if I'm wrong,
There’s no simple recipe to tell us what to build into WebKit and what goes
into client applications. Explicit support for search fields and API directly
related to the configuration of browser search has been left out of WebKit up
until this point.
Reasons for putting things into WebKit
13 matches
Mail list logo
