A tag: href vs. onClick

us****@vikas.mailshell.com said the following on 10/22/2005 11:00 PM:

See

<ul>
<li><a name="link1" onClick="alert(this.name);return false;"
href="#">Link1</a></li>
<li><a name="link2" href="javascript:alert(this);">Link2</a></li>
<li>Item 3</li>
</ul>

Clicking on the first list item gives me "link1" because "this" refers
to the A node so this.name returns the value of the name attribute of
that node.

But in the second link, "this" seems to refer to the window node!
Yeppers. Because the javascript: pseudo-protocol is executed in the
global context.
Why is this? Why does the meaning of "this" change so drastically when
used in a href=javascript: vs. a onClick=

this doesn't change, what changes is the context in which it is executed.

Don't use javascript:, use the onclick and you don't have that problem.

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

us****@vikas.mailshell.com said:

See

<ul>
<li><a name="link1" onClick="alert(this.name);return false;"
href="#">Link1</a></li>
<li><a name="link2" href="javascript:alert(this);">Link2</a></li>
<li>Item 3</li>
</ul>

Clicking on the first list item gives me "link1" because "this" refers
to the A node so this.name returns the value of the name attribute of
that node.

But in the second link, "this" seems to refer to the window node!

Why is this? Why does the meaning of "this" change so drastically when
used in a href=javascript: vs. a onClick

The onclick handler is a method of the link. The "javascript:"
pseudo-protocol is a mechanism for loading new content into the page.
For example:

<a href="javascript:(new Date()).toLocaleString()">What time is it?</a>

Using it to execute arbitrary functions is a perversion of its intended
function. Since it is loading new content into the page, the page
(ie, the window) is its execution context.

> <a name="link2" href="javascript:alert(this);">Link2</a>

<a href="javascript:(new Date()).toLocaleString()">What time is it?</a>

I'd just like to point again that you *never ever* should use
javascript:someFunction() syntacs. The only place and time for it is
when you're replacing the current page by a new HTML page generated by
someFunction.

To call JavaScript from javascript: while staying on the same page you
have to use void() wrapper:
javascript:void(whateverYouWant)
Otherwise it's going to be a gross misuse of javascript:
pseudo-protocol.

us****@vikas.mailshell.com wrote:

Why is this? Why does the meaning of "this" change so drastically when
used in a href=javascript: vs. a onClick=

