By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,574 Members | 2,960 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,574 IT Pros & Developers. It's quick & easy.

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

P: n/a
I asked about this a while ago, and got a great answer and a reference
to http://www.javascripttoolbox.com/bestpractices/new.php. I just need
to override onclick and return false. No biggie!

However, I discovered that my code worked fine in IE (no # in URL after
click), but not in FF (# appears in URL after click). Can anyone tell
me why?

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)"); }

else { eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)"); }
Thanks for any help you can give!

Tyler

Jun 16 '06 #1
Share this Question
Share on Google+
35 Replies


P: n/a
In the generated source the link looks like this, btw:

<a href="#" class="rCatalogHeadSortable"
onclick="ts_resortTable(this);return false;">

Jun 17 '06 #2

P: n/a
instead of

link =document.createElement("a");
link.setAttribute("href","#");

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)");
}
else {
eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)");
}

I used

try { //IE will not allow name attribute to be set after element
creation
link =document.createElement("<a name='itemNo|" +intPartId +"'
href='#itemNo|" +intPartId +"' />");
} catch (e) {
link =document.createElement("a");
link.setAttribute("name","itemNo|" +intPartId);
link.setAttribute("href","#itemNo|" +intPartId);
}
//when clicking a product description, scroll the anchor clicked to the
top; cannot just use #, as this breaks in FF unless # is defined on the
page
if(link.attachEvent) {
eval("link.attachEvent('onclick',function() { GB_show('" +part.strDesc
+"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600); },false)");
}
else {
eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
},false)");
}
which has the added bonus of positioning the item clicked at the top of
the page, very nice for me. I think FF dies because it is looking for
an explicitly defined anchor "#", whereas IE implicitly just scrolls to
the top. Still....I would like to know for sure why my "#" onclick
dies on FF but not IE...
Logos wrote:
I asked about this a while ago, and got a great answer and a reference
to http://www.javascripttoolbox.com/bestpractices/new.php. I just need
to override onclick and return false. No biggie!

However, I discovered that my code worked fine in IE (no # in URL after
click), but not in FF (# appears in URL after click). Can anyone tell
me why?

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)"); }

else { eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)"); }
Thanks for any help you can give!

Tyler


Jun 17 '06 #3

P: n/a
Logos wrote:
In the generated source the link looks like this, btw:

<a href="#" class="rCatalogHeadSortable"
onclick="ts_resortTable(this);return false;">


And does any javascript error occur in Firefox?
Because if it occurs then the "return false" will never be executed.
Jun 19 '06 #4

P: n/a

Robert wrote:
Logos wrote:
In the generated source the link looks like this, btw:

<a href="#" class="rCatalogHeadSortable"
onclick="ts_resortTable(this);return false;">


And does any javascript error occur in Firefox?
Because if it occurs then the "return false" will never be executed.


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

Jun 19 '06 #5

P: n/a
Hi,

Logos wrote:
Robert wrote:
Logos wrote:
In the generated source the link looks like this, btw:

<a href="#" class="rCatalogHeadSortable"
onclick="ts_resortTable(this);return false;">

And does any javascript error occur in Firefox?
Because if it occurs then the "return false" will never be executed.

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


In the cases where the console doesn't show anything, the last resort is
to use Venkman.
http://www.mozilla.org/projects/venkman/

Greetings,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch
Jun 19 '06 #6

P: n/a
Just leave the href bit out as far as I can see it doesn't actually do
anything as you are using onclick. In fact is doesn't really have to be
an anchor tag it could be a div. If you are worried about loosing the
pointer cursor add some css for this.
Logos wrote:
instead of

link =document.createElement("a");
link.setAttribute("href","#");

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)");
}
else {
eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)");
}

I used

try { //IE will not allow name attribute to be set after element
creation
link =document.createElement("<a name='itemNo|" +intPartId +"'
href='#itemNo|" +intPartId +"' />");
} catch (e) {
link =document.createElement("a");
link.setAttribute("name","itemNo|" +intPartId);
link.setAttribute("href","#itemNo|" +intPartId);
}
//when clicking a product description, scroll the anchor clicked to the
top; cannot just use #, as this breaks in FF unless # is defined on the
page
if(link.attachEvent) {
eval("link.attachEvent('onclick',function() { GB_show('" +part.strDesc
+"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600); },false)");
}
else {
eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
},false)");
}
which has the added bonus of positioning the item clicked at the top of
the page, very nice for me. I think FF dies because it is looking for
an explicitly defined anchor "#", whereas IE implicitly just scrolls to
the top. Still....I would like to know for sure why my "#" onclick
dies on FF but not IE...
Logos wrote:
I asked about this a while ago, and got a great answer and a reference
to http://www.javascripttoolbox.com/bestpractices/new.php. I just need
to override onclick and return false. No biggie!

