case sensitivity in find() vs children()

Reported by:	hubquery	Owned by:
Priority:	minor	Milestone:	1.2.2
Component:	core	Version:	1.2.1
Keywords:		Cc:
Blocked by:		Blocking:

Description

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
}

Attachments (2)

1991.diff (1.4 KB) - added by davidserduke December 05, 2007 08:37AM UTC.

possible patch
jquery_test.html (2.3 KB) - added by davidserduke December 05, 2007 08:08AM UTC.

test case

Change History (5)

Changed November 29, 2007 11:08PM UTC by hubquery comment:1

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).

Changed December 05, 2007 08:16AM UTC by davidserduke comment:2

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.

Changed December 05, 2007 08:39AM UTC by davidserduke comment:3

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.

Changed December 05, 2007 09:35PM UTC by davidserduke comment:4

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

Changed May 16, 2009 03:05AM UTC by dmethvin comment:5

resolution:	→ invalid
status:	new → closed

Since jQuery's $("html") function is only documented to parse html, I'll close this as invalid.

Side navigation

#1991 closed bug (invalid)