Because it relies on `javascript:', a proprietary, almost undocumented URI
scheme. Implementors cannot be blamed in any way if they do not implement
code attached there to be run in the context of the element object that
fired the event but instead in the global context (and so have pointing
`this' to the Global Object instead which happens to be the current
`window' object in most/all HTML DOMs).
HTH

PointedEars

VK wrote:

<a name="link2" href="javascript:alert(this);">Link2</a>

<a href="javascript:(new Date()).toLocaleString()">What
time is it?</a>

I'd just like to point again that you *never ever* should use
javascript:someFunction() syntacs. The only place and time
for it is when you're replacing the current page by a new
HTML page generated by someFunction.

To call JavaScript from javascript: while staying on the same
page you have to use void() wrapper:
javascript:void(whateverYouWant)
Otherwise it's going to be a gross misuse of javascript:
pseudo-protocol.

The void operator produces an expression that results in the value -
Undefined -. It takes the value of its operand and throws it away, and
evaluated to Undefined instead. Whenever a function call is that
operand, and that function itself returns - Undefined -, using that
function call as an operand to - void - is redundant and pointless.

If the value of the expression was such that not applying the - void -
operator would result in the replacement of the current document, and
the replacement of the current document was not desired, then applying
the - void - operator would make sense. But suggesting that all function
calls used in a javascript pseudo-protocol context should be made into
operands of - void - is taking an action that has a known rational, an
purpose under _some_ circumstances, and promoting it to the status of a
mystical incantation, to be chanted in the face of all javascript HREFs.
This does not represent a contribution to computer programming.

Richard.

us****@vikas.mailshell.com wrote:

<ul>
<li><a name="link1" onClick="alert(this.name);return false;"
href="#">Link1</a></li>
<li><a name="link2" href="javascript:alert(this);">Link2</a></li>
<li>Item 3</li>
</ul>

Clicking on the first list item gives me "link1" because "this"
refers to the A node so this.name returns the value of the name
attribute of that node.

But in the second link, "this" seems to refer to the window node!

Why is this? Why does the meaning of "this" change so drastically
when used in a href=javascript: vs. a onClick=

The only circumstances under which the - this - keyword refers to
anything other than the global object (which is also the window object
in web browsers) is when a function is *executed* as a method of an
object.

A web browser will take he string provided as the value of an onclick
attribute and use it as the body of a function that it creates
internally and attaches to the - onclick - property of the corresponding
element in the DOM. When the corresponding event occurs this internally
generated function is called as a method of the element in question, and
so the - this - reference has the normal handling for methods and refers
to the element.

Code executed as a result of acting upon a javascript pseudo-protocol
HREF is not executed as a function at all. This can be demonstrated by
executing - href="javascript:return false;" -, which produces a syntax
error along the lines of 'return outside of function'.

The javascript pseudo-protocol is unspecified and nearly undocumented so
its actual behaviour is uncertain, implementation depended and extremely
variable. In the past it has been possible to extract clues about the
behaviour of specific implementations, for example, in IE 4 triggering:-

<a href="javascript:'cc';" target="_blank">
Javascript Pseudo-protocol test</a>

- had the effect of opening a new window (because of target="_blank")
and viewing the source in that new window showed:-

<HTML>
<SCRIPT LANGUAGE=javascript>
var __w='cc';
if(__w!=null)document.write(__w);
</SCRIPT>
</HTML>

- and so provided an insight into how IE 4 implemented the javascript
pseudo-protocol. Later IE versions removed the ability to see this code
by viewing the source of such a pop-up.

You will observe that the code following the - javascript:- in the HREF
(the string literal 'cc' in this case) is inserted into a code block in
a context where it represents the right hand side of an assignment
expression that is executed as an ExpressionStatement in a global
context. The result of the evaluation of that expression (as assigned to
the global variable - __w -) is then tested for type-converted
equivalence with - null - and, when _not_ equivalent, passed through the
document.write method (with all of its implications for the destruction
of any "current" document).

It has also been observed that executing a javascript pseudo-protocol
HREF in some browsers triggers a 'state' change. Apparently a result of
'navigation' associated with the expected outcome of triggering any
link's HREF (and the resulting anticipated replacement of the page's
contents). The most evident symptom of this 'state' change is provided
by Windows IE, where triggering a javascript pseudo-protocol HREF
immediately terminates the animation of animated GIF images. However,
many other unexpected symptoms are suspected to be a result of this
'state' change, and so it can only be reasonably recommended that
javascript pseudo-protocol HREFs never be used unless their expected
action is to replace the current page (or page contents) in the browser.

Richard.

Thanks for everyone's input.

To summarize: When the javascript: pseudo-protocol is used in the HREF
attribute of the A tag, it executes in the global context and so "this"
refers to the window object. When it is used in the onClick event
handler, the "this" refers to the A node.

I was surprised to get so much "never ever use the href=javascript:
URI, it is baaad, evil, etc" comments. Come on guys, leave the
"language purists" stuff aside...In 2005, is there any modern
website/web app that really runs at all if I turn off Javascript.
Client-side scripting and DOM manipulation is so ingrained in the web
development world that it can safely be taken for granted. So, to me,
href="javascript:something()" and onClick="something();return false;"
are really equivalent for all practical intents and purposes. Of
course, If you need to use "this" in your function and need it to refer
to the A node, use the event handler variant, simple.

Thanks

Richard Cornford wrote:

It has also been observed that executing a javascript pseudo-protocol
HREF in some browsers triggers a 'state' change. Apparently a result of
'navigation' associated with the expected outcome of triggering any
link's HREF (and the resulting anticipated replacement of the page's
contents).

I am not sure I understand. The expected outcome of triggering any
link's HREF is not always to replace the page's content. Even if we
leave Javascript out of this, how about <a href="#anchor">? Following
that HREF just navigates to a different section of the currently loaded
document. So does this also trigger the "state change" you mention?

Thanks

VA wrote:

To summarize: When the javascript: pseudo-protocol is used in the HREF
attribute of the A tag, it executes in the global context and so "this"
refers to the window object.
Maybe, maybe not. That's the problem with proprietary features.
When it is used in the onClick event handler, the "this" refers to the
A node.
Most certainly.
I was surprised to get so much "never ever use the href=javascript:
URI, it is baaad, evil, etc" comments. Come on guys, leave the
"language purists" stuff aside...
Some things work reliably, others don't. This has nothing to do with
purity, it has to do with how to get the job done and maintained
efficiently. `href="javascript:..."' is considered a Bad Thing for
good reasons. One reason is that it is not reliable (as you have
experienced) and another one that it does not only not degrade
gracefully itself, using it in place of a proper `http:' URI prevents
the link from degrading gracefully.
In 2005, is there any modern website/web app that really runs at
all if I turn off Javascript.
Oh yes, there are plenty. And the more plain ignorance towards the user
such as displayed by you is taken away from the minds of Web designers, the
more they become Web authors who write for their readers, the less services
will no longer not degrade gracefully, so allowing hopefully *all* users an
adequate experience of the presented content, whether they use a desktop
PC, a notebook, a PDA, a mobile phone, a Braille line, a reading machine,
a printer or any other device.
Client-side scripting and DOM manipulation is so ingrained in the web
development world that it can safely be taken for granted.
Definitely not. But you are still missing the point anyway.
So, to me, href="javascript:something()" and onClick="something();return
false;" are really equivalent for all practical intents and purposes.
They are not.
Of course, If you need to use "this" in your function and need it
to refer to the A node, use the event handler variant, simple.

No, the two features are following completely different approaches.
And while the DOM event model continues to evolve, `javascript:' is
supported merely for reasons of backwards compatibility.
PointedEars

