A tag: href vs. onClick

[Randy Webb]

VK said the following on 10/24/2005 10:39 AM:

Who said that?!? Not me.
javascript: p-protocol is a great thing. You just need to know how it
works and enjoy ever after.

And you also need to know it's problems and limitations.

1) javascript:someFunction() means: "execute someFunction and replace
current page by content from someFunction's return value". Thusly if
someFunction returns null, you'll end up with a blank page with the
proud word "null" written in the top left corner.

It means all that plus "and give a non-JS browser a useless blank page".

2) javascript:void(someFunction()) means: "where will be no new content
provided, just stay where you are; and by the way execute
someFunction".

It means all that plus "and give a non-JS browser a useless blank page".

Despite what some people says, void() operand *doesn't return* neither
null, nor undefined. As its name suggests it does not return any values
whatsoever. This is how it works in Java also (there this idea has been
taken from).
Yes if you try to assign
var foo = void(something);
then you'll get undefined. But it's the same "pseudo-value" as in case:

var arr = new Array(1,2,3);
var foo = arr[1000]; // the same undefined as with void()

<a href="noJS.html" onclick="alert('This doesnt break without JS, you
just dont see the alert')">Test Me</a>

Why make it more difficult than it has to be?

 

[Lee]

Randy Webb said:

VK said the following on 10/24/2005 10:39 AM:

It means all that plus "and give a non-JS browser a useless blank page".

<a href="noJS.html" onclick="alert('This doesnt break without JS, you
just dont see the alert')">Test Me</a>

Why make it more difficult than it has to be?

It's very handy sometimes. You simply restrict its use to pages
which are only reached if Javascript is enabled.

 

[Richard Cornford]

Who said that?!? Not me.
javascript: p-protocol is a great thing. You just need to
know how it works and enjoy ever after.

1) javascript:someFunction() means: "execute someFunction
and replace current page by content from someFunction's
return value".

In the event that the function call returns undefined the current page
will not be replaced.

Thusly if someFunction returns null, you'll end up with
a blank page with the proud word "null" written in the
top left corner.

That depends a great deal on the browser being used.

2) javascript:void(someFunction()) means: "where will be
no new content provided, just stay where you are; and by
the way execute someFunction".

Despite what some people says,

Those people being the authors of ECMA 262; the standard implemented by
JavaScript, JScript and every other javascript-like browser scripting
language produced in at least the last five years?

void() operand

void is an operator, not an operand. And - void() - is a syntax error
(because the Expression contained in the parentheses of the grouping
operator is not optional).

*doesn't return* neither null, nor undefined.

Expressions do not return values, they evaluate to values. The
algorithms that define the behaviour of operators return values, but
those values become the evaluated result of the expression. The
algorithm for void reads:-

<quote cite="ECMA 262, 3rd edition: section 11.4.2">
11.4.2 The void Operator

The production UnaryExpression : void UnaryExpression is
evaluated as follows:

1. Evaluate UnaryExpression.
2. Call GetValue(Result(1)).
3. Return undefined.
</quote>

So ECMA 262 certainly does assert that the UnaryExpression;- void
UnaryExpression - evaluates to the primitive value Undefined, without
exception.

As its name suggests it does not return any
values whatsoever. This is how it works in Java also
(there this idea has been taken from).
Yes if you try to assign
var foo = void(something);

The value - Undefined - can be, and in this case is, explicitly assigned
as the value of a defined proeprty.

then you'll get undefined. But it's the same "pseudo-value"
as in case:

In javascript - Undefined - is an explicit value, it is one of the 5
primitive types and, like - null -, it only has one value.

var arr = new Array(1,2,3);
var foo = arr[1000]; // the same undefined as with void()

JavaScript is just too samplified and user-friendly to
bother you (and itself) with fine details.

You mean that you are too samplified to bother yourself with fine
detail.

So it just gives you undefined every time you're trying
to go beyond the scope of the program or to get return
value from something that doesn't have it by definition
or do something equally bizarre ;-)

