A List Apart

Menu
Issue № 57

Why IE5/Mac Matters

by Published in Browsers, State of the Web, Information Architecture

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!

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

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

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

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?

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

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:

“It’s the difference between a written language based on symbols that depict specific words such as ‘dog’ or ‘man,’ and language based on an alphabet. Twenty-six characters in the word-symbol language convey 26 objects or concepts. Twenty-six characters in the alphabet convey whatever you want to say.”

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

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.

No Comments

  1. Sorry, commenting is closed on this article.