Of note: the last line in my Fiddle, above, shows how the text is no longer considered part of the A tags!

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.

Simpler test case: http://jsfiddle.net/npMDu/3/

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.

http://jsfiddle.net/rwaldron/npMDu/7/

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

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/

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.

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

Yeah I saw that. It's still pretty easy to avoid by quoting the href attribute value.

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?

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.

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.

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.

http://www.whatwg.org/specs/web-apps/current-work/#syntax-start-tag

http://www.whatwg.org/specs/web-apps/current-work/#unquoted

Duplicate of #6236.