Using a # in a dummy onclick plus page reload, part 2

[Logos]

Try using href="javascript:void;" instead of href="#". This will cause

the link to just do nothing, rather than do something (attempting to
move to the anchor tag with a blank name).

Thanks Jeremy, that DOES work... but unfortunately, I need the href to
have a valid URL due to non-technical requirements.

Tyler

 

[Randy Webb]

Dr John Stockton said the following on 6/22/2006 1:28 PM:

JRS: In article <[email protected]>, dated
Wed, 21 Jun 2006 16:31:05 remote, seen in Randy Webb <[email protected]> posted :


Your last word needs updating.

Sad but true.

The URL needs to be changed also as the document at that URL is not the
latest that can be found.

 

[Randy Webb]

Jeremy said the following on 6/22/2006 2:29 PM:

Try using href="javascript:void;" instead of href="#".

And then don't use it.

This will cause the link to just do nothing, rather than do something
(attempting to move to the anchor tag with a blank name).

It doesn't do "nothing", it does something.

Well, technically it's doing "something", but that something is just
executing an empty javascript statement and ignoring the result.

No, it does more than that. Perhaps you should read up on the pitfalls
of javascript: pseudo-protocol's in href's of links.

 

[Jeremy]

Jeremy said the following on 6/22/2006 2:29 PM:

No, it does more than that. Perhaps you should read up on the pitfalls
of javascript: pseudo-protocol's in href's of links.

You're quite an antagonistic fellow, aren't you?

I agree that it's normally a bad idea. But avoiding real-world
workarounds unilaterally is just as bad as using them consistently
without considering alternatives. In this case, he's tried
alternatives, and they break his application. I don't see what's bad
about suggesting another approach, even if it's less than ideal. It's
not as if I suggested executing any complicated, problematic javascript.

It's that kind of unilateral thinking that causes HTML beginners to
think that they're supposed to avoid tables for *everything*, and
proceed to construct a data table out of <div>s.

Maybe it is important to him that the application work properly in
Links2 or some other browser in which the javascript: pseudo-protocol
might cause a problem. But that's for him to decide, not you. If you
disagree with my suggestion, perhaps you should present an argument
rather than just contradicting me and insinuating that I'm ignorant and
need to "read up".

Jeremy

 

[Lasse Reichstein Nielsen]

Try using href="javascript:void;" instead of href="#".

Apart from being syntactically incorrect Javascript (the "void"
operator needs an operand), it's generally a bad idea to use
"javascript:"-URL's.
<URL:http://jibbering.com/faq/#FAQ4_24>
Following such a link, even if it doesn't go anywhere will cause
IE to stop animating images and other unexpected side effects.

It also degrades badly if Javascript is not enabled.


/L

 

[Lasse Reichstein Nielsen]

You're quite an antagonistic fellow, aren't you?

It happens

I agree that it's normally a bad idea.

It's not as if I suggested executing any complicated, problematic
javascript.

The problem is that it *is* problematic when used in IE. Following a
javascript:-URL makes the browser go into "I'm about to leave the
page"-mode where not everything works as it usually does (the most
visible problem being that animated gifs stop, but that's not the
only problem).

Maybe it is important to him that the application work properly in
Links2 or some other browser in which the javascript: pseudo-protocol
might cause a problem.

It's probably important to him that it works in IE, where there is
also a problem.

/L

 

[Matt Kruse]

I agree that it's normally a bad idea. But avoiding real-world
workarounds unilaterally is just as bad as using them consistently
without considering alternatives.

The problem is that your "work-around" is just a mask that hides the real
problem.
The OP should fix the broken code that causes the onclick to not return
false, not find a way to cover it up.

 

[Jeremy]

The problem is that it *is* problematic when used in IE. Following a
javascript:-URL makes the browser go into "I'm about to leave the
page"-mode where not everything works as it usually does (the most
visible problem being that animated gifs stop, but that's not the
only problem).


/L

Interesting. I've never noticed such an effect. But then again, I don't
make a habit out of using this method.

I wrote up a quick test page here:
<http://www.duckwizard.com/jsLinkTest>, which attempts to test the
suggestion I gave for any ill effects. I notice no such troubles in
Mozilla, IE Windows/Mac, Safari, or Opera.

