- From: Kyle Simpson <getify@gmail.com>
- Date: Wed, 15 Jun 2011 11:06:10 -0500
- To: "Alex Russell" <slightlyoff@google.com>, "Paul Bakaus" <pbakaus@zynga.com>
- Cc: <public-web-perf@w3.org>
I do think it's important to note in this conversation that the temptation
is usually to put such requests into absolute buckets ("will always work
exactly", "will never be (fully) accurate/reliable"). Those who are arguing
against such stats are (correctly) pointing out that such stats are likely
to always be somewhat fuzzy and implementation dependent (and thus belong in
the "unreliable" bucket, in the strict sense of the term). But that's
perhaps an unfair black-or-white type of argument.
I think it would be a fair characterization of Andrew's points in his TXJS
talk that such stats would simply be useful *additional* data (in addition,
say, feature tests) for libraries to try and make best guesses. The question
is not really "can I get a perfect reliable guarantee of hardware
acceleration?", it's instead "can I get a better hint than simply UA
whitelisting that hardware acceleration is helpful or not for my intended
CSS animations?" So, there needs to be at least a third bucket in the middle
like "will (possibly) be informative but not contractually guaranteed".
For instance, being able to monitor the average framerate of animations over
the lifetime of a page might allow an animation library to adjust its
approach as conditions vary (maybe higher CPU utilization at some point
means the framerate goes down, so the library adjusts its method during that
time, etc).
>From the difficulties that Andrew has expressed during his development of
Scripty2, I get the impression that replacing JS animations with CSS
animation equivalents is quite hairy, and the majority of the open web would
probably look at it as nearer to "rocket science" in terms of difficulty of
managing all the various factors. Of course, as a library author, a common
goal is to try and simplify and smoothe out a lot of such messes so
end-users can more effectively take advantage of it. So, if a library can
keep the user from having to worry about such details, this helps both the
user and the library do their jobs more effectively.
I think such stats would assist such a library in making better guesses as
to the best approach for a requested animation.
Andrew said in his talk that he essentially gave up on the proposition of
the animations being perfect in all situations, and is instead going for
good-enough or best-attempt. This is most often the case in general web dev
and certainly in library authoring, and that's exactly what these types of
stats would go to: best-attempt guesses.
--Kyle
Received on Wednesday, 15 June 2011 16:06:57 UTC