IE 7 Bugs are at it again!

Today's fun is with Unordered Lists. The basic structure is like this:

• something
• something else
• another something

The styles that go with it are pretty simple too:

list-style-type
list-style-image
list-style-position

So why does it have to be so hard for Internet Explorer to render these little buggers correctly? If you can answer that question, Fly to Seattle and let MS know... maybe they'll make you a millionaire...

Okay... enough of the bashing and onto the issue at hand.

1. IE does not correctly handle margin/padding with image bullets... lets say you want there to be a 10px top margin so that your bullets are not stacked right on top of each other, FireFox does just fine... IE moves the text but forgets to line up the bullet... the solution? Take your bullet image and add some transparent canvas to the top... luckily, FF will still line the image up for you.

2. IE does not like if you specify a height on an LI where you are using "list-style-position:inside;". For whatever untold reason, IE decides to make it "list-style-position:outside;" instead. This is clearly a bug. FF also handles this correctly... the solution? either add padding-bottom to the LI or margin-top to an element inside the LI.

3. If you set the UL & LI to "padding:0;" and "margin:0;" and set "list-style-position:inside;" with a nested LI that is set to "list-style-position:none", IE does not correctly align the first line within the nested LI.

The first line within the nested LI gets indented to the same position it's parent LI, while every subsequent line is flush to the left. Again, clearly a bug... Again, FireFox handles this fine making both lines flush left. The solution? Add a break tag before the text... the downside is, this leaves vertical space between "item:" and your first line of text in BOTH browsers. Another solution is to use an empty div tag with it's height set to 0. This will fix indention problem in IE, still giving a horizontal space (because of a separate but related bug that causes the div to live below the indented first line) but still allowing FF to render correctly. Man what a pain! Thankfully, I was able to "overcome" this issue by making the background image of the header for the bulleted LI taller and just using a the blank div tag fix... This unfortunately won't work for everyone...


I know there were a couple others I had to deal with, but I am way too tired after spending the last 5 hours trying to make this work...

So you ask yourself why even use these pesky unordered lists if IE is so incompatible? I am asking myself that right now... HA! No, but really, the reasons are two fold. First, it gives the content semantically correct placement on the page, which is important for things like search engines and screen readers. Secondly, it is to create an accordion style menu that can expand and collapse showing additional navigational options.

I keep hoping and praying that one day, Microsoft will figure out how much pain and suffering they have been putting web developers though and start working as a standards compliant browser. There's always hope for IE8... of course that's what everyone was saying about IE7...

IE and another JS blunder...

So I report with great disdain, yet another problem with IE and cross browser compatibility. IE does not (by design) support the .innerHTML property correctly for elements like TABLE, THEAD, TFOOT, TR, and TBODY (even though it's not listed there). They decided for some unknown reason to be different on this topic than EVERY OTHER browser on the market.

Now, I will say, as a matter of practice, I resist the use of innerHTML as much as possible, using the DOM's document.createElement instead. I have, however, run into a case where this is not only impractical, it is not possible due to the very dynamic nature of the project I am working on.

So I built my project using FireFox (as usual) then crossed my fingers and launched it in IE to test compatibility. I was greeted with an ever-so-informative "Unknown runtime error". Even running they handy script debugger didn't give me any more information as to why .innerHTML would cause this sort of thing.

After much searching and much testing, I was forced to just destroy the table and use innerHTML on the parent DIV to recreate it.

What a pane... it's no wonder my boss made the early decision to only support FireFox for the administrative side of our software... too bad we can't do the same with the public side .

Firefox 3 launched today!

I welcome with open arms the arrival of FireFox 3. It's pretty, it's quick, and it successfully passes the Acid2 test!

So far, I have found only minor CSS corrections that need to be made for FF3 to work correctly on my many web sites.

I'll report more on my findings as I have more time to work with the newest version of FireFox.

Upper limits of the query string...

So I ran into a problem recently where information was not correctly being passed from one remote page to another... It took quite a bit of digging to finally find the root of this issue. It turns out, that in addition to having to deal with issues with cross-browser compatibility regarding JavaScript, we also have to deal with it regarding the querystring!

Now I know what you are thinking... who in their right mind passes so much information in the querystring that it would reach the upper limits??? I agree with you, but it is currently out of my hands.

Building "widgets" and "plugins" for commercial sites that expect to be able to "remote authenticate" can be quite tricky... especially if they are built on 4th party CMS's that decided to build their own proprietary server side scripting language (that remotely resembles classic asp)...

Okay, long story short, I am passing variables to the remote authenticator via POST variables... that software is then authenticating the users and moving all of those POST variables to the querystring as GET variables to return the user back to the clients CMS where we then process their data... I know, I know, it's an incredibly complex mess, but until the CMS is able to provide us with methods to read and write cookies, we are stuck with it.

So, it turns out that although this specific case works fine with FireFox and even Safari, it breaks in Internet Explorer (what a surprise =). Because of this I did some testing... and here are the results:

Browser      version        querystring upper limit
FireFox      2.0.0.5        8182
Safari       2.0            8184
IE           7.0            2047