href="javascript:func()" vs href="#" onclick="javascript:func()"

C

CRON

Howdy!
I was wondering which is better to use:

href="javascript:func()"

OR

href="#" onclick="javascript:func()"

Problem is the second one, anchors to the top of the page which is very
messy in most cases.

Thanks
Ciaran ;c)
 
J

Jonathan N. Little

CRON said:
Howdy!
I was wondering which is better to use:

href="javascript:func()"

OR

href="#" onclick="javascript:func()"

Problem is the second one, anchors to the top of the page which is very
messy in most cases.

Better to have

<a href="someRealUrl" onclick="return someJavaScriptFunction()">...

That way if someone has JavaScript disabled they are not left wondering
why the link goes nowhere!
 
C

CRON

Cheers again Jonathan,
But what if you don't want the link to go anywhere? If it is solely
there to run the javascript function? Is there anything wrong with
href="javascript:func()" ? It is simple and clean and makes more sense
to me.

Ciaran
 
D

Dan

CRON said:
Cheers again Jonathan,
But what if you don't want the link to go anywhere? If it is solely
there to run the javascript function? Is there anything wrong with
href="javascript:func()" ? It is simple and clean and makes more sense
to me.
[top-posting snipped -- http://mailformat.dan.info/quoting/ ]

In many (most?) cases, the JavaScript link is there to bring up some
content in some fancy way (like in a popup box), so it would make sense
to have a valid link URL as a graceful degradation in the case of
non-JavaScript-enabled users.

Your function can end with "return false;" in order to suppress the
normal link, so it won't do something annoying like jump around in the
page when JavaScript is enabled.
 
C

CRON

That's a good way to deal with it - Never thought of that before.
Thanks a bunch Dan,
Ciaran
 
C

CRON

Best solution found::::

<a href="#" onclick="func();return false">

This is a handy way to stop the page from jumping around but still run
the function.
 
R

Richard Cornford

CRON said:
Howdy!
I was wondering which is better to use:

href="javascript:func()"

The only circumstances under which you should consider using a
javascript: pseudo-protocol HREF is when the expression evaluates as a
string of HTML that it intended define the replaced content of the
current page (or the entire contents of a new window), and mostly not
even then as the result is inevitably javascript dependent.

A significant practical reason for this is that some browsers (and
importantly including windows IE browser) regard the activation of such
a link as navigation. A consequence of this apparent navigation is that
the browser puts the current page into a 'waiting' state in anticipation
of the navigation resulting in the current page being replaced. In this
'waiting' state some resource hungry activity is closed down by the
browser.

The simplest demonstration of this phenomenon is to create a page
containing an animated GIF and a link with a javascript pseudo-protocol
HREF, load it into IE 6, and observe that the animated GIF promptly
stops animating as soon an the HREF is activated.

The list of things that stop working as expected once a javascript
pseudo-protocol HREF has been activated includes META refresh stopping
working, Flash-javascript interaction problems, image swapping and
pre-loading issues and a number of other scripting related issues.
Indeed the consequences of the use of javascript pseudo-protocol HREF
regularly feature in questions asked in the comp.lang.javascript
newsgroup, although no comprehensive list of related issues has been
created because the general conclusion is that such links should never
be used and once their use has ceased no consequential issues remain to
be studied.
OR

href="#" onclick="javascript:func()"

In javascript syntax the "javascript:" at the beginning of that onclick
attribute's value is a label, used with the - continue - and break -
statements to define the exit points of loops. The rest of the attribute
value contains no loops, continue or break statements, so the label is
redundant.

Microsoft took advantage of this construct being syntactically valid in
javascript to allow this label to be used to define the type of
scripting language that would be used to interpret the value of the
onclick attribute, but they also made JScript the default, so unless an
alternative scripting language is used on a page in a way that stops
JScript being the default the label is still redundant on Microsoft
browsers.

This also means that if a label is wanted in the value of an intrinsic
event attribute 'javascript' is the one label that should never be used
(well, not the 'one' as 'vbscript', or the name of any other installed
scripting language, would also be a bad ideal).
Problem is the second one, anchors to the top of the
page which is very messy in most cases.

Only if you don't cancel the default action of the link.

Of the two the second is better because the former should never be used.
The latter would be improved by having an ability to cancel the link,
preferably conditionally.

Ultimately the best option may be to use some other sort of element
(i.e. <input type="button">) to trigger activity that is not navigation.

Richard.
 
N

Neredbojias

Best solution found::::

<a href="#" onclick="func();return false">

This is a handy way to stop the page from jumping around but still run
the function.

FYI, another best way is:

<a href="javascript:void(0)" onclick="func()">
 
J

Jukka K. Korpela

Neredbojias said:
FYI, another best way is:

<a href="javascript:void(0)" onclick="func()">

The first "best solution" is a link to the start of the page, with a
scripted that overrides the link functionality with the invocation of a
function, when scripting is enabled. That does not sound quite logical to
me. A self-referencing link would be slightly more logical as well as much
more practical when scripting is disabled:
<a name="foo42" href="#foo42" onclick="func();return false">
Of course, if the sole purpose of the "link" is the scripted event, then the
link should be dynamically generated using the scripting language, so that
the link is there if and only if scripting is enabled. In that case, you
could use href="error.html" where error.html is a page that explains that an
unexpected error has occurred, etc.

Using href="javascript:void(0)" does not conform to any published
specification, since there is no such spec that defines javascript: URLs.
Besides, it fails even on some old browsers that do not recognize such URLs
(or pseudo-URLs), despite supporting JavaScript.
 
A

Adrienne Boswell

Using href="javascript:void(0)" does not conform to any published
specification, since there is no such spec that defines javascript:
URLs. Besides, it fails even on some old browsers that do not
recognize such URLs (or pseudo-URLs), despite supporting JavaScript.

Yes, and it even fails on some modern browsers, like Opera. AFAIK, Opera
doesn't like href="javascript:anything". Opera is my default browser, and
I'm redoing a site that has tons of links like this - none of 'em work - so
I am replacing them with plain hrefs.
 
J

Jim Higson

CRON said:
Best solution found::::

<a href="#" onclick="func();return false">

This is a handy way to stop the page from jumping around but still run
the function.

The best way I'd say is to not include any link in the page, but then add it
in using javascript once the page has loaded.

Or, if the link must be created on the server-side, try something like:

<a href="javascript:whatever()" style="display:none" id="js-link">blah</a>
<script type="text/javascript">
var link_ele = document.getElementById( "js-link" );
link_ele.setAttribute( "sytle", "" );
</script>

This way, the link will only be shown if the user has javascript enabled.
 
D

David Dorward

CRON said:
But what if you don't want the link to go anywhere?

The point is links is to go somewhere. If you don't want to go somewhere,
then don't use a link (or link to a page explaining /why/ JavaScript is
required - and I suggest phrasing it as an apology, don't insult the user
for disallowing untrusted third party program code from running on their
computer). A large number of the really useful things that JavaScript can
do can be done server side too, so a server side alternative is a good
fallback URL.
 
