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 window.chrome.* by the way.) -Darin On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel <eric@webkit.org> wrote:
http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.htm... 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 <darin@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 browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes.
I suggest we put this feature in browsers, not the engine.
-- Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev