I'm speaking from the framework's side. Yes, I did gloss over certain complexities and constraints, but yes, it's almost there in practice.
1. If they don't expose the node through a ref or something, and no event handlers exist, they could just assume (unsafely) you don't reference it, and act accordingly. Note that I'm speaking from the framework level, which can take liberties browsers can't. 2. I make the assumption you build change lists beforehand, and that resolves all dependencies first. And in general, once you figure out what changes need made, it doesn't actually matter as long as you unregister `blur`/etc. handlers that fire on removal before applying the change list. 3. Script elements execute async, so you could ignore order here. 4. For style elements and ref-accessible elements, you could still execute the changes in set slices, splitting on nodes/callbacks that require awareness of past effects. (This could just be a flag.) However, these are exceedingly rare. On Fri, Jan 26, 2018, 23:18 Boris Zbarsky <bzbar...@mit.edu> wrote: > On 1/26/18 10:49 PM, Isiah Meadows wrote: > > Applying DOM changes from a static change list is > > an embarassingly parallel\* problem. > > Only if you know there are no overlaps in terms of the nodes involved. > And you ignore mutation events. And you ignore the fact that mutation > records expose your order of operations. And you know that none of the > insertions have immediate side-effects (e.g. none are <script> nodes). > And your style system doesn't try to do style recomputation in certain > ways. And probably some other conditions that I'm forgetting. > > -Boris > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
