A tag: href vs. onClick

[Randy Webb]

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.

 

[Thomas 'PointedEars' Lahn]

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

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]

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.

 

[VK]

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.

 

[VK]

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]

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

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]

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.

 

[VK]

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]

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

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

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]

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

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





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.

 

[VK]

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

Randy Webb wrote:

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]

P.S. Ave we advocation VBScript ?

Wow! Lesser beer - more sport! ;-)

P.S. Are we advocating VBScript?

 

[VK]

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

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