/    Sign up×
Community /Pin to ProfileBookmark

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

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?

to post a comment
JavaScript

43 Comments(s)

Copy linkTweet thisAlerts:
@Beach_BumNov 22.2002 — no inline javascript statement.

no ; as there is only the option for one statement

the most common textbook answer would be

onclick="functionName('value')"
Copy linkTweet thisAlerts:
@CharlesNov 22.2002 — onClick="javascript: function('value');"[/quote]

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.
Copy linkTweet thisAlerts:
@NigorrauthorNov 22.2002 — Ok,

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

onClick="function('value');"

Not to sure about this return [b][i]true[/i][/b] or [b][i]false[/i][/b] 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.
Copy linkTweet thisAlerts:
@Beach_BumNov 22.2002 — I believe that putting javascript inline has been depreciated by W3C.
Copy linkTweet thisAlerts:
@Rick_BullNov 22.2002 — You should [b]not[/b] use the javascript bit generally, instead you should specify the default script type with a declaration in the head:

<i>
</i>&lt;meta http-equiv="Content-Script-Type" content="text/javascript"&gt;


You only need to use javascript: (or vbscript: or whatever) if the script is not the same as the one in the meta tag.
Copy linkTweet thisAlerts:
@CharlesNov 22.2002 — I believe that putting javascript inline has been depreciated by W3C.[/quote]

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.[/quote]

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:[/quote]

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/scripts.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.
Copy linkTweet thisAlerts:
@CharlesNov 22.2002 — So, if I understand your post corrrectly, the psuedo-JavaScript construction [FONT=courier new]onClick="javascript:alert('foo')"[/FONT] [I]is[/I] 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?
Copy linkTweet thisAlerts:
@CharlesNov 23.2002 — [font="georgia"]It is documented at MSDN.[/quote]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/networking/predefined/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[/quote]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.[/font]
Copy linkTweet thisAlerts:
@Beach_BumNov 23.2002 — 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.
Copy linkTweet thisAlerts:
@CharlesNov 23.2002 — [font=georgia]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. [/font]
Copy linkTweet thisAlerts:
@Beach_BumNov 23.2002 — 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.
Copy linkTweet thisAlerts:
@Zach_ElfersNov 23.2002 — [i]Originally posted by Nigorr [/i]

[B]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? [/B]
[/QUOTE]


I don't know what your talking about. Say what you're trying to get the script to do pleaze.?
Copy linkTweet thisAlerts:
@StefanNov 24.2002 — [i]Originally posted by Dave Clark [/i]

