376740 - XPath expressions in HTML must be lowercase

Status: NEW

(Core :: XSLT, defect)

Description

[aaronr]

Attachment: testcase

It has been observed here that XPath expressions evaluated with JS in an HTML document will only find nodes if the whole expression is lower case.  Timeless and bz thought that only upper case would work since all the nodes in HTML are uppercased regardless of how they appear in the original document.  Jonas thinks, "actually, when using DOM-XPath on an HTML document you should be able to 
use any casing, i.e. /hTmL/BOdy should work."  So there is definitely some confusion here.

Regardless of what the correct answer is and whether this testcase points out a bug or not, it really needs to be documented somewhere, at least in MDC if nowhere else.  So hopefully that will be one of the outcomes from this bug.

The behavior that I observe seems to be the same on FF1.5 and FF2, too.

Comment 1

[aaronr]

Attachment: testcase2

changed initial expression to be all uppercase.  Previous testcase used default of lowercase which will, of course, work.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

You need to use the evaluator you get off the document to get case insensitive matching. Change

var xpe = new XPathEvaluator();

to

var xpe = document;

Does that work?

Comment 3

[aaronr]

yep, that works, thanks.  Its not obvious, though.  Most of the examples I've come across use new XPathEvaluator.  But at least one page under mozilla.org says to use document.evaluate.  Doesn't say why, though...

Oh, well.  Thanks again for the correction!

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Peter: Do we want to make it such that |new XPathEvaluator| with a HTML document as scripting context makes the XPathEvaluator case insensitive?

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yet an alternative solution would be to make it such that when we create an expression object we compile it both in a case sensitive and a case insensitive manner. We could then use the version that is appropriate depending on what the context node is.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Oh, FWIW, document.evaluate is what the W3C spec says. |new XPathEvaluator| is our own invented extra syntax sugar.

Comment 7

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-06)]

I think this should be WONTFIXed. Lower case works interoperably and case-insensitivity is trouble now that HTML docs can have camelCase SVG local names.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Henri: Note that we already have case-insensitive matching using document.evalutate. This bug is only about (new XPathEvaluator).evalute.

Though the case-insensitive matching probably doesn't work with camelCase SVG elements :( But that is a separate bug.

I think it'd be nice for consistency if (new XPathEvaluator).evaluate worked equivalently to document.evaluate.

Comment 9

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-06)]

(In reply to comment #8)
> Henri: Note that we already have case-insensitive matching using
> document.evalutate. This bug is only about (new XPathEvaluator).evalute.
> 
> Though the case-insensitive matching probably doesn't work with camelCase SVG
> elements :( But that is a separate bug.

:-( Fixing that mean either having an XPath version of bug 499655 or making XPath case-sensitive (requiring expressions to use the canonical case).

Making XPath expressions case-sensitive would be the simpler solution and, therefore, IMO preferable if feasible considering existing content. (My vague recollection is that WebKit requires expressions to use the canonical case but Opera doesn't.)

> I think it'd be nice for consistency if (new XPathEvaluator).evaluate worked
> equivalently to document.evaluate.

Sure.

Comment 10

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-06)]

(In reply to comment #9)
> Making XPath expressions case-sensitive would be the simpler solution and,
> therefore, IMO preferable if feasible considering existing content.

jgraham tells me Dojo sniffs WebKit. Thus, making browsers that don't sniff as WebKit behave like WebKit would break Dojo.

That's really sad, but I guess it means the XPath expressions should be compiled with dual atoms like Selectors in order to appear ASCII-case-insensitive when matching against HTML nodes and as case-sensitive when matching against anything else including SVG nodes.