disassociated.com Flickr photos

deadset

Posted by John Lampard on Friday, 3 February, 2006 to the design and art subset

Web designers will be more than familiar with a number of Internet Explorer’s rendering bugs. Need I mention the three pixel jog, or the double margin float bug? Not all bugs, or “quirks” are CSS related though, and while designing the latest version of disassociated I stumbled upon a problem IE6 has rendering straight out XHTML.

Now in the old days (dare I say it; from the time IE6 dates), if a browser encountered mark-up, or a tag, it did not understand, it would usually ignore it. It was a very simple principle really.

We could use blink or marquee tags to our heart’s content, (though I would not actually recommend doing so) safe in the knowledge that if a browser saw such tags, and had no idea how to render them, it would do nothing.

Ideal behaviour and what designers had come to expect of any self respecting browser.

In the top right hand corner of each page on the disassociated site, there is a search box. It is a feature I introduced through out the site, with the redesign. Previously it only appeared on the home page. Hopefully it is of convenience to anyone who has a hankering to search the site at any given moment. Just type in a search term, anywhere, anytime, and away you go.

Another change incorporated during the redesign was to adopt the strict version of the XHTML 1.0 specification for the mark-up. Now that presentation and structure have been completely separated, thanks to CSS, there is no need to continue using the transitional version of the spec. Truth be told there’s been no real requirement to use it here for sometime, so transitional was overdue for the ditching.

And it’s not as if moving from transitional to strict is particularly difficult either. Not a whole lot of extra, or even tricky, coding changes are required to go strict. And needless to say everything went fine. The site displayed exactly as I hoped it would it in all the latest versions of Firefox, Opera, and Netscape. To boot my XHTML also validated perfectly.

It wasn’t until I tested disassociated in IE that a problem became apparent. The search box was breaking out of its container div, as if it were too wide for it. Odd, since it was fine in every other browser. Here is the XHTML for the search box:

<h2>Search</h2>
<form method="get" action="http://search.atomz.com/search/">
<fieldset class="set">
<input class="input-box" size="19" name="sp-q" />
<input class="btn" type="submit" value="Find" />
<input type="hidden" name="sp-a" value="sp1002ae18" />
<input type="hidden" name="sp-p" value="all" />
<input type="hidden" name="sp-f" value="ISO-8859-1" />
</fieldset>
</form>

I double checked all width settings for the divs, but everything tied in. Yet IE seemed to be rendering the width of the search box based on the overall width of the whole site, that is 750 pixels. It was some bizarre parent/child ascendancy was taking place.

Strange. I checked the old version of disassociated in IE, and it was fine. This was getting stranger by the minute. So I started tinkering with the search box code. The only difference in search box code between the old and new versions was the use of the fieldset element. Its use is essential for the code validate to XHTML 1.0 strict spec.

Ah ha.

I removed them, and suddenly all was fine with IE. This didn’t really solve the problem though. Without the fieldset tags, the site wouldn’t validate, but by keeping them, they totally break the layout in IE. So I started digging around to see if anyone had encountered this… situation before. I could only find two others who had, but the solution was simple enough.

Even if it was effectively a code extraneous work-around of a hack. Cheers, IE.

All that is required is to create some “pseudo” divs within the form code which makes up the search box code. They need exist in code only and do not require any styling to work. Here’s what I did, with the “amended” code bolded for emphasis:

<h2>Search</h2>
<form method="get" action="http://search.atomz.com/search/">
<fieldset class="set">
<!-- thisisnotadiv required to "hack" IE’s fieldset bug -->
<div class="thisisnotadiv">
<input class="input-box" size="19" name="sp-q" />
<input class="btn" type="submit" value="Find" />
<input type="hidden" name="sp-a" value="sp1002ae18" />
<input type="hidden" name="sp-p" value="all" />
<input type="hidden" name="sp-f" value="ISO-8859-1" />
</div>
</fieldset>
</form>

Apparently IE simply cannot comprehend fieldset tags and completely trips up when it runs into them. So much for ignoring alien, or unknown, tags?

Permalink | Contact | disassociated.com

Comments are welcome, please keep them relevant to the topic at hand. If you want to talk about something else, please contact me. Spam, SEO keyword "names", and crassness will not be tolerated.