Apperachix? Ok, I'm calling you on that one, McCain. Somebody get out the scrabble dictionary. 1 hr ago

First off: I would never be building a page without a doctype unless I had no other choice. Let’s get that clear. In all honesty, I don’t think I’ve ever had to suffer through Internet Explorer’s quirks mode because I’ve always built my sites using HTML 4.01 or XHTML 1.0 (both strict).

I’ve been working on building the new header and footer for one of our larger properties at work, and it just so happens that this site launched on a flavor of Vignette that wasn’t conducive to a doctype. So here we are years down the road, trying to update pieces of it without breaking others. A little investigation would probably allow you to narrow it down to 2 or 3 properties, but I’m not going to name names.

For those who aren’t familiar with web development, if you lack or have an incomplete doctype declared at the top of your page, you will trigger quirks mode as opposed to standards mode. This little omission causes stuff to go crazy. No, really. Even after pulling in the YUI CSS reset, I’m encountering an amazing bug in IE 6 and 7. It is as follows:

I have a form. Inside that form, I have an input. That input has a background: url(images/input-bg.png) no-repeat left top;. Note that I intentionally didn’t declare the attachment. Also note that this input has a fixed width in hard pixels. And it is within another container with a fixed width, only big enough for the input, a button, and a span of descriptive text.

normal input field

Normally (as it does it Safari and Firefox), when you insert more text than the width of the input field, your text begins to scroll, but the background image stays put, creating the illusion that you are typing “inside” of the image container.

input field with text

It is a swell effect. Except that in quirks mode, the entire background-image begins to slide off to the left and slides behind the fixed width container it lives within. And yes, right top causes it to slide off in the opposite direction.

input background-image sliding away

Eli, you are an idiot. Why didn’t you set the attachment? Funny you should ask. Turns out, if you set it to fixed, the ENTIRE background disappears in IE7.

background-attachment:fixed

Oddly enough, this fixes it in IE6, but that only serves to aggravate me further. I’ve tried triggering hasLayout with zoom:1, and just about every other trick I could think of.

Sam, who had his first day at the office today, pointed me to a comment on Zeldman’s blog where someone else was having the same problem, although nobody proposed a solution.

I’m about 2 *hacks away from making IE7 just show the form elements in their default state and calling it a day, except that now my curiousity has really been piqued and I want to say that I squashed this bug once and for all. So now I turn to you, fellow web peoples. Have you seen or heard of this before? Know of a fix? I’m dying to close this case.

Bonus: Meet Sam!

2 Responses to “When IE7 really sucks: No doctype”

  1. Hi Eli,

    This is what I used for IE7 on the client’s site:

    background: url(../images/layout/input-search-bg.gif) no-repeat 100% 100%;

    This makes the background correctly aligned every second character stroke, see it in action on the search box here: http://www.ibahealth.com/

    I don’t think I’ve bothered with non-repeating background images on form elements since that experience!

    Best of luck with it, let me know if you find a fix!

  2. Hey Jason! Thanks greatly for that comment. I’m testing it out right now. every 2nd character, while not perfect, is a big improvement over whats currently happening.

    Here’s to hoping I can get to the bottom of this!

Leave a Reply