I recently had to do a lot of Javascript and CSS scripting
for a project. I have some experience with Javascript and CSS and know how to
work around little quirks in Internet Explorer and FireFox. But now I had to do
advanced things (manipulating the DOM-tree, AJAX, layouts that had to be very precise (if one pixel was wrong the
layout was ruined). This was the moment I got really tired of Internet
Explorer. I use FireFox since version 0.3 and really like it for the speed and
tabbed browsing. Internet Explorer was all right, but I preferred FireFox But
now I realized FireFox also did a good job under water. Internet Explorer does
some really strange and unpredictable things.
I don’t hate Microsoft or wrote this article to do some
bashing, they just could have done a better job creating Internet Explorer and
it’s just a warning that testing in FireFox is not enough. With every quirk of
Internet Explorer I will give a workaround or let you know how the avoid the
bug. IE is still used on most of the pc’s and we just can’t ignore the people
using it.
Transparent PNG’s
don’t work (HTML)
When you use PNG’s with transparency in Internet Explorer
they just are opaque. Why? It isn’t like PNG is a brand new format (it’s at
least 11 years old) or that it’s a bad format (PNG offers better compression
and more features than GIF, the other lossless format. It is very annoying
because with the recent AJAX-hype we want moving stuff on our page with transparency
(and preferably 24-bit with transparency). And even without AJAX it’s nice to have 24-bit transparency.
The left image is a 24-bit PNG and on the right is a 8-bit
PNG. At first sight the left image looks ok in IE. But it’s totally wrong, what
was meant are the images in FireFox. A black to transparent gradient.
What we can do now are two things:
Write an angry letter to Bill Gates and tell him we start
using Linux if he doesn’t fix this bug. This probably isn’t such a good idea, I
would go for the solution of Erik Arvidsson
It even works with 24-bit PNG’s and FireFox doesn’t complain
much about it (a minor CSS error)
Substr with negative
arguments are not possible (Javascript)
Use x.substr(begin, end) to get a piece of a String (where x
is a String). The specification says we can use negative numbers which is very
handy. In Java an Exception would be thrown and we had to make a workaround to
get the last piece of a String.
“testAmisâ€.substr(-4) will print Amis, that’s just great!
But wait, when we do this in Internet Explore testAmis is
showed and no error. That’s strange.
Now we still have to use the Java-solution to fix this
problem: “testAmis”.substr(“testAmis”.length-4)
It isn’t that much work, but I was so happy I could use
negative numbers and actually found something in Javascript that’s better than
in Java.
Attribute
class!=class (DOM)
When I want to change the CSS style of a DOM-element I just
have to change the class attribute, right? Not right, Internet Explorer just
doesn’t care (much).
Let’s take a look at this HTML page:
<html>
<head>
<style
type=”text/css”>
.s1{ color:red;
}
.s2{
color:#FFCC00; }
</style>
<title></title>
</head>
<body>
<div id=”p1″>
<div
id=”c1″ class=”s1″>text of part c1</div>
<div
id=”c2″>text of part c2</div>
<div
id=”c3″>text of part c3</div>
</div>
<script
type=”text/javascript”>
var c1=document.getElementById(“c1”);
var c2=document.getElementById(“c2”);
c1.setAttribute(“class”,”s2″);
c2.setAttribute(“class”,”s2″);
</script>
</body>
</html>
It sets the attribute class of the nodes with id c1 and c2
to s2. Well in FireFox it works as expected but in IE nothing happens. But it
gets even better. Let’s take a look at the DOM tree in IE:
The attribute is set! But it doesn’t work, isn’t that great?
I could’ve lived with it that you can’t set the class attribute because it’s a
special kind of attribute. But don’t show the attribute and give me an error.
The first node is even worse:
The class attribute is set twice! Oh wait, maybe we have to
remove the class attribute:
c1.removeAttribute(“class”);
In FireFox the attribute is removed, but in Internet
Explorer nothing happens. The DOM tree just has 2 class attributes. That’s
crazy and too unpredictable.
The solution is simple and works in FireFox too:
c1.className=”s2″;
Maybe the specification says we can’t set the attribute
class because it’s a bit special. But don’t pretend it works a bit. Give me an
error or do nothing, don’t make up stuff!
Float:left; is almost
left (CSS)
I had to create a pixel precise layout. A black panel with 3
columns in it. The width of each column is 100 pixels. I want a small border of
1 pixel, so the width of the black panel should be 304 pixels.
The CSS:
.canvas
{
background-color: #000000;
width: 304px;
height: 202px;
}
.frame
{
background-color: #EEEEEE;
width: 100px;
height: 200px;
float: left;
margin-left: 1px;
margin-top: 1px;
}
The HTML:
<div
id=“canvas” class=“canvas”>
<div
id=“c1” class=“frame”>c1</div>
<div
id=“c2” class=“frame”>c2</div>
<div
id=“c3” class=“frame”>c3</div>
</div>
On the left is IE and the right side is FF (image is scaled
300%). Float: left in FF is what we expect, but in IE there are 2 black pixels.
It just makes no sense because at the top is only 1 black pixel and between the
columns also is only one black pixel.
I haven’t found a solution for this problem. You could place
all the div’s with absolute values, but that ruins the whole idea of CSS.
Internet Explorer
reloads images but caches Ajax
requests.
When you change the DOM-tree and add an image (just an
ordinary <img> tag) Internet Explorer reloads the image and doesn’t
search for the image in his cache. This means that when you have a tree with
folder icons every folder icon is reloaded! The server will return an 304
status code (which means the image hasn’t changed since the last request and
you could reuse your old one), but that doesn’t matter because the round trip
to the server is the most expensive with small images.
This alone wouldn’t have made it as a topic in this article because
there are situations when this behaviour is required (a real time stock
exchange graph for example). But now comes the big flaw: Ajax requests are cached! Why?! Caching
images and don’t cache Ajax
requests is far more logical. For the caching of Ajax requests is a simple solution, just set
these headers in your response:
response.setHeader(“Cache-Control”,
“no-cache”);
response.setHeader(“Pragma”,
“no-cache”);
There are people that claim that this doesn’t help. I think
it does, but maybe some versions of IE don’t care (I haven’t come across them
and didn’t have any complaints of customers about it). Then the solution is
adding an extra request parameter with a timestamp in it (this is also the
solution when you can’t change your request)
Event handling in IE
is different (Javascript)
I called the title of this paragraph different because
FireFox might me wrong. But FireFox uses the W3C recommendation and I
personally think that is the standard and the W3C way works a lot nicer.
The FireFox way:
o.addEventListener(‘click’, callback,
false);
The callback method has the signature methodname(e) where e
is an event object with which you can do a lot of nice things.
And now we want to add an event in Internet Explorer:
o.attachEvent(‘onclick’,callback);
The callback method has no parameters, if you want the nice
things of the event you have to get it from window.event, this is a global
object.
Scott Andrew wrote an article about event handling and shows
us a method to hide the problems.
Conclusion
These strange things are just thing I came across in one
week. I already knew about some but didn’t encounter them myself. I hope
Internet Explorer 7 is a lot better.
I have found only one strange thing in FireFox yet. When you walk down the DOM-tree you will find
#text nodes between all the elements when you used spaces or newlines.
Technically it is correct, but very inconvenient. Internet Explorer works
better on this topic.
In this article the author found a bug. The browser locks up with a synchronous
XmlHttpRequest. I don’t agree with that because synchronous means you have to
wait for the answer, that’s the whole idea of it. The article also mentions
some other bugs in Internet Explorer which might come in handy when you start
developing serious Javascript/Ajax pages.
The performance of Javascript and DOM manipulation is also a
noticably worse than FireFox. I didn’t do any testing yet, but someone wrote an
article about it.
The point I wanted to make with this article is that testing
in one browser is not enough. Unfortunately FireBug (http://getfirebug.com)
only works in FireFox and this is the browser with the fewest problems,
otherwise you could have developed your page in IE and test it in FireFox to be
sure it works. Now you have to develop in FireFox and if it doesn’t work in IE
you still have to do a lot of work.
Sources
http://www.libpng.org/pub/png/#history
http://www.quirksmode.org/js/strings.html#substr
http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Registration-interfaces
http://www.scottandrew.com/weblog/articles/cbs-events
http://www.sourcelabs.com/blogs/ajb/2006/04/rocky_shoals_of_ajax_developme.html
http://www.pannonrex.com/blog/?p=25
![Rounding numbers given in string representation while controlling their number of significant digits]({"aperture":"0","credit":"","camera":"","caption":"","created_timestamp":"0","copyright":"http:\/\/seattletimes.nwsource.com\/ABPub\/2012\/08\/02\/2018836700.jpg","focal_length":"0","iso":"0","shutter_speed":"0","title":"","orientation":"0"} "Rounding numbers given in string representation while controlling their number of significant digits")
The float problem can be fixed by inserting:
display: inline;
into the div.
Great article, nice job..
Nice article. Hopefully this will convince more webdevelopers to do some proper multi-browser testing. I took this opportunity to test some of the quircks in IE7 (beta 2). Of course there is good as well as bad news. To summarize:
The good:
1) 24-bit transparent PNGs work as expected (at last, I might add)
2) The css float bug is gone, as well as some of the other well known bugs
The bad:
1) IE7 handles the ‘class’ attribute in the same odd way as did IE6.
2) CSS2 implementation still lacks considerably, i.e. no focus:
3) Don’t even think off CSS3 attributies like, border-radius, background-origin, opacity etc.
To quote Jeroen:
“I hope Internet Explorer 7 is a lot better. ”
Well, I’m afraid it isn’t, although I really like the Developer Toolbar!
Jeroen,
This is a great post! Trying to find differences between Firefox and IE not always is very easy. So having a summary of these differences will save us a lot of time. Thanks!
Wouter