Archive for the ‘Uncategorized’ Category

Two Odd IE Behaviors

Monday, October 12th, 2009

I noticed two odd Internet Explorer (or IE for short) behaviors while I was working on a beta version of a network tools app my boss wanted. I also figured out the workaround.

Dynamically Visible DIVs Don’t Appear

I used a tab-based navigation for the beta version. When you click on a tab (composed of an h2 and an a), the corresponding div would appear, hiding all the others. This was achieved by adding and removing a value in the .className. In IE, though, the tab would work for two tabs, but would only hide tabs after that. The new tab wouldn’t appear.

To make matters worse, if I alerted something in the loop that set or unset the .classNames, it would work. I tried various things like .display="none" while I was modifying things, then setting it back to block when I was done, but none worked.

The solution turns out to be that you need to remove the container element, then reinsert it. For example:

1
2
3
4
var tabcont = document.getElementById('tab-container'),
	pn = tabcont.parentNode,
	ns = tabcont.nextSibling;
pn.insertBefore(pn.removeChild(tabcont), ns);

DOM Created TABLEs Don’t Show Content

I also needed to dynamically create tables. This can be done via straight text with .innerHTML or via the DOM with document.createElement and .appendChild. In some areas, the tables could use thead because the row headers were on top of the table. Other times, the th was in the same tr as the td it matches.

In instances where there was a thead, I also created a tbody. Where there weren’t, I didn’t bother because the browser usually figures that stuff out. IE does not. So, if you’re using the DOM method of creating tables, make sure you explicitly use a tbody.

For the record, I was also using a caption. So, that may have triggered something in IE that wanted an explicit tbody. If your stuff seems to be working fine without the tbody, it may have more to do with caption being present.

A Good Design Doesn’t Just Look Pretty

Thursday, September 20th, 2007

A successful design doesn’t just look pretty. It communicates.

Recently at work, I had to review several websites to determine what category the business falls under. I found only one that clearly stated what the business did. All the others were written under the assumption that the reader knew what the business did. Since I had no idea, this was rather irritating. I came to the conclusion that one of the ugliest sites on my list was the most well designed.

Websites exist to communicate. A website that doesn’t communicate is poorly designed. So, a note to designers, make sure your copy clearly states what the business does on the home page (or something akin to an about us page) so that people that aren’t familiar with the company know what the company does without having to figure it out. Otherwise, people might do what I wanted to: close the site after 10 seconds of not seeing a clear description.