My Box

[jscheuer1]

I've been working on my own take of lightbox/slimbox/interstitial content box/et al - and am ready for some feed back. I wasn't going to call it My Box, until I did a search on Google and found that no one appears to have such a named script yet. That and the fact that there was this hilarious video . . .

Anyways here's the link to the demo page:

http://home.comcast.net/~jscheuer1/side/mybox/

The script is really very easy to use, but I think I could explain it more simply. So, in addition to any critique of the code, help in making the explanation seem simpler and clearer would also be appreciated.

[alexjewell]

Wonderful! I may use the iFrame one.

[djr33]

Works fine in Mozilla 2.0 for Mac.
The only trouble was with the extra large image when it overlapped the lower textbox, and the scrollbars popped up through the image.
I'm not sure if this is a bug or your script or of the browser, as I have seen this before, though not frequently. (The other time I've seen this is with the IM windows in www.meebo.com.)

Now... for Safari 2.0 for Mac.
The script works identically for the first two links, and the link from 'hi' to 'bye'.
However, all of the rest (images, ajax, iframes) fail, simply loading in a new window. This proves, at least, that the script IS backwards compatible without any negative feedback, etc.


One thing I note about the script is its lack of fancy sliding/loading effects. This is good, or bad, depending on how you look at it.
I don't particularly like all of these effects and think there should at least be a way to disable them (if you were to add them).
But there are a lot of users out there who might want such and effect.

Just something random-- would it be possible to enable the escape key to exit the viewer?

[kobo1d]

hey lol.. i just thought about a script like that, for some stuff on my page..
and then i saw your post.. nice.. goana try it out !

[djr33]

Another thought came to mind--
I've seen your scripts, so I can only assume this is coded as well as or better than other similar scripts.
However, is there anything else that makes this worthwhile? What does this have that other scripts don't have?
I suppose it does certainly allow for various types of content. That's very convenient.

