Re: Page Visibility Simplifications

> 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?

------

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.

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

Received on Tuesday, 21 June 2011 19:42:09 UTC