Just a quick one, as I don’t have a lot of time to post… but of course, as usual, I had to make time for a detour into the madness of Internet Explorer when I discovered that my CSS line-height positioning was breaking when there was an inline image in the text. Why? Who knows? But the solution involved sticking vspace=”7″ into each offending image tag. Yet another case of hacking a one-off solution into the code to work around an Internet Explorer quirk. Almost as frustrating as IE’s violations of standards is the fact that there’s almost never a one-size-fits-all workaround!
Tag Archives: Internet
Forget what I said before; we have a winner!
It’s a given that anything I post here is going to be brain-deflatingly stupid. But this one goes beyond even what I would have expected of Microsoft. Fortunately, thanks to a highly effective Google search, I was able to solve the problem in minutes.
The problem was this: For a site I’m working on, we are manipulating the 404 error feature to allow users to set up customized URLs. If the URL entered doesn’t match a real page, it gets fed into this 404 error script, which looks up the path in a database and redirects the user to their customized page. A bit of a hack, but it’s pretty slick.
As usual, I am developing the site using Firefox as my test browser. But… UH-OH! Surprise! When giving a demo of this feature today using Internet Explorer, we discovered it didn’t work! Internet Explorer was not returning the server’s 404 error page, instead using its own internal version (which we’ve all seen and most generally ignore).
Drat! What to do? Well, as it turns out (thanks to the aforementioned Google search), the problem is quite simple. To quote the unbelievable but, as I verified, 100% accurate description I found on this page:
Internet Explorer has a lightly-documented “feature” that stops it from serving any custom 404 error page that is less than 512 bytes long. Your visitors will instead be sent to IE’s own 404 page, which is generic and suggests they use an MSN search to “look for information on the Internet.” That’s one way to lose visitors! Make sure your custom 404 error page is over this limit — about 10 full lines of text and HTML should be enough.
Yep, that’s it. I did my best Bart Simpson-at-the-blackboard impersonation, filling my 404.html file with a large comment block wherein I repeated (about 130 times, for good measure) the phrase “This block exists solely to force Internet Explorer to load this page.”
Sure enough, it worked. D’oh!
Thinking a bit more about this, I at least think I understand why Microsoft chose to do this. “If the server’s default 404 error page is so short,” I imagine them musing, “then it probably doesn’t offer users much helpful information. And since our wonderful web browser is much more important to our users than the web pages themselves, let’s just butt in and do things our way. (Is there really any other way anyway?)”
This one just may take the cake…
First, a qualification: Since I got a flat-panel display at work, I no longer have my PC connected directly to the display; I view the PC’s video output via Remote Desktop Connection on my Mac. I’ve learned over time that RDC does not provide a direct, unaltered feed of the PC’s video. For understandable reasons (faster screen refresh), but by perhaps unjustifiable methods, RDC re-renders parts of the video display. The result is that you do not see a pixel-perfect (or even simply downsampled) representation of the actual PC video; it appears to be redrawn completely for network transmission.
In particular, this does funky things with Internet Explorer’s output. Last year I spent a few hours trying to figure out why borders around my buttons were extending by one pixel both down and to the right, until I realized that on the actual PC’s display this wasn’t happening… it was just an RDC quirk.
With that out of the way, I have to admit that perhaps my current problem is an issue with RDC and not with Internet Explorer. But either way, it’s a Microsoft problem.
After making some CSS adjustments to a page I was working on, I noticed that the main body seemed to be extending 3 pixels wider than it should be. Further testing revealed this only happened on certain pages, and after resorting to commenting out each CSS class one-by-one, I tracked this down to an inline class that simply italicizes text. So, for whatever reason in the grand Microsoft scheme, a word or two in italics can cause a much larger section of the page (at least 2 or 3 levels up in the document tree) to expand by 3 pixels.
Again I ask… WHY???
And again my cry for explanation goes unheeded. Time for another lame workaround?
Addendum: As it turns out, in this particular case a workaround will not be needed. I went to our test PC and confirmed that this is an RDC glitch, and not an Internet Explorer one.
Microsoft, how do I hate thee? Let me count the ways…
Most people who know me well understand that I am an acknowledged Apple fanboy. But I don’t simply hate Microsoft because I love Apple. There may be more truth to the fact that I love Apple because I hate Microsoft.*
At any rate, it’s clear that I hate Microsoft, and for reasons that are much more concrete, tangible, and, in the context of this article, quantifiable.
As you may know (if you know me, and probably wouldn’t if you don’t, but you do now… get it?), I make my living building websites, which means that I am forced to deal with both Windows and Internet Explorer, like it or not. (Not.) I do my work on Macs, and my day-to-day web browser is Firefox. But everything I do needs to be tested in the Microsoft world, since that’s the context in which 95% of my audience will be viewing my work.
At least once every month or two, I am forced to bring my work to a grinding halt while I attempt to diagnose some obscure Internet Explorer problem I’ve just run into. It is usually some trivial function that I take for granted, but for some mysterious reason simply does not work in Internet Explorer under a particular set of conditions. So I spend a day or so fruitlessly searching Google to find others who’ve experienced the same problem. Eventually I resign myself to the fact that there is no logical explanation for the problem and I will never discover a real solution to it. So, the only alternative is to concoct a hokey workaround that Internet Explorer can accept. These weak victories are always bittersweet: at least I’ve found a way to move on and get back to the real tasks at hand, but my work is forever tainted by Microsoft lameness, without even giving me the satisfaction of a glimmer of understanding as to why I’ve just undergone a day of torture.
Finally, I’ve had enough. I know that as long as I work in this field, I will always have to deal with this problem, but I’m no longer going to silently submit to the whims of mediocre software. I will catalog my woes here for the world to see, so when I finally jump off a bridge with a thousand Windows Vista CD-ROMs tied around my waist, people won’t wonder why.
* For the record, I don’t unequivocally hate everything Microsoft does. I own, and enjoy immensely, an XBOX game console.
The mysterious window.print() problem
It seems an easy task: print the damn window. But no, nothing is ever as easy as it seems with Microsoft. In this particular case, I have a pop-up window which contains a frameset. The frameset consists of a left frame with a tree of page links, and a right frame containing the body of the page linked from the left frame. Within the body of the page in the right frame there are links to allow you to print the frame. So far, so good. But there’s also a special link that opens a new page that contains the full content of all of the pages, so you can basically print the whole lot at once instead of one page at a time.
As expected, all of this works just fine in other browsers, but not in Internet Explorer. It handles the regular single-page window.print() just fine, but when you go to the full page, nothing. No printing, no JavaScript errors, nothing. It’s like it’s just a dead link. With the exact same code as what works on the other pages. And, if you open the page from the frame in a new window by itself, it prints just fine. So, we have some pages printing just fine in the frame, and another page that prints just fine when it’s by itself, but it won’t print if it’s in the same frame that the other pages print fine in, using the same code. You can see why this is driving me insane, can’t you?
Nothing I find anywhere online suggests that this problem exists. So eventually I resort to the only option that’s available… open the troublesome page in its own pop-up (yes, a pop-up opening a pop-up… always a great idea), where window.print() works just fine.
Thanks again, Microsoft!