Further concerns with PageVisibility

I've already expressed in previous threads my concerns with PageVisibility:
1. confusions of the various conditions under which a window goes through 
visible (and partially visible) states in various OS's and devices

2. It lacks the "de-bouncing" inherently required to effectively work with 
it as a "throttling" trigger for various activities (meaning we'll have to 
manually author setTimeout type de-bouncing every time).

3. That this interface basically looks like a half-attempt at a PageIdle 
API, which would serve all use-cases of PageVisibility adequately, except 
for the "prerender" use-case (for Chrome only, currently). Implementing an 
API as a standard so that only one browser can experiment seems premature 
and unhealthy.

-----------------

However, I want to add to that discussion some more concerns I have, 
specifically with how PageVisibility will necessarily be used in the 
Chrome-prerendering (officially announced now) functionality:

1. How will PageVisibility affect (or not) certain functionality that 
"automatically" happens on a page, such as "autoplay" on a video element, or 
"autofocus" on a <input> box (and there are others which are not JavaScript 
based)? In those cases, it might be quite desirable to have them not happen 
until the page is actually rendered/visible (for the input autofocus, it 
might be an animation that occurs on the focus event, or it might be 
analytics gathering on the focus event, etc).

It's quite unclear how PV could/should interact or affect (delay?) such 
behaviors? Does even the question of such overlap between JavaScript and 
automatic markup-driven events open a pandora's box of potential 
complications?


2. It's obvious that PageVisibility was originally intended as a broader 
concern than just the prerendering, but it's also clear that the 
prerendering is (now) a major reason why it's being kept (despite my 
previous concerns), instead of my proposal to simplify to just the PageIdle 
approach (which doesn't address the prerendering use-case). Since the two 
are so closely related, I think it's fair to combine concerns of 
prerendering as a feature with concerns of PageVisibility itself as an 
approach.

Based on that, it should be pointed out (spelled out explicity in Chrome's 
blog post, btw) that my page could be forced into working not in the way I 
intended (that is, rendering before being visible) if any other author on 
the web lists my URL in their <link rel=prerender> tag, and then presents a 
link with that URL which a user follows. That user could end up on my page 
"too late", in that they miss out on important earlier rendering.

So, I as a web author am now forced into dealing with PageVisibility if I 
have anything on my pages which I really want my users to see when they 
first arrive. This is rather hostile to say the least.


3. It's fair to say that there's a lot of code on web pages that authors 
would like to have execute invisibly to the user (to prevent FUOC/FUBC and 
other undesirable UX, etc). So, on the surface, this prerender functionality 
seems quite useful.

But, there's also a non-trivial amount of code on the web that authors 
probably *want* the user to see, like visual effects/animations, etc. So 
authors will now have to segment out their code to what they "want" to 
happen invisibly during prerendering, and what they "want" to have happen 
visibly while the user is seeing the page. Existing pages which do not take 
this into account could, rather suddenly (as Chrome rolls out prerendering), 
start seeing less than desired behavior.

Which then leads to the question, how easy is it for a page to adjust to 
take PV/prerendering into account?

The nature of code on web pages today is that code already has to dance a 
somewhat less-than-ideal tango where it straddles on, between, or after 
DOMready and window.onload events. But the `visibilitychange` (VC) event 
will now introduce a third event to factor into this, which by its nature 
will complicate things significantly.

Since the VC event can come before, between, or after window.onload, it 
means that a more complicated "event gate" system must be employed, to make 
sure that your code runs at the proper time, and not too early. Consider 
this code (which only deals with DOMready and PV, ignoring onload for now):

function doThisWhenDOMIsReadyAndPageIsVisible() {
  // ...
}

(function(){
   var events_fired = {
            domready: document.readyState == "complete"
            visible: document.visibilityState == "visible"
        }
   ;

   function check_events() {
      if (events_fired["domready"] && events_fired["visible"]) {
         doThisWhenDOMIsReadyAndPageIsVisible();
      }
   }

   if (!events_fired["domready"]) {
      document.addEventListener("DOMContentLoaded", function() {
         events_fired["domready"] = true;
         check_events();
      }, false);
   }
   if (!events_fired["visible"]) {
      document.addEventListener("visibilitychange", function VC() {
         document.removeEventListener("visibilitychange", VC);
         events_fired["visible"] = true;
         check_events();
      }, false);
   }
   check_events();
})();

Add in code that needs to wait for window.onload, and this code gets even 
more messy. Nevertheless, that type of complicated event handling is, I 
think, a deal breaker in terms of me ever wanting to use such a feature.

For instance, we *could* have considered simply making the first "page is 
visible" event delay the window.onload, so that existing event handling 
wouldn't need nearly as much extra complexity. `window.onload` is already 
guaranteed to run after DOMContentLoaded, so the event-gating is unecessary. 
PV being able to run at any time means that it requires more sophisticated 
and brittle event handling logic. Considering code like the above, I think 
the onus is too much on web authors.

Bottom line: I'm quite un-thrilled that I may be "forced" into dealing with 
this complication (if there's indeed no effective "opt-out" to prevent a 
<link rel=prerender> on some other page I don't control from triggering 
pre-rendering of my pages).


--Kyle

Received on Wednesday, 15 June 2011 17:12:29 UTC