onClick="javascript: function('value');" or onClick="function('value');"?

[Nigorr]

What is the best way to do this sort of thing.

onClick="javascript: function('value');"
onClick="function('value');"
onClick="return function('value');"

onClick="javascript: function('value')"
onClick="function('value')"
onClick="return function('value')"

Is there a way you are "suppose" to do it?

[Beach Bum]

no inline javascript statement.
no ; as there is only the option for one statement

the most common textbook answer would be

onclick="functionName('value')"

[Charles]

onClick="javascript: function('value');"

is never right . Both of the others are correct but they mean different things. Which one you ought to use will depend on the context.

[Nigorr]

Ok,

thanks for clearing that up for me. I'll be using and converting to:

onClick="function('value');"

Not to sure about this return true or false business though. As some functions of mine don't need to return a value, as they invoke other functions.

edit: Also I was just using onClick() event as an example, as in I mean it for all events, onBlur(), onMouseOver(), onMouseDown(), etc. I think that for some of these events, should require a return true; or something.

[Beach Bum]

I believe that putting javascript inline has been depreciated by W3C.

[Rick Bull]

You should not use the javascript bit generally, instead you should specify the default script type with a declaration in the head:

<meta http-equiv="Content-Script-Type" content="text/javascript">

You only need to use javascript: (or vbscript: or whatever) if the script is not the same as the one in the meta tag.

[Charles]

I believe that putting javascript inline has been depreciated by W3C.

Not in HTML, but as braces cause problems with XML parsers you are encouraged to use only external scripts in XHTML.

The use of the javascript: psuedo-protocol identifier is probably unnecessary in most cases -- just keep in mind that it is valid for those times when you may need to use it. The semicolon is also probably unnecessary in most cases but, again, I would recommend that you make a habit of always using it -- as it is good programming practice to do so.

Please stop just making things up. Its a pseudo-protocol identifier because it's aping the protocol part of a URL and it applies to a construction such as:

<a href="javascript:window.open()">Open Sesame</a>

And that construction was never really valid, though it used to work (and it doesn't work anymore). And you will not find your construction in any HTML or JavaScript specification.

... if you're coding for the IE browser, that is. The IE browser (and all versions of the NS browser, for the matter) always support the following:

HTML browsers are supposed to try to recover from your errors, but that's no reason to keep on making those errors. You never know when someone with a less forgiving browser might try to use you site.

If you want to use two different scripting languages with you event handlers then:

<a href="http://www.w3.org/TR/REC-html32">3.2</a>
<script type="text/javascript">
document.links[document.links.length-1].onclcick = function() {alert('3.2'); return false}
</script>

<a href="http://www.w3.org/TR/html4/">4.01</a>
<script type="text/perlscript">
...
</script>

See Section 18.2.2, Specifying the scripting language, of the HTML 4.01 Specification ( http://www.w3.org/TR/html4/interact/....html#h-18.2.2 ) for the valid ways of specifying your scripting language. That's the actual HTML rules and not something that somebody just made up.

[Charles]

So, if I understand your post corrrectly, the psuedo-JavaScript construction onClick="javascript:alert('foo')" is something that you just made up. Yes, as I pointed out some browsers understand what it is that you are trying to communicate to them but that's no reason to go about encouraging others to use your new method when perfectly good and valid methods already exist. There are hundreds of browsers out there, Have you tested your own special method on all of them?

[Charles]

It is documented at MSDN.

I've searched the MSDN site and could find neither example nor description of your your special little construction. The only thing close is the JavaScript protocol (http://msdn.microsoft.com/workshop/n...javascript.asp) but, as I've already pointed out, that refers to URLs and not event handlers.

I said I've used it in all IE and NS browsers and versions (on a Windows platform). That's all... ...and that's all most of the people will care about

Perhaps, but you need to make it clear to them that your special little construction is not only unnecessary but it might cause harm on those other browsers. Which is what was meant when I wrote that it was always wrong. But you took offence at that. And I suspect that there are more people out there than you think who do care that their pages work on all browsers. I'm quite sure that you don't vare very much for those using Braille and audio browsers but other do - and some of them out of a well founded fear of legal action.

[Beach Bum]

a little off track - but i find this "all browsers" issue to be very interesting.

i have a site that uses some features and positioning that i am not willing to compromise. and i am also willing to accept that 90% coverage is ok for this site.

so i test it with IE6 and NS7. and on my first page i check to see if you support frames, javascript, and that your resolution is at leat 800*600. if not, i give you a polite message and bounce you out (don't even want you in because things just will not look right).

so i think the key here is not right or wrong. but understanding what works where, so we can all make choices.

[Charles]

The problem is that that approach is often against the law in the United States. (See http://www.usdoj.gov/crt/foia/tal712.txt for the offical US Department of Justice position on the matter.) And it's a good thing too, for without that push most wee authors wouldn't even consider making sure their pages are accessible to persons with diasabilities who might be using assistive technologies.

The trick isn't to eschew the use of positioning and client side scripting but to employ it in a way that the page 'fails safe' when the positioning or scripting isn't there.

[Beach Bum]

its a good thing the site i am talking about is not subject to ADA or any other government intrusion (good or bad).

your point is a good one, which i think reinforces what i was saying:

"the key here is not right or wrong. but understanding what works where, so we can all make choices."

that is one consideration in the list when making your choices.

[Zach Elfers]

Originally posted by Nigorr
What is the best way to do this sort of thing.

onClick="javascript: function('value');"
onClick="function('value');"
onClick="return function('value');"

onClick="javascript: function('value')"
onClick="function('value')"
onClick="return function('value')"

Is there a way you are "suppose" to do it?

I don't know what your talking about. Say what you're trying to get the script to do pleaze.

[Stefan]

Originally posted by Dave Clark
It was your use of the word "always" that I took offense to -- since it obviously was required in my situation.

But Charles have already showed exactly how you should add different scriptlanguages to a page the CORRECT way, so why do you instist on using a non valid way?

[Stefan]

Originally posted by Dave Clark
[b][list][*]You didn't read all the details. My situation required using two scripting languages in the same document. Nobody addressed this issue -- they weren't going to touch what they knew nothing about. Instead, they were satisfied to baselessly criticize.

You can put as many <script type=""> in your HTML page as you like, and each one can be any scripting language you specify.
As I already stated, Charles even posted examplecode in this very thread.

[*]Nobody proved what I am doing is not valid. The fact that it fixed an error in the browser proves that it is a valid method -- some people just can't accept that.

You mean like <blink> creating blinking text in NS4 proves that is valid markup? You are not serious are you?
As for the proof that it's invalid, check the link to the HTML spec provided by Charles.
It specifies exactly what you are alowed to do. Anything else that is not in the spec is NOT alowed. That's the entire point with having a spec to begin with...