Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

getAttribute('href') in IE

39 views
Skip to first unread message

kangax

unread,
Mar 18, 2008, 1:08:14 PM3/18/08
to
According to MSDN [1], if iFlag is set to the integer 2, the
getAttribute() method should return "... the value exactly as it was
set in script or in the source document."

Yet, when appending anchor element via innerHTML, calling
getAttribute('href', 2) on that element always returns string
representing absolute url (ignoring the actual value).

Does anyone know of a way to get value of href attribute exactly as it
was defined in the document?

[1] http://msdn2.microsoft.com/en-us/library/ms536429.aspx

Thank you.

VK

unread,
Mar 18, 2008, 1:40:11 PM3/18/08
to

You have actually set a URL and the method hapilly reports what:
either you have set www.ExAmPlE.CoM or www.example.com

If you have actually have to know either www.ExAmPlE.CoM or www.example.com
had been set then your solution is having much more serious problems
than stated in our OP.

tomtom....@gmail.com

unread,
Mar 18, 2008, 1:45:33 PM3/18/08
to

I've duplicated your problem here:

<!-- Problem: setting href=document.html alerts as "http://host/
document.html" and not "document.html" -->
<html><body><span id=mystuff></span></body>
<script>
document.getElementById("mystuff").innerHTML = "<a id=mycall
href=document.html>My Link</a>";
alert(document.getElementById("mycall").getAttribute("href",2));
</script>
</html>

Don't know how to get around the browser translating the href into an
absolute although I do have a workaround.

When writing out the elements to innerHTML, simply add another
attribute. I called my new attribute "xref" in the example below:

<!-- Workaround: use additional attribute "xref" to skip around
browser resolving relative-to-absolute URLs -->
<html><body><span id=mystuff></span></body>
<script>
document.getElementById("mystuff").innerHTML = "<a id=mycall
href=document.html xref=document.html>My Link</a>";
alert(document.getElementById("mycall").getAttribute("xref",2));
</script>
</html>

This skirts around the issue but could get you going for now.

Cheers,

-Tom Woz

kangax

unread,
Mar 18, 2008, 3:33:28 PM3/18/08
to

Tom,

This is an interesting solution. One thing I'm concerned about is the
cost of maintenance when using such workaround. In order to overcome
bugs in IE's DOM implementation, I would have to duplicate all the
"href" attributes throughout all of my "templates" (relatively large
chunks of html which are then inserted into a document).

What's more disappointing is that element.outerHTML and
element.parentNode.innerHTML properties both contain absolute (!!!)
url representation as well. *sigh* I would be more than happy if
anyone else could shed some light on the issue.

Thanks.

RobG

unread,
Mar 18, 2008, 8:07:37 PM3/18/08
to

It seems to me that you are trying to use the href property for
something that it was not intended to be used for. It doesn't seem
like a good idea to create a dependency on an implementation detail of
the unspecified innerHTML property or the non-standard iFlag argument
for getAttribute.

If you want to distinguish between identical links where one is
relative and one absolute in the original source, you could use a
value in the class attribute or add a query string after the link,
e.g.:

<a href="index.html" class="var_relative ..." ...>

<a href="index.html?relative" ...>


--
Rob

kangax

unread,
Mar 18, 2008, 9:21:20 PM3/18/08
to

Rob,

I understand your concerns but the idea is to have a consistent result
of getting an href attribute across browsers. The fact that part of
document was modified via innerHTML is something that could have
happened or could have not. We can't be sure if it will or will not be
used. We only care about "reading" href attribute in a consistent way.
innerHTML just hapenns to trigger this bug.

Am I missing something?

Thanks.

--
kangax

Message has been deleted
0 new messages