Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-12 Thread Maciej Stachowiak
I agree with this position as well. It seems good to have a transition period and to gather some data. - Maciej On Oct 11, 2012, at 9:59 PM, Darin Fisher da...@chromium.org wrote: I agree with what Adam wrote in https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites

Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-12 Thread Dean Jackson
Me too. Please don't just remove the prefix - we need a period of time where we support both prefixed and unprefixed. Dean On 12/10/2012, at 6:58 PM, Maciej Stachowiak m...@apple.com wrote: I agree with this position as well. It seems good to have a transition period and to gather some

[webkit-dev] Unprefixing requestAnimationFrame

2012-10-11 Thread James Simonsen
I've posted a patch to remove the webkit prefix from requestAnimationFrame. [1] The question is whether or not to continue to support the prefixed version. I propose dropping it for the following reasons: 1. We're changing the callback semantics to match the spec. [2] 2. IE10 is shipping with

Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-11 Thread Paul Irish
From early on, requestAnimationFrame articles and documentation recommended shims/polyfills alongside the prose. Because of this nearly every script library using rAF detects all prefixes and the unprefixed standard version. More than nearly any other prefixed API I can think of, shipping

Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-11 Thread Darin Fisher
I agree with what Adam wrote in https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites will magically failover to the unprefixed API, we can't know for sure that this change won't break sites. We need to give them a chance to update. (I don't know if one Chrome release cycle