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 <[email protected]> wrote: > > 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 <[email protected]> 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 > > [email protected] > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
