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 why WebKit needs to be involved, since I would assume a browser would use a second-overlay WebView for the navigation preview. -eric On Fri, Oct 15, 2010 at 10:46 AM, Eric Seidel <e...@webkit.org> wrote: > 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 is outside that box, and thus belongs outside of > WebKit, correct? > > -eric > > On Fri, Oct 15, 2010 at 10:43 AM, Tony Gentilcore <to...@chromium.org> wrote: >> >> 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 >>> 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 <e...@webkit.org> wrote: >>>> >>>> >>>> http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html >>>> would be more compelling with a video. :) >> >> http://www.youtube.com/watch?v=tefRwthQaes shows an old version where the >> content didn't adjust to the dropdown size. You can play w/ it yourself on a >> windows dev channel build. >> >>>> >>>> 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 <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 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. >> >> Okie. It sounds like the answer to my first question is an implied "no." >> I'll keep in it Chrome for now. If this is ever something that other ports >> are interested in supporting, I'll still be happy to do the upstreaming >> work. >> >>>> >>>> > >>>> > -- 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 >>> >>> >>> _______________________________________________ >>> 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