However, I discovered that my code worked fine in IE (no # in URL after
click), but not in FF (# appears in URL after click). Can anyone tell
me why?

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)"); }

else { eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)"); }
Thanks for any help you can give!

Tyler


Jun 19 '06 #7

P: n/a

Unfortunately many people complain when we leave out the href, as no
info appears in the status bar as to where the link goes. Apparently
quite a bit of our customer base relies on this.

I've also just discovered that this screws up page reload; if the URL
in the address bar contains an #, the page doesn't reload correctly in
FF. Dammit.

ma*****@chickenskinners.com wrote:
Just leave the href bit out as far as I can see it doesn't actually do
anything as you are using onclick. In fact is doesn't really have to be
an anchor tag it could be a div. If you are worried about loosing the
pointer cursor add some css for this.
Logos wrote:
instead of

link =document.createElement("a");
link.setAttribute("href","#");

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)");
}
else {
eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)");
}

I used

try { //IE will not allow name attribute to be set after element
creation
link =document.createElement("<a name='itemNo|" +intPartId +"'
href='#itemNo|" +intPartId +"' />");
} catch (e) {
link =document.createElement("a");
link.setAttribute("name","itemNo|" +intPartId);
link.setAttribute("href","#itemNo|" +intPartId);
}
//when clicking a product description, scroll the anchor clicked to the
top; cannot just use #, as this breaks in FF unless # is defined on the
page
if(link.attachEvent) {
eval("link.attachEvent('onclick',function() { GB_show('" +part.strDesc
+"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600); },false)");
}
else {
eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
},false)");
}
which has the added bonus of positioning the item clicked at the top of
the page, very nice for me. I think FF dies because it is looking for
an explicitly defined anchor "#", whereas IE implicitly just scrolls to
the top. Still....I would like to know for sure why my "#" onclick
dies on FF but not IE...
Logos wrote:
I asked about this a while ago, and got a great answer and a reference
to http://www.javascripttoolbox.com/bestpractices/new.php. I just need
to override onclick and return false. No biggie!

However, I discovered that my code worked fine in IE (no # in URL after
click), but not in FF (# appears in URL after click). Can anyone tell
me why?

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)"); }

else { eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)"); }
Thanks for any help you can give!

Tyler


Jun 19 '06 #8

P: n/a
Logos said the following on 6/19/2006 1:17 PM:
Unfortunately many people complain when we leave out the href, as no
info appears in the status bar as to where the link goes.
Then make the href point to the current page. Have a tooltip that
displays in the page giving information about the link. Seeing "#" in
the statusbar is useless to a user.

But, many people in this group complain when people top post.
Apparently quite a bit of our customer base relies on this.
Yes, many people do use the status bar to know where a link will take them.
I've also just discovered that this screws up page reload; if the URL
in the address bar contains an #, the page doesn't reload correctly in
FF. Dammit.


As for problems with your code, start with the setAttribute problems (IE
has major problems with it) and ditch the eval stuff. Then post a URL to
a sample page that displays the problem.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 19 '06 #9

P: n/a
<lol> I am a top poster. I prefer it because it means the newest
material is at the top, so I don't have to actively hunt for the latest
text. I can read previous posts and see the response structure
graphically, so bottom posting is a waste of time in my view. Back
when one just had nn and such for newsgroup reading on one's 'nix
terminal, it made a lot more sense, but unless one is in a text only
environment with 80x24 columns, bottom posting is not useful IMO.
Then make the href point to the current page. Have a tooltip that
displays in the page giving information about the link. Seeing "#" in
the statusbar is useless to a user.
They don't see #, they see the page URL. At least they do on FF and
IE5.5 and above, which is all I am required to code to. In Opera,
those don't even show up as links, though the onclick does work (Opera
rocks for speed!). Anyway, since two of my bosses are the complainers,
and they read email from people who complained about it when I left it
off other pages, in the # goes! It's not my design decision to make,
alas.
As for problems with your code, start with the setAttribute problems (IE
has major problems with it) and ditch the eval stuff. Then post a URL to
a sample page that displays the problem.


I would LOVE to ditch the eval, I hate using it. It offends my sense
of programming style and good programming practices. Unfortunately, I
can't think of any other good way to insert the URL at runtime into the
call; since these pages are dynamically generated, I can't specify
ahead of time. I thought of a couple workarounds, but nothing that
seemed any more efficient or graceful than using eval (eg, chucking
things into a global array hashed on the element's ID and calling
GB_show(_URLs[this.id],470,600)). I'd be happy to hear any suggestions
for alternatives.

