- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 15 Oct 2010 12:08:08 -0400
On Thu, Oct 14, 2010 at 2:59 PM, Peter Kasting <pkasting at google.com> wrote: > This proposal is not by any means the totality of everything involved with > "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> wrote: > 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? > 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.
Received on Friday, 15 October 2010 09:08:08 UTC