Why IE5/Mac Matters

This week, Microsoft released IE5 Macintosh Edition, the first
shipping web browser to meaningfully support two key standards:
HTML 4, and Cascading Style Sheets (CSS) Level 1. This is good
news whether you use a Mac or not, because the browser not only
empowers webmakers to begin building standards-compliant sites,
it also cures headaches caused by trying to support Mac-based
visitors.

Equally noteworthy is what’s missing from IE5/Mac: meaningful
support for XML and the DOM. On that level, IE5/Mac is just like
IE5 for Windows: not good enough. Then again, no shipping browser
is good enough, because no browser truly supports these
standards, one of which has been languishing for two years.

Executive Summary: IE5/Mac is the best browser ever released on any platform. But key pieces of the standards puzzle are still missing.

In this brief article, we’ll talk about IE5/Mac’s superb handling
of the standards it supports, and the importance of what it leaves out. But first, let’s see how the browser helps users (and designers) by solving long-standing cross-platform problems.

Attention Flashmeisters!#section2

Matt, Jason, Amy, Auriea, Francis, Shirin, listen up: You can now
serve Flash files and other streaming and embedded media to Mac
IE users, because JavaScript plug-in detection now works in
Explorer, just as it has always worked in Netscape Navigator.

As to why it took so long, originally JavaScript was Netscape’s
secret sauce, and Microsoft had to reverse engineer their own
version, Jscript. Not to appear backward, they came up with
ActiveX, and combined it with VBScript to detect the presence or
absence of plug-ins like Flash. Unfortunately, VBScript was for
Windows only, so Mac IE users were treated to endless loops of
malfunction. Visiting a Flash site which used VBScript to
accommodate Explorer would leave Mac users puzzling over
error messages (or send them scrambling back to Netscape
Navigator).

That is now history.

Fontology#section3

When things get slow on web design mailing lists, someone will
inevitably bring up the difference in font sizes between Mac OS
and Windows, and a deluge of solutions will follow.

Guess what? It’s no longer an issue. IE5/Mac’s default setting is
16px type at 96ppi (Windows resolution). Before you scream bloody
murder, Netscape is rumored to be planning on using the same
setting in Gecko. And there’s a simple reason for it: the W3C has
recommended this setting (well, technically, they’ve recommended
90ppi) in order to avoid the cross-platform problems that have
plagued the medium since designers first gained rudimentary
control over web typography.

Here’s the rationale. The web is authored by everyone from
advanced designers and programmers to absolute beginners.
Beginners tend to design according to what works and looks good
on their system. On the Windows platform, with its larger fonts,
8pt type looks good. Since Mac OS was designed to implement
desktop publishing, it delivers a one-to-one correspondence
between points and pixels. Thus, 8pts is the same as 8 pixels.
And 8 pixels is at least one pixel too few to render type
legibly. Since CSS came into use, Mac users have been hitting
pages they could not read, because Windows-based web designers
had specified 8pt type in the style sheet.

By switching to a 96ppi default, IE5 solves this long-standing
problem.

Now, you could argue (and we’d agree) that pts are meaningless on
the screen. You could also argue that the best authoring practice
— and the one the W3C recommends — is to refrain from setting
absolute font sizes on the web, both for reasons of browser and
platform compatibility, and to avoid usability and accessibility
problems. We agree again.

But even the most eloquent
articulations of that argument will not stop inexperienced web
authors from putting 8pt type on the web, thus causing terrible
readability problems for Mac and Linux users, among others. And
it’s not just Johnny at Geocities who commits these follies. It’s
Frankie at Widgets.com, who’s been told to convert all the
company’s Word documents to HTML pages pronto.

IE5/Mac’s default font setting solves that problem. And it is the
only conceivable solution, unless you have a technique for
instantly educating everyone who makes web pages. (We thought
not.)