VA wrote:

Richard Cornford wrote:

It has also been observed that executing a javascript
pseudo-protocol HREF in some browsers triggers a 'state'
change. Apparently a result of 'navigation' associated
with the expected outcome of triggering any link's HREF
(and the resulting anticipated replacement of the page's
contents).
I am not sure I understand.

The situation is as easily demonstrated as explained. find yourself an
animated GIF, preferably one that shows constant change so that it is
instantly apparent when it stops being animated and place a reference to
it in the IMG element's SRC in the following HTML:-

<html>
<body>
<img src="anAnimated.gif">
<br>
<a href="javascript:void 0;">javascript:void 0;</a>
<br>
<a href="http://bogus.example.com/">http://bogus.example.com/</a>
</body>
</html>

- and load the result into a Windows IE 6. Then clink the javascript
pseudo-protocol link. The odds are good that the animation will stop
animating at precisely that point. If you then re-load the page the
animation should start again, and if you subsequently click the
bogus.example.com link you should (while the domain is failing to
resolve) have an opportunity to observe that the animation of the GIF
also stops. This demonstrates that the current document undergoes a
'state' change when a javascript pseudo-protocol HREF is activated that
is apparently similar to a 'state' change that accompanies requests to
navigate.
The expected outcome of triggering any link's HREF
is not always to replace the page's content. Even if we
leave Javascript out of this, how about <a href="#anchor">?
Following that HREF just navigates to a different section
of the currently loaded document. So does this also trigger
the "state change" you mention?

It is not useful to observe that a browser may recognise that the
activation of some HREFs do not represent navigation, and so do not
necessarily induce an equivalent 'state' change, so long as javascript:
HREFs can be demonstrated to be treated as navigation in some browsers.
We have a real, demonstrable, condition that applies to versions of a
web browsers that cannot be ignored in commercial web authoring. And we
have good reason to believe that the undesirable consequences of the
execution of javascrip pseudo-protocol HREFs go well beyond the visually
apparent symptoms exposed by animated GIFs.

