IE666: The Browser of the Beast
Comments: 9
I spent the afternoon huddled in a café drinking terrible coffee (hey, it was highly caffeinated and the refills were free) hunched over my PowerBook and a copy of The Salmon Book trying to figure out where I went wrong with the CSS here that IE6 is having so much trouble displaying pages.
My biggest mistake was thinking I could get away with a low-tolerance layout, i.e., one that requires browsers to know simple arithmetic. But no… a bunch of numbers that sum to 420 anywhere else in the world seem to add up to 427 in Redmond, Washington.
IE6 users (if there are any of you left reading this), you will get your 7 pixels. But not until I know exactly what the hell is going on, and that’s not going to happen at 1:30 in the morning.
More soon. Sleep tight.
•••
Posted to Computers • 2002.11.05 (Tue) • 01:38
Comments
Posted by josh 2002.11.05, 02:13
Don’t want to insult your intelligence if you have already been workinng on this, but are you sure it isn’t the IE box model problem?
http://www.tantek.com/CSS/Examples/boxmodelhack.html
Have you tried using different doc types to make IE switch between standards and quirks mode?
Good luck.
Posted by Mike 2002.11.05, 15:39
Woo hoo you seem to have fixed the problem. Don’t you just love IE? I know I do…sheesh why can’t people just start using Mozilla?
Posted by marko 2002.11.05, 16:57
IE does not adhere to CSS as many think it does- it is crap like this that makes us think that MS should be penalized. it’s probably an easy fix on Frontpage…the trappings of greed seeth
Posted by sebastian 2002.11.05, 17:11
now it looks pretty good in IE6. let me just say, that i like the new layout. great job.
Posted by jh 2002.11.05, 18:01
Josh, Mike —
I did a lot of reading about the box-model hack (BMH for short) and did plan to try to incorporate it. But something about the combination of the words “CSS” and “hack” made me really reluctant to go down that road (this page, by the way, has a good explanation of the hack along with a simplified version).
The DTD I’m using switches on ‘standards’ mode for IE, and almost everything I read about the BMH related to IE5 — not 6, which is supposed to be much less quirky.
As it turns out, it may be much less quirky than I suspected. The solution to the problem suggests (to me at least, in my addled state) that IE6 may actually be the only browser I’ve tested that conforms to the CSS spec when it comes to the collapsing-margins rule. I know this sounds far-fetched, but I’m aware of what I’m saying. I certainly can’t offer proof until I’ve tested this properly and I simply haven’t had time (and won’t for a couple of days). But from what I’ve seen in the last 24 hours, the most promising hypothesis points to incorrectly implemented collapse-margins rule handling in all the other browsers I’ve tested.
I may be delusional at this point, let’s not forget.
To sum up the situation: Buried in a corner of the style sheet that I’d reserved for MT-derived styles was a line of legacy-styling from the previous version of the site that added a certain number of pixels to the width of the main column. How many pixels? Seven, of course. I wasn’t looking in that part of the style sheet, being too hung up on the idea that the problem originated elsewhere (i.e., the main column layout styles). This morning I did a line-by-line check and there it was. I smacked myself on the forehead many times, so there’s no need to beat up on me again, it’s all been taken care of.
The right-hand margin of the main column is determined elsewhere in the style sheet (at least I thought so) and it’s 30px. This is the margin I was seeing everywhere except IE (PC).
Now the collapse-margins rule is supposed to apply only to the vertical margins of (vertically) adjacent block-level elements (the smaller of the margins is ignored in favour of the larger). Horizontal margins are not collapsed. At the moment, without proper testing, the only way I can account for not having spotted my error sooner (and yes, ultimately this all my fault and I will eat crow on the main page when I can confirm all of this) is that Mozilla, Chimera, IE (Mac) and Opera collapse horizontal margins when they should not. The problematic 7 pixels were therefore hidden from me (but I’m not making excuses when I say this). IE seems to have correctly added the bogus 7 pixels to the intended 30 pixels specified elsewhere.
Keeping in mind that none of this is proven yet, what are the lessons I have to relearn?
Assumptions are generally bad and preconceptions will probably fuck you up. (The baddest assumption I made was in thinking the bug was in the column layout code because that’s where the problem was manifesting. The baddest preconception was that IE on the PC is so buggy that it must be to blame by reacting inappropriately to something I’d done.)
Beware legacy code. When making a new version, start with a clean slate and be careful with what you bring over from previous versions.
Beware the logical fallacy of consensus gentium (I think it’s called). In other words, just because everyone’s doing something, doesn’t mean it’s correct.
Posted by jh 2002.11.05, 18:10
Marko, Sebastian —
You both posted comments while I was writing my mea culpa explanation.
Marko, I’d generally agree with you, and if my hpothesis is corrcet, no one is going to be more stunned than me.
Sebastian, thanks for the kind words. I’m just so glad you can finally see it properly! Apologies for the delay.
Posted by Ryan Carter 2002.11.05, 19:55
Ahh… seems to be fixed… and just when you were getting ready to haul out the chainsaw…
Posted by nick 2002.11.06, 06:29
sure, IE might get that margin collapsing thing right, but as far as i’m concerned it doesn’t make up for the lack of a nice dotted border, which we both seem to love so dearly.
Posted by nick 2002.11.06, 06:31
sure, IE might get that margin collapsing thing right, but as far as i’m concerned it doesn’t make up for the lack of a nice dotted border, which we both seem to love so dearly.
Post a comment:
Send This Story to an Enemy
• • •