"Every time"? So no Exceptions then?

Richard.

 

[Thomas 'PointedEars' Lahn]

Randy Webb said:

It's very handy sometimes. You simply restrict its use to pages
which are only reached if Javascript is enabled.

And how do you make sure that those "pages" are not reached by a user
without JS-enabled user agent? You can't. The more "intelligent" the
indexing engine used is, the more likely is that this user will find
them.


PointedEars

 

[Thanatos]

Great discussion guys. I moved a lot a my website to
href="javascript...)" because at the time it seemed more widely
supported than href="#" onClick="...."

The href="#" seemed to behave strangly at times. Now with my latest
version of IE(6.0.2800.1106) the Javscript function is actually
displayed in the address bar! Although Firefox does not do this, lets
face it, it's going to look a bit ugly for most users.

So I'm wondering what I should do now

Some Javascript URIs load new pages and from the guist of this
discussion, it should be ok to leave these alone. The problem is with
javascript URI's that popup a new window. Appart from looking ugly they
also *break* the original page if the javascript URI is too long!

So, and here's my question, what should my HREF target be? I don't want
to go back to "#" and the "js_error.html" page idea seems a bit too
cute. Is there a specific recomendation?

Regards

 

[Evertjan.]

Thanatos wrote on 25 okt 2005 in comp.lang.javascript:

[....]

So, and here's my question, what should my HREF target be? I don't want
to go back to "#" and the "js_error.html" page idea seems a bit too
cute. Is there a specific recomendation?

Just do not use a <a but a <div

<div onclick='location.href="http://"+thePage'
onmouseover='window.status="Goto the Page"'
onmouseout='window.status=""'>
Goto the Page</div>

The only reasons IMHO to use <a onclick=.. are:

1 giving a reasonable js-off alternative

2 not wanting to miss simple a:hover, etc. css capability

 

[VK]

Great discussion guys. I moved a lot a my website to
href="javascript...)" because at the time it seemed more widely
supported than href="#" onClick="...."
The href="#" seemed to behave strangly at times.

An anonymous anchor (href="#") is made as synonyme of the page top (at
least in IE). So on a big page it will lead to the page scroll each
time you're clicking a href="#" link.
This option as well as self-linked link <a href="#foo" name="foo"> has
been explorer and failed to be usable long time ago. From Netscape Gold
(3.0) and untill the last buttles of the Browser Wars the only reliable
way remainded by using specially introduced void operator:
<a href="javascript:void(myFunction())".
It was used for years and on millions of *professional* pages. Neither
the fact that event cancelling became finally reliable enough to be
used instead; nor the fact that in 1999 ECMA decided to put in writing
(at the best of their limited capabilities) Netscape inventions;
doesn't make this technique illegal overnight.
IMHO

 

[VK]

giving a reasonable js-off alternative

I'm not sharing this big fuss over "what if JavaScript/JScript is
disabled". Yes ideally *each site* has to have three incarnations:
1. Full features version
2. JS-off version
3. Terminal version (for Lynx-like browsers)

As no one customer in semi-good mind will no pay triple rate for these
academical twists (unless his particular auditory or his government
requires it) we should just skip on this idea. Then I don't see any
reason to fill the whole site with links on a nug screen "JavaScript
required". Your visitors are not complet idiots and one bold red
message at the top is more than enough:
....
<body>
<noscript>
<!-- Using ancient font formatting also for CSS disabled -->
<h3><font color="#FF0000">! This page requires JavaScript enabled to
work properly.</font></h3>
</noscript>
....

Animated GIF issue

Yes there is currently a bug in IE:
clicking javascript:void(something) link halts image sequence loop in
GIF89a images. It's a rendering engine bug not a javascript: p-protocol
issue. FF doesn't have this bug.

 

[Matt Silberstein]

On Mon, 24 Oct 2005 17:48:22 -0400, in comp.lang.javascript , Randy
Webb <[email protected]> in <[email protected]>
wrote:

