IE 5 for the Mac has very good standards support. Sure, it has some bugs, some of them quite odd. In many cases, though, it’s IE 5/Mac that’s correct and your assumptions that are wrong. This page documents some of these instances. I would like to thank all the readers that have written in with what they thought were bugs, but really weren’t. I would like to specifically not thank all the twits that have linked MacEdition’s Bug Guide as “evidence” that IE 5/Mac sucks in some unspecified way, usually nothing to do with CSS.
IE 5.x for the Mac introduced a useful method of dealing with old tag-soup incorrect Web pages. Pages are rendered in “standards” mode if certain DOCTYPE declarations are present, and in “quirks” mode if short-form DOCTYPES or no DOCTYPE is present. Quirks mode emulates many of the box model errors of IE5 for Windows. This DOCTYPE-switching involves some simple assumptions about the DOCTYPE declarations used by authors who support web standards versus those who do not, and the practice has since been adopted in IE6/Windows and Mozilla-based browsers. What this means is that if you author a page without a DOCTYPE, or with a DOCTYPE that triggers quirks mode, IE might render the page in ways that don’t strictly conform to the spec. Similarly, if you do use a full HTML 4.01 DOCTYPE or author in XHTML, you will trigger strict mode, which might involve renderings that you aren’t used to but are correct according to the spec. Neither of these behaviours is a bug, but you do need to pick the DOCTYPE that’s right for you.
According to the CSS specification:
The case-sensitivity of document language element names in selectors depends on the document language. For example, in HTML, element names are case-insensitive, but in XML they are case-sensitive.
XHTML, being an application of XML, is case-sensitive — the
element names should be in lowercase. So if you write your CSS
stylesheet with uppercase selectors like BODY and DIV,
they won’t match the elements in your XHTML document. Simple when you
think it through, but it’s easy to get caught out. Don’t blame the
browser for this one.
Maybe this isn’t obvious from the HTML specification, but when it says:
Coordinates are relative to the top, left corner of the object.
it means that it makes no sense to have negative coordinates off the
edge of the object. They are relative to the top left corner, not to the
most recently defined coordinate point. Image map coordinates are
lengths, which according to
the specification can be (positive) percentages, or (positive)
pixels. The
HTML DTD shows
that these must also be integers — no half-a-pixel or fractions of a
percentage. However, many browsers, including IE/Windows, treat negative
coordinates in image map definitions as relative to the previous
coordinate. This is incorrect according to the spec, but causes people
to be caught out by IE 5/Mac’s stricter interpretation.
If you’re used to thinking about “DHTML” instead of CSS and standards,
then you might be a bit disappointed that IE 5/Mac doesn’t support your
favorite JavaScript methods like documentElement.clientWidth
and window.innerWidth. This is as it should be: innerWidth
is a proprietary Netscape method, while clientWidth is a
proprietary IE/Windows method. Failure to support proprietary
JavaScript, or proprietary CSS properties like IE filters and
properties starting with -moz, is not a bug.
It would be unfair to single out people who have notified these
things to me, thinking they were bugs when they weren’t. Nonetheless I
thank them for the contributions. Even though these things aren’t bugs,
they are common traps for Web authors, and their contributions help make
this page a useful resource.