Re: [Page Visibility 2] Request for Comments

I similarly expect compat problems with changing rAF.

On Thu, Oct 30, 2014 at 8:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 10/30/14, 11:24 PM, Boris Zbarsky wrote:
>
>> I've already sent my thoughts on this to this list.  I suggest just
>> reading those mails if you want to know what I think...
>>
>
> But since, given my past interactions with this working group, I somewhat
> doubt people will do the work of looking it up, let me repeat one more time
> (more or less from http://lists.w3.org/Archives/Public/public-web-perf/
> 2014Jan/0040.html and following):
>
> 1)  This is a backwards-incompatible change (but see item 5 below).
> 2)  It's a change to behavior that's been shipping for a long time now;
> the last time this came up was nearly a year ago, and _then_ I was
> concerned about content depending on the behavior and suggested that if the
> working group actually wants to make the behavior change it better convince
> implementors to make it ASAP.  That clearly did not happen.
> 3)  This change is particularly incompatible because it has knock-on
> effects on a number of other specifications and APIs. requestAnimationFrame
> is not the only API affected.
> 4)  The behavior being suggested for requestAnimationFrame in the "Note"
> in the specification (I know, not normative), doesn't match any UA and I
> fully expect it's not web-compatible, and will assume so until proven
> otherwise.
> 5)  There are no MUST requirements that result in ever returning "hidden",
> so as far as I can tell all existing UAs are compliant with the new spec
> version.  Which raises the question of what the point of the change is,
> really.
>
> In term's of Mozilla's implementation, what I will probably be
> recommending internally is that we not change our behavior at all, since
> it's already spec-compliant and a known quantity in terms of web compat.
> If any other UAs do change behavior in some way, and we find out about it
> and think that the change is worth doing for some reason, we'll have to
> reverse-engineer what they're doing exactly, I guess; the spec is not
> particularly helpful here in terms of actually specifying behavior.
>
> -Boris
>
>