From Fil on Dev list:

I had a similar problem with an <a href="~fil/..."> being transformed

into <a href="%7Efil/..."> with the .html() method under FF

(consequences were that the cookies were not transmitted, so the

"action" was not "authorised"). This did not happen with .clone(), but

.clone() was crashing Safari.

So finally I resorted to:

jQuery.fn.clone2 = jQuery.browser.safari ? jQuery.fn.html : jQuery.fn.clone;

(under jquery 1.1.1 release 2); see

http://trac.rezo.net/trac/spip/changeset/8786/spip/dist/javascript/async_upload.js

IE serializes href and src attributes when using innerHTML ... thats it.

Can you explain more on why this ticket is closed and won't be fixed? This issue is problematic for the WYMEditor project as when they try to insert images or relative hyperlinks into the editor the links get all mangled.

The problem lies in IE's

innerHTML

implementation. There isn't any practical and performant way for jQuery to work around this for the general case of getting and setting arbitrary HTML strings.

Here are some possible workarounds that may work in your situation: If you know you are creating an A or IMG element, create it and set its attributes explicitly rather than using an HTML string to do it. For reading, grab the elements with a selector and use

.attr()

to get the href or src attributes.

I'm sorry for reopening this ticket once again, but the proposed workaround isn't cuting it.

Setting the element attributes explicitly works fine if you're just creating single elements, but if you're dealing with larger chunks of html strings (say the whole document body) things get a bit more complicated.

Regarding possible workarounds, have you taken a look at Steve Tucker's innerXhtml?

http://www.stevetucker.co.uk/innerxhtml.htm

It's a fairly lightweight alternate to the non-standard innerHtml (about 1kb minified and gzipped). It shouldn't be that hard to adapt it for jQuery (with the authors permission of course.)

As this bug is causing a lot of people a lot of trouble I think that it's worth reconsidering fixing this. Not to mention the fact that this is one of few areas where jQuery's behaviour differs between browsers.

Also worth mentioning is that I'm a developer on the WYMeditor project, and that this issue as previously stated is casing us a lot of trouble. We could work around this issue ourselves but since a lot of people are affected an official fix would be nice.

The issue seems to be that 95% of the time the normal innerHTML processing is "good enough" but for the remaining 5% there's no easy workaround. Maybe we need to pull out the code in

jQuery.clean

and make it able to be overridden for cases where it's not good enough. Say,

jQuery.StringToNodes(string, documentNode)

or something like that. That would also provide a hook to fix usage in XUL per #4352.

Steve Tucker's innerXHTML code seems like it would be significantly slower than the browser's native innerHTML support--it's implementing an HTML parser in Javascript rather than C. If it could be slotted in only when it was needed, as a plugin you included to replace the standard processing, that would give you a way to produce fully pristine DOM without slowing down the 95% of cases that are fine with the default innerHTML.

I did some performance testing of innerXhtml yesterday, and the difference in performance between innerXhtml and the native innerHtml is far to great indeed. It's barely noticeable a small set of elements, but when you try to insert a greater number of elements things get painfully slow.

It would seem that some kind of plugin is the way to go.

As noted before - any sort of solution that we could try and provide would either use too much memory or be far too slow - unfortunately this is just going to be something that we can't guarantee :-/