I experienced the same problem while developing a plugin that does
some tricks with the page content during the ready event. I noticed
that attr('href') works fine if I don't manipulate the body tag
content. IE won't return the correct href attribute if I do so.
The code I used to workaround the problem looks like this:
$('a').attr('xref', function() {
return $(this).attr('href');
});
...
document.body.innerHTML = someContent + document.body.innerHTML;
...
$('a').attr('href', function() {
return $(this).attr('xref');
}).removeAttr('xref');
Hope this helps.
On Mar 25, 9:47 pm, Shane Riley <shanerileydoti...@gmail.com> wrote:
> Right, it's not hard, it was just unexpected is all. I guess I've
> gotten used to JQuery working the same in all browsers.
>
> I've got it working now with some old-fashioned Javascript. Thanks!
>
> On Mar 25, 3:20 pm, Shane Riley <shanerileydoti...@gmail.com> wrote:
>
> > Alright, so your example shows the actual strings for all three values
> > in Safari, and in IE7(Vista) it shows the absolute path for #3. After
> > looking back at my code, I'm actually loading in the links via Ajax
> > when the page is loaded, so they're not in the original document. So
> > I'm guessing that means having to do string manipulation since there's
> > no way to grab the actual href string in IE in this case.
>
> > Thanks for putting up an example.
>
> > On Mar 25, 3:11 pm, Karl Swedberg <k...@englishrules.com> wrote:
>
> > > Hi Shane,
>
> > > Yes, I believe you're reading me right. Strange, though. I'm not able
> > > to reproduce the problem you're having. Take a look here:
>
> > >http://test.learningjquery.com/href.html
>
> > > In IE 7 for #1 and #2 $(this).attr('href') is reporting the actual
> > > text string of the href attribute while this.href is reporting the
> > > fully qualified URL. For #3, in which I injected the link with
> > > javascript, they're both reporting the fully qualified URL.
>
> > > Which version of IE are you testing in?
>
> > > --Karl
>
> > > ____________
> > > Karl Swedbergwww.englishrules.comwww.learningjquery.com
>
> > > On Mar 25, 2009, at 2:21 PM, Shane Riley wrote:
>
> > > > Karl, I'm pretty sure I'm reading you right, but are you saying that
> > > > by all accounts JQuery should account for this and return the string-
> > > > literal value of href and not IE's absolute path? If so, it's not
> > > > working properly. I wish I could show you the live code, because it's
> > > > probably easier to visualize, but here's the process involved in these
> > > > specific anchors appearing before manipulation:
> > > > 1. User visits page
> > > > 2. User makes selection from a drop-down
> > > > 3. Ajax call initialized sending the href attribute as the variables
> > > > using a POST request
>
> > > > So in this case, the anchors in the drop-down list are present on page
> > > > load and part of the initial DOM structure. That means that if JQuery
> > > > is supposed to sort this out for me, it's not. If you meant that I'd
> > > > absolutely have to use Javascript's getAttribute(), then I'll try that
> > > > and see if it works.
>
> > > > On Mar 25, 1:17 pm, Karl Swedberg <k...@englishrules.com> wrote:
> > > >> Hi Shane,
>
> > > >> IE has a second "flag" argument for getAttribute that, when set to 2,
> > > >> is supposed to get the literal value of the attribute rather than
> > > >> their special-sauce value.
>
> > > >> So, this.getAttribute('href', 2) *should* get the relative href.
> > > >> (note: no need to do $(this)[0] ; this works just fine)
>
> > > >> jQuery uses that flag internally, so .attr('href') should do the same
> > > >> thing:
>
> > > >> var attr = !jQuery.support.hrefNormalized &&
> > > >> notxml && special
> > > >> // Some attributes require a
> > > >> special call on IE
> > > >> ? elem.getAttribute( name, 2 )
> > > >> : elem.getAttribute( name );
>
> > > >> I believe that this works in every case except when the href is set
> > > >> via JavaScript. In that case, I'm not sure anything can be done.
>
> > > >> --Karl
>
> > > >> ____________
> > > >> Karl Swedbergwww.englishrules.comwww.learningjquery.com
>
> > > >> On Mar 25, 2009, at 12:21 PM, Shane Riley wrote:
>
> > > >>> Ha! I looked at your post too fast, and didn't notice that it was
> > > >>> pure
> > > >>> Javascript. Sorry. I'll try it and see.
>
> > > >>> The way I currently have it will not work with javascript turned off
> > > >>> either. I'm doing it this way only because the client is requiring
> > > >>> the
> > > >>> user to have Javascript enabled to use the site (it's a backend
> > > >>> system
> > > >>> for very specific clients). They want to add all sorts of animations
> > > >>> and effects like everyone wants to do once they see JQuery
> > > >>> animations
> > > >>> in action.
>
> > > >>> On Mar 25, 12:14 pm, Martijn Houtman <martijn.hout...@gmail.com>
> > > >>> wrote:
> > > >>>> On Mar 25, 2009, at 5:04 PM, Shane Riley wrote:
>
> > > >>>>> Thanks for the article link, but your proposed change isn't valid
> > > >>>>> JQuery, is it? My exact jQuery code to read in the value looks
> > > >>>>> like
> > > >>>>> this:
> > > >>>>> pageID = $(this).attr("href");
> > > >>>>> Adding what you suggested to make it $(this)[0].attr("href") will
> > > >>>>> not
> > > >>>>> do anything apart from force the link to be followed.
>
> > > >>>> Well, no. I suggested using:
>
> > > >>>> pageID = $(this)[0].attr;
>
> > > >>>> This is plain JavaScript, rather than using jQuery's attr()
> > > >>>> function.
> > > >>>> As the article suggests, this works cross-browser.
>
> > > >>>>> I think I'm going to have to move the contents of href to rel
> > > >>>>> instead.
>
> > > >>>> Well, you could, but I wouldn't; this is not what the rel attribute
> > > >>>> is meant for. Besides, it would break the anchor when JavaScript is
> > > >>>> turned off.
>
> > > >>>> Regards,
> > > >>>> --
> > > >>>> Martijn.
