On Jun 29, 2007, at 10:22 AM, Thomas Broyer wrote:
2007/6/29, Simon Pieters:
For HTML elements in HTML documents, why is Element.localName
uppercased
for tag names and lowercased for attribute names?
Because of this:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-5353782642
and this:
http://www.w3.org/2000/11/DOM-Level-2-errata#html-2
If you look at the part of the spec that is actually normative for
HTML, it only requires this behavior for tagName and nodeName. There
is no such requirement for localName.
1.6.3. Exposing Element Type Names (tagName, (nodeName))
If the document is an HTML 4.01 document the element type names
exposed through a property are in uppercase. For example, the body
element type name is exposed through the tagName property as BODY. If
the document is an XHTML 1.0 document the element name is exposed as
it is written in the XHTML file. This means that the element type
names are exposed in lowercase for XHTML documents since the XHTML
1.0 DTDs defines element type names as lowercase, and XHTML, being
derived from XML, is case sensitive.
DOM Level 2 Core does not call for any special case behavior for
localName either. Although it says that localName should be null for
HTML elements created with createElement, which seems wrong: "For
nodes of any type other than ELEMENT_NODE and ATTRIBUTE_NODE and
nodes created with a DOM Level 1 method, such as createElement from
the Document interface, this is always null.". It would be silly to
have a null localName for dynamically created HTML elements only, and
even more silly to do so for all HTML elements.
We originally made tagName/nodeName uppercase but localName lowercase
in WebKit so that you'd get the required HTML behavior for the first
two, but localName would show through to a more XML-like view, so it
could be used together with namespaceURI and you wouldn't have to
care whether the document was XML or not.
I still think the WebKit behavior is nice in theory, although it
appears to be a compat issue.
Regards,
Maciej