We can speculate about the nature and extent of this 'state' change and
suffer the consequences of being overly-optimistic, or plain wrong, or
we can notice that there are no remaining circumstances in the DOM where
the execution of a javascript pseudo protocol HREF cannot be completely
avoided with the use of an appropriately default-action cancelling
intrinsic event handler, and so avoid ever having to provoke the
condition or deal with the consequences. Thus, for this reason, in
addition to many others, best practice is to never use a javascript
pseudo-protocol HREF that is not intended to completely replace the
current page.

Richard.

Po*********@web.de wrote:

Some things work reliably, others don't. This has nothing to do with
Just to clarify...other than the demonstrated example of "this" meaning
different things, what exactly does *not* work when href="javascript:"
is used?
experienced) and another one that it does not only not degrade
gracefully itself, using it in place of a proper `http:' URI prevents
the link from degrading gracefully.
But what if I (as the web designer) have nothing to degrade to? In
other words, the functionality that my website/app provides can only be
delivered using Javascript?

So are you suggesting that I do something like

href="sorry.html" onClick=...
where sorry.html informs the user that Javascript is required for
proper functionality?
Oh yes, there are plenty. And the more plain ignorance towards the user
Can you please point me to some? I am honestly curious to see some
commercial, useful websites providing some product/service on the
public Internet that are implemented without using Javascript.
such as displayed by you is taken away from the minds of Web designers, the [...] adequate experience of the presented content, whether they use a desktop
PC, a notebook, a PDA, a mobile phone, a Braille line, a reading machine,
a printer or any other device.
I think your jab on my "ignorance" is not warranted. Presenting content
for all various output devices you mention above is the domain of the
presentation layer, which, I am sure you agree is CSS. CSS has plenty
of features for displaying output device-appropriate content.
(off-topic for this forum, so we'll leave it at that, shall we?).

What we are talking about in this thread is functionality ("what
happens when I click on this link?"), not presentation ("how does this
page look?").
No, the two features are following completely different approaches.
And while the DOM event model continues to evolve, `javascript:' is
supported merely for reasons of backwards compatibility.

I dont understand this. Backward compatibility comes into the picture
when Version x+1 of some technology supercedes some feature in Version
x. Until all the users of that technology "catch up", Version x+1 also
supports the usage of that feaure just as if Version x were running.

In this case, the A tag and its HREF attribute was present from Day 1.
Along comes Javascript and its onSomething event handlers. Older
browser that did NOT implement Javascript and its event handlers
therefore "ignored" the unknown (to them) onClick attribute of the A
tag.

But if they didnt understand/implement Javascript, what use is
providing a href="javasript:function()" feature? Those browsers cant
interpret/run the "function()" anyway! So whats the point? In other
words, who is the intended audience of this "backward compatibility"
feature?

Thanks

Richard: Thank you for that wonderfully eloquent refutation. I am duly
enlightened. Thanks again.

VA said the following on 10/23/2005 4:28 PM:

Po*********@web.de wrote:

Some things work reliably, others don't. This has nothing to do with

Just to clarify...other than the demonstrated example of "this" meaning
different things, what exactly does *not* work when href="javascript:"
is used?

Any link in my cell phone browser for starters.

