requestTransaction() and requestAnimationFrame

Dear all,
    the requestAnimationFrame proposal looks good and work already good
where implemented.

However, the implementation is slightly inconsistent with setTimeout and
setInterval, no extra arguments can be passed in order to promote recycled
functions instead of requiring nested scoped callbacks (most of the time).

I understand it's late for such change, since the draft has been widely
early adopted but it was worth mention such possible improvement.

On the other hand, requestAnimationFrame does not solve multiple DOM
changes at once, it simply lets the UA handle in a better way all
operations but it does not tell the UA that those operations should be
performed only at the end of the callback.

Here a proposal/idea of a `requestTransaction()` callback able to put the
UA in a "read only" state that won't involve repaint or reflows until the
callback has been completed (simply reactivated through the event loop).

In order to better explain the logic, here an example.

```javascript

requestTransaction(function () {
  // the UA can read all properties
  // without triggering reflows or repaints
  // following some generic operation
  var position = document.body.scrollTop +
                 document.querySelector('nav').offsetHeight;
  // should not trigger repaints or reflows
  document.body.removeChild(document.body.firstChild);
  // should not trigger repaints or reflows
  document.body.appendChild(
    document.createElement('div')
  ).style.height = position + 'px';
  // should not trigger repaints or reflows
  document.body.scrollTop = position;

  // end of the callback
  // next event loop will do
  // all repaints and reflows at once

  // as example ...
  setTimeout(function(){
    // being executed in the next loop
    // DOM will be already repainted/reflowed
  });

  // requestAnimationFrame at the end
  // would work just fine too
  // instead of using timers

});

```

This approach gives the ability to modify the surrounding DOM environment
at once without compromising the user interaction, causing unnecessary
flicks, repainting and reflowing many times for no reason, as it is today
when many mutations are performed at once but there's no way to ask the
browser to not perform repaint/reflow until everything has been completed.

I have already proposed this in another W3C mailing list but it was not
probably the most appropriate one and I've received many interesting
comments privately and some +1 across web developers.

I'd really appreciate thoughts, hints, or any consideration on this that
will never be able to speed up that much Android 2.3 phones, but could make
highly dynamic web apps/page react better without draining the battery or
wasting CPU cycles.

Thanks a lot for your attention and Best Regards,
    Andrea Giammarchi