Getting Lightbox js to work with existing js include

Discussion in 'Javascript' started by daniel, Aug 23, 2007.

  1. daniel

    daniel Guest

    Hello, I have limited understanding of js (css/html is more me) and
    when I run into complicated problems I am left undone. The person I
    normally call upon is on holiday so I was wondering if I could present
    it here for an answer.

    The page in question is
    (and will be applied to all other product pages)
    I am using the lightbox js (from
    which is here:
    and I am using my own (well actually Dreamweaver's) _basic_ mash of
    functions that sort of get me by most of the time :) and can be viewed

    Essentially the issue is in the onLoad event being required/fired
    twice. Once by Lightbox:
    function addLoadEvent(func)
    var oldonload = window.onload;
    if (typeof window.onload != 'function'){
    window.onload = func;
    } else {
    window.onload = function(){


    addLoadEvent(initLightbox); // run initLightbox onLoad

    And then again by the default.js:
    function runIt(){

    which appears as an onLoad event in the body tag of the HTML.

    With it all as it is, the image enlargement doesn't work in the
    lightbox, however, if I take the onLoad event off the body tag then it
    How do I get them to work together?
    I have removed the onLoad event from the following page so you can see
    the Lightbox working:

    Thanks for any help!
    daniel, Aug 23, 2007
    1. Advertisements

  2. Hi Daniel,

    You seem to know a bit and could probably make your life a lot more
    fun if you buy a book on JavaScript and dig in.

    I actually sent a memo to all techs at my work that those MM_
    functions have a short life expectancy as I weed through the legacy

    The problem is those DOM0 style event handlers that are clobbering
    each other. If this was all done with DOM2 listeners then it would all
    just work, I think. If you want to stick with DOM0 handlers...

    1) remove the onload="runIt()" since this is clobbering.

    2) after your definition of runIt do this

    function runIt(){


    I'm assuming that addLoadEvent is available at this point. If not
    reorder your <script src=""> elements so that it is available.

    Peter Michaux, Aug 23, 2007
    1. Advertisements

  3. The second is not a DOM 0 style event handlers, it is are defined in
    HTML 3.2 and well beyond that.
    You (and all the other delusional "unobtrusive JavaScript" followers)
    think wrong. Because you attempt to replace a *well-supported*,
    *backwards-compatible*, *standardized* feature with a *less* supported,
    *not* backwards-compatible, standardized feature. This is just madness.
    No, the standards-compliant `onload' event handler attribute is the
    best way to do this. The method should not be called before the
    document has loaded, otherwise it slows down loading the document.

    The assignment to the proprietary `onload' property should be removed
    instead, because that is error-prone.

    Thomas 'PointedEars' Lahn, Aug 23, 2007
  4. You're entitled to your opinion but your solution is not completely
    robust. I think you are being overly conservative and are going too
    far to say using DOM2 events are "wrong". For example, if I am
    building an intranet site clearly the restrictions are different then
    building an internet site. You also seem to be implying that a page
    has to work with JavaScript for all browsers. This is not the case and
    won't ever be true. At some point as you travel back though browser
    history your code will cease to work and will also not work on modern
    browsers without JavaScript. You must always plan a degradation path.
    It may be I put more browsers down the degradation path then you do
    but they all see a working page. For a general internet site it may be
    that I'm only putting 0.1% more browsers down the degradation path
    when using DOM2 listeners but most of those browsers don't support try-
    catch or === so they syntax error anyway.

    Peter Michaux, Aug 23, 2007
  5. You must be kidding. Show me where it fails. I can show you at least one
    instance where a DOM2-only solution fails.
    Why, I don't say that.
    In this case, it can and will. Most of the now standards compliant event
    handler attributes go back to DOM Level 0, i.e. NN3 and IE3.
    However, it should be the goal for any Web developer to achieve as much
    interoperability as possible.
    Perhaps you do that, but the effort to achieve that could be far less.
    0.1% of 1'000'000 potential customers are 1'000 potential customers less.
    Do you still think you can afford that?
    As for try...catch, you are not required to use that, and it can be used
    so that the code at least compiles where it is not supported.

    As for `===', this is supported since JavaScript 1.3 (NN 4.06, 1998 CE),
    JScript 1.0 (IE 3.0, 1996-08), ECMAScript Ed. 3 (at least Opera 6, 2001-12),
    and so it is hardly a compatibility issue. But, it is one that can be
    accomodated as well.

    Thomas 'PointedEars' Lahn, Aug 23, 2007
  6. If your relies on the onload attribute and JavaScript then your page
    won't work in Mosaic 1. Given you were preaching backwards
    compatibility this is a valid point.

    Please show me.

    But most of the JavaScripts I, or most people, write don't run (syntax
    errors) that far back for other reasons so it is a mute point.

    This issue of DOM2 support or not is not what makes programming the
    degradation path difficult.

    In many cases, emphatically *yes*.

    Dollars = dollars/enabled customer * number enabled customers +
    dollars/degradation customer * number degradation customers
    development cost

    If using modern technology like Ajax etc pushes more people down the
    degradation path but the first term in the equation grows more than
    the second term drops then it is a net win. Some sites sell
    specifically because they are fancy and modern. Great success with
    some customers can be better then mediocre success with all possible
    customers. This is Marketing 100 stuff.

    If development cost goes down using modern JavaScript techniques more
    than the second term goes down then it is also a net win. It could
    even be beneficial to discard the degradation customers all together
    if the degradation path is expensive to write.

    An obsession with backwards compatibility can result in lost profit.

    Peter Michaux, Aug 23, 2007
  7. It's not. Mosaic 1 is not around anymore. IE 6 is.
    See above.
    Then you have more and different problems. I what way does this make
    writing other inefficient-if-not-incompatible code any good?
    Yes, the chosen approach does.
    Your math is flawed, because you do not take three things into account:

    1. Not all customers spend the same amount of money.
    2. The human factor.
    3. DOM2-only event handler code is *less* cost-effective.

    And probably I have forgotten one.
    True. But a disregardment of that will result in an even greater loss.

    Thomas 'PointedEars' Lahn, Aug 23, 2007
  8. By DOM2 I have, of course, been meaning DOM2 + the IE version packaged
    together in a nice event library. Sloppy on my part.

    Note I've used different left hand multiplicands in the first two

    Statisically we are looking at two groups. I've accounted for their

    You're computing a final value for the equation without explaining the
    values you used. Unless you are being picky about DOM2 vs IE in which
    case I was just using sloppy language.

    Well I've accounted for all the ones you did list.

    A complete disregard may result in a greater loss.

    Peter Michaux, Aug 23, 2007
  9. That covers recent versions of about four or five distinct UAs. What about
    all the others where it could also work if the most compatible approach
    would have been taken?
    It still doesn't work out.
    You are forgetting the people that don't buy at your Web shop because it
    does not work at one of their friend's, colleague's, or relative's, and so
    cannot be recommended by them or is actively recommended against by them.
    Most humans are lazy: they won't try anything if they are sure it fails.
    It is quite simple. Determining ways of attaching event listeners and
    accomodating for element object retrieval methods of all possible DOMs
    requires much more effort than just adding the event handler attribute
    and passing `this' or `event' in its value; and since all DOMs are not
    known, the former is doomed to fail. Where `event' is not guaranteed
    in contrast to `this', granted, but has a very high probability of
    being supported (as it originates from DOM Level 0, and vendors are
    inclined to be backwards-compatible in order not to lose their user base).
    It *will*, definitely, because there are more people that don't use the
    latest technology than people that use it. Especially on the Web.

    Thomas 'PointedEars' Lahn, Aug 23, 2007
    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.