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.

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.

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.

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.

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!