[snip]

Why make it more difficult than it has to be?

I understand your feeling, but you are going against thousands of
years of human history.

--
Matt Silberstein

Do something today about the Darfur Genocide

Genocide is news | Be A Witness
http://www.beawitness.org

"Darfur: A Genocide We can Stop"
www.darfurgenocide.org

Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/

 

[Randy Webb]

Matt Silberstein said the following on 10/25/2005 11:38 AM:

On Mon, 24 Oct 2005 17:48:22 -0400, in comp.lang.javascript , Randy
Webb <[email protected]> in <[email protected]>
wrote:

[snip]

Why make it more difficult than it has to be?

I understand your feeling, but you are going against thousands of
years of human history.

"thousands of years of human history" is what makes people want to make
a link not work versus working? Thats not even close to intuitive.
Unless you are referring to people trying to make things harder than
they have to be. In that case, it is typically incompetent programmers
that try to make things harder than they are so they can say something
to the effect of "Look, I wrote this long code" instead of "This one
line does it, it was simple".

Has nothing to do with human history.

 

[Lasse Reichstein Nielsen]

I do not believe that handling href="javascript: was in the beginnings
of the browsers.

Trivially, since Javascript wasn't introduced until Netscape 2.

It was an afterthought (a very poorly thought out
one) when scripting came along. And it was introduced before the
onclick event handler as a way to allow a link to activate a
script.

No. Both were in Netscape 2. The "javascript:" pseudo-protocol was
introduced to allow replaceing the page with a string generated by
Javascript code, whereas the onclick event was introduced to do
something when a link (or something else) was clicked.

Now, there is no need for that use.

Only for its original intent at least, but that is so very rarely a
reasonable thing to do, that it's pretty much the same as no need.

As for why the browser vendors leave the support in, who
knows. Probably the same reason they leave eval support in.

That would alse be because eval() is part of ECMAScript.

But even if my intentions were to replace the entire contents of the
page via script, I still wouldn't use a href="javascript: construct to
do it.

There are safer, and much easier, ways.

/L

 

[Lasse Reichstein Nielsen]

Despite what some people says, void() operand *doesn't return* neither
null, nor undefined. As its name suggests it does not return any values
whatsoever.

It returns nothing, since it is not a function. It is an operator,
taking a single operand, and always evalutaing to the value "undefined".

This is how it works in Java also (there this idea has been
taken from).

Idea, yes. How it works in Java ... quite different.

In Java, "void" is only usable as the return "type" of a method,
meaning that the method does not return a value. That means that
a call to the method cannot be used in a context where a value
is expected (i.e., an expression context).

Yes if you try to assign
var foo = void(something);
then you'll get undefined. But it's the same "pseudo-value" as in case:

var arr = new Array(1,2,3);
var foo = arr[1000]; // the same undefined as with void()

They have to be the same, since the type "undefined" has only one
value.

The operator "void" is an unary prefix operator, that evaluates its
operand expression and evaluates to the *value* "undefined" (the
single value of the type "undefined").