(I'm not challenging it with this question, but just suggesting that you may want to try to think of something you could do to set it clearly one step above any similar options.)

[jscheuer1]

Well, thanks folks. Um, lessee, the idea for this was first of all, none of the implementations of boxes that I saw around handled videos very well. That's because videos will continue to play unless you navigate away from them. Using an iframe wasn't even enough in and of itself. The iframe handling in this code actually navigates to a blank (about:blank) page whenever an iframe box is closed, and does so effectively for stopping a video. Navigating an iframe brings with it the issue of the history stack. Working out a way around this was the real trick to the code. That, and finding a way to get all the browsers I tested on to follow it, as well as to follow the Ajax routine without looking odd while doing so.

Then I figured, why not do everything else that these scripts offer - at least from the point of view of the types of content that can be loaded. I didn't want to load it up with special (ala scriptaculous or mootools) effects though. I wanted the code to be about as light weight as possible, while still providing an engaging interface. I copied the basic look of the box from DD's interstitial content box - without looking at the code, just figured out how I'd do it. That is css driven and can be customized. However, owing to the necessity of IE specific styles, getting IE and all others to follow the changes will be tricky if anything more than basic color and font changes are desired.

I also wanted to make the interface for a page designer to be as simple as possible. Lightbox has that, but does only images, some of the other scripts out there require you to write a mini script to initialize each box. I came up with the four similar and fairly simple methods outlined on the demo page as well as easy ways to call up a box or to close one with javascript code to be used anywhere on the page.

So, nothing really special here, it's just done the way I think it should be.

I'm still looking forward to code critiques and information on making the explanation of how to use it easier. I also want to go through the code again after a bit of time to see if I can cut it down a bit more or improve it in some way(s).

[Twey]

Rather nice, well-constructed. Just a few qualms:

if(window.opera||/Apple/.test(navigator.vendor))

Browser detection bad Also, I don't like your extensive use of the string form of the Function constructor. This is similar to using eval(), and as everyone knows, eval() is evil.

[mwinter]

http://home.comcast.net/~jscheuer1/side/mybox/

The script is really very easy to use, but I think I could explain it more simply.

The whole explanation, or are there some specific parts you don't like?

So, in addition to any critique of the code, [...]

I've had a cursory glance, though I'd reformat the code before critiquing it: if you want critiques, making the code pretty first would be nice.

I don't like the escaped new lines in the initial string literal: these are actually illegal, though tolerated in most browsers. I'd either settle for string concatenation or joining an array (below). The two other escapes are unnecessary, too - the first always is, no matter how the script is included.

document.write(['<style type="text/css">',
    '#boxcontent {',
    '    position: absolute;',
    '    top: -80000px;',
    '    left: -80000px;',
    '}',
    '</style>'].join('\n'));

As someone might call a "box" mybox, you should declare the global with the same name properly using a variable declaration. If you don't, an exception will occur in MSIE as it will create its own read-only global. A variable declaration will give priority to the script - this is why globals should always be explicitly declared.

Not a problem, but curious: why use the DOM 0 Image constructor function if you're depending upon the DOM 1 createElement method? It seems strange to mix the two unnecessarily.

I'm sure you know that I'd appreciate feature detection and a defensive style, which seems absent.

The regular expression could be simplified to:

  ^(img|iframe|ajax|id)$

The initialisation portion of the for loop that follows is redundant.

The default for getAttribute in MSIE is a case-insensitive attribute search so the second (kludgy) argument isn't necessary. However, I would recommend that you drop use of the method entirely and use property equivalents.

Rather than obtain the value of the rel attribute repeatedly, cache the value and avoid the overhead of all of those method calls (or property look-ups). This applies to similar code patterns.

Drop the call to overrideMimeType and the related code. As discussed previously, this method is really only of use when wanting to have the response parsed as XML so that the responseXML property can be used to access the document using DOM methods. If you're only using the responseText property, attempting to change the media type is redundant.

[jscheuer1]

Rather nice, well-constructed. Just a few qualms:

if(window.opera||/Apple/.test(navigator.vendor))

Browser detection bad Also, I don't like your extensive use of the string form of the Function constructor. This is similar to using eval(), and as everyone knows, eval() is evil.

The browser detection is simply to disallow the changing of the font-weight on hover of the close button. Both Safari and Opera handled it poorly, yet it looks so nice in others. If I could find another way, I will go with it - ideally a way that allows those two browsers to handle the effect. Safari moved the close link in response to its changing font-weight, even though it is positioned absolutely. Opera didn't do that, but did shift the contents of some iframe loaded pages slightly when this hover effect was applied - a very strange and virtually impossible to track down response.

I may rip out the new Function() and replace it with a direct assignment of a function. I had it like that at one point, but I think I like it better this way. You can assign your own onclick events to the links without them being overwritten by the script. The eval like component of it isn't very open to problems though, as any errors that arise would (I think only) be due to a weird URL with math operators in it (in the case of Ajax) being used - however, as it would be a string, maybe not even that would be a problem. The rest of the assignments are carried out in a controlled fashion and can only be the type of values expected. The other option, attaching/adding a function, would involve extra code and properties (if doable), but might be worth looking into.

[Twey]

The eval like component of it isn't very open to problems though, as any errors that arise would (I think only) be due to a weird URL with math operators in it (in the case of Ajax) being used - however, as it would be a string, maybe not even that would be a problem.

Performance is more of an issue really. eval() and new Function() both create a new compiler instance to compile the code, something that's done on every iteration. This is horribly inefficient. A closure would be much more efficient, and only slightly more code.

The browser detection is simply to disallow the changing of the font-weight on hover of the close button. Both Safari and Opera handled it poorly, yet it looks so nice in others.

Handled it poorly how? I see the difference in it between Konqueror and Firefox (the letters shift outwards to accommodate their new weights in Konq) but they both look rather ugly to me Also, a prime example of why this approach to working around the problem is bad is demonstrated right here: it also exhibits what I presume is the unwanted behaviour in other browsers that you haven't considered. In fact, since Presto and KHTML are known for their standards-compliance, I'd suspect that that behaviour is probably actually correct.
If you can't find a more flexible way of deciding whether the effect will work or not, don't use the effect.