[webkit-dev] SearchBox API

[Eric Seidel]

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 <eric at 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 <tonyg at chromium.org> wrote:
>>
>> On Fri, Oct 15, 2010 at 10:28 AM, Darin Fisher <darin at 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 <eric at 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 <darin at 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 at lists.webkit.org
>>>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>> >
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>>
>