Tag: ie
Today's Painful DOCTYPE Lessons
Just some painful web lessons I thought I'd share for similarly-beleaguered web developers who are wondering if their browsers (or their clients' browsers) are possessed of evil spirits.
IE Does Font Sizing Right
I know I put down IE a lot on my site. As a web developer, it has made my life a living hell for the last 4 years. Some people prefer to point the finger at Firefox for starting all these compatibility issues, but for the most part it is IE that deviates from CSS specifications (and sometimes ECMAScript specs too!).
However there is one issue where Firefox is wrong. Dead wrong. So painfully wrong that I have been complaining about it for years. See, Firefox ignores CSS spec on pixel font sizes. Its reasoning is that people have misused pixel font sizes all over the web and wouldn't it be nice if old granny's could read those pages anyway? But this kind of thinking is what put IE in the mess that it's in now. You can't just ignore spec because people made their pages wrong. They are WRONG.
The reason why pixel fonts are and should be absolute is because there are times when you really need text to be absolute. When it's aligning with an image, or needs to fit inside a box. Scaling it so the user can read it may make them happier, but it makes my page look really ugly and can break a lot of other elements depending on that one to stay in its own damn area. When we say we want a box to be 300 pixels wide, you don't go scaling that, now do you, Firefox? If we wanted it scaled, we would have used "em" or percent. Don't make us use a text graphic just to force the size!
And apparently this will now be causing grief to more developers thanks to the new all-in-one advertising tool from google's adsense: http://groups.google.com/
You might say that google could make their banners scalable to overcome this, but banners have traditionally been of a fixed size and few websites can accommodate scaling sizes. The fact is, we as designers should be able to say that we want our text in some circumstances to be *just the right size*. And I am pissed off that Firefox won't let me do it. And Safari. Opera, thank god you decided to just add Zoom and skip the whole font-sizing thing. You are awesome. :)
However there is one issue where Firefox is wrong. Dead wrong. So painfully wrong that I have been complaining about it for years. See, Firefox ignores CSS spec on pixel font sizes. Its reasoning is that people have misused pixel font sizes all over the web and wouldn't it be nice if old granny's could read those pages anyway? But this kind of thinking is what put IE in the mess that it's in now. You can't just ignore spec because people made their pages wrong. They are WRONG.
The reason why pixel fonts are and should be absolute is because there are times when you really need text to be absolute. When it's aligning with an image, or needs to fit inside a box. Scaling it so the user can read it may make them happier, but it makes my page look really ugly and can break a lot of other elements depending on that one to stay in its own damn area. When we say we want a box to be 300 pixels wide, you don't go scaling that, now do you, Firefox? If we wanted it scaled, we would have used "em" or percent. Don't make us use a text graphic just to force the size!
And apparently this will now be causing grief to more developers thanks to the new all-in-one advertising tool from google's adsense: http://groups.google.com/
You might say that google could make their banners scalable to overcome this, but banners have traditionally been of a fixed size and few websites can accommodate scaling sizes. The fact is, we as designers should be able to say that we want our text in some circumstances to be *just the right size*. And I am pissed off that Firefox won't let me do it. And Safari. Opera, thank god you decided to just add Zoom and skip the whole font-sizing thing. You are awesome. :)
IE Display:Block Link Interference Error
Issue: In IE, when using links with display:block overtop of images, the block setting disappears and only the link text is clickable.
There are a few CSS tricks running around these days to replace the old image maps (which are a big pain in the ass to write). My personal favorite is to write a text link, then hide the text, size it, and place it over the image-to-be-mapped. Then the html makes complete sense and you always know which link is which. And people without css can still navigate. Excellent all around.
I created the following ultra-simplified example of my image-map substitute below. The blue-bordered area is a relatively-positioned wrapper div. The image inside is absolutely-positioned, and the red-bordered link is relatively positioned on top. You could reverse this: I didn't see a difference in the results. The link is set to be a block (not inline) so it will fill the dimensions specified. A span surrounds the text inside the link and that span is set display:none.
Sample #1: (initial attempt)
This works in all browsers but IE, where the image covers up the link. At first I thought this was a z-index issue (which IE has some well-documented issues with). But after exploring that for several hours, I found that this was not the case. When I set the background color of the link, it shows above the image (proving it is above the image in z-index).
Sample #2: (with background color)I thought this might be one of those IE things where you can fix the element by setting width or display:inline-block. But not the case. Nothing helped but background-color. Then I let the text become visible again to see what would happen. This is really entertaining.
Sample #3: (showing text)If you hover (in IE) over the text, it becomes immediately apparent that the block status of the link is being ignored - you can only click on the text area of the link. But this is only true in the area where the lower-level image is visible. So basically, IE will only see visible stuff inside the link (background-color or link text) and ignores the link block otherwise. Joy. So it was a quick matter to find an invisible element that IE sees as visible in order to overcome this problem: a blank gif! It doesn't matter if you use it as a background image or an inline-element set to the right size: IE sees this as a link object and shows the link. Yay!
Fix #4: (fixed - with blank background image in CSS) Fix #5: (fixed, with inline blank image)
If you would like to see these 5 simplified examples with no other interfering html see the IE Display Block Link Test Page.
IE DOM Cloning
One of my major gripes with IE has always been with the way it passive-aggressively recodes the html on every page it loads. Just take a look at view source. That's not my code. My code is pretty and lower-case with proper xhtml quotes on all attribute values.
IE does this so it can create the DOM tree (other browsers create the DOM tree just fine without mucking up code, but I guess this argument has never really been a motivator over at MS headquarters). And this is probably also why IE has so many problems with its DOM.
For instance, I've had lots of fun trying to change the select element's name through DOM in IE. Why would I want to do this, you ask? Well, I created a generic filepath dropdown on the server which I wanted to clone and insert into various parts of the form via DOM and rename "oldpath" and "newpath" and such. If I do it this way, it sort of works:
var x=document.getElementById("x"); //x is a select list with name and id "x"
var x2=x.cloneNode(true);
x2.id=x2.name="x2";
document.forms[0].appendChild(x2);
In this case, the innerHTML is wrong (the name remains "x") - and it remains wrong throughtout the life of the page and from every element's innerHTML in the page - but IE still sends the correct name in the form. And if you ever edit the page using innerHTML, it breaks (sends the incorrect name in the form).
document.forms[0].innerHTML+="New list:"+x2.outerHTML; //this does not work
So, you say, never use innerHTML in IE? It's not so easy. Some values can only be retrieved correctly from the innerHTML text. Try accessing href and src using getAttribute() and you will get a mucked-up absolute pathname. You have to parse it out of innerHTML to get the correct pathname.
And when you clone a select list, IE resets its selectedIndex to 0. Even the innerHTML is wrong here. You
have to manually reset the selectedIndex of the cloned list using the
selectedIndex of the original list using DOM. I have a sneaky suspicion that IE thinks this is desired behavior.
If this doesn't make your DOM life miserable enough, IE has several distressing DOM memory issues:
Understanding and Exploring Internet Explorer Leak Patterns
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp)
Note that they never express any of these leaks as bugs. They are exactly the way things should be, and every JavaScript developer out there should be doing their aggressive DOM garbage collection or it's their own damn fault.
Yup, I love that browser.
IE DOCTYPE Strikes Again
OK, I understand IE's whole DOCTYPE quirks vs. standards (or strict) CSS variations (I don't agree, but I understand). But when did they decide to change their javascript as well (without backwards compatibility)?
http://aranea.zuavra.net/index.php/5 and http://www.quirksmode.org/js/doctypes.html
Basically, when you switch to standards mode, some of the IE proprietary javascript properties move from document.body to document.documentElement. document.body.scrollTop is now always 0 on a standards-compliant page, and the value can be found in document.documentElement.scrollTop instead.
Really, would it have been so hard to leave the document.body.scrollTop value? I know that the IE freaks love to tell us we should develop a million separate CSS files for each damn browser version they throw at us, but having to develop separate javascript as well is enough to make me want to jump up and down and scream violent profanities at my monitor.
IE Submit() AutoComplete
Another subtle IE problem - when using javascript to invoke the submit() method of a form, AutoComplete form data is lost. But thank goodness there is a decent fix for this one, provided we pull some CSS and DOM tricks out of our hat.Fixed Example
IE DOM Lost Form Cache
Another nitpicky issue I have with IE. Whenever you use DOM to manipulate form fields, IE loses the form field's cache value. So if you play with DOM and have users with back buttons, prepare for grief.
Update 04/02/2006: I found a similar problem in Firefox. It is triggered by a more complex example involving tables and new form fields.
IE High Contrast Relative Font Size Conflict
Yup, another fine IE bug. We were getting rare and unreproducible large (HUGE!) font size complaints from users on a new page (all the old pages were just fine) and only in IE. Customer Service - with the help of one clever user - finally tracked down the issue to the Windows XP Accessibility feature called "High Contrast." In my futile attempts to make the new page compatible with this Windows feature, I trailed the feature's failure down to nested relative font sizes. This is a fun one to reproduce on your own computer. Imagine all the lovely places it will occur on your own supposedly perfect web pages!
IE Scrollbar/DOCTYPE Conflict
I found this one at work. The focus of an element disappears when clicking the scrollbar - but only in xhtml compliant pages! This irritated an amazingly huge number of people. Yet another instance of IE punishing me for trying to be standards-compliant.
![[bluehost]](http://mleiv.com/wp-content/files/site_images/bluehost.gif)
