#9530 closed bug (duplicate)
jQuery erroneously treats some a tags as self-closing
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | low | Milestone: | 1.next |
Component: | manipulation | Version: | 1.6 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Test case:
Compare http://jsfiddle.net/npMDu/1/
to: http://dl.dropbox.com/u/105727/web/why_not_links.html
Same exact input, different outputs.
What’s going on:
Sometimes you have code like:
<a href=http://example.com/>foo</a>
For example, one HTML sanitizes stripped out the surrounding quotes on the attribute value and gave me that output.
If you do an .html(foo) where foo is the above, then jQuery parses this as
if it were
<a href="http://example.com" />
, self-closing, that is,<a href="http://example.com/..."></a>foo</a>
Thus the link is not actually clickable anymore; it's empty and then followed by a text node and an extra closing tag.
Change History (17)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
I realize the problem description is a bit sparse, but basically: markup rendered directly in an HTML document (in WebKit) ≠ the same markup placed into a document via jQuery.
comment:4 Changed 12 years ago by
Component: | unfiled → manipulation |
---|---|
Priority: | undecided → low |
Resolution: | → invalid |
Status: | new → closed |
Your html is invalid. When using unquoted attribute syntax, the "/" (solidus) is being seen as a closing of the anchor. If you A) remove the solidus or B) add a space between the solidus and the closing greater-than, this issue does not exist.
comment:5 Changed 12 years ago by
Please re-open this issue.
According to http://html5.validator.nu/ the markup I used above is valid.
Furthermore all the browsers I checked render it as expected. Only jQuery misunderstands.
While it is true that using quotes or inserting a space would “solve” the problem, note that I am not generating the input HTML by hand! It is html5lib that is outputting this markup. (https://code.google.com/p/html5lib/)
Please-reopen for discussion, as this is indeed a bug.
comment:6 Changed 12 years ago by
Please note that .innerHTML
and .html()
yield very different results here, which is not intuitive and backs my claim that this is indeed a real bug.
New fiddle to demonstrate: http://jsfiddle.net/alanhogan/Neznc/6/
comment:8 Changed 12 years ago by
Note that I repeated my tests on these URLs:
http://jsfiddle.net/alanhogan/Neznc/6/
and
http://dl.dropbox.com/u/105727/web/why_not_links.html
in IE7, IE8, and Firefox (originally tested in Chrome), and the behavior is consistent: .innerHTML and native web page rendering get it right, and jQuery .html interprets erroneously as a self-closing element.
comment:9 Changed 12 years ago by
Uh, interestingly enough, the last linked jsfiddle gains an odd quirk in the latest stable Chrome: the second button may not appear to remove the link! I think a redraw is failing to fire, as resizing the window or clicking the first button causes the text to finally disappear, and attempting to select or click the link, while it’s visible but removed, will fail. Separate issue, please ignore (or use Safari/Firefox if confused).
comment:10 Changed 12 years ago by
Yeah I saw that. It's still pretty easy to avoid by quoting the href attribute value.
comment:11 Changed 12 years ago by
I don't think this is something we can fix in the general case; IE6/7/8 also interprets a trailing slash in a url as a self-closing tag. (See #8939.) Is it such a burden to quote the attribute? If your HTML is being built from a variable you will need to be doing escaping anyway, right?
comment:12 Changed 12 years ago by
I’m not sure I get what’s happening in #8939, but I tested IE8 in IE8 and IE7 modes and it parses the A tag correctly, that is to say, not like jQuery does, but like all other browsers.
comment:13 Changed 12 years ago by
I am not building the URL from a variable, but rather, my HTML sanitizer is actually removing unnecessary quotes. And in all cases but jQuery’s, the quotes would indeed be unnecessary here.
I disagree with the parser’s behavior and am looking into changing it, but this bug is (a) still valid IMO and (b) something that, if fixed, would also solve my issue.
comment:14 Changed 12 years ago by
Relevant html5lib "discussion" (no replies yet): http://groups.google.com/group/html5lib-discuss/browse_thread/thread/6d80ebe39e1f688b
The issue arises because of a combination of html5lib and jQuery quirks.
Disheartening to see that neither library seems to acknowledge a problem yet.
In the meantime, using raw .innerHTML solves my issue for now.
comment:15 Changed 12 years ago by
Status: | reopened → open |
---|
comment:16 Changed 12 years ago by
Resolution: | → duplicate |
---|---|
Status: | open → closed |
Of note: the last line in my Fiddle, above, shows how the text is no longer considered part of the A tags!