2005/11/24

The earth goes round the sun, the moon goes round the earth, JSP sucks.

blogsMoaningAboutJSP.add(
Blogger.getInstance("http://ianso.blogspot.com")
.createBlankAnnoyedProgrammerEntry()
);


So anyway, although I do realise that JSP came a long before MVC was applied to webapp development, but WTF is a templating solution doing setting the MIME type on my response?

This is not even taking into account the stupid, stupid, requirement to compile JSPs into Java files and then Java classes, meaning that there are twice as many places for compilation errors, and twice as many places for logical errors, and a PIA to write a decent IDE for, Hell! JSP is never a good idea. But it's standard.

Ingredients for a seamless iframe with no border in IE6:

In most webapp development, you don't want to draw attention to your techniques - iframes are a good example, you don't want a "look ma, a page within a page!" feeling, you just want it to display and look & feel like the rest of your app.

In FF this is easy: the CSS is "iframe {border:0;}". Naturally, this also applies to stuff you add to the DOM via scripting.

In IE, it's a complete pain in the ass, as usual. Not only do you have to set the old-style "like it's 1999!" attributes as follows:

iFrame.setAttribute("border", "0");
iFrame.setAttribute("frameborder", "0");

you also have to set the style on the body of the iframe you loaded, as follows:

body {border:0;}

As if there was any other circumstance in which the border style of your body affects the container. Grr.

2005/11/18

More IE quirks: "This page contains secure and non-secure items. Do you want to display the non-secure items?" when using iframes in https web-pages

This one is more google-able than the ones I've noted down below, but anyway: the gist of the issue is that iframes loaded into a secure page with an src attribute of "" (an empty string) or missing, or "about:blank", are treated as insecure.

This is done when the iframe is going to be filled dynamically via javascript or equivalent.

Since network sniffing doesn't show any non-ssl HTTP requests, this one might be a bit of a pain to debug, were it not for the users of a a wysiwyg/textarea replacement project who reported the problem on their forums.

Anyway, the solution is to use src="javascript:;" as an initial value, which is apparently secure enough for IE not to throw an error message in the user's face.

1/12/2005: This also appears to happen with <object>s, with a codebase that is not https, and that sucks.