I did get rid of the setAttribute stuff already tho:

try { //IE will not allow name attribute to be set after element
creation
link =document.createElement("<a name='itemNo|" +intPartId +"'
href='#itemNo|" +intPartId +"' />");
}
catch (e) {
link =document.createElement("a");
link.setAttribute("name","itemNo|" +intPartId);
link.setAttribute("href","#itemNo|" +intPartId);
}
if(link.attachEvent) {
eval("link.attachEvent('onclick',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)");
}
else {
eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470, 600);
return false; },false)");
}

I don't know why FF puts the # in the location bar when IE does not
when it returns false. I suspect FF evaluates both the href and the
onclick, while IE just evaluates the onclick.

Demo page at
http://65.110.86.247/Product_List3.asp
Relevant code is buried at line 82 in
http://65.110.86.247/ajax/js/view/ViewCatalog.js

Go easy on me, as this is only my second attempt at a web application,
and I'm also playing with a strict MVC architecture. :)

Tyler

Jun 19 '06 #10

P: n/a
Logos said the following on 6/19/2006 4:34 PM:
<lol> I am a top poster. I prefer it because it means the newest
material is at the top, so I don't have to actively hunt for the latest
text.


Most of the people here, myself included, are interleaved posters that
ignore top posters.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 20 '06 #11

P: n/a
Logos wrote:
<lol> I am a top poster. I prefer it because it means the newest
material is at the top, so I don't have to actively hunt for the latest
text. I can read previous posts and see the response structure
graphically, so bottom posting is a waste of time in my view.
It may be a "waste of time" for you as the original poster, but for the
people who respond to your and many others threads, and for the casual
readers, it is useful to know what you are replying to, without having
to open other posts in the thread.
Back
when one just had nn and such for newsgroup reading on one's 'nix
terminal, it made a lot more sense, but unless one is in a text only
environment with 80x24 columns, bottom posting is not useful IMO.


I use Thunderbird and it is still useful. And you will think so too when
you search for answers in posts with people that top post.
Jun 20 '06 #12

P: n/a
Hm. I guess I am interleaved, and not top then. If you look, my
previous post is interleaved. To be frank, it seems a fairly minor
issue either way, like code indentation prefs. Not to mention
seriously off topic. :)

Randy Webb wrote:
Logos said the following on 6/19/2006 4:34 PM:
<lol> I am a top poster. I prefer it because it means the newest
material is at the top, so I don't have to actively hunt for the latest
text.


Most of the people here, myself included, are interleaved posters that
ignore top posters.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/


Jun 20 '06 #13

P: n/a
Logos wrote:
Hm. I guess I am interleaved, and not top then. If you look, my
previous post is interleaved. To be frank, it seems a fairly minor
issue either way, like code indentation prefs. Not to mention
seriously off topic. :)


Courtesy is never a minor issue, neither is it ever off-topic.

But if you want to ignore the conventions of this group, by all means,
please do. Odds are the group will end up ignoring you.

--
"The most convoluted explanation that fits all the available and made-up
facts is the most likely to be believed by conspiracy theorists"
Jun 20 '06 #14

P: n/a
I search for answers in posts frequently, and I find the ones that are
top posted to be far easier to read. I can zip down the thread and
always find the releveant material right at the top. Someone doesn't
*have* to open up the other posts to read what I'm responding to, it's
right there - just bottom to top instead of top to bottom. Really,
it's a matter of preference and style. There is no one true posting
methodology, just like there isn't one true indentation methodology.
The benefits of the types are mutually exclusive; which one appeals
most comes down to personal preference. There's no final answer.

Robert wrote:
Logos wrote:
<lol> I am a top poster. I prefer it because it means the newest
material is at the top, so I don't have to actively hunt for the latest
text. I can read previous posts and see the response structure
graphically, so bottom posting is a waste of time in my view.


It may be a "waste of time" for you as the original poster, but for the
people who respond to your and many others threads, and for the casual
readers, it is useful to know what you are replying to, without having
to open other posts in the thread.
Back
when one just had nn and such for newsgroup reading on one's 'nix
terminal, it made a lot more sense, but unless one is in a text only
environment with 80x24 columns, bottom posting is not useful IMO.


I use Thunderbird and it is still useful. And you will think so too when
you search for answers in posts with people that top post.


Jun 21 '06 #15

