href="javascript:func()" vs href="#" onclick="javascript:func()"

Discussion in 'HTML' started by CRON, Jun 18, 2006.

  1. CRON

    CRON Guest

    Howdy!
    I was wondering which is better to use:

    href="javascript:func()"

    OR

    href="#" onclick="javascript:func()"

    Problem is the second one, anchors to the top of the page which is very
    messy in most cases.

    Thanks
    Ciaran ;c)
     
    CRON, Jun 18, 2006
    #1
    1. Advertisements

  2. Better to have

    <a href="someRealUrl" onclick="return someJavaScriptFunction()">...

    That way if someone has JavaScript disabled they are not left wondering
    why the link goes nowhere!
     
    Jonathan N. Little, Jun 18, 2006
    #2
    1. Advertisements

  3. CRON

    CRON Guest

    Cheers again Jonathan,
    But what if you don't want the link to go anywhere? If it is solely
    there to run the javascript function? Is there anything wrong with
    href="javascript:func()" ? It is simple and clean and makes more sense
    to me.

    Ciaran
     
    CRON, Jun 18, 2006
    #3
  4. CRON

    Dan Guest

    [top-posting snipped -- http://mailformat.dan.info/quoting/ ]

    In many (most?) cases, the JavaScript link is there to bring up some
    content in some fancy way (like in a popup box), so it would make sense
    to have a valid link URL as a graceful degradation in the case of
    non-JavaScript-enabled users.

    Your function can end with "return false;" in order to suppress the
    normal link, so it won't do something annoying like jump around in the
    page when JavaScript is enabled.
     
    Dan, Jun 18, 2006
    #4
  5. CRON

    CRON Guest

    That's a good way to deal with it - Never thought of that before.
    Thanks a bunch Dan,
    Ciaran
     
    CRON, Jun 18, 2006
    #5
  6. CRON

    CRON Guest

    Best solution found::::

    <a href="#" onclick="func();return false">

    This is a handy way to stop the page from jumping around but still run
    the function.
     
    CRON, Jun 18, 2006
    #6
  7. The only circumstances under which you should consider using a
    javascript: pseudo-protocol HREF is when the expression evaluates as a
    string of HTML that it intended define the replaced content of the
    current page (or the entire contents of a new window), and mostly not
    even then as the result is inevitably javascript dependent.

    A significant practical reason for this is that some browsers (and
    importantly including windows IE browser) regard the activation of such
    a link as navigation. A consequence of this apparent navigation is that
    the browser puts the current page into a 'waiting' state in anticipation
    of the navigation resulting in the current page being replaced. In this
    'waiting' state some resource hungry activity is closed down by the
    browser.

    The simplest demonstration of this phenomenon is to create a page
    containing an animated GIF and a link with a javascript pseudo-protocol
    HREF, load it into IE 6, and observe that the animated GIF promptly
    stops animating as soon an the HREF is activated.

    The list of things that stop working as expected once a javascript
    pseudo-protocol HREF has been activated includes META refresh stopping
    working, Flash-javascript interaction problems, image swapping and
    pre-loading issues and a number of other scripting related issues.
    Indeed the consequences of the use of javascript pseudo-protocol HREF
    regularly feature in questions asked in the comp.lang.javascript
    newsgroup, although no comprehensive list of related issues has been
    created because the general conclusion is that such links should never
    be used and once their use has ceased no consequential issues remain to
    be studied.
    In javascript syntax the "javascript:" at the beginning of that onclick
    attribute's value is a label, used with the - continue - and break -
    statements to define the exit points of loops. The rest of the attribute
    value contains no loops, continue or break statements, so the label is
    redundant.

    Microsoft took advantage of this construct being syntactically valid in
    javascript to allow this label to be used to define the type of
    scripting language that would be used to interpret the value of the
    onclick attribute, but they also made JScript the default, so unless an
    alternative scripting language is used on a page in a way that stops
    JScript being the default the label is still redundant on Microsoft
    browsers.

    This also means that if a label is wanted in the value of an intrinsic
    event attribute 'javascript' is the one label that should never be used
    (well, not the 'one' as 'vbscript', or the name of any other installed
    scripting language, would also be a bad ideal).
    Only if you don't cancel the default action of the link.

    Of the two the second is better because the former should never be used.
    The latter would be improved by having an ability to cancel the link,
    preferably conditionally.

    Ultimately the best option may be to use some other sort of element
    (i.e. <input type="button">) to trigger activity that is not navigation.

    Richard.
     
    Richard Cornford, Jun 18, 2006
    #7
  8. CRON

    Neredbojias Guest

    FYI, another best way is:

    <a href="javascript:void(0)" onclick="func()">
     
    Neredbojias, Jun 18, 2006
    #8
  9. The first "best solution" is a link to the start of the page, with a
    scripted that overrides the link functionality with the invocation of a
    function, when scripting is enabled. That does not sound quite logical to
    me. A self-referencing link would be slightly more logical as well as much
    more practical when scripting is disabled:
    <a name="foo42" href="#foo42" onclick="func();return false">
    Of course, if the sole purpose of the "link" is the scripted event, then the
    link should be dynamically generated using the scripting language, so that
    the link is there if and only if scripting is enabled. In that case, you
    could use href="error.html" where error.html is a page that explains that an
    unexpected error has occurred, etc.

    Using href="javascript:void(0)" does not conform to any published
    specification, since there is no such spec that defines javascript: URLs.
    Besides, it fails even on some old browsers that do not recognize such URLs
    (or pseudo-URLs), despite supporting JavaScript.
     
    Jukka K. Korpela, Jun 18, 2006
    #9
  10. Yes, and it even fails on some modern browsers, like Opera. AFAIK, Opera
    doesn't like href="javascript:anything". Opera is my default browser, and
    I'm redoing a site that has tons of links like this - none of 'em work - so
    I am replacing them with plain hrefs.
     
    Adrienne Boswell, Jun 18, 2006
    #10
  11. CRON

    Toby Inkster Guest

    Works fine here: http://examples.tobyinkster.co.uk/javascript-url

    Tested in Opera 5.12, 6.06, 7.03, 8.02 and 9.00 Beta 2.
     
    Toby Inkster, Jun 18, 2006
    #11
  12. CRON

    Jim Higson Guest

    The best way I'd say is to not include any link in the page, but then add it
    in using javascript once the page has loaded.

    Or, if the link must be created on the server-side, try something like:

    <a href="javascript:whatever()" style="display:none" id="js-link">blah</a>
    <script type="text/javascript">
    var link_ele = document.getElementById( "js-link" );
    link_ele.setAttribute( "sytle", "" );
    </script>

    This way, the link will only be shown if the user has javascript enabled.
     
    Jim Higson, Jun 18, 2006
    #12
  13. The point is links is to go somewhere. If you don't want to go somewhere,
    then don't use a link (or link to a page explaining /why/ JavaScript is
    required - and I suggest phrasing it as an apology, don't insult the user
    for disallowing untrusted third party program code from running on their
    computer). A large number of the really useful things that JavaScript can
    do can be done server side too, so a server side alternative is a good
    fallback URL.
     
    David Dorward, Jun 18, 2006
    #13
  14. Or stylesheets disabled or unavailable.
     
    David Dorward, Jun 18, 2006
    #14
  15. Better would be use JavaScript to actually insert the link code, then
    and only then when JavaScript enabled would the link appear.
     
    Jonathan N. Little, Jun 18, 2006
    #15
  16. CRON

    Jim Higson Guest

    Like I said in the grandparent post, a better way still is to create the
    link altogether in js using DOM. Something like:

    <span id="link-placeholder" />
    <script type="text/javascript">
    var a_ele = document.createElement ( 'a );
    a_ele.setAttribute( 'href', 'javascript:whatever()' );
    a_ele.appendChild( document.createTextNode( 'blah' ));

    var placeholder_ele = document.getElementById( "screensaver-intro" );
    placeholder_ele.parentNode.replaceChild( a_ele, placeholder_ele );
    </script>

    Now, I think that covers all bases?
     
    Jim Higson, Jun 18, 2006
    #16
  17. Well to be precise you only use JavaScript in that post to remove the
    element's styling that was hiding it...not to create the link.
     
    Jonathan N. Little, Jun 18, 2006
    #17
  18. CRON

    Neredbojias Guest

    To further the education of mankind, "Jukka K. Korpela"
    In other words, clicking the link with javascript disabled will reload
    the page and return the user to the same spot from which he started.
    Sounds good.
    I very much agree. Similarly, I've done many pages with, for example,
    (pseudo) lists of thumbnail image links. There is no javascript to be
    seen in the html per se; any j/s events, etc., are added afterwards by a
    link-loop which, of course, does nothing with j/s disabled.
    Well, javascript:void is a core javascript construct, and if the browser
    supports javascript... Perhaps there is no _specific_ _html_ spec citing
    "javascript:void" verbatim, but I hardly consider that a good reason to
    avoid it's usage. There is much documentation written regarding this
    usage which certainly seems acceptable and valid by all parties
    concerned.

    http://developer.mozilla.org/en/docs/Core_JavaScript_1.5
    _Reference:Operators:Special_Operators:void_Operator
     
    Neredbojias, Jun 19, 2006
    #18
  19. CRON

    Philip Guest

    Since Javascript is apparently a requirement for this page to operate
    correctly, you might want to include a noscript block at the top like so:

    <noscript>
    <div>O ye pitiful mortal, thou art humbled before my site! Begone, and
    return only with a browser which supporteth Javascript!
    </div>
    </noscript>

    Or something a little less ridiculous. I think you get the picture.

    Cheers
     
    Philip, Jun 19, 2006
    #19
  20. Really? I thought core javascript was ECMAScript.
    By HTML specifications, the content of an href attribute is a URL (or a
    URI), so a specification of the javascript: _URL_ would be needed. This
    would not be part of HTML _or_ JavaScript but a separate specification;
    normally URL specifications are published as RFCs. It would of course
    specify it as a pseudo-URL, which is a URL syntactically only. Anyway, there
    is no such specification.
    Browser vendors' documents are not specifications.
     
    Jukka K. Korpela, Jun 19, 2006
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.