#1991 closed bug (invalid)
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)
Change History (7)
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
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.
comment:3 Changed 14 years ago by
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.
comment:4 Changed 14 years ago by
There is too much of a speed hit doing it this way to warrent commiting this patch.
comment:5 Changed 13 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Since jQuery's $("html") function is only documented to parse html, I'll close this as invalid.
As discussed in this thread, this issue breaks down as:
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).