How about a global `requestTransition(callback)` mechanism ?

Something pointless to discuss on Twitter as I am doing right now :-)

I wonder if I am the only one that would like to have the possibility to
avoid any visual rendering on the screen during multiple DOM actions such
adding classes to different nodes, change the scrollTop after dropping an
element that is not even visible on the screen but up there in the body
content or who know what else.

It's not the first time I find myself in a situation where
requestAnimationFrame is badly/hopefully used only to speed up the amount
of flicks I could have with multiple changes at once and specially in the
mobile world (on desktop things are fast enough I cannot notice).

I understand that browsers should optimize already multiple operations at
once but these are inevitably in troubles doing this implicitly when it
comes to access classes, add more that could change layout for everything
else around, etcetera, etcetera.

How much effort would be to be able to explicitly inform the browser that
many DOM operations will be performed at once and that all computation
(reflow, repaint) should be avoided until the callback has finished its
execution ?

Similar, but actually simpler, mechanism we have for
`requestAnimationFrame` except this one will take care of "transitions" (or
the equivalent of SQL transitions)

```javascript

// example
requestTransition(function () {
  // do anything you want
  document.body.classList.add('whatever');
  documentquerySelector('div.stuff').appendChild(
    document.createElement('p')
  ).classList.add('a', 'b', 'c');
  document.querySelector('div.drop').remove();
  // offsetHeight of that element will the the one
  // **before** this transition, no need to reflow, repaint
  // nothing in here, the DOM is still as it was before
  // this callback ws executed
  document.body.scrollTop -=
    document.querySelector('div.drop').offsetHeight;
  transitionCompleted();
});

// invoked later on
function transitionCompleted() {
  // now the screen is showing
  // the DOM after all things happened before
  // we have just avoided N potential flicks
  // and maybe lagged some extra ms ... who cares ?
  // flicking is worse than a tiny delay, imho
}

```

At least in my experience a similar approach could solve TONS of modern
WebApp problems but of course I would like to know if anything I've written
or proposed makes sense to you too.

Thoughts?

Thanks for reading and Best Regards,
    Andrea Giammarchi