J

Jonathan N. Little

David said:
Or stylesheets disabled or unavailable.

Better would be use JavaScript to actually insert the link code, then
and only then when JavaScript enabled would the link appear.
 
J

Jim Higson

David said:
Or stylesheets disabled or unavailable.

Like I said in the grandparent post, a better way still is to create the
link altogether in js using DOM. Something like:

<span id="link-placeholder" />
<script type="text/javascript">
var a_ele = document.createElement ( 'a );
a_ele.setAttribute( 'href', 'javascript:whatever()' );
a_ele.appendChild( document.createTextNode( 'blah' ));

var placeholder_ele = document.getElementById( "screensaver-intro" );
placeholder_ele.parentNode.replaceChild( a_ele, placeholder_ele );
</script>

Now, I think that covers all bases?
 
J

Jonathan N. Little

Jim said:
JaavScip
Like I said in the grandparent post, a better way still is to create the
link altogether in js using DOM. Something like:

<span id="link-placeholder" />
<script type="text/javascript">
var a_ele = document.createElement ( 'a );
a_ele.setAttribute( 'href', 'javascript:whatever()' );
a_ele.appendChild( document.createTextNode( 'blah' ));

var placeholder_ele = document.getElementById( "screensaver-intro" );
placeholder_ele.parentNode.replaceChild( a_ele, placeholder_ele );
</script>

Now, I think that covers all bases?

Well to be precise you only use JavaScript in that post to remove the
element's styling that was hiding it...not to create the link.
 
N

Neredbojias

To further the education of mankind, "Jukka K. Korpela"
The first "best solution" is a link to the start of the page, with a
scripted that overrides the link functionality with the invocation of
a function, when scripting is enabled. That does not sound quite
logical to me. A self-referencing link would be slightly more logical
as well as much more practical when scripting is disabled:
<a name="foo42" href="#foo42" onclick="func();return false">

In other words, clicking the link with javascript disabled will reload
the page and return the user to the same spot from which he started.
Sounds good.
Of course, if the sole purpose of the "link" is the scripted event,
then the link should be dynamically generated using the scripting
language, so that the link is there if and only if scripting is
enabled.

I very much agree. Similarly, I've done many pages with, for example,
(pseudo) lists of thumbnail image links. There is no javascript to be
seen in the html per se; any j/s events, etc., are added afterwards by a
link-loop which, of course, does nothing with j/s disabled.
In that case, you could use href="error.html" where
error.html is a page that explains that an unexpected error has
occurred, etc.

Using href="javascript:void(0)" does not conform to any published
specification, since there is no such spec that defines javascript:
URLs. Besides, it fails even on some old browsers that do not
recognize such URLs (or pseudo-URLs), despite supporting JavaScript.

Well, javascript:void is a core javascript construct, and if the browser
supports javascript... Perhaps there is no _specific_ _html_ spec citing
"javascript:void" verbatim, but I hardly consider that a good reason to
avoid it's usage. There is much documentation written regarding this
usage which certainly seems acceptable and valid by all parties
concerned.

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5
_Reference:Operators:Special_Operators:void_Operator
 
P

Philip

CRON said:
Best solution found::::

<a href="#" onclick="func();return false">

This is a handy way to stop the page from jumping around but still run
the function.

Since Javascript is apparently a requirement for this page to operate
correctly, you might want to include a noscript block at the top like so:

<noscript>
<div>O ye pitiful mortal, thou art humbled before my site! Begone, and
return only with a browser which supporteth Javascript!
</div>
</noscript>

Or something a little less ridiculous. I think you get the picture.

Cheers
 
J

Jukka K. Korpela

Neredbojias said:
Well, javascript:void is a core javascript construct,

Really? I thought core javascript was ECMAScript.
Perhaps there is no _specific_ _html_
spec citing "javascript:void" verbatim, but I hardly consider that a
good reason to avoid it's usage.

By HTML specifications, the content of an href attribute is a URL (or a
URI), so a specification of the javascript: _URL_ would be needed. This
would not be part of HTML _or_ JavaScript but a separate specification;
normally URL specifications are published as RFCs. It would of course
specify it as a pseudo-URL, which is a URL syntactically only. Anyway, there
is no such specification.
There is much documentation written
regarding this usage which certainly seems acceptable and valid by
all parties concerned.

Browser vendors' documents are not specifications.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,832
Latest member
GlennSmall

Latest Threads

Top