The property access operator evaluates its two operands, then converts
the first to an object (if it's not already) and the second to a
string, and calls the internal [Get] method on the first with the
second operand as argument.
In this case, the [Get] method of the array object will find that it
has no property called "1000", and return the *value* "undefined". This
is the value of the property access operator.


So, in Javascript, the "undefined" type has exactly one value. The "void"
operator evaluates to that value. In Java, the "void" type has no values.

/L

 

[Michael Winter]

An anonymous anchor (href="#") is made as synonyme of the page top (at
least in IE).

Fragment (not anchor) semantics are defined by the media type. In this
case, that is HTML and it does not account for empty fragments. If a
'top' link is desired, then either an anchor or an id attribute should
be included near the start of the document and explicitly linked.

An empty fragment is used because at worst the document will scroll, and
at best nothing will happen.

[snip]

<a href="javascript:void(myFunction())".
It was used for years and on millions of *professional* pages.

That doesn't really mean anything. There are millions of badly written
HTML files floating around the Web, written by companies that would
describe themselves as 'professional'.

[...] the fact that event cancelling became finally reliable enough
to be used instead; [...] doesn't make this technique illegal
overnight.

It's not illegal, but it is ill-advised. As for 'overnight', it wasn't
necessary years ago.


Rather than reply to your second post separately, I'll continue below.

I'm not sharing this big fuss over "what if JavaScript/JScript is
disabled". Yes ideally *each site* has to have three incarnations:
1. Full features version
2. JS-off version
3. Terminal version (for Lynx-like browsers)

No-one, to my knowledge, has ever proposed writing separate versions of
a site (except when it comes to all-Flash sites, but that's a different
matter). A single version can accommodate all of those conditions when
written properly.

Well-written markup, when coupled with CSS, will look as envisaged for
the 'average' visitor and those with settings close to the norm. It will
also degrade properly when images or CSS are disabled or unavailable, or
if overridden by user style sheets.

A similar situation exists for client-side scripting. With feature
detection, the script will either execute fully, degrade to a lesser
state (if appropriate), or not run at all (with no errors). The last two
states deal with browsers that either have client-side scripting
disabled entirely or not implemented at all, or don't support requisite
features (a situation you seemed to have overlooked).

[snip]

Then I don't see any reason to fill the whole site with links on a
nug screen "JavaScript required".

That shouldn't be necessary anyway. There are few occasions when
client-side scripting should be required on the Web (scripting
demonstrations are one of those exceptions).

Your visitors are not complet idiots [...]

Perhaps, but that doesn't mean they'll know what JavaScript is or how to
enable it. Don't forget that not everyone will have the ability to
choose, anyway (within offices, libraries, etc.)

[snip]

<!-- Using ancient font formatting also for CSS disabled -->

Why? You don't want to suggest a fourth, 'CSS disabled' version, do you?

[snip]

Yes there is currently a bug in IE:
clicking javascript:void(something) link halts image sequence loop in
GIF89a images. [...]

That's not necessarily a bug at all. In fact, it's quite reasonable to
stop animation if the user activates a link or some other navigation
mechanism. They are, after all, supposed to take the user to some other
resource.

Mike

 

[Matt Silberstein]

Matt Silberstein said the following on 10/25/2005 11:38 AM:

On Mon, 24 Oct 2005 17:48:22 -0400, in comp.lang.javascript , Randy
Webb <[email protected]> in <[email protected]>
wrote:

[snip]

Why make it more difficult than it has to be?

I understand your feeling, but you are going against thousands of
years of human history.

"thousands of years of human history" is what makes people want to make
a link not work versus working? Thats not even close to intuitive.
Unless you are referring to people trying to make things harder than
they have to be.

Give the man a cigar.

In that case, it is typically incompetent programmers
that try to make things harder than they are so they can say something
to the effect of "Look, I wrote this long code" instead of "This one
line does it, it was simple".

I think we have more of a problem with "small" tricky code than long
code.

Has nothing to do with human history.

Nay, people have been making things harder than they need to be for
thousands of years. Programmers are only a small subset of that.

--
Matt Silberstein

Do something today about the Darfur Genocide

Genocide is news | Be A Witness
http://www.beawitness.org

"Darfur: A Genocide We can Stop"
www.darfurgenocide.org

Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/

 

[Thomas 'PointedEars' Lahn]

Great discussion guys. I moved a lot a my website to
href="javascript...)" because at the time it seemed more widely
supported than href="#" onClick="...."

Bad decision.

The href="#" seemed to behave strangly at times. Now with my latest
version of IE(6.0.2800.1106) the Javscript function is actually
displayed in the address bar!

It is not here. If it is with you, the respective code is b0rken.

Although Firefox does not do this, lets
face it, it's going to look a bit ugly for most users.

Properly canceling the event in the event handler attribute will not show
the code to the less experienced user, not even in the address or status
bar. In no JS-enabled browser that I know.

So I'm wondering what I should do now

Have all elements dependent on client-side scripting generated by it
(thus saving the no-script user trouble) while having all "javascript:"
replaced with `onclick' event handler attributes (without containing
`javascript:', of course).

So, and here's my question, what should my HREF target be?

"#" appears to be the best choice since empty URI references are specified
by RFC3986, but not the user agent's behavior when used as `href' attribute
value.

I don't want to go back to "#"

There is no valid reason left why you should not.

and the "js_error.html" page idea seems a bit too cute.

I would bother with being "too cute" on my Web content if it means to
maintain interoperability.

Is there a specific recomendation?

Yes, as written several times.


PointedEars

 

[VK]

So, and here's my question, what should my HREF target be?

"#" appears to be the best choice since empty URI references are specified
by RFC3986, but not the user agent's behavior when used as `href' attribute
value.


There is no valid reason left why you should not.

Specially for people with reading problems:

ANY REFERENCE TO A NAMED ANCHOR WITHOUT ANCHOR NAME ASSIGNED AFTER THE
POUND SIGN (#) REFERS TO THE TOP OF THE CURRENT PAGE (THE AREA RIGHT
AFTER THE <BODY> TAG). THIS LEADS TO THE PAGE SCROLL IF THE PAGE BIG
ENOUGH. THIS IS WHY <a href="#"...> CANNOT BE USED ANYHOW RELIABLY AS A
PSI-LINK.

Please check this in any decent browser of your choice:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF">

<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p><a href="#" onclick="alert('test')">test</a></p>
</body>

Yes, as written several times.

But still not enough times I guess...

 

[Matt Silberstein]

So, instead of referencing #, should one put an anchor at the link and
reference that? That is, make the non-JavaScript link just go right
were it is?


--
Matt Silberstein

Do something today about the Darfur Genocide

Genocide is news | Be A Witness
http://www.beawitness.org

"Darfur: A Genocide We can Stop"
www.darfurgenocide.org

Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/

 

[Thomas 'PointedEars' Lahn]

Specially for people with reading problems:

ANY REFERENCE TO A NAMED ANCHOR WITHOUT ANCHOR NAME ASSIGNED AFTER THE
POUND SIGN (#) REFERS TO THE TOP OF THE CURRENT PAGE (THE AREA RIGHT
AFTER THE <BODY> TAG). THIS LEADS TO THE PAGE SCROLL IF THE PAGE BIG
ENOUGH. THIS IS WHY <a href="#"...> CANNOT BE USED ANYHOW RELIABLY AS A
PSI-LINK.

Where does this wisdom come from (missing reference) and why do you have
it to CRY upon the world?

Anyhow, I wrote that href="#" is to be used *only* for elements that
*require* client-side script support to be enabled, that those elements
should be generated by client-side script and that the click event has
to be canceled in that case.

Please check this in any decent browser of your choice:

Above I wrote about specifications, not implementations.

Now who is the one of us with the reading problem?


PointedEars

 

[Lee]

Matt Silberstein said:

So, instead of referencing #, should one put an anchor at the link and
reference that? That is, make the non-JavaScript link just go right
were it is?

Put yourself in the place of a visitor who has clicked what appears
to be a hypertext link. Which would you prefer:

a) the page scrolls to the top.

b) the page shifts slightly or nothing happens

c) a new page appears, explaining that the "link" won't work for you
because you don't have scripting enabled, apologizing for not
having provided alternative functionality, and possibly explaining
how to enable scripting in some of the more common browsers

I can tell you that if either of the first two happens to me, I lose
faith in that web site. I certainly wouldn't trust it to handle my
credit card information safely.

You might also consider the option of not having the active text
even appear to be a hypertext link unless Javascript is enabled.

 

[Thomas 'PointedEars' Lahn]

So, instead of referencing #, [..]

Don't let yourself be confused by VK's rambling. href="#" is the
method of choice *provided* all other conditions mentioned are met.


PointedEars