On 8/11/10 10:31 AM, Garrett Smith wrote:
It would have been more helpful to explain, if you can, the cause of
the slowness in Firefox..
Sure thing. https://bugzilla.mozilla.org/show_bug.cgi?id=481131#c12
(the paragraph starting "The time") and
https://bugzilla.mozilla.org/show_bug.cgi?id=481131#c17
Note that I was wrong in my previous mail; it's status.js that causes
the mutations that trigger the Firefox bug, not to.js
Looping through the dom on page load is something that is best avoided.
That's not an issue here.
No. Actually it *is* an issue here; that issue is just massively
dwarfed by the other issue behind door #2.
What makes you say that "looping through the dom" is a performance issue?
In case you care, an actual loop through the DOM on the HTML5
single-page spec, like so (making sure to touch all the nodes, etc):
javascript:var start = new Date(); function f(n) { for (var k =
n.firstChild; k; k = n.nextSibling) f(k); } f(document); alert(new
Date() - start)
alerts numbers under 50ms for me in all the browsers I've tried that can
load the spec to start with.
Most (if not all) of this stuff seems best suite for server-side
logic.
That's possible; I'm assuming Ian had a reason for setting it up the way
he did.
Possible where? On w3c server or whatwg server?
It's possible that the output the scripts generate is more suited to
being generated server-side. I made no comment on the feasibility of
doing so, since I have no idea what the server setup looks like.
-Boris