P: n/a
Logos said the following on 6/21/2006 4:13 PM:
I search for answers in posts frequently, and I find the ones that are
top posted to be far easier to read.
That is your choice and it is not the preferred method in this group. Do
you not understand or comprehend that? Or, do you choose to ignore it
simply to be annoying?
There is no one true posting methodology, just like there isn't one
true indentation methodology.
There are 4 if you want to be picky about it.

Top-posting.
Bottom-posting.
Not-quoting.
Interleaved.
There's no final answer.


It has been given to you several times already.

Do you drive on the left side of the road simply because it's more
comfortable or do you drive where public consensus agrees to drive? The
principle is the same. The regulars in this group have debated it -
repeatedly in the past - and have come to the consensus that
inter-leaved posting is preferred and that top-posting is despised. It
is even covered - explicitly - in the groups FAQ. The fact that you keep
choosing to ignore that is why you have not had your question answered yet.

If you don't play by the rules, you get ignored and run over.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 21 '06 #16

P: n/a
Tony wrote:
Logos wrote:
Hm. I guess I am interleaved, and not top then. If you look, my
previous post is interleaved. To be frank, it seems a fairly minor
issue either way, like code indentation prefs. Not to mention
seriously off topic. :)


Courtesy is never a minor issue, neither is it ever off-topic.

But if you want to ignore the conventions of this group, by all means,
please do. Odds are the group will end up ignoring you.

It's difficult to comply both with Randy and your notions of courtesy.
Randy states that "But, many people in this group complain when people
top post."

You state that "Most of the people here, myself included, are
interleaved posters that
ignore top posters."

So, without knowing who I'm talking to in advance, and not being able
to format in bottom, top and interleaved formats simultaneously, how
can one observe 'courtesy'? Someone is going to be offended no matter
what. This is why this sort of topic is ridiculous and pointless.
Unless you founded the group yourself, or there is a clear FAQ posted
weekly stating the local bylaws, it's incredibly rude to insist that
everyone else follow your own particular set of rules. Usually when a
FAQ is posted weekly it shows up in pretty much every seach of a
newsgroup, or in the listing of recent posting headers, making it easy
for people to observe protocol.

Searching for FAQ just now, which I usually do before posting to most
newsgroups, there was nothing from this year. In fact, in my search
just now the first hit was
"The FAQ - Making my life easier, and the FAQ better." talking about
how to automate it. From Dec of 2001! (discounting the faq for this
newsgroup posted June 19th; my post was on the 16th, and this seems to
be posted in response). So since the FAQ wasn't being constantly
posted, and nothing obvious showed up searching for just FAQ, I don't
think I was being either rude or discourteous.

(http://www.JavascriptToolbox.com is a fantastic page btw, and I've
been referred to it by people and google before on other occasions - I
never realized it hosted a FAQ for this group, though).

Now that I've had the FAQ pointed out to me, I'm happy to abide by it.
But don't chastise me for not following it when it's not readily
available, and when you contradict it yourself.

Tyler

Jun 21 '06 #17

P: n/a
> Now that I've had the FAQ pointed out to me, I'm happy to abide by it.
But don't chastise me for not following it when it's not readily
available, and when you contradict it yourself.


