IE6 and form submit fixery
Yesterday presented a problem I was unfamiliar with, and while ie6 continues to be the bain of all web developers existance, I finally was able to emerge triumphant, with the head of the demon tucked nicely under my arm... for now. The problem of course is trying to submit a form through javascript with ie6.
After poking around the large interweb I stumbled on another site that had run into the same problem. a slightly more indepth description of the problem is that you have a form, but rather than use a submit button, you have an image wrapped in an a-tag that you have assigned a click-event too that submits the form (or sends it to some js validation, and then submits the form). This is all fine-and-dandy with any 'modern' web browser, but for some reason that only m$ can tell us, when ie6 follows the a-tag, it gets lost without ever submitting the form, it doesn't even attempt to load the page.
Some people have reported that adding an empty anchor to your a-tag fixes the problem (you know, a simple >a href='#'<), but we like code that validates, so we usually insert ye olde 'javascript:void(null);' into our a-tags when we handle them with onclicks, or jQuerify them.
The solution that we ended up using was to use a setTimeout(); around the form submit in the js. For some reason, this allows ie6 to remember what it was supposed to do and get it done. I like to think of it as a virtual kick in the teeth to the browser. Anyway, here is some sample code to help you visualize the problem and solution.
Here is our form, (yes, it has a smattering of JSTL in it 
, you can ignore that if it bothers you)
<div class="review-form-input"> <a href="javascript:document.reviewForm.submit();"> <img src="<c:out value="${jspStoreImgDir}" />en_US/submit.gif" alt="Submit" /> </a> </div> |
And here is our sample javascript code BEFORE being fixed (note the jQuery goodness, that I can't use enough of)
$(document).ready(function(){ $(".submit a").click(function(){ $("#reportForm").submit(); }); }); |
Note that the above code works fine in Opera 9+, Safari 3+, Firefox 3+ (and most-likey but untested in Firefox 2+), and yes even the black-sheep of the browser family ie7 can render and run this code just fine.
Here is the fixed javascript...
$(document).ready(function(){ $(".submit a").click(function(){ setTimeout('$("#reportForm").submit();', 50); }); }); |
Yep, that's it, a very subtle change, just inserting the setTimeout() method fixes the ie6 stupidity.
Print This Post
JSTL Agent identification
So converting NT2.2 to be IE6 friendly was a kick in the teeth... and as Dustin posted earlier, it would have been nice to throw up a warning window and let them see the horror or an IE6 rendering job. However we coded it up to be usable in IE6 and in the process had to rewrite some of the homepage. At first I used the ugly <![if IE 6]> // do something magical <![endif]--> tags, but they caused Safari to explode on itself. So I went back did a quick study and came out with a JSTL solution, and then modded it with Drew to get it working.
Using JSTL you can get the browser through the user-agent string in the URL request header. Like this:
<c:set var="browser" value="${header['User-Agent']}" scope="page"/> |
You can see that I used a c:set to get the 'User-Agent' string and set the variable 'browser' to that value.
Now we just need to set up a c:choose to determine the path of IE 6 or other browser types using the indexOf function in the JSTL 'fn' library. So a quick c:choose statement would look like this.
<c:set var="browser" value="${header['User-Agent']}" scope="page"/> <c:choose> <c:when test="${!empty browser && fn:indexOf(browser, 'MSIE 6') >= 0}"> NOT EMPTY </c:when> <c:otherwise> EMPTY </c:otherwise> </c:choose> |
In the 'c:when test' you can see that the indexOf ends with a '>=0', this is because indexOf returns an INT, which is treated Boolean-esque in this case (it's not a Boolean, but the way we are using it resembles a Boolean).
Don't forget that when using the JSTL fn and c tag libraries you need to include them in your jsp file. use the following at the top of your page to use these excellent tag-libs.
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %> <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> |
If you have any questions, leave'em in the comments 
.
Print This Post
jQuery pngFix
One of the greatest jQuery plug-ins that I have stumbled on has been the pngFix plugin. This fantastic piece of code takes your png images and applies the AlphaImageFilter logic to make ie6 actually display them with the correct transparency (not that nasty gray-ish stuff) When I found it, I was ecstatic, when I first tried it I was overjoyed! Then I tried to develop with it.
While this may be uncommon for most users, it has a severe bug. In fact the bug was mentioned on the creator's blog in the comments by one unfortunate user (Dj) who ran into the same thing I did. The problem arises when you use a png as a clickable object, or even as a background where your clickable object is going to be. As near as I can tell, when the pngFix executes, it grabs all the png files on the page and runs then through the image filter and then slams them back down on the page. On top of all of your links... on top of everything. I tried changing the z-index of my links, I tried changing the png image from a background to an img-tag. Nothing worked. I had almost given up hope (as there was no answer posted on the blog) when I found another site that mentioned the problem. Someone in there (Elbert Oh) had commented that they had found a possible solution and pointed users towards this site for examples.
By using the example site, I ended up with a working solution (this will be deployed in the new ProForm site)
Here is an example of the solution (with the correct code in place)
Here is the header image that will link back to the homepage
Seems simple enough right? Here's the css that I used.
#logo { margin-left: 531px; height: 90px; background: url('images/logo.png') no-repeat scroll 0px 3px; } #logo a { display: block; width: 459px; height: 90px; position: relative; z-index: 1; } #logo a span { display: none; } |
What you should be able to see here is that I set the logo appear on the right side of the page (hence the fatty margin-left). Then I set the height of the object, and finally pointed it to the png image that I'm using as a background (that without the fix would be picked up, filtered, and then slammed back down on top of my clickable area).
I made the link take up the entire image area by making the display a block and setting the width and height to the same dimensions as the image. Then there's the real magic of making this work. setting the position to relative, and then setting the z-index to 1. ((POSSIBLE BS ALERT)) Somehow the positioning gets tweaked when the transparency filter is applied and that is part of the reason for the links becoming unclickable. By setting the position to relative, and then setting the z-index to 1, it forces the image to stay where it is and leaves the links clickable. That may not be what is actually happening, but I think that's what's going on...
Anyway with those small changes, the site* is now working with clickable links and png images in ie6, ie7, Firefox 2, Firefox 3, Safari 3.1, and Opera 9.5 .
*The development site on my local server, not the actual ProForm.com as we have not launched the new site yet
Print This Post
IETester: my new best friend for handling my worst enemy
I found a great tool out in the depths of the interweb, and I thought that I'd do a quick-ish post on it so that I can share the happiness with other people. The tool is called IETester, and it is brilliant. It seems to be a mdi container that is hooked into the api's of IE5.5, 6, 7, and 8 beta 1. This allows you to crack open a tab using each rendering engine and view your websites the way they would look in that browser.
This (above) is a screen shot of the program with the about pop up showing as well as several tabs open (all at nordictrack.com)
NordicTrack in IE 5.5 (above)
NordicTrack in IE 6 (above)
NordicTrack in IE7 (above)
NordicTrack in IE8 (above)
As you can see from the pictures, each release of IE handled the css styling and the page layout a little bit differently. It's almost fun to watch IE change from its quirky youth to an almost standards compliant browser (yes almost is a stretch isn't it).
BUGS:
Yeah you knew there'd be some, here's what I found, and what is posted on the developer's website.
- I almost went into epileptic shock while using it. Lots of screen flickering.
- It crashed on me the first time I opened it, not sure why.
- If you resize the screen, content may disapear.
- Flash may not work in the IE6 rendering engine (note: it did work for me at freemotion).
- Previous/Next buttons may not work.
- Focus doesn't work properly.
- Java applets esplode.
- Javascript loading may have problems... (may be the hidden cause of the screen flickering)
Print This Post