XSLT written on the web expects local-name to return lowercase node names. Example from http://suda.co.uk/projects/microformats/hcard/xhtml2vcard.xsl <xsl:apply-templates select="//*[local-name() = 'title']" mode="unFormatText"/> All existing server processors for XSLT return local-name as lowercase. I remember having a discussion with sicking a while ago about this, and there was a reason for this, but I don't remember what that was. Something DOM related. We should be consistent with other XSLT processors.
Which processors are you talking about? Libxslt for example seems to use the case of the original document.
The built in PHP5 XSLT processor $doc->load($filename); $xsl->importStyleSheet($doc); $xsl->setParameter('', 'Source', $uri); $xsl->setParameter('', 'Anchor', $anchor); $xsl->setParameter('', 'Encoding', $outputEncoding); $doc->loadHTML($xml_string); $doc->formatOutput = true; $Str = $xsl->transformToXML($doc);
Are we talking about transforming HTML or XML? I.e. is the *source* file an XML or HTML file? (i.e. what the result file is is irrelevant in this case) For XML the specs are quite clear that the case should be the same as in the source document. So any processor doing that is incompatible with the spec, there is no question about that. So even if there are some buggy processors out there that lowercases the name, I think changing to be compatible with them would run the risk of breaking as much things as it would fix. For HTML things are a bit more unclear since HTML as source is entirely unaddressed in the XSLT and XPath specs. HTML is case insensitive so it makes a lot of sense to do case folding one way or the other. We choose to do it to upper case as things like .localName returns the upper case when accessed through the DOM.
Source file is HTML.
HTML as source is something that is wholly undefined by any spec unfortunately. In fact, we are a bit inconsistent. For example patterns has to use lower case to match, whereas local-name() returns upper case. I doubt there is much precedence anywhere here as as far as I know very few XSLT processors allow using HTML as source at all. If we should do anything here I would actually prefer to instead be more consistent internally and make patterns match case insensitively.
Clearly the PHP processor is a precedence, and it probably pretty widely used. Should people expect that XSLT they write for the PHP XSLT processor works in Firefox?
Well, we're also precedence :) Yes, ideally all XSLT processors should work the same. But it's always hard to know what is going to break when you make a change. We have for a very long time supported DOM-XPath on HTML which has the same behavior for local-name(). It'd suck to have different behavior for XPath in DOM vs. XPath in XSLT. I'd be happier to make a change one way or another if there was a spec, but that's unlikely to happen :(
Note that the PHP XSLT processor API was copied from our API, you could just as well ask: "should people expect that XSLT they write for the Firefox XSLT processor works in PHP?" ;-). I don't have a strong preference either way, but as sicking noted our DOM uses upper case for localname in HTML so our current behaviour makes more sense to me.
FWIW, per HTML5 localName should be in the original case (lowercase if coming from an HTML5 parser). (Internet Explorer does not support localName.) DOM attributes such as tagName and nodeName will return in uppercase.
So is this a INVALID or WONTFIX then?
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.