Thank you. †This is helpful feedback.<div><br></div><div>-Darin</div><div><br><br><div class="gmail_quote">On Fri, Oct 15, 2010 at 11:27 AM, Darin Adler <span dir="ltr">&lt;<a href="mailto:darin@apple.com">darin@apple.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>

<br>
Reasons for putting things into WebKit include things that have complicated interactions with other aspects of web technology, or are difficult to implement correctly and thus itís good to share them among multiple WebKit clients.<br>

<br>
Thereís no principle that would forbid starting to put technologies in WebKit to help implement features like APIs to control the search field or even other search field related features such as Safariís search field snap back feature. On the other hand, just because API is exposed to websites does not on its own justify putting the API into the engine.<br>

<br>
I still stand my my original objectionóthis API should not go in WebKit at this timeóbut itís not a simple black and white case of what can and canít be in WebKit.<br>
<div><div></div><div class="h5"><br>
 † †-- Darin<br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></blockquote></div><br></div>