SeeMySites Blog

Ok, this is a problem that has vexed JavaScript programmers for a long time, and frankly most of the solutions for this problem are rather convoluted. At first, I had written a helper function to determine whether or not Internet Explorer was being used, and then I figured out a better way to do things. Here is an example:


var file_input = document.createElement('input');
file_input.type = 'file'; // Works in everything EXCEPT for Internet Exploder
file_input.setAttribute('type', 'file'); // Works for everything I have tried it in so far.


So there. One less nightmare that you have to deal with when coding in JavaScript.

I think it’s about time that I wrote this one down. Perhaps if I got it out of my system I would feel better, but I doubt it. As I am trying to come up with a new design for TuneSmith Central, I am butting my head up against some rather stupid problems in Internet Explorer. I personally call IE the whore of all the earth, though one of my associates likes to call it “Internet Exploder.” Both are rather accurate. Honestly, the only browser that is worse than IE which I have personally come across is Konqueror (a Linux browser that seems to be dropping out in favor of Firefox). Even Safari is better than IE in almost every respect except for dynamic editable HTML content - which has been fixed in the lastest version of the code. IE’s JavaScript interpretation, JScript, still is not standards compliant after all these years. I even came across a bug a couple of days ago for using innerHTML on a select to add options - after searching around on the ‘Net, I found out that this bug has been there since version 5 - almost 10 years and Microsoft has never fixed it. Worse, they’ve known about it for almost as long as the bug has been around. CSS support is better with version 7 than in previous versions, but there are still too many bugs. I can get my designs to look great in Firefox, Opera, and Safari with little coding effort - with IE it is almost always laborious to make things look right. There is almost always a small, non-obvious bug that totally trashes a certain aspect of the layout. I pray for the day when M$ is no longer a monopoly. It took the emergence of Firefox for them to start fixing Internet Exploder, but they still have a long way to go.

I have tested this in IE7, Opera, Firefox, and Safari (latest to date versions) as well as WebKit. What I have found is that for some stupid reason, IE7 and Safari do not respect min and max widths on tables. Unfortunately due to a couple of limitations in CSS, and also because IE 6 with its garbage CSS support is unfortunately still used in large numbers, I am forced to use tables for layout on occasion. I hate it, but I do what works. I can’t always work on principle alone :). Anyway, if you find yourself needing a fix for this dilemma, it’s pretty easy: enclose the table in a DIV, which all the latest browsers support these properties on.

So:

<div style=”min-width: 45em; max-width: 55em; width: 50%; position: relative”>
<table>
<tr>
<td>Table Content</td>
</tr>
</table>
</div>

I have included the minimum amount of code needed in order to get this to work properly in all latest version browsers. To get IE 6 to behave like it supports min-width, I suggest you do a Google search on that one. I try to make my designs so that overall it functions better with these attributes, but works OK if the browser does not display it correctly.

There is a feature called “haslayout” in IE that often drives web developers insane - mostly because many are not aware of this so-called feature. If you want more information on this, I suggest you search Google for the term “haslayout” - you will get a wealth of information on it and so I will not elaborate on this here. This article will deal with a bug/annoyance with IE 6 in which JavaScript resizing goes very slow inside a container that has haslayout enabled.

I am currently working on a project in which it is necessary to have a minimize/maximize function for DIVs as there is a lot of information on the screen and it is helpful to only have the headers visible until the user decides that he wants to access the options below the headers. I made a function to make the minimize/maximize function more fluid (with the DIV being resized in increments) rather than an all-at-once surprise. It works fine in every browser by itself, but I had to give the containing element “layout” in order for floats to work properly in Internet Explorer. If you don’t know what I’m talking about, do that Google search at the top. I did this by using position: relative in the style for the containing div, but I also tried using other “haslayout” methods like zoom: 1 with the same results. Any time the containing element had the “haslayout” property enabled, the rendering was about twice as slow as before. IE 7 does just fine with it, but IE 6 has the problems. I have not been able to test for older versions of Internet Explorer yet, but it is driving me nuts have to work around garbage like this. In futility, I decided to put a warning up on the login page if a user is using IE6 to upgrade to 7 or get a better browser like Firefox.