Getting Lightbox js to work with existing js include

[daniel]

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 http://www.sunraycomfort.com.au/p-inslab.html
(and will be applied to all other product pages)
I am using the lightbox js (from http://huddletogether.com/projects/lightbox/)
which is here:
http://www.sunraycomfort.com.au/lightbox/lightbox.js
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
here:
http://www.sunraycomfort.com.au/default.js

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(){
oldonload();
func();
}
}

}



addLoadEvent(initLightbox); // run initLightbox onLoad
---------------------------------------------

And then again by the default.js:
---------------------------------------------
function runIt(){
MM_preloadImages(
...snip...
);
}

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
works...
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:
http://www.sunraycomfort.com.au/p-undertile.html

Thanks for any help!
daniel

 

[Peter Michaux]

Hi Daniel,

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.

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.

The page in question ishttp://www.sunraycomfort.com.au/p-inslab.html
(and will be applied to all other product pages)
I am using the lightbox js (fromhttp://huddletogether.com/projects/lightbox/)
which is here:http://www.sunraycomfort.com.au/lightbox/lightbox.js
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
here:http://www.sunraycomfort.com.au/default.js

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
code.

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(){
oldonload();
func();
}
}

}

addLoadEvent(initLightbox); // run initLightbox onLoad
---------------------------------------------

And then again by the default.js:
---------------------------------------------
function runIt(){
MM_preloadImages(
..snip...
);

}

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
works...
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:http://www.sunraycomfort.com.au/p-undertile.html

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(){
MM_preloadImages(
..snip...
);

}
addLoadEvent(runIt);

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

Peter

 

[Thomas 'PointedEars' Lahn]

Essentially the issue is in the onLoad event being required/fired
twice. Once by Lightbox:
[...]
window.onload = func;
} else {
window.onload = function(){
[...]
And then again by the default.js:
---------------------------------------------
function runIt(){
MM_preloadImages(
..snip...
);

}

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
works...
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:http://www.sunraycomfort.com.au/p-undertile.html

The problem is those DOM0 style event handlers that are clobbering
each other.

The second is not a DOM 0 style event handlers, it is are defined in
HTML 3.2 and well beyond that.

If this was all done with DOM2 listeners then it would all
just work, I think.

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.

If you want to stick with DOM0 handlers...

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

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.


PointedEars

 

[Peter Michaux]

Essentially the issue is in the onLoad event being required/fired
twice. Once by Lightbox:
[...]
window.onload = func;
} else {
window.onload = function(){
[...]
And then again by the default.js:
---------------------------------------------
function runIt(){
MM_preloadImages(
..snip...
);
}
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
works...
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:http://www.sunraycomfort.com.au/p-undertile.html

The problem is those DOM0 style event handlers that are clobbering
each other.

The second is not a DOM 0 style event handlers, it is are defined in
HTML 3.2 and well beyond that.

If this was all done with DOM2 listeners then it would all
just work, I think.

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.

If you want to stick with DOM0 handlers...

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

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.

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

 

[Thomas 'PointedEars' Lahn]

You're entitled to your opinion but your solution is not completely
robust.

You must be kidding. Show me where it fails. I can show you at least one
instance where a DOM2-only solution fails.

I think you are being overly conservative and are going too
far to say using DOM2 events are "wrong".

Why, I don't say that.

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

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.

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.

However, it should be the goal for any Web developer to achieve as much
interoperability as possible.

You must always plan a degradation path.

Perhaps you do that, but the effort to achieve that could be far less.

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

0.1% of 1'000'000 potential customers are 1'000 potential customers less.
Do you still think you can afford that?

but most of those browsers don't support try-catch or === so they syntax
error anyway.

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.


PointedEars

 

[Peter Michaux]

You must be kidding. Show me where it fails.

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.

I can show you at least one
instance where a DOM2-only solution fails.

Please show me.

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.

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.

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.

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

0.1% of 1'000'000 potential customers are 1'000 potential customers less.
Do you still think you can afford that?

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

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] wrote:
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.
You're entitled to your opinion but your solution is not completely
robust.

You must be kidding. Show me where it fails.

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.

It's not. Mosaic 1 is not around anymore. IE 6 is.

Please show me.

See above.

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.

Then you have more and different problems. I what way does this make
writing other inefficient-if-not-incompatible code any good?

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

Yes, the chosen approach does.

In many cases, emphatically *yes*.

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

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.

An obsession with backwards compatibility can result in lost profit.

True. But a disregardment of that will result in an even greater loss.


PointedEars

 

[Peter Michaux]

Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
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.
You're entitled to your opinion but your solution is not completely
robust.
You must be kidding. Show me where it fails.

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.

It's not. Mosaic 1 is not around anymore. IE 6 is.

Please show me.

See above.

By DOM2 I have, of course, been meaning DOM2 + the IE version packaged
together in a nice event library. Sloppy on my part.

Your math is flawed, because you do not take three things into account:

1. Not all customers spend the same amount of money.

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

2. The human factor.

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

3. DOM2-only event handler code is *less* cost-effective.

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.

And probably I have forgotten one.

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

True. But a disregardment of that will result in an even greater loss.

A complete disregard may result in a greater loss.

Peter

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
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.
You're entitled to your opinion but your solution is not completely
robust.
You must be kidding. Show me where it fails.
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.

It's not. Mosaic 1 is not around anymore. IE 6 is.

I can show you at least one instance where a DOM2-only solution fails.
Please show me.

See above.

By DOM2 I have, of course, been meaning DOM2 + the IE version packaged
together in a nice event library. Sloppy on my part.

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?

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

It still doesn't work out.

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

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.

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.

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).

A complete disregard may result in a greater loss.

It *will*, definitely, because there are more people that don't use the
latest technology than people that use it. Especially on the Web.


PointedEars