It was your use of the word "always" that I took offense to -- since it obviously was [b]required[/b] in my situation. [/QUOTE]


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? ?
Copy linkTweet thisAlerts:
@StefanNov 24.2002 — [i]Originally posted by Dave Clark [/i]

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

  • [/QUOTE]


    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 [b][i]is[/i][/b] a valid method -- some people just can't accept that.
    [/QUOTE]


    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...
    Copy linkTweet thisAlerts:
    @StefanNov 24.2002 — [i]Originally posted by Dave Clark [/i]

    [B]You're still not reading/listening to all the details. I'm not talking about SCRIPT blocks. I'm talking about [b][i]inline[/i][/b] script coding.

    [/QUOTE]




    You can call any function via inline scripting that is in a <script> entity appearing before it on the page.
    Copy linkTweet thisAlerts:
    @StefanNov 24.2002 — [i]Originally posted by Dave Clark [/i]

    I didn't say inline [b][i]function calling[/i][/b], I said inline [b][i]script coding[/i][/b]. [/QUOTE]


    Too bad, because that is how you do it the correct way.

    If you are not capable of understanding that, well stick to only 1 language on your pages then.

    However it's dishonest to try to teach other people coming here for help that it's impossible to use different languages on the same webpage (using only valid markup), becuse that is simply not true and it has been proven several times in this thread now.
    Copy linkTweet thisAlerts:
    @CharlesNov 26.2002 — [font=georgia]Mr. Clark;

    It's been a couple of days. Have you found documentation for you special little construction yet?[/font]
    Copy linkTweet thisAlerts:
    @CADDAug 31.2006 — i have a similar problem:

    http://www.webdeveloper.com/forum/showthread.php?t=119584

    can someone make a recommendation on the best way to return the URL?
    Copy linkTweet thisAlerts:
    @LeeUAug 31.2006 — You can use a form button:
    [CODE]
    <form>
    <input type"button" value="Click here" onclick="Popup()">
    </form>
    [/CODE]
    Copy linkTweet thisAlerts:
    @CADDAug 31.2006 — You can use a form button:
    [CODE]
    <form>
    <input type"button" value="Click here" onclick="Popup()">
    </form>
    [/CODE]
    [/QUOTE]


    that would be great, but what if someone else owns the button and I don't have control over it?

    http://www.pandorabots.com/pandora/talk?botid=875d96ffae366536
    Copy linkTweet thisAlerts:
    @KorAug 31.2006 — that would be great, but what if someone else owns the button and I don't have control over it?

    http://www.pandorabots.com/pandora/talk?botid=875d96ffae366536[/QUOTE]

    Then that means that button belongs to a page which is hosted on another domain, case in which there is nothing you can do. Cross-domain javascript reference is not possible for obvious security reasons

    Regarding to the main topic. Why, on Earth, to use a construction on line like

    <tag onclick="javascript:somefunction()" />

    (no matter that it is obsolate) when you can write it short as

    <tag onclick="somefunction()" />

    On the other hand, to keep the context separate from script, you may attach the events to the object onload
    <i>
    </i>onload = function(){
    [I]myobject[/I].onclick=function(){somefunction()}
    }
    Copy linkTweet thisAlerts:
    @FX_LeachNov 15.2011 — Regarding to the main topic. Why, on Earth, to use a construction on line like

    <tag onclick="javascript:somefunction()" />

    (no matter that it is obsolate) when you can write it short as

    <tag onclick="somefunction()" />[/QUOTE]


    I currently ran across an issue in Chrome where I HAD to use the convention of putting "javascript:" before the function of my onclick event. Strange yes, non-compliant-yes, but it worked. I haven't come across this before in my development, but when you're working for a medium-large sized business it's unacceptable for it not to work in specific browsers. You have to hack your way to reaching everyone possible. I have since switched over to using an unobtrusive javascript approach to handling the event, but it still stands that this method worked where simply naming the function didn't.
    Copy linkTweet thisAlerts:
    @KorNov 16.2011 — I currently ran across an issue in Chrome where [COLOR="Red"]I HAD[/COLOR] to use the convention of putting "javascript:" before the function of my onclick event. [/QUOTE]
    No way. There are no circumstances which should oblige a coder to use the [B]javascript:[/B] old fashioned token. On the contrary, most of the time that syntax will bring errors. So, I seriously doubt that [I]YOU HAD[/I] to do that by all means. can you give me an example? ?
    Copy linkTweet thisAlerts:
    @Declan1991Nov 16.2011 — No way. There are no circumstances which should oblige a coder to use the [B]javascript:[/B] old fashioned token. On the contrary, most of the time that syntax will bring errors. So, I seriously doubt that [I]YOU HAD[/I] to do that by all means. can you give me an example? ?[/QUOTE]Agreed. That "javascript:" just is a label pointing to a statement, it has nothing to do with being it being executed as JavaScript. I, also, would love to see a sample.
    Copy linkTweet thisAlerts:
    @FX_LeachNov 16.2011 — Sure. Is this scenario reproducible? I don't know. Anyways here's how it goes...

    I have a div, which I am putting an onclick event on (in PHP) like so...

    $design_code = '<div class="skip" onclick="skipOffer2();">'.$design.'</div>';

    I echo the $design_code on the page. In IE & FF this works fine. In Chrome, it works roughly 50% of the time. When it doesn't work, and I examine this div using Firebug on Chrome, it shows an empty onclick event:

    <div class="skip" onclick="">

    I do not have any code that removes this event, overrides it, does anything with that div, or modifies the DOM whatsoever, and again... it's only happening on Chrome. Somehow Chrome is removing this event.

    However, when I prepend the onclick function with "javascript:" it works 100% in Chrome.

    $design_code = '<div class="skip" onclick="javascript:skipOffer2();">'.$design.'</div>';

    I don't know why, there are no errors on the page, and Chrome keeps removing my inline onclick event without it. I didn't say you'd like it, but that's my experience with this situation.
    Copy linkTweet thisAlerts:
    @KorNov 16.2011 — Again: no way! I have tested and I can not confirm that. Anyway, even if that could have happened, it must have been a PHP error somewhere, or a bad Apache or PHP installing.

    For instance this simple code works in Chrome, of course, and it supposes to work in all the browsers, starting with IE4 and NS4 till the present days browsers ? :
    <i>
    </i>&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;
    &lt;html&gt;
    &lt;head&gt;
    &lt;title&gt;Untitled Document&lt;/title&gt;
    &lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"&gt;
    &lt;meta http-equiv="Content-Style-Type" content="text/css"&gt;
    &lt;meta http-equiv="Content-Script-Type" content="text/javascript"&gt;
    &lt;script type="text/javascript"&gt;
    function skipOffer2(){
    alert('It works!')
    }
    &lt;/script&gt;
    &lt;/head&gt;
    &lt;body&gt;
    &lt;?php
    $design='foo';
    $design_code = '&lt;div class="skip" onclick="skipOffer2();"&gt;'.$design.'&lt;/div&gt;';
    echo $design_code; ?&gt;
    &lt;/body&gt;
    &lt;/html&gt;


    I work with PHP for more then a decade, I had never problems with echoing JavaScript event handlers like that. Never. No matter the browser.
    Copy linkTweet thisAlerts:
    @FX_LeachNov 16.2011 — So you're saying that a bad Apache or PHP installation is actually causing my web server to traverse my code and actively remove my inline javascript events?
    Copy linkTweet thisAlerts:
    @KorNov 16.2011 — So you're saying that a bad Apache or PHP installation is actually causing my web server to traverse my code and actively remove my inline javascript events?[/QUOTE]
    I don't know. It was just a saying. Something happened at the server-side level, that is for sure. Or, perhaps your Chrome had something (which I doubt). Or maybe you had a virus.

    Look: open this with your Chrome, and tell me what you see? (View page source - and click on that DIV):

    http://www.beler.eu/desters/test.php

    ?
    Copy linkTweet thisAlerts:
    @FX_LeachNov 16.2011 — Well I've gotten to the bottom of it and I'm a little confused, maybe you can help. The problem was occurring only when I was switching from one page to another, so I made a little test and this is my findings... when I pass a url encoded string that contains an onclick function with the same name as a function on the next page, it breaks in Chrome.

    I'll break that down... here's my test page: http://mattkeaveney.com/test1.php

  • 1. On my initial page I have a form with a hidden field like this:
    [CODE]<input type="hidden" name="test" id="test" value="onclick%3D%22alertMe%28%29%22" />[/CODE]


  • The encoded string is a piece of html code. I've shortened it here to just a small part for testing purposes, but it still illustrates my point. It contains an onclick function called alertMe(). Decode it and you can see for yourself.

  • 2. I have a submit button on the form that sends the user to the next page.


  • 3. Once I'm on the next page... I do not do anything with the hidden value passed from the previous page, but it's useful to me and I need it there to pass along to subsequent pages. However, this value is actually screwing up the current page.

    Any function calls to alertMe() will fail. When I view source I can see it there:
    [CODE]<div class="skip" onclick="alertMe()">[/CODE]
    ... but viewed with Firebug it's actually an empty onclick event like this:
    [CODE]<div class="skip" onclick="">[/CODE]


  • So my question... why is the urlencoded POST value messing up the javascript on the next page, and only in Chrome?
    Copy linkTweet thisAlerts:
    @FX_LeachNov 16.2011 — I'm guessing it's a bug in Chrome, as no one has disputed me so far. But back to the topic, it just goes to show that the format "javascript:" is useful in some strange cases! ?
    Copy linkTweet thisAlerts:
    @KorNov 17.2011 — 
    1. On my initial page I have a form with a hidden field like this:
    [CODE]<input type="hidden" name="test" id="test" value="onclick%3D%22alertMe%28%29%22" />[/CODE][/QUOTE]

    Well, that is a Chrome bug, indeed, but it is related with something else. Chrome do not encode the double quotes properly.

    If you send the query using (as you should) the enctype="application/x-www-form-urlencoded", the value should be:[B] value='onclick="alertMe()"'[/B].

    This works in all the browsers, but not in Chrome. This is a bug.

    On the other hand, if you use the PHP decoding method (even if in theory there is no need, because the global $_GET should automatically decode the ulrencoded values) like

    [B]htmlspecialchars(urldecode($_GET['test']))[/B]

    Chrome will, finally decode the query, but it will render them as:

    [B]onclick=&quot;alertMe()&quot;[/B]

    which migh be or might be not a bug. In fact, PHP standards say clearly that:

    [I]"The superglobals $_GET and $_REQUEST are already decoded. Using urldecode() on an element in $_GET or $_REQUEST could have unexpected and dangerous results."[/I]

    Conclusion: you should not encode tour data like that. You might have simply send data as string, using a delimiter (say comma) and rebuild the expression on the server-side level.

    Like:
    <i>
    </i>&lt;form action="x.php" method="get" enctype="application/x-www-form-urlencoded"&gt;
    &lt;input type="hidden" name="test" id="test" value="onclick,alertMe"&gt;
    &lt;input type="submit" value="Submit"&gt;
    &lt;/form&gt;

    and in x.php should be something like:
    <i>
    </i>&lt;script type="text/javascript"&gt;
    function alertMe(){
    alert('I am here!');
    }
    &lt;/script&gt;
    ...
    &lt;?php
    $data=explode(',',$_GET['test']);
    $handler=$data[0].'='.$data[1].'()';
    echo '
    &lt;div '.$handler.'&gt;click&lt;/div&gt;
    ';
    ?&gt;


    That is crossbrowser and avoids the Chrome's encoding bug.
    Copy linkTweet thisAlerts:
    @FX_LeachNov 17.2011 — Thank you for the explanation! I have modified the form to send the data with the enctype "application/x-www-form-urlencoded" and it is indeed still happening just as you said.

    But as for your conclusion, it doesn't necessarily fit into my predicament. The issue is that I'm not using the encoded data at all. That's the most puzzling part! I'll repeat that, the onclick="alertMe()" urlencoded string that I'm passing is not being read, I'm not decoding it and using it on the second page anywhere.

    Here is the code to prove that I'm not accessing the REQUEST data at all.

    page 1:

    [CODE]<html>
    <head>

    </head>
    <body>

    <form name="testForm" method="get" action="test2.html" enctype="application/x-www-form-urlencoded">
    <input type="hidden" name="test" id="test" value="onclick%3D%22alertMe%28%29%22" />
    <input type="submit" value="Skip" />
    </form>

    </body>
    </html>[/CODE]


    Page 2:

    [CODE]<html>
    <head>

    <style type="text/css">
    .skip {cursor: pointer; cursor: hand; color: blue;}
    </style>

    </head>
    <body>

    <div class="skip" onclick="alertMe()">
    Clicking this will do nothing in Chrome!
    </div>

    <script type="text/javascript">
    function alertMe() {
    alert('hello, world!');
    }
    </script>

    </body>
    </html>[/CODE]


    If this is indeed a bug in Chrome, should I file a bug report with them?
    Copy linkTweet thisAlerts:
    @KorNov 17.2011 — 
    If this is indeed a bug in Chrome, should I file a bug report with them?[/QUOTE]

    It is, I reckon, an old bug, as it was already reported since Chrome 4, upon my knowledge ?
    Copy linkTweet thisAlerts:
    @KorNov 17.2011 — On the other hand, you should not encode manually the data. It is redundant, and it might provoke errors. The [B]enctype[/B] will do that, automatically. In fact, the [B]application/x-www-form-urlencoded[/B][I] is the default enctype[/I], thus you don't even use it by all means.
    Copy linkTweet thisAlerts:
    @FX_LeachNov 17.2011 — Good to know. I've tried removing the encoding on the data and it's still happening.

    I'll try to dig up that bug report, but I believe that this issue is slightly different.

    The fact that Chrome is not encoding double quotes properly isn't the issue. Since I'm not using the (improperly) encoded data, it should have no effect on the page functionality. If I were to use this encoded data on the page, then yes, I would expect some errors to appear as you've illustrated in your code samples. [B]But since I'm not[/B], it leads me to believe there are other underlying issues.
    Copy linkTweet thisAlerts:
    @KorNov 17.2011 — Good to know. I've tried removing the encoding on the data and it's still happening.

    I'll try to dig up that bug report, but I believe that this issue is slightly different.

    The fact that Chrome is not encoding double quotes properly isn't the issue. Since I'm not using the (improperly) encoded data, it should have no effect on the page functionality. If I were to use this encoded data on the page, then yes, I would expect some errors to appear as you've illustrated in your code samples. [B]But since I'm not[/B], it leads me to believe there are other underlying issues.[/QUOTE]

    Well, there are different bug reports at different times... however, there is [I]something[/I] which makes Chrome to enctype double quotes in a different manner, which brings that error.

    On the other hand, you should take care about possible MySQL injections or XSS attacks, so that, in fact, at a server-side you should even remove any special characters which might be used for a malicious attack. Like using the PHP [B]mysql_real_escape_string()[/B] and [B]trim() [/B]and whichever.

    So that, I come back to my first advice: if it is not absolutely necessary, don't send special characters in query. Don't permit that, even.

    Keep it simple... ?
    Copy linkTweet thisAlerts:
    @NoobProgrammerDec 09.2011 — I am still fairly new to html and javascript and know next to nothing about php. However I am starting to become a LITTLE skilled with html and JavaScript. I have noticed myself that with the newest Google Chrome (as of Dec. 8, 2011) that with a text link (ex.: [<a href="blah">Display</a>]) that I needed to make it <a href="javascript:myFunction('parameter')">DisplayText</a> or it took me to the classic "WEB PAGE COULD NOT BE FOUND AT ... " However, when I created a button such as: <input type=button onClick="myFunction('parameter')" value="DisplayText"> the "javascript:" was not needed in order for the input to function. I am still boggled on why this is, but I hope this information helps someone.
    Copy linkTweet thisAlerts:
    @NoobProgrammerDec 09.2011 — I have noticed myself this "bug" in Google Chrome. I found that the "javascript:" was required before naming the function in text links (ex:/ < a href="...">...</a>) but not in input buttons (ex:/ <input type=button onClick="..." value="...">). I am still boggled on why this occurs, but if it must be then I say do it if it works. I have found, in my abundance of research and experience, that mechanics, programmers, and computer repair technicians all play by the book. If the book says that you don't use "javascript:myFunction(blah)", they don't use it and sit with a headache, frustration, and their page still not functioning correctly.

    My advice to all: If it works, do it. Don't make things harder than they need to be.

    (Please note that I am saying this with all due respect, and not to offend any mechanics, programmers, or computer repair technicians. That's just from my observation and experience and I AM NOT saying that it is true for all of the described. Thank you for your understanding.)
    Copy linkTweet thisAlerts:
    @KorDec 09.2011 — Once again and forever: [B]javascript:[/B] token is never [I]required[/I]. What supposed to be a Chrome bug is not related with JavaScript. It is related with the defectively way Chrome understands to encode/decode special characters
    Copy linkTweet thisAlerts:
    @FX_LeachDec 09.2011 — I don't believe it's [I]required[/I]. Maybe Noob used that word a little sparingly. We're just saying that there are certain situations (be it a bug in a browser, or even an unseen error in your own code!) when using [I]javascript:[/I] just works, when other methods don't.

    If it looks good, and you're happy with it, and you're not doing something completely ridiculous... go for it. Sometimes you just want it to [B]work[/B] and not have to stress about finding that perfect W3C-compliant validated piece of code.
    Copy linkTweet thisAlerts:
    @FangDec 11.2011 — ... that I needed to make it <a href="javascript:myFunction('parameter')">DisplayText</a> or it took me to the classic "WEB PAGE COULD NOT BE FOUND AT ... " However, when I created a button such as: <input type=button onClick="myFunction('parameter')" value="DisplayText"> the "javascript:" was not needed in order for the input to function. I am still boggled on why this is, but I hope this information helps someone.[/QUOTE]
    The anchor's natural event is also being fired. To prevent this use [I]return false[/I] after the function call:[CODE]myFunction('parameter');return false;[/CODE]
    The javascript: pseudo-protocol is only of use if you are writing specifically for IE and using javascript and VBScript in the same document.
    Copy linkTweet thisAlerts:
    @Declan1991Dec 11.2011 — I don't believe it's [I]required[/I]. Maybe Noob used that word a little sparingly. We're just saying that there are certain situations (be it a bug in a browser, or even an unseen error in your own code!) when using [I]javascript:[/I] just works, when other methods don't.[/QUOTE]The problem is that you are using a language construct without knowing what it does. javascript is not a keyword in Javascript, it's being used as a [url=https://developer.mozilla.org/en/JavaScript/Reference/Statements/label]label[/url]. We're not saying it's bad practice like the choice between putting inline JavaScript in href or an inline event handler or elsewhere, it's just a complete misunderstanding of the syntax. You can put anything in there, it makes no difference.&lt;a href="#" onclick="any_old_label: alert('Works!');"&gt;Works!&lt;/a&gt;Whether that still happens to avoid your bug with the double quotes, I don't know, but that's irrelevant, irrational solutions could make a bug work, but mistakenly using a token used to indicate something in the browser in one specific context everywhere, that is only accidentally valid syntax is always wrong.
    Copy linkTweet thisAlerts:
    @FX_LeachDec 12.2011 — Whether that still happens to avoid your bug with the double quotes, I don't know, but that's irrelevant, irrational solutions could make a bug work, but mistakenly using a token used to indicate something in the browser in one specific context everywhere, that is only accidentally valid syntax is always wrong.[/QUOTE]

    I never said it was right either. What I said was "Sometimes you just want it to work". I can get sleep on accidentally valid syntax.
    ×

    Success!

    Help @Nigorr spread the word by sharing this article on Twitter...

    Tweet This
    Sign in
    Forgot password?
    Sign in with TwitchSign in with GithubCreate Account
    about: ({
    version: 0.1.9 BETA 5.5,
    whats_new: community page,
    up_next: more Davinci•003 tasks,
    coming_soon: events calendar,
    social: @webDeveloperHQ
    });

    legal: ({
    terms: of use,
    privacy: policy
    });
    changelog: (
    version: 0.1.9,
    notes: added community page

    version: 0.1.8,
    notes: added Davinci•003

    version: 0.1.7,
    notes: upvote answers to bounties

    version: 0.1.6,
    notes: article editor refresh
    )...
    recent_tips: (
    tipper: @Yussuf4331,
    tipped: article
    amount: 1000 SATS,

    tipper: @darkwebsites540,
    tipped: article
    amount: 10 SATS,

    tipper: @Samric24,
    tipped: article
    amount: 1000 SATS,
    )...