experienced) and another one that it does not only not degrade
gracefully itself, using it in place of a proper `http:' URI prevents
the link from degrading gracefully.

But what if I (as the web designer) have nothing to degrade to? In
other words, the functionality that my website/app provides can only be
delivered using Javascript?

So are you suggesting that I do something like

href="sorry.html" onClick=...
where sorry.html informs the user that Javascript is required for
proper functionality?

Yes. That is preferable to getting a blank page and no indication of
why. The browser in my cell phone is a non-JS browser so at least some
kind of indication of why it isn't working is a great help.
But if they didnt understand/implement Javascript, what use is
providing a href="javasript:function()" feature? Those browsers cant
interpret/run the "function()" anyway! So whats the point? In other
words, who is the intended audience of this "backward compatibility"
feature?

See above.

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

Randy Webb wrote:

But if they didnt understand/implement Javascript, what use is
providing a href="javasript:function()" feature? Those browsers cant
interpret/run the "function()" anyway! So whats the point? In other
words, who is the intended audience of this "backward compatibility"
feature?

See above.

I dont understand. See above for what? My question was "if the client
cannot understand Javascript (thus causing it to ignore the onClick),
then what use is providing a href=javascript:?" That wont be understood
either.

VA said the following on 10/23/2005 11:35 PM:

Randy Webb wrote:

But if they didnt understand/implement Javascript, what use is
providing a href="javasript:function()" feature? Those browsers cant
interpret/run the "function()" anyway! So whats the point? In other
words, who is the intended audience of this "backward compatibility"
feature?

See above.

I dont understand. See above for what? My question was "if the client
cannot understand Javascript (thus causing it to ignore the onClick),
then what use is providing a href=javascript:?" That wont be understood
either.

My bad, I mis-read the question.
I do not believe that handling href="javascript: was in the beginnings
of the browsers. 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. Now, there
is no need for that use. As for why the browser vendors leave the
support in, who knows. Probably the same reason they leave eval support in.

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.

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

Randy Webb wrote:

support in, who knows. Probably the same reason they leave eval support in.

Hm? Forgive the newbie question, but you seem to be saying "eval" is
not necessary in the Javascript language? So whats the alternative?

Thanks

"VA" <us****@vikas.mailshell.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Randy Webb wrote:

support in, who knows. Probably the same reason they leave eval support
in.

Hm? Forgive the newbie question, but you seem to be saying "eval" is
not necessary in the Javascript language? So whats the alternative?

Turn the question around:

Name a few scenarios where you feel eval() *is* neccessary, and we will
try to show you why its not...

--
Dag.

> I was surprised to get so much "never

ever use the href=javascript: URI, it is baaad, evil, etc" comments.

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". Thusly if
someFunction returns null, you'll end up with a blank page with the
proud word "null" written in the top left corner.

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, 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()

JavaScript is just too samplified and user-friendly to bother you (and
itself) with fine details. 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 ;-)

VA said the following on 10/24/2005 6:49 AM:

Randy Webb wrote:

support in, who knows. Probably the same reason they leave eval support in.

Hm? Forgive the newbie question, but you seem to be saying "eval" is
not necessary in the Javascript language? So whats the alternative?

http://jibbering.com/faq/#FAQ4_40

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

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

I was surprised to get so much "never
ever use the href=javascript: URI, it is baaad, evil, etc" comments.

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?

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

Randy Webb said:

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

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

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

VK wrote:

I was surprised to get so much "never
ever use the href=javascript: URI, it is baaad, evil,
etc" comments.
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.

Lee wrote:

Randy Webb said:

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

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

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

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

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

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
--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Thanatos wrote:

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

Damn I pressed <Enter> by ocassion. So Part II now:

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.

On Mon, 24 Oct 2005 17:48:22 -0400, in comp.lang.javascript , Randy
Webb <Hi************@aol.com> in <j5********************@comcast.com>
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/

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 <Hi************@aol.com> in <j5********************@comcast.com>
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.

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

Randy Webb <Hi************@aol.com> writes:

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 - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

"VK" <sc**********@yahoo.com> writes:

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

On 25/10/2005 09:52, VK wrote:

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.

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)

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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

On Tue, 25 Oct 2005 11:54:10 -0400, in comp.lang.javascript , Randy
Webb <Hi************@aol.com> in <6d********************@comcast.com>
wrote:

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 <Hi************@aol.com> in <j5********************@comcast.com>
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/

Thanatos wrote:

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

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

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>
</html>

Yes, as written several times.

But still not enough times I guess...

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/

VK wrote:

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

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

Matt Silberstein wrote:

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

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 said the following on 10/26/2005 10:42 AM:

Matt Silberstein wrote:

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.

No. The method of choice is to use a button if you don't want to
navigate via the href attribute.

JS creates and appends the button.
The button's onclick triggers the function.

*That* is the "method of choice" to those who are informed.

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

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 10/26/2005 10:42 AM:

Matt Silberstein wrote:

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.

No. The method of choice is to use a button if you don't want to
navigate via the href attribute.

The question of "Thanatos" was a little bit different than your
reply suggests.
JS creates and appends the button.
The button's onclick triggers the function.

That is another acceptable way. However, the question was about
how to do it with the `a' element which is what I replied to.
PointedEars

Thomas 'PointedEars' Lahn said the following on 10/26/2005 12:38 PM:

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 10/26/2005 10:42 AM:

Matt Silberstein wrote:

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.

No. The method of choice is to use a button if you don't want to
navigate via the href attribute.

The question of "Thanatos" was a little bit different than your
reply suggests.

JS creates and appends the button.
The button's onclick triggers the function.

That is another acceptable way. However, the question was about
how to do it with the `a' element which is what I replied to.

And if a person wants to do something and they are using the wrong
approach, then it should be pointed out that a better approach exists.
Which is what I did.

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

If we are staying on the *pure purisme* positions then no one of
proposed methods is correct including but not limited to "Best
Practice" advises.

We have to completely forget then <a> element as not intended and
having nothing to do with JavaScript code execution.

The two approaches we have then are:

1) Use a neutral tag to imitate link behavior. <noscript> and
conditional comments should be used to provide all necessary info to
customers w/o JavaScript, CSS or neither of both.

This approach is demonstated at:
<http://www.geocities.com/schools_ring/archives/PsiLink1.html>
Yahoo! crap free version contained in archive:
<http://www.geocities.com/schools_ring/archives/PsiLinks.zip>

I hope no one will oversize <noscript> so largely as on this demo. But
it gives you ideas how to provide roll-back and conditional content /
formatting even when all imaginable features are disabled.

This demo shows correct roll-back and conditional compilation back to
NCSA Mosaic. For who's curious here is a screenshot of this page
displayed in the Great Mother :
<http://www.geocities.com/schools_ring/archives/PsiLink1_Mosaic.gif>

(If you have any idea for further roll-back, just let me know :-)
2) Still this approach cannot be considered as totally acceptable. Even
in the case 1) we are still using some tag in contradiction to its
functions as spelled by W3C.
So the only way we really can accept as the best practice would be an
element from our own specially constructed namespace.

This approach is demonstated at:
<http://www.geocities.com/schools_ring/archives/PsiLink1.html>
Yahoo! crap free version contained in archive:
<http://www.geocities.com/schools_ring/archives/PsiLinks.zip>

Here we are declaring new JS namespace and creating <JS:LINK> element
with all needed formating and behavior.

Matt Silberstein wrote:

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?

You just going right by middle 90's road. This is how first JavaScript
programmers had to twist their minds. If you would *read my posts in
this thread* you'll see the self-linked link mentioned. As it said
where,
<a href="#foo" name="foo"> trick is not usable neither for two reasons:

1) It crashes IE 3.x / IE 4.x which is not important anymore though
2) On a big page it still scrolls, so the self-linked link would be
placed at the top of the page.

VK said the following on 10/26/2005 1:43 PM:

Matt Silberstein wrote:

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?

You just going right by middle 90's road. This is how first JavaScript
programmers had to twist their minds. If you would *read my posts in
this thread* you'll see the self-linked link mentioned. As it said
where,
<a href="#foo" name="foo"> trick is not usable neither for two reasons:

1) It crashes IE 3.x / IE 4.x which is not important anymore though

Does this crash them:

<a href="#foo">Link Text</a><a name="foo">

?
2) On a big page it still scrolls, so the self-linked link would be
placed at the top of the page.

Top of the page or top of the viewport? I think it would scroll to the
top of the viewport, instead of top of the page. I think that is what
you meant.

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

VK said the following on 10/26/2005 1:27 PM:

If we are staying on the *pure purisme* positions then no one of
proposed methods is correct including but not limited to "Best
Practice" advises.

We have to completely forget then <a> element as not intended and
having nothing to do with JavaScript code execution.

The two approaches we have then are:

1) Use a neutral tag to imitate link behavior. <noscript> and
conditional comments should be used to provide all necessary info to
customers w/o JavaScript, CSS or neither of both.

And it still does not cover the scenario where a script error will cause
all scripts on the page to stop functioning. The NOSCRIPT element does
not cover that aspect.

It also does not cover a scenario as such in script enabled non-IE browsers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<script type="text/vbscript">
Dim MyVar
MyVar = MsgBox ("Hello World!", 216, "MsgBox Example")
' MyVar contains either 1 or 2, depending on which button is clicked.
</script>
</head>
<body>
<P>This is the body of the document</P>
<noscript>
<P>You have scripting disabled</P>
</noscript>
</body>
</html>

Test that code in Opera or Firefox.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

Randy Webb wrote:

VK said the following on 10/26/2005 1:27 PM:
1) Use a neutral tag to imitate link behavior. <noscript> and
conditional comments should be used to provide all necessary info to
customers w/o JavaScript, CSS or neither of both.
And it still does not cover the scenario where a script error will cause
all scripts on the page to stop functioning. The NOSCRIPT element does
not cover that aspect.

Hey! It isn't fair :-(
;-)
We're discussing "no feature" downgrade issue. Runtime error script
stability is a whole other issue.

It also does not cover a scenario as such in script enabled non-IE browsers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<script type="text/vbscript">
Dim MyVar
MyVar = MsgBox ("Hello World!", 216, "MsgBox Example")
' MyVar contains either 1 or 2, depending on which button is clicked.
</script>
</head>
<body>
<P>This is the body of the document</P>
<noscript>
<P>You have scripting disabled</P>
</noscript>
</body>
</html>

Test that code in Opera or Firefox.

I did not get that I guess. On both Opera 8.01 and FireFox 1.0.7 it
ignores VBScript and shows "This is the body of the document" line only
in the body. What's wrong with that?

Randy Webb wrote:

VK said the following on 10/26/2005 1:43 PM:

Matt Silberstein wrote:

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?

You just going right by middle 90's road. This is how first JavaScript
programmers had to twist their minds. If you would *read my posts in
this thread* you'll see the self-linked link mentioned. As it said
where,
<a href="#foo" name="foo"> trick is not usable neither for two reasons:

1) It crashes IE 3.x / IE 4.x which is not important anymore though

Does this crash them:

<a href="#foo">Link Text</a><a name="foo">

?

Truthfully I don't remember anymore this issue because there was no
need to overcome it, simply do not use it. It's like a taboo no one
remembers anymore why: "Do not go to that cave!", "Do not use # for
scripted links!" :-)

2) On a big page it still scrolls, so the self-linked link would be
placed at the top of the page.

Top of the page or top of the viewport? I think it would scroll to the
top of the viewport, instead of top of the page. I think that is what
you meant.

I guess you right (see above). I just know that it moved the document,
and it still moves it somehow: maybe not in that exact way as 8 years
ago (the progress doesn't stay :-) but it moves it. So it's still
should not be used.

VK said the following on 10/26/2005 5:56 PM:

Randy Webb wrote:

VK said the following on 10/26/2005 1:27 PM:
1) Use a neutral tag to imitate link behavior. <noscript> and
conditional comments should be used to provide all necessary info to
customers w/o JavaScript, CSS or neither of both.

And it still does not cover the scenario where a script error will cause
all scripts on the page to stop functioning. The NOSCRIPT element does
not cover that aspect.

Hey! It isn't fair :-(
;-)
We're discussing "no feature" downgrade issue. Runtime error script
stability is a whole other issue.

It also does not cover a scenario as such in script enabled non-IE browsers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<script type="text/vbscript">
Dim MyVar
MyVar = MsgBox ("Hello World!", 216, "MsgBox Example")
' MyVar contains either 1 or 2, depending on which button is clicked.
</script>
</head>
<body>
<P>This is the body of the document</P>
<noscript>
<P>You have scripting disabled</P>
</noscript>
</body>
</html>

Test that code in Opera or Firefox.

I did not get that I guess. On both Opera 8.01 and FireFox 1.0.7 it
ignores VBScript and shows "This is the body of the document" line only
in the body. What's wrong with that?

It does not support the script. So, in theory, it should show the
noscript element but it doesn't.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.