Re: Page Visibility Simplifications

Hi Kyle,

Looks like I sent my earlier e-mail on this thread mere seconds after you
sent yours.  I'm in agreement with your general argument in the earlier
message.

On Tue, Jun 21, 2011 at 12:40 PM, Kyle Simpson <getify@gmail.com> wrote:

> Although the majority of cases don't require precise knowledge of why the
>> page is hidden, there are some that do.  As a particular example, removing
>> the state would make it impossible to factor out prerendering from
>> client-side impression counts.  Many advertising and analytics packages
>> today define a page view or impression as when the page loads, irrespective
>> of if the document is focused or not.
>>
>
> Do analytics packages really do this on purpose? Or is it just that prior
> to now, there was no (reliable) way to know if a page was only ever in a
> background tab and never actually viewed?
>
> I can't understand why it would be desirable to lump "loaded but never
> actually viewed or interacted with" events in with "loaded and viewed at
> least once" events. It would seem like advertising and analytics packages
> are misleading their customers (unintentionally of course) by reporting
> background-tab-renders as impressions, when in fact there was no actual
> impression.
>
> So wouldn't it make much more sense to lump together both "prerendered" and
> "rendered only in the background and never seen" as illegitimate page-views,
> thereby leaving page-view counting only to actually legitimately *seen* web
> pages? Wouldn't we be doing advertising/analytics *and* end-users a favor by
> making this type of reporting more explicitly accurate?
>

I'm not directly involved in analytics or advertising, I'm just representing
what I've come to understand from prior experience.  I'm also not defending
the status quo (or, rather, my limited understanding of it) -- I think the
page visibility API actually does allow these types of folks to come up with
better metrics in the long run. I was merely trying to point out that
without a way to distinguish prerenders, it wouldn't be possible for web
sites to have the same semantics that they might want today.  So long as
there is some way--with a vendor-specific prefix or not--for a site to
detect that it's being prerendered, then this shouldn't be an issue.

>
> ------
>
> Also, since prerendered currently is only a experimental feature in an
> experimental branch of one browser, your argument seems to assume that we
> need to include this data because we're sure that prerendering is going to
> catch on and be a non-trivial reality on the web. This I think is far from
> an obvious assumption.
>
> If "prerendering" sticks around for awhile, or if other browsers pick up on
> it, I think *then* it'd be an argument for why a spec needs to define that
> "prerendered" value. And that would be at least a decent support for my
> previous message's assertion that we should keep the `visibilityState`
> variable, with only the two values for now. But defining in an official spec
> now something that only chrome is experimenting with is premature and
> tail-wagging-the-dog, I think.



> If Chrome wants to, in conjunction with their "prerendering", define a
> vendor-prefixed state value like "-chrome-prerendered", then I think they
> should be able to just fine. And if advertisers and analytics packages want
> to special case their page-view counting for such a vendor-specific
> behavior, they also should be allowed to.


I strongly agree with you in this and the earlier e-mail that keeping the
visibilityState as a mechanism for experimental vendor-specific return
values makes sense.

I personally think--and this is where we diverge--that it makes sense to
include "prerender" and "preview" in the spec already given that there are
already browsers that implement those features and the spec clearly denotes
them as optional. My personal tendency is that, given we already know of
specific use cases for additional return values, we may as well formalize
the semantics. That avoids page authors having to update their scripts again
when or if "prerender" or "preview" are formally added in the
future. However, ultimately as long as visibilityState remains a part of the
spec (providing a mechanism for vendor-specific return values for
experimental features like prerender) then I think the necessary use cases
will be satisfied.



> But if we insist on keeping the "prerendered" value *now* as an official
> spec'd value, it points back to my assertions in last week's communications,
> that there is in fact a non-trivial dependency between "prerendering" and
> "PageVisibility" -- an assertion which was strongly denied in last week's
> communications. The two are either strongly related (co-requisite), or
> they're separate and not co-requisite. We have to pick one, it can't be both
> answers at once.
>
>
>
> --Kyle
>
>
>