Hm. I apologize for that, I was kind of annoyed and not thinking
clearly about it. He never says anything about what way things SHOULD
be posted, I just assumed that he meant bottom instead of top posting.
But he never acually says one way of the other. Reading the FAQ (which
is hosted on two separate domains, http://www.javascripttoolbox.com/clj
and http://jibbering.com/faq?) does say that interleaving is the
preferred way. Most of the time that's the way I post/reply to email,
too, is the funny part.

But I'd like to reiterate that the FAQ wasn't readily available/obvious
in the group itself, in my defense.

Anyways, I think I've made enough of a jackass of myself here for now,
and appreciate the help that was given earlier, and would appreciate
any further help if anyone still wants to offer it.

Tyler

Jun 21 '06 #18

P: n/a
Logos wrote:
(http://www.JavascriptToolbox.com is a fantastic page btw, and I've
been referred to it by people and google before on other occasions - I
never realized it hosted a FAQ for this group, though).
It doesn't actually host the group's FAQ - it merely points to it at
jibbering.com.
I wrote a "newbie FAQ" to address some of the most common posting complaints
here, as well as a best practices document. These are both hosted on my
site.
Now that I've had the FAQ pointed out to me, I'm happy to abide by it.
But don't chastise me for not following it when it's not readily
available, and when you contradict it yourself.


The fact that people here insist on adherence to the FAQ, yet the document
itself is very outdated and overwhelming is a contradiction which many
choose to ignore. Stale documentation is sometimes worse than no
documentation at all.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jun 21 '06 #19

P: n/a
JRS: In article <e4******************************@comcast.com>, dated
Wed, 21 Jun 2006 16:31:05 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :
Do you drive on the left side of the road simply because it's more
comfortable or do you drive where public consensus agrees to drive?
In my case, both, really; and it's nice as the driver to be sitting
nearer the middle of the road.

comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly


Your last word needs updating.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jun 22 '06 #20

P: n/a
Logos wrote:
However, I discovered that my code worked fine in IE (no # in URL after
click), but not in FF (# appears in URL after click). Can anyone tell
me why?

Tyler


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).

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

Jeremy
Jun 22 '06 #21

P: n/a
> 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

Jun 22 '06 #22

P: n/a
Dr John Stockton said the following on 6/22/2006 1:28 PM:
JRS: In article <e4******************************@comcast.com>, dated
Wed, 21 Jun 2006 16:31:05 remote, seen in news:comp.lang.javascript,
Randy Webb <Hi************@aol.com> posted :
<snip>
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly


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
comp.lang.javascript FAQ -
http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 22 '06 #23

P: n/a
Jeremy said the following on 6/22/2006 2:29 PM:
Logos wrote:
However, I discovered that my code worked fine in IE (no # in URL after
click), but not in FF (# appears in URL after click). Can anyone tell
me why?

Tyler

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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 22 '06 #24

P: n/a
Randy Webb wrote:
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
Jun 22 '06 #25

P: n/a
Jeremy <je*****@uci.edu> writes:
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 - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jun 22 '06 #26

P: n/a
Jeremy <je*****@uci.edu> writes:
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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jun 22 '06 #27

P: n/a
Lasse Reichstein Nielsen wrote:
Jeremy <je*****@uci.edu> writes:

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
Jun 22 '06 #28

P: n/a
Jeremy wrote:
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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jun 22 '06 #29

P: n/a
Matt Kruse wrote:
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
Jun 22 '06 #30

P: n/a
Jeremy said the following on 6/22/2006 4:48 PM:
Randy Webb wrote:
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?


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 23 '06 #31

P: n/a

Randy Webb wrote:
Jeremy said the following on 6/22/2006 4:48 PM:
Randy Webb wrote:
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?


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

Jun 23 '06 #32

P: n/a
Jeremy wrote:
Lasse Reichstein Nielsen wrote:
Jeremy <je*****@uci.edu> writes:

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).

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.
Jun 23 '06 #33

P: n/a
Logos wrote:
Randy Webb wrote:
Jeremy said the following on 6/22/2006 4:48 PM:
Randy Webb wrote:

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?


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.


Read my reply to Jeremy to see he made a mistake.
Jun 23 '06 #34

P: n/a
Logos wrote:
Robert wrote:
Logos wrote:
In the generated source the link looks like this, btw:

<a href="#" class="rCatalogHeadSortable"
onclick="ts_resortTable(this);return false;">

And does any javascript error occur in Firefox?
Because if it occurs then the "return false" will never be executed.

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.
Jun 23 '06 #35

P: n/a
Logos wrote:
Randy Webb wrote:
Jeremy said the following on 6/22/2006 4:48 PM:
Randy Webb wrote:

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?
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.


I would say that most of us started out that way. It gets VERY tiring,
though, after many months (in my case) or even years (in Randy's case)
to keep answering the SAME BASIC questions and dealing with the SAME
FUNDAMENTAL javascript issues 3-4 times every week.
Blunt, short answers saying
things like "That's incorrect" don't inspire nor really help the person
learn anything new.
While I can't speak for others, I'm not here to be a teacher. If you
want me to TEACH you javascript, then you can pay me by the hour. If you
want to discuss javascript programming, then at least make the effort to
understand the basics on your own - because, frankly, if you can't do
that much, then nothing I contribute is going to help.

As for not inspiring people to learn anything new - I suppose that's up
to the individual. I, for one, have made it a point to really look into
a subject before posting here for help, simply because I DON'T want
those sort of answers.
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?
Probably by reading the archives. Or maybe doing some research on their own.
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.
You seem to like calling things off-topic, I've noticed. I contend that
subjects like this constitute a meta-topic, and are therefore quite
on-topic for the group. As for it being pointless - maybe, maybe not.
What's pointless to you might not be to others.
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


Well, then - see? I'd say you have a perfect right to hijack your own
thread if you want :)
--
"The most convoluted explanation that fits all the available and made-up
facts is the most likely to be believed by conspiracy theorists"
Jun 23 '06 #36

This discussion thread is closed

Replies have been disabled for this discussion.