Mac users: If you hate the 16px default, you can lower it to 14px
or 12px in the Preferences dialogue. We lowered it to 14px
ourselves, for better Truetype scaling and a more comfortable
reading experience based on the resolution of our monitor. You
can even switch back to 72ppi (standard Mac resolution) if you
wish, though by doing so, you’ll be defeating the browser’s
usability enhancements. But if you only visit well-authored
sites, and you prefer 72ppi, go for it. IE5/Mac lets you decide.
(We hope Navigator 6 will, too.)

To those who design content portals and other
type-resolution-dependent sites – sites that won’t work unless
the site renders body type at 10px Geneva and Arial – stop using
platform detection, start using pixels in your global Style
Sheet, and don’t tell the W3C you heard it from us. (Oh, and
expect angry letters from Linux users unless you’re willing
to rethink your design strategy.)

All I Wanna Do is Zoom, Zoom, Zoom#section4

As if the (user-switchable) 96ppi font setting were not solution
enough, IE5/Mac has implemented an ingenious Text Zoom feature
that lets users increase or decrease the size of type on any web
page. Naturally, your web page initially shows up exactly the way
you designed it. But if a viewer can’t read it, she now has the
power to solve that problem with a click of the mouse.

Print-oriented designers, before you start screaming, here is the
rationale: Millions of people are visually impaired, millions
more have eyesight that isn’t what it used to be, and still
others may find that what was readable and attractive on your
monitor is too big or too small for comfortable reading on
theirs. One click of the mouse, and the problem is solved.

After all, the goal of web design is to present content, and what
good is content if your visitors can’t read it?

Note that text zooming scales all web typography, including
content set in points and pixels. If you argue that CSS-1 doesn’t
call for scalability when type is set in points and pixels, we’ll
argue that CSS-2 does, and that the spirit of all web standards
does, because web standards are about accessibility.

We’ll also
point out that IE5’s text zooming does not alter what you’ve
designed; it merely temporarily resizes to accommodate the needs
of your visitors, and they are the most important people on the
web.

In our view, accessibility is not a theory — and users should
never be penalized for our authoring practices, whether we’ve set
type in FONT SIZE tags, keywords, percentages, points, pixels, or
the secret language of plants. We’re glad that the makers of
IE5/Mac agree.

User Style Sheets#section5

User Style Sheets are here. What does this mean?

A User Style Sheet is exactly what it sounds like. A CSS document
created by the user, and applied to every web page they load.

What does this mean to web users? It means they are in control of
the web.

What does it mean to designers? It means we had better design
sites so beautiful and so functional that visitors will not want
to turn on User Style Sheets.

Note that User Style Sheets don’t necessarily kill the style
sheets on the sites we design. For instance, the user can have a
style sheet that simply makes all type larger or smaller. Or that
removes link underlining even when the designer left link
underlining turned on. Or that turns on underlining even though
the designer turned it off.

This is all a little scary for designers, but it’s the way the
web is supposed to work, and conceptually it is no different than
the user’s ability in older browsers to “always use my colors” or
“always use my fonts.”

Is there a DOCTYPE in the house?#section6

All web pages – even this one – are supposed to begin with a
DOCTYPE – a simple tag that tells the browser (or other device)
what type of document it is dealing with. Common DOCTYPES include
HTML 3.2, HTML 4.0 Transitional, HTML 4.0 Strict, and XML.

They’re essential for validating your code, but until now they
have not been particularly useful to most browsers. Open a page
you’ve designed, and change the DOCTYPE from HTML 3.2 to HTML 4.0
strict, for example. Usually, it will make no difference in the
rendering of the page.

In IE5/Mac, finally, it makes all the difference in the world.

In fact, you can use the DOCTYPE to determine whether you want
100% compliance with the standards IE5/Mac supports, or backward
compatibility with a browser like IE5/Windows, which does not
fully support these standards.

Just as Text Zoom puts the user in charge of readability, DOCTYPE
switching puts the web designer in charge of the standards
compliance (or not) of the browser.

