[whatwg] .localName shouldn't change case

On Fri, 29 Jun 2007, Darin Adler wrote:
> On Jun 29, 2007, at 9:15 AM, Simon Pieters wrote:
> 
> > For HTML elements in HTML documents, why is Element.localName 
> > uppercased for tag names and lowercased for attribute names? I 
> > wouldn't expect it to, and it makes it harder to write scripts that 
> > work for both HTML and XHTML. For example, if you want a script to 
> > work in both legacy HTML UAs and HTML5 UAs as well as in XHTML, you 
> > may want to do something like if ((elm.tagName == "A" && 
> > !elm.namespaceURI) || (elm.localName == "a" && elm.namespaceURI == 
> > "http://www.w3.org/1999/xhtml")) to check that a given element is an 
> > HTML "a" element.
> 
> Good timing, mentioning this.
> 
> WebKit uses lowercase for localName for HTML elements in HTML documents 
> for the reasons you mention.
> 
> We received a bug report about a library, "Jira", that doesn't work with 
> Safari 3 because of this <http://bugs.webkit.org/show_bug.cgi?id=14114>. 
> We were surprised to learn that Mozilla uses uppercase.

On Fri, 29 Jun 2007, Maciej Stachowiak wrote:
> On Jun 29, 2007, at 10:22 AM, Thomas Broyer wrote:
> > 
> > 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.

The spec requires the localName-is-real behaviour now (by virtue of not 
requiring it to do anything else). It seems the compat issue isn't very 
serious, based on the bug cited above having not changed in over a year, 
and the cite in question being down now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 12 August 2008 16:11:56 UTC