Friday, September 17, 20040 Comments
Sometimes it's the simplest things. When converting a list into a nice-looking menu (like on my homepage), IE has a really annoying but when there isn't any width specified to the <li>: it doesn't ignore whitespace! So if your source looks like this:
When rendered into boxes, with say just a little simple CSS like:
border: 1px #CCCCCC solid;
You'll end up with nice bordered boxes, with a big old line in between each. The problem? There is whitespace between consecutive <li> items. I've read several CSS hacks to work around this, but I abhor CSS hacks, because they're so fragile, depending mostly on bugs to fool browsers into behaving. I've discovered that simply removing the whitespace between closing and beginning <li> tags takes care of the problem. This can make things unreadable when building big lists, but there can be whitespace (i.e. newlines) anywhere within a list item. So, you format your source data like this, and all is well with IE:
I didn't fool around with what difference it makes with whitespace between <li> and <ul> tags, but that doesn't matter too much. This way, you get readable lines in code, and nicely displayed boxes in IE.
Server.URLEncode and Spaces
While I'm talking about annoying bugs I've had to deal with forever, how about ASP's URLEncode? I've been working on making a site cross-browser compatible. One of the main features of this site is the ability of users to upload files and share them with other project team members. It's really simple, just a Windows share. The problem is that several characters allowed in Windows aren't valid URL characters, like ? #, spaces, and lots more.
So, sure, just URLEncode it, and it works! Nope. URLs to web pages would work, but not for links to files. Turns out URLEncode replaces spaces with a + character, which is fine for a web pages URL, but not a file, either in IE or other browsers. So, URLEncoding, and then replacing all + characters with %20 works like a charm! All the links work. IE didn't mind the non-URL encoded string too much, but Gecko-based browsers couldn't (rightly so) take it. Now I'm home free!