W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: oldNode.replaceWith(...collection) edge case

From: Glen Huang <curvedmark@gmail.com>
Date: Wed, 21 Jan 2015 07:45:32 +0800
Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
Message-Id: <13E1A9FA-A266-420A-8022-67DE70E848C5@gmail.com>
To: Simon Pieters <simonp@opera.com>
Ah, thank you for letting me know.

I vaguely remember document fragment is introduced just to reduce reflows. Looks like this best practice is obsolete now? (I remember myself wondering why bowsers couldn’t optimize that back then.) Many people still suggest it though, including google (https://developers.google.com/speed/articles/javascript-dom <https://developers.google.com/speed/articles/javascript-dom> the "DocumentFragment DOM Generation” section), and you can find more by googling “why use document fragment".

So to recap, when you have the need to pass the context node as an argument along with other nodes, just use before() and after() to insert these other nodes? And even insert them one by one is fine?

> On Jan 20, 2015, at 11:57 PM, Simon Pieters <simonp@opera.com> wrote:
> On Tue, 20 Jan 2015 15:00:41 +0100, Glen Huang <curvedmark@gmail.com> wrote:
>> I wonder what the correct method should be? For the example I gave in the previous mail, it looks like I have to either create two fragments (and compute which nodes go to which fragment) and insert them before or after the node (two reflows), or implement the transient node algorithm myself (but with no suppressing observer ability, also three reflows (insert fake node, pull out context node, insert fragment), i guess if browsers implement it natively, they can reduce it to just one reflow?). Both doesn’t sound very optimal.
> In all cases it would be just one reflow after the script has finished, unless you force a reflow by asking for layout information (e.g. offsetTop) between the mutations.
> -- 
> Simon Pieters
> Opera Software

Received on Tuesday, 20 January 2015 23:46:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC