case sensitivity in find() vs children()

[hubquery]

I was using jQuery to parse XML (actually a text string returned from an XMLHttpRequest) and found some odd behaviour when dealing with elements that weren't all lowercase. Basically find() seems to only select lowercase elements, regardless of whether the selector string is lowercase or not, while children() selects elements with no case sensitivity.

Here's an example that should illustrate the problem:

var s = document.createElement("script");
s.setAttribute("type", "text/javascript");
s.addEventListener("load", doParse, true);
s.setAttribute("src", "http://code.jquery.com/jquery-latest.js");
document.getElementsByTagName("head")[0].appendChild(s);

function doParse(){
 var n = "<Test><Items><item/><Item/><Item/></Items></Test>";
 var $n = $(n);
 console.log($n.html());

 console.log($("item", $n)); // expected 1, found 1

 console.log($("Item", $n)); // expected 2, found 1

 console.log($n.find("Items").children("Item")); // expected 2, found 0

 console.log($n.children("Items").children("Item")); // expected 2, found 3
}

[hubquery]

As discussed in this thread, this issue breaks down as:

• children() is case insensitive
• find() is case sensitive
• but selectors in find() are being lowercased, so there's no way to match elements with uppercase characters using find()

Ideally then, the selector string used for find() should remain in its original case.

There may be a flag needed for dealing with differences between HTML (case-insensitive - could convert the selector to upper- or lower-case as appropriate) and XML/XHTML (case-sensitive, should leave the selector as is).

[davidserduke]

test case

[davidserduke]

I put together a test case with two buttons. One shows what the author has written up as the problem. The other shows what he needs to do instead. The second one also shows a "bug" (or lack of feature) in jQuery.

The author has an XML string as is using jQuery to create an XML version. Unfortunately, at this point, jQuery does not have this capability. So instead what jQuery is creating is non-standard html. That is the main reason for the odd results. This can be seen in the test case.

Instead of using jQuery's $(string) to create the xml one can be created using a function like parseToXML (which is shown in the test case). This will create a true xml doc and not just non-standard html. The second button shows how jQuery operates on this using similar calls to the authors original description. There is still some issues but not nearly as many.

In [4032] I have moved the case-sensitivity parse of the nodeName comparison to jQuery.nodeName(). So by removing the toUpperCase() calls in that function, jQuery will start being case sensitive on those compares. Of course that would mess up html where it is NOT suppose to be case sensitive. Perhaps a switch or something as the author suggests is the way to go.

[davidserduke]

possible patch

[davidserduke]

I attached a patch that appears to fix this problem of case sensitivity being different for html and xml. It tests to see if the element is part of an xml doc to decided which test is appropriate.

[davidserduke]

There is too much of a speed hit doing it this way to warrent commiting this patch.