I haven't even tested IE9 because I can't be fucked with the setup hassle.

I tried the IE10 preview and it's got a shit installer that doesn't work.

IE8 is functional, though I had to duplicate a chunk of jQuery and change it slightly to make it work (and make my code more brittle), and I still couldn't figure out why borders aren't showing, so it looks crap.

I get unnecessary scrollbars in IE and Chrome, but not in the others.

etc.

I got things good enough, but I'm pissed off stuff so simple doesn't behave consistently nor as expected.

I've just uploaded the new QuickSlide files to replace my old ones and I've broken it.

 

Before I start digging any ideas?

And by not working it's just opening the image in a new tab (Chrome) rather than in the QuickSlide box.

Hrmm, possiby. I changed the options thing around a bit. What options are you using now? Could you provide a demo page?

Edit: to clarify, it should work fine even if you don't specify any options at all, so long as you have rel="quickslide" in your links' attributes.

Here's a test page

Peter if you ever need someone to test pages for you let me know. I have Chrome, IE8, IE9 and for you I'd even install FF.

Ok, fixed it now. Because you're putting the script tags in the document head, it's failing when it tries to add the dimmer and box to the document body, because that doesn't exist yet. I've changed it so it waits for the window onload event before adding the elements (unless you specify the no_wait option). New version uploaded to my site.

Also, you should put script tags at the end of the document, just before the closing body tag, as they block page rendering until the files they reference have been loaded and parsed. This isn't so bad if you're just loading files from your own server, but if you ever need to load external ones (e.g. jQuery from the Google CDN) it could make your page appear to load slower than necessary.

Ahh, ok, my fault then. It had been there all along though, not sure what made me put it there though.

Fixed by moving the <script> tags, but I'll download the new version anyway.

Is that top secret tin foil?

You can test it when it goes live - I'll need to see how people who can't read react to it. :P

haha whut?

Nope!

Alternatively, you should put script tags in the head of the document because they block page rendering until the files they reference have been loaded and parsed, and that means you don't get a page that has rendered but is buggy and unresponsive because only half the scripts have loaded. :@

I've also updated it so it will still work even if you put the script tags in the head and use the no_wait option; in such a case it'll just pretend you didn't use no_wait.

It's not your fault!

The head is where script files have always been intended to go - the blocking of loading is deliberate. It's a relatively recent fad of "optimising" pages by putting them at the end.

As above, it means that the page can load and look like it's ready before any of the JavaScript is actually executed, which is especially a pain when people use files on a slow CDN, and you have to sit waiting before you can interact with a page.

It wouldn't be a problem if document.write() never existed :-/