For strict, standards-compliant HTML rendering, use

» 
"http://www.w3.org/TR/REC-html40/strict.dtd">

… and be sure to include the w3.org URL, as shown above. This tells the browser that you are serious about your code, and have validated it. For “compatible” mode, use

»
Transitional//EN">

… and leave out the w3.org URL. (The presence of a W3C url tells IE5 to treat the document as “strict,” even if you have marked it up otherwise.)

IE5/Mac renders “Transitional” HTML 4 in “quirky/compatible” mode, which basically means it renders it the way Windows IE5 would render it. Since IE5/Windows Edition is less standards-compliant than IE5/Mac, why would you ever mark up a document this way?

Well, for one thing, you may want your document to look the same across platforms. Or you may be using the JavaScript “NAME” element, which would cause validation errors in a strict HTML 4.0 document. Basically, if you are supporting older browsers, deploying older JavaScript, or using any workarounds, HTML 4 Transitional is the way to go, until enough of your audience is using standards-compliant browsers, and you can clean up your code. Again, be certain to leave out the W3C url, or IE5/Mac will treat your code as Strict.

We suspect that most web designers will initially specify HTML 4
Transitional, to ensure backward compatibility and render their
sites the same way across platforms. We further suspect that when
Netscape releases Navigator 6, if it lives up to its billing and
begins winning converts, web designers will finally start using
the HTML 4.0 STRICT DOCTYPE, and validating their code. It’s all
good.

Missing in Action#section7

Like Explorer for Windows, and like Netscape Navigator 4.x,
IE5/Mac does not support XML 1.0 or the DOM 1 Core.

The Document Object Model (DOM) began its life when Netscape
invented JavaScript. Put simply, the original JavaScript DOM was
like a listing explaining which objects on a web page could be
manipulated through JavaScript. As JavaScript improved and
changed, so did the JavaScript DOM. (One word: Rollovers.)

The web kept evolving, and with that evolution came new and
conflicting DOMs. There was Netscape’s DOM, Microsoft’s DOM, and
five DOMs on Flatbush Avenue. To avoid meltdown, the W3C brought
everyone together, and what emerged was a powerful Document
Object Model incorporating JavaScript/EcmaScript, CSS, and XML.

Sounds great, right?

We don’t have it yet. Not in this browser or any other shipping
browser.

XML is a super markup language that is waiting to turbo charge
the web. Where HTML is a finite set of task-oriented tags
(<h1>

<form>), XML is an environment that lets developers
create their own tags. As Rebecca Rohan usefully observes in the
15 March issue of Software Development Times, comparing HTML to
XML:

XML is powerful, but it is not some wacky new theory or unproven
experiment. As Tim Bray of The Web Standards Project unhappily
notes, XML 1.0 has been stable since 1998. So why are we still
waiting for a browser to support this web standard? Why are web
developers everywhere standing around like poor rural folks
waiting for telephone service? Hell if we know.

IE5/Mac does implement some flavors of XML. XML + CSS seems to
work (but not perfectly). Similarly, the Microsoft flavor has of XSLT has been implemented.

But XML 1.0 is the real deal, and we still don’t have it.

Out on an Up Note#section8

The web still waits for a browser that fully supports key
standards like XML 1.0 and the DOM 1 Core. But we finally have a
browser that supports two crucial standards, and does so with
intelligence, depth, and commitment. That’s reason enough to
celebrate.

The release of IE5/Mac sends a clear signal that the days of duct
tape and workarounds are drawing to a close.

We hope that, having succeeded on the Macintosh platform,
Microsoft will be persuaded to bring the same level of standards
compliance to millions of Windows users. And that they will take
the next step and deliver full support for XML and the DOM.

Meantime, we trust that a widespread adoption of IE5/Mac will
persuade more designers to lose their fear of style sheets and really begin to
exploit the power of web standards.