Closed
Bug 119087
Opened 23 years ago
Closed 12 years ago
Implement DOMHeadLoaded event
Categories
(Core :: DOM: Events, defect, P5)
Core
DOM: Events
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: ian, Unassigned)
References
Details
We need a DOMHeadLoaded event. See bug 103097.
Comment 1•23 years ago
|
||
As discussed with Hyatt on irc, this event is really hard to implement *right*, especially if you need to deal with non-standard html that might not specify any or all of the <head>, </head>, <body> or </body> elements. But it seems to me that we could implement an "approximate" DOMHeadLoaded that would improve our situation considerably if we just use the following simple rules: - For text/html, fire the event from HTMLContentSink::OpenBody - For text/xml, if the content element is html with the right namespace for xhtml, fire the event when the </head> is encountered. Otherwise fire the event as soon as we can tell that the content element won't be xhtml (because there's no possible way to tell when or where we might get <link>s in other kinds of xml, and waiting until the load has completely finished is wasteful). - For application/xhtml+xml, use the same rules as text/xml for the xhtml case. - For all other content types, fire the event immediately the content type is determined. Would it be hard to write a patch like that?
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
> non-standard html that might not specify any or all of the <head>, </head>, > <body> or </body> elements The parser should take care of this. The *tags* may be optional, but in an HTML document the elements are always there. http://www.w3.org/TR/html401/struct/global.html#h-7.3 For the <link> implementation, you might also be able to simply handle non-HTML situations in the JS.
Updated•22 years ago
|
Priority: -- → P5
Updated•15 years ago
|
QA Contact: vladimire → events
Updated•15 years ago
|
Assignee: hyatt → nobody
Comment 3•15 years ago
|
||
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Comment 5•12 years ago
|
||
Needs a spec first.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•