Bug 41361

Summary: HTML5 TreeBuilder should attach whole subtrees instead of individual nodes
Product: WebKit Reporter: Geoffrey Garen <ggaren>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED LATER    
Severity: Normal CC: abarth, ahmad.saleem792, eric, jamesr, rniwa, tonyg
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   

Description Geoffrey Garen 2010-06-29 10:44:02 PDT
The simplest way to do this might be to call recalcStyle() on the root of the subtree. An alternative would be just to rely on the layout timer.

This is a substantial change, but since we're rewriting the tree builder anyway, maybe this is the right time for such a change.

Here are two cases that would definitely get faster if elements attached lazily instead of individually:

1. An element is added to the page but, before it displays, a script removes it from the page. (More common than you might think.)

2. An element is added to the page but, before it displays, another element is added, or a new stylesheet is loaded, changing the first element's layout or rendering.

In both of these cases, the eager attach done by the parser is just thrown away.

I'd also expect improved cache effects from building the render tree in one go.

Concerns about this approach:

1. JavaScript access to rendering-dependent properties. Our design is that any JavaScript accessors that depend on layout should update layout if needed before doing their thing. Any failures in this area are the fault of the accessor. So, in theory, this is either not a concern, or a concern with a set of simple one-off fixes for pre-existing bugs.

2. attach() has side effects for plugins.  Plugins trigger their initialization off of attach(). One solution is to attach plugins before executing any scripts. Another solution is to treat plugin access from script just like any other rendering-dependent access. Another solution is to trigger plugin initialization based on DOM insertion instead of attach().
Comment 1 Adam Barth 2010-07-20 18:19:40 PDT
This doesn't block the master bug because it's not required in this phase.  I'd still like to do this, however.
Comment 2 Ahmad Saleem 2022-12-19 15:05:17 PST
Is it something still worth pursuing so we can mark it as "RESOLVED LATER" or we can close this now? Thanks!
Comment 3 Ryosuke Niwa 2022-12-19 15:12:56 PST
Yeah, this is "later" at this point.