Summary 

The HTML5 spec contains the following section

"6.2 Timers
Note: This API does not guarantee that timers will fire exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected.
... 
The setTimeout() method must run the following steps:
... 
5. If the currently running task is a task that was created by the setTimeout() method, and timeout is less than 4, then increase timeout to 4.
... 
The setInterval() method must run the following steps:
... 
	5. If timeout is less than 10, then increase timeout to 10."

We propose removing the exact timeout values from the spec for the following reasons:
1. Many architectures and computing platforms are unlikely to support these timeout values.
2. The provided timeout values can have a very negative impact on power consumption and battery life
3. Every major released and pre-release browser implements different setTimeout and setInterval behavior and don't adhere to the timeout values provided


Rationale

Even though the spec clearly states that timers aren't guaranteed to fire exactly on schedule, the spec does set the expectation for web developers that a setTimeout of 4ms can be expected to work and only occasionally not fire precisely at the given timeout. 

Many mobile architecture and platforms are aggressive with regards to power consumption and battery life times. Consequently, they do not allow callbacks with timeouts of 4ms or even 10ms. 

The impact on battery life time can be significant: 

Energy Smart Software[1] page 6:
"The default Windows 7 timer resolution is 15.6 milliseconds (ms), which allows the processor to make effective use of C-states when the system is not heavily loaded. The highest timer resolution available on most modern systems is 1ms. Setting the timer resolution to 1ms on a modern system can increase power consumption by 15 percent. For a typical client scenario of a modern laptop that is being used to browse the web and to do light processing, setting the timer to 1 ms could reduce battery run time by more than an hour."

Furthermore, frequent periodic executions are detrimental to power consumption since it prevents processors and surrounding components from entering power conservation states and the overhead of entering and exiting power states frequently negates any power savings. It is more optimal to execute a burst of computation followed by a long idle time during which cores and other chipset components can be turned off:

CPU Power Utilization on Intel Architectures [2]:
"Every interrupt will pull back the CPU from a deeper sleep state to C0 due to the interrupt handler that services the interrupts. This impacts the sleep state residencies that are critical to optimize the power consumed. There is also an energy cost associated in transitioning between multiple C-states. If the interrupt rates are high, the power savings due to deeper sleep states are negatively impacted due to the decrease in sleep state residencies and the cost associated with C-state transitions. While Intel® platforms offer platform-specific C3-like states, they require long residency (multiple milliseconds) to fully amortize their transitional costs. An aggressive interrupt rate can potentially negate the benefits of deep sleep states offered by the platform."


Details

The bullet 5 in the setTimeout part of section "6.2 Timers" should be changed to:

5. If the currently running task is a task that was created by the setTimeout() method, and timeout is less than a user-agent-defined value, then increase timeout to the user-agent-defined value.
	
As well as the bullet 5 in the setInterval part of the same section should be changed to:

5. If timeout is less than a user-agent-defined value, then increase timeout to the user-agent-defined value.


Impact

Positive Impact
* Not prescribing specific timeout values avoid setting expectations with web developers that certain timeouts can be achieved on all architectures and platforms
* Removing the prescribed timeouts allows browser vendors to create implementations that are power conscious, conserve battery lifetime and reduce power consumption ultimately impacting world energy consumption
* Allows browser vendors to implement HTML5 conforming browsers on platforms that cannot meet the currently prescribed values as well as meet power restrictions.

Negative Impact
* Implementation will not converge on implementation, but that is unlikely to happen due to different architecture constraints

Risks

Considering that more major browsers do not adhere to the currently prescribes timeout values, removing the values entirely from the spec should not impact existing web pages. 


References

[1] Energy Smart Software (June 16, 2010) 
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/Energy-Smart_SW.mspx 

[2] CPU Power Utilization on Intel Architectures
http://software.intel.com/en-us/articles/cpu-power-utilization-on-intel-architectures/