In any case, the point is moot since the OP is bound by project
requirements. However, thanks for making a constructive argument
instead of just being a jerk

Jeremy

 

[Jeremy]

The OP should fix the broken code that causes the onclick to not return
false, not find a way to cover it up.

Agreed. But the OP's question was how to have a link that doesn't go
anywhere and doesn't install a hash sign in the URL bar. I was just
trying to offer a suggestion for his question

Jeremy

 

[Randy Webb]

Jeremy said the following on 6/22/2006 4:48 PM:

You're quite an antagonistic fellow, aren't you?

Not in this instance. That issue has been brought up so many times that
it is the group FAQ.

I agree that it's normally a bad idea.

I only know of one use for href="javascript: and that isn't even a good
use for it. There are alternatives to it that don't have pitfalls.

But avoiding real-world workarounds unilaterally is just as bad as
using them consistently without considering alternatives. In this case,
he's tried alternatives, and they break his application. I don't see
what's bad about suggesting another approach, even if it's less than
ideal. It's not as if I suggested executing any complicated,
problematic javascript.

The problem with it is as much a problem with the archives as anything
else. Some newbe comes along, reads this post first looking for a way to
execute script and cancel the default navigation. They read about using
href="javascript:void(0)" and they are off to the races. They come back
2 months later and want to know why the animations stopped working. Then
they reply "But I saw this in this thread...."

It's that kind of unilateral thinking that causes HTML beginners to
think that they're supposed to avoid tables for *everything*, and
proceed to construct a data table out of <div>s.

The same could be said for eval. It has it's place but you don't tell
people to use it when another way is available. Use the best tool available.

Maybe it is important to him that the application work properly in
Links2 or some other browser in which the javascript: pseudo-protocol
might cause a problem. But that's for him to decide, not you. If you
disagree with my suggestion, perhaps you should present an argument
rather than just contradicting me and insinuating that I'm ignorant and
need to "read up".

<URL: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/#FAQ4_24>

Only because I can't access jibbering.com right now.

 

[Logos]

Jeremy said the following on 6/22/2006 4:48 PM:

Not in this instance. That issue has been brought up so many times that
it is the group FAQ.

Actually, Jeremy's comment reflects my impression too. I wasn't going
to say anything, as I thought perhaps it was just me. Your answers
seemed very terse and condescending to me. Just because it's in the
(very long, difficult to read, seldom posted to the newsgroup) FAQ, or
perhaps it's a dumb question or comment, doesn't mean that you can't
point this out in a friendly fashion. Blunt, short answers saying
things like "That's incorrect" don't inspire nor really help the person
learn anything new. And while you may well be a good authority on what
you're talking about...how do the people posting know that, or what the
reasoning is behind the statement?

Not that I don't appreciate the help! Just offering my 2 cents on it,
since others already brought it up.

Anyway, it's both pointless and off topic to debate here anyway. Shall
we just leave it at that, or continue by email if needs be? tyler AT
healthyhabitsweb DOT deleteMeThanks DOT com

Tyler, the now off topic but formerly original poster

 

[Robert]

Interesting. I've never noticed such an effect. But then again, I don't
make a habit out of using this method.

I wrote up a quick test page here:
<http://www.duckwizard.com/jsLinkTest>, which attempts to test the
suggestion I gave for any ill effects. I notice no such troubles in
Mozilla, IE Windows/Mac, Safari, or Opera.

That's because you also included the onclick="return false" in the
link!! So the href is never processed in your example. And the problem
of the OP is that his href is processed even though he has a "return
false" in his onclick.

Furthermore you have to change the href to void(0) otherwise you get a
javascript error (which you did not see, because of the "return false").
Fix this and remove the onclick in your example and you will see the
animating image stop.

Robert.

 

[Robert]

Actually, Jeremy's comment reflects my impression too. I wasn't going
to say anything, as I thought perhaps it was just me.

Read my reply to Jeremy to see he made a mistake.

 

[Robert]

No, the console doesn't show anything. It's very annoying...

For a simple test put an alert just before the return false to be really
really sure that the onclick returns false.
onclick="ts_resortTable(this); alert('returning false'); return false;"
Also look if there are any other click handlers attached to the link.

Did you try debugging with Venkman yet like Laurent suggested?
You could also try to show a stacktrace from a function you call in the
href with javascript: (just for debugging).

Robert.