After replacing $(this).attr("href") with this.getAttribute("href", 2)
I get the same result. If I output the attribute, IE still shows the
absolute path.

On Mar 25, 2:21 pm, Shane Riley <shanerileydoti...@gmail.com> 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.

Reply via email to