[webkit-dev] setTimeout as browser speed throttle
darin at apple.com
Tue Sep 30 13:58:50 PDT 2008
This debate is not new. We tried this in WebKit, when we first
We repeatedly encountered pages that behaved well in other browsers
and did not behave well in Safari, and the root problem was that they
had an effective minimum timer value.
It's arrogant to say that it's a website problem. Until the browser
has a large market share, almost all misbehaving sites are browser
problems, not website problems.
We saw similar issues with GIF frame timing before we got the minimums
right there too.
> This still implies there is a meaningful compatibility hit to making
> this change. I have not yet seen any reason to agree that is the
> case (in the sense of "CPU usage is not a web compatibility issue").
This is an incorrect straw man argument that you're putting forward
repeatedly and forcefully.
We started the Safari project with the naive view that there was no
need for a minimum timer value. Then we changed this in WebKit because
of sites that were misbehaving and real bug reports. The new value is
clearly close enough to the value in the top market share browsers
that these incompatibilities are effectively a thing of the past.
Unless we bring them back by removing that minimum again!
You keep stating that CPU usage isn't "a compatibility problem" and
that these concerns were not real. But that seems to be an unimportant
semantic distinction. We had to do this to get Safari to behave
properly with many real websites. I'm sorry that it's difficult to
quickly find examples now, but I trust there are still many sites out
there with this issue.
After the many years of the challenging task of fixing incompatible
websites one at a time, I'm loathe to undo a change that was made to
fix specific websites. Some of the value in the WebKit project is the
accumulated knowledge about what matters in practice for
compatibility. This is definitely one of those things.
More information about the webkit-dev