[whatwg] SearchBox API
tonyg at chromium.org
Fri Oct 15 09:17:55 PDT 2010
On Fri, Oct 15, 2010 at 9:08 AM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> On Thu, Oct 14, 2010 at 2:59 PM, Peter Kasting <pkasting at google.com>
> > This proposal is not by any means the totality of everything involved
> > "instant"-style support. It is only a piece.
> It's hard to evaluate a proposal that doesn't actually do anything by
> itself. I don't see any problems in principle with this approach, but
> it's impossible to say for sure without a full proposal. It could be
> that this approach forces problems in other parts of the design which
> aren't evident yet.
> On Thu, Oct 14, 2010 at 7:53 PM, Tony Gentilcore <tonyg at chromium.org>
> > This is a good point that wasn't in the initial API proposal. The page
> > needs to advertise support for instant. But the decision is more
> > complicated that simply "provider A supports it and provider B
> > doesn't." The Google SERP determines on a case-by-case basis whether
> > instant is supported. For instance, for users with a high RTT time, we
> > don't advertise instant support because it would be a bad experience.
> How does Chrome figure this out at present? Does it include hardcoded
> heuristics like checking the RTT to google.com itself? Does it
> optimistically assume that the feature should be used, so fetch the
> page, then discard it if the page somehow says not to use it?
> Something else?
The app has the heuristics. The UA fetches the page and discards it if the
page doesn't indicate support. As pointed out this is suboptimal. Perhaps we
need a two phase indication of support. First OpenSearch indicates that the
page might support it, then the page itself has a chance to deny support on
a per-request basis.
> > Yes, the API requires a bit of imagination at this point. I'll write
> > up conformance requirements in more detail, but thought it worthwhile
> > to get high level feedback and gauge interest first.
> Feedback from other search vendors would be particularly essential
> before this becomes standardized, I'd think. Possibly other search
> engines would have somewhat different takes that would require a
> different API.
Agreed. That is exactly what I'm trying to elicit.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg