[whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)
Boris Zbarsky
bzbarsky at MIT.EDU
Wed Aug 11 08:48:15 PDT 2010
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
More information about the whatwg
mailing list