If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

doesn't conform to any javascript syntax I'm aware of. At best it does nothing. At worst it could generate an error severe enough to stop all javascript processing on the page. This would probably vary by browser.

The object contained therein (highlighted in the above) isn't even a valid javascript object. There should be a comma after each of the first two 300 values.

Now assuming the lightwindow code is available to this page at the locations specified and I haven't made any typos or other errors, this should do what it looks like you intend:

Having it inline or in a separate function should make no difference - except that inline there is less pollution of the global scope. That could be dealt with though by using addEvent/attachEvent or its equivalent from prototype.

I just tried out my code and it worked - with one important modification:

Using Event.observe is a way of keeping content and function separate. Because I execute it within a function that also contains the function named whatever, it keeps whatever out of the global scope. Both of these are just good practice, and will make it easier to add to or modify this code for use on multiple pages should the need ever arise.

I discovered that if you tell lightwindow 2.0 (which I used in my mock up) what sort of type to expect, it reacts fine without that trailing slash:

I also discovered that lightwindow 2.0 apparently (at least for this code) runs fine under prototype 1.7.0.0 and scriptaculous 1.8.3 (both the latest stable versions I think, and more advanced than those in the lightwindow distro).

This allows us to use the document dom:loaded event (faster than the window load event) and the Event.observe shortcuts:

Yes. The official lightwindow.js 2.0 is limited by the methods available in prototype 1.5.1.1 for which it was written.

At that time we had to wait for the entire window to load, including all of it's scripts, styles and images, Flash objects (if any and not streamed), etc. before clicking on a normal trigger for lightwindow would do anything special (the default without lightwindow for a normal lightwindow link is to launch the content in the current window, effectively wiping out the page).

Now we just have to wait for the DOM (HTML code) to load.

There are other refinements possible, such as making normal lightwindow content that arrives later via AJAX, innerHTML insertion, or DOM manipulation also be respected. But that's a bit more complicated.

Yes. The official lightwindow.js 2.0 is limited by the methods available in prototype 1.5.1.1 for which it was written.

Now we just have to wait for the DOM (HTML code) to load.

So it loads everything up once at the start, instead of each time?

Alright, well I made those changes - updated the prototype and scriptaculous and changed that line at the end of the lightwindow.js.

Interestingly, this has solved an error in IE where, on the second time of loading a given lightwindow on a page, an extra panel would appear on the window with the text ''by null'' on it. It didn't look so good.

Only thing now is, IE isn't displaying swf content in the lightboxes - I'm wondering if the update has effected something here.