A tag: href vs. onClick
use...@vikas.mailshell.com
<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=
Thanks
Randy Webb
> 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
VK
> <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.
Thomas 'PointedEars' Lahn
> 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
Richard Cornford
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.
Richard Cornford
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.
VA
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
VA
> 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
Point...@web.de
> 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
Richard Cornford
> 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.
VA
> 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
VA
enlightened. Thanks again.
Randy Webb
> Point...@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.
VA
> > 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.
Randy Webb
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.
VA
> 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
Dag Sunde
news:1130150990.2...@g14g2000cwa.googlegroups.com...
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.
VK
> 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 ;-)
Randy Webb
Randy Webb
>>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?
Richard Cornford
>> 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.
Thomas 'PointedEars' Lahn
> 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
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.
[....]
> 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)
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
Webb <HikksNo...@aol.com> in <j5adnVBXnoL...@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/
Randy Webb
> On Mon, 24 Oct 2005 17:48:22 -0400, in comp.lang.javascript , Randy
> Webb <HikksNo...@aol.com> in <j5adnVBXnoL...@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.
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 - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
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.
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.
>> 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.
Matt Silberstein
Webb <HikksNo...@aol.com> in <6didnYz9zb2...@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 <HikksNo...@aol.com> in <j5adnVBXnoL...@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.
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
>
> "#" 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> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p><a href="#" onclick="alert('test')">test</a></p>
</body>
</html>
> Yes, as written several times.
But still not enough times I guess...
Matt Silberstein
reference that? That is, make the non-JavaScript link just go right
were it is?
Thomas 'PointedEars' Lahn
>> > 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
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
Randy Webb
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.
Thomas 'PointedEars' Lahn
> 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
Randy Webb
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.
VK
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.
VK
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.
Randy Webb
> 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 Webb
> 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.
VK
> > VK said the following on 10/26/2005 1:27 PM:
> > 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?
VK
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.
Randy Webb
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.
VK
> >>"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>
> >>
> >
> > 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.
But it does support *the* script! Try <body onload="alert('I support
scripting')">
It simply ignores fragment of unknown Content-Type "text/vbscript"
which seems right to me (?)
If VBScript was a part of common Web standards we would expect 3
separate tags from W3C like:
<NOJSSCRIPT>
<NOVBSCRIPT>
<NOANYSCRIPT>
Otherwise single <NOSCRIPT> is sufficient (?)
If anyone puts her nose out of the ASP box to the client-side, it's her
duty to provide a roll-back for standard browser users.
<script type="text/vbscript">
// Code
</script>
<script type="text/javascript">
// Warning message if VBScript
// was not executed
</script>
P.S. Ave we advocation VBScript ? ;-)
VK
VK wrote:
> P.S. Ave we advocation VBScript ?
Wow! Lesser beer - more sport! ;-)
P.S. Are we advocating VBScript?
VK
issue we should insist on proper META-EQUIV declaration for used
language as suggested by W3C:
<http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.2.1>
(that was not nice of you to force me to go into Triple-W docs :-)
Naturally it still fails if a language cocktail (VBScript/JScript) is
used on the same page. But in case of VBScript-only it would prevent
script error in the sample below *if it was implemented by anyone*. But
neither of browsers I know of (including FireFox) doesn't respect this
content header.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Testcase</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<meta http-equiv="Content-Script-Type" content="text/vbscript">
<style type="text/css">
<!--
body { background-color: #FFFFFF}
-->
</style>
<script>
Function vbsFunction()
Dim Foo
Foo = MsgBox("VBScript Message Box",64,"Test")
End Function
</script>
</head>
<body onload="vbsFunction()">
<p>No content</p>
</body>
</html>
Thomas 'PointedEars' Lahn
> Formally thinking over the "VBScript is here but JavaScript is not"
> issue we should insist on proper META-EQUIV declaration for used
> language as suggested by W3C:
> <http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.2.1>
> (that was not nice of you to force me to go into Triple-W docs :-)
The MS script engine, which is to my knowledge the only one to support
client-side VBScript, ignores the proper default scripting language
declaration via `meta' element. Instead, it selects the scripting
language in event handler attribute values based on the previously
selected scripting language or a label at the beginning of the event
handler attribute value.
> Naturally it still fails if a language cocktail (VBScript/JScript) is
> used on the same page. But in case of VBScript-only it would prevent
> script error in the sample below *if it was implemented by anyone*. But
> neither of browsers I know of (including FireFox) doesn't respect this
> content header.
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
To not let Quirks/Compatibility Mode be used by UAs with DOCTYPE switch
feature, a proper system identifier (DTD URL) is missing here.
> [...]
> <style type="text/css">
> <!--
Trying to comment out the contents of `style' and `script' elements for UAs
is an obsolete practice in HTML and error-prone in XHTML. Both elements
have already been defined in HTML 3.2 (even if only as placeholders), and
even older specified versions of HTML are (marked as) obsolete by RFC.
PointedEars