[Webkit-unassigned] [Bug 30232] [HTML5] Add document.head

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30232





--- Comment #9 from Joseph Pecoraro <joepeck at webkit.org>  2009-10-08 14:34:54 PDT ---
> I'm not sure that's correct. I think perhaps it should be on Document. Is there
> a downside to having the head property be exposed to JavaScript in XML and SVG
> documents? If not, then you were right to have it in Document.

In order to track this down I checked to see if there was a downside to having
the body property be exposed to JavaScript in XML and SVG.

>From the Internet Side of Things:

This article (2005) seems to indicate that the web developer at the time did
not expect document.body to appear in an XML or SVG Document and would fail in
WebKit?
http://userjs.org/help/tips_and_tricks/what-type-of-page

Someone on the XML/SVG mailing list (2008) wrote that document.body was not a
part of the SVG DOM:
http://article.gmane.org/gmane.text.xml.svg.devel/43755

document.body is not in the SVG 1.1 or SVG Tiny 1.2 Specs (under ECMAScript
Bindings):
http://www.w3.org/TR/SVGTiny12/ecmascript-binding.html

However, on the WebKit side of things:

document.body was moved from HTMLDocument.idl to Document.idl in ChangeSet
26078 (2007):
http://trac.webkit.org/changeset/26078

The ChangeLog states:
> Moved a bunch of methods and properties from
> HTMLDocument down into Document to make
> them available for all documents (xml, svg).

Maciej Stachowiak on bug 12628 (2007):
> We should consider supporting all HTMLDocument properties and
> methods on all XML documents (because any XML document could
> contain XHTML).


I see no harm in putting the body and head properties on XML and SVG documents.
Especially if document.body has been that way for over two years in WebKit
without complaints.  Anyone know how Firefox handles this?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.