Re: [PageVisibility] Page Visibility 2 - Patent disclosure update?

Hi Philippe,

Thank's for the fast reply.

You are correct. This is in relation to optimizing and exposing
optimizations through javascript. My recommendation is to extend the
functionality of the current Page Visibility API to allow optimizing
content not visible in the active area of the viewport. As defined in the
Page Visibility 2 Editor's Draft, this would include iframes separate from
the parent document, content hidden by CSS manipulation (display:none,
opacity:0, visibility hidden, width/height:0), minimization of the window,
backgrounding, screen savers, but could also include browser windows hidden
from display, or obscured by other windows (ex: Apple's App Nap or botnets
running browser shells of webkit/Trident/Chromium purposely hidden from
view). Currently, this relates to how the browser is optimizing content,
but this could be amended to simply broadcast if it were out of view, and
capable of being passively ignored or actively utilized.

This ability is currently only available via obscure techniques involving
security exploits, non-uniform plugin behavior, and direct execution of
remote scripts in cross domain content, something routinely frowned upon
because of privacy concerns. All known scenarios involve significant
challenges on the part of developers to discover and implement tactics.
Techniques are complex and come with excess execution costs associated with
detection. For instance, spooling up multiple flash documents which all
measure FPS, local connection speeds, or which try to capture throttle
events, in many cases where unsupported.

An extended native browser API would absolutely improve every user's
experience. These techniques are typically used today in advertisements
where no recommended approach is available, leaving each advertising
company to roll their own closely guarded secret sauce recipe. The drive
toward this goal has picked up significant momentum this year as the Media
Rating Council has given the green light to advertisers to use these
techniques to improve their ad campaign performance as explained here on
http://mediaratingcouncil.org/ and here on http://www.spider.io/viewability/
while security concerns have been publicly voiced here
http://www.spider.io/blog/2012/12/internet-explorer-data-leakage/

Google, Microsoft, and Apple, all being advertisers themselves, should show
no reluctance to pushing development forward on something that improves
both their web browser performance and advertising platforms. Mozilla
already exposes this behavior through non-standard APIs, but these may be
removed at any point in the future, and are far from optimal ways of
measurement. This is especially valuable to mobile browser users, where
resources are scarce, and traditional user agent sniffing cannot be relied
upon for their detection on the server side. All major mobile browsers can
and do masquerade as desktop browsers resulting in advertisers routinely
attempting complicated measurement strategies on mobile devices, naively
degrading page performance.

Thanks to the great prior work of this work group, all web developers are
now able to benefit from tapping into the current Page Visibility API where
supported, and system performance as a whole has improved. The same is true
for requestAnimationFrame where it throttles the demand of applications
animating content when they are in a background tab. To ignore the obvious
and real need for a performant and standard API which can replace costly
and controversial tactics currently served up as often as jQuery seems like
a step backward from the direction the web is currently moving. Additional
uses are lazy loading content, improving web component responsiveness, and
allowing better development and debugging tools like the ones in chrome,
firefox, and flash which expose redraw areas for reducing costly reflows.

Additionally, I've been attempting to improve standard behaviors by testing
contexts where throttling does occur and how it is implemented in each
browser as can be seen in my discussions with the IE team here:

https://twitter.com/jeffreytgilbert/status/494919758597595136

https://twitter.com/jeffreytgilbert/status/509076949038137344


Jeffrey Gilbert
http://www.linkedin.com/in/jeffreygilbert

On Mon, Sep 22, 2014 at 7:54 PM, Philippe Le Hegaret <plh@w3.org> wrote:

> On Mon, 2014-09-22 at 18:20 -0500, Jeffrey Gilbert wrote:
> > The last update to this document was Novermber 27th, 2013. After almost a
> > year of quiet, I'm wondering if there has been any movement on gathering
> > the patent disclosure requested in the document, or if this was ever
> > revisted. The last line of the current document linked here (
> >
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility2/Overview.html
> > )
> > reads:
> >
> > "This document was produced by a group operating under the 5 February
> 2004
> > W3C Patent Policy. W3C maintains a public list of any patent disclosures
> > made in connection with the deliverables of the group; that page also
> > includes instructions for disclosing a patent. An individual who has
> actual
> > knowledge of a patent which the individual believes contains Essential
> > Claim(s) must disclose the information in accordance with section 6 of
> the
> > W3C Patent Policy."
> >
> > This technology is fundamental to improving web application performance,
> as
> > has been the case with similar technologies (requestAnimationFrame,
> > PageVisibility 1, timer throttling, connection throttling, defer/async,
> > lazy loading, etc). I would like to see it moved forward if it's
> currently
> > collecting dust.
>
> Which part of PV2 do you exactly need asap? Page Visibility 2 contains
> substantial clarification over Page Visibility 1. It is related to
> iframe,the CSS properties display/opacity. If I remember correctly, last
> time we talked about this topic, it wasn't clear at the end whether we
> could even make the change. See the thread at [1].
>
> Philippe
>
> [1]
> http://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0040.html
>
>