20 January 2003 :::
“I refuse to accept the view that mankind is so tragically bound to the starless midnight of racism and war that the bright daybreak of peace and brotherhood can never become a reality.... I believe that unarmed truth and unconditional love will have the final word.” — ML King :::
17–18 January 2003 :::
[weekend edition]
Shipping news
Shipped three book chapters and the design and templates for a client website this week. Did it by not doing anything else. No time for Mr Phone or Ms Razor. No time for laundry or shoe shines. No time to book flights or reserve hotel rooms, no time for pleasantries, no time for the bare civility of a call returned, a gift acknowledged, no time for no nothin’ but work and please Jesuses and thank you Lords when the bastards finally shipped.
Poor people in poor countries work like this. They work like this every day and they don’t have book sales or clients or speaking engagements to look forward to. They work like this in the hope their babies will have enough to eat, in the hope nobody in the family will get sick, in the hope no guns tanks bombs will snuff out the little they have and the certainty that sooner or later their luck, such as it is, will run out. :::
Dutch treat
We were going to write about Cinnamon Interactive’s subtle design sensibility, well-implemented access enhancements, and Meyeresque way with CSS, but 50,000 bloggers beat us to it. Good design and good markup are too rarely found on the same site. One day that may change. In their modest way, sites like Cinnamon Interactive help bring that day closer. :::
Spellbound
The long-awaited Spell Catcher for OS X is here. We installed it this morning. The good news is, it works. The bad news is, you can’t run Spell Catcher and Typeit4Me at the same time, because they both share the same little International menu bar widget. (In OS 9, you could run both simultaneously, and we did, we did.)
Typeit4Me is a text expander. Peck out a couple of characters and it expands them into a line of XHTML, or a URL, or a stored password, or a paragraph of boilerplate text. Spell Catcher is a system-wide, interactive, international spell checker, dictionary, and thesaurus. Both products are great at what they do. Both do something we find essential. Toggling between them is a productivity-wasting hassle. One is always spell checking when one wants to be expanding, and vice-versa. To avoid going bonkers with frustration, you must quit using one of your long-cherished programs and coax the other into emulating it as best it can.
Typeit4Me can’t pretend to be a full-featured spell checker or dictionary, of course. But Spell Catcher’s user shorthand glossary feature can emulate Typeit4Me’s expansion capabilities. It’s not as full featured as Typeit4Me and it can’t import Typeit4Me’s expansion key shortcuts. They must be manually entered, one at a time, in a dialog box, and this must be done from memory because OS X won’t let you run both programs at the same time (remember?), and because Typeit4Me’s shortcuts file can’t be opened in a text editor, and...
Point is, under OS 7, 8, and 9, users could simultaneously run multiple system-wide text managers. Under OS X we can’t. We’re not sure it’s progress we smell. No doubt we’ll get letters from OS X extremists telling us it is progress—like the letters you sometimes see on W3C mailing lists, saying how great it is that XHTML 2 finally gets rid of that nasty, horrible IMG tag. It’s good you wished them people into the cornfield. It’s real good. :::
A room with no view
While we’re being honest, here’s an update on that whole “view source in your HTML editor” problem. You can’t view source in your editor of choice in Chimera. You can’t view source in your editor of choice in Safari. You could view source under your editor of choice in IE5/Mac under OS 9, but you can’t in OS X, and no one can tell us why the browser no longer supports this function.
We edit our sites in PageSpinner. Russell Harlan sent us an Apple Script he wrote that tells the browser to view source in that application. Such scripts can be added to the optional Apple Script menu bar widget in OS X. The optional Apple Script menu bar widget in OS X slowed our system to a crawl—and our system is Apple’s newest and fastest. So we deleted the Apple Script widget from our menu bar.
Scripts can also be added to DragThing and then triggered by a user-selected command key. We added Russell Harlan’s script to DragThing, assigned Command-E as the trigger (i.e., the same View Source command built into the browser), and it worked like a charm.
It is absurd that web designers must jump through such hoops to restore needed, ordinary functionality to their browsers. Write an Apple Script and use a third party application to trigger it? Phooey. All browsers should let you view source in your editor of choice. All old browsers did that.
This would be great: a site offering downloadable Apple Scripts that tell specific OS X browsers to open source in BBEdit or PageSpinner. (Does such a site exist already?) This would also be great: an OS X Internet Preferences control panel that allowed users to choose an HTML editor for viewing source in all browsers, and a hook all OS X browsers could use to comply with that preference. :::
15 January 2003 :::
[noon]
More about XHTML 2
Tantek Çelik offers additional thoughts on XHTML, and explains what he believes the HTML Working Group must do before expending any more energy on XHTML 2. He knows whereof he speaks: the man is a contributor to the CSS, HTML, and XHTML specs, and the creator of the Tasman rendering engine that, by code and by example, helped bring standards to our browsers. Tantek encourages his readers to share their feedback with the W3C as a matter of public record. :::
A Sally Field moment
In 2001, Terry Eaton bought a copy of our first book and sent it to designers all over the world. Working in secret, they autographed it, drew in it, painted on it, pasted collages onto it, and annotated the text. In short, they turned it into a high school yearbook of the web. After all hands had transformed it, the book was returned to Terry, who sent it here. We got it on our birthday. Need we say more. :::
14 January 2003 :::
XHTML 2 and all that
Five months ago, I underwent a crisis of faith after reading a draft XHTML 2 specification that was deliberately incompatible with XHTML 1 and HTML 4. For weeks I was unable to work on my book, Forward Compatibility. The title seemed a lie.
The new spec appeared needlessly complex (too hard for humans). It smashed existing conventions for no reason I could see. Where earlier markup specs had gently discouraged outdated methods, the thing called XHTML 2 burst roaring out of smoke and flame, a scaly hellspawn wielding a bloody butcher’s axe.The W3C seemed to have abandoned the notion that the web could move forward without breaking what we already know and use. Standards had been a lie. The sky was falling.
One day I realized XHTML 2 was not coming soon to a browser near me.
Next day I realized the sky was not falling.
W3C does have a problem, but it can be fixed.
Dive into despair
As it is currently configured, the draft XHTML 2.0 spec moves closer to a semantic ideal and farther from existing web development methods—many of which, as Mark Pilgrim observes, are already semantic. Mark’s “Semantic Obsolescence” post of 13 January is what I was feeling five months ago after reading the spec and talking to W3C working group members who were as unhappy with “XHTML 2” as I was.
Today I agree with Mark in having no desire to use XHTML 2. (Which I can’t anyway, since it’s not a final spec and no browser supports it or will for years, if ever.) But I disagree with Mark’s conclusion that standards are crap. XHTML 1, CSS1, CSS2, ECMAScript, and the W3C DOM are working just fine here and on other sites I design. The problem is not standards but this proposed XHTML 2 standard, and the problem, I think, is one of nomenclature rather than hubris or stupidity.
Backward incompatible by design
By design, the present XHTML 2.0 draft is not backward compatible with HTML 4 or XHTML 1. It abandons familiar conventions including the IMG element (OBJECT is to be used instead), the BR tag (replaced by a new LINE element), and the time-honored A HREF anchor link (in whose stead we are presently offered a technology called HLINK). It also drops support for inline CSS via the STYLE attribute. These curiosities and others in the proposed XHTML 2.0 spec may change by the time the spec is finalized or they may congeal into the hard shell of reality.
The XHTML 2 we get may be just like the current draft proposal. But that doesn’t mean we’ll be stuck with it.
Problem solved by example
Suppose Illustrator had been named Photoshop 2. Some artists would yelp with pleasure: “Finally, I can use vectors!” Others would howl: “What do you mean I can’t edit photos any more?”)
But Illustrator and Photoshop are different. Their different names clue you in to the fact that they’re different tools built for different jobs. Illustrator doesn’t cancel Photoshop. Photoshop doesn’t cancel Illustrator. Some people use one, some people use the other, some people use both.
You see where this is going.
An alternative, not a replacement?
The W3C XHTML working group may have travelled too far down the road of “XHTML 2.0” to consider making it more compatible with the methods used by all site builders, including hundreds of thousands of non-experts.
But the W3C could rename the specification they are now calling XHTML 2. They might call it AML (Advanced Markup Language) or MML (Millennial Markup Language) or anything else they like.
Renaming the spec would relieve developer anxieties and make clear that the language now called XHTML 2 is not intended as a replacement but as an alternative to the markup with which all of us are familiar. Just as Illustrator is an alternative to Photoshop. Different tools for different jobs.
Then, of course, the W3C might want to clarify exactly what job the markup spec currently known as ”XHTML 2” was built to perform.
No time for maidenly modesty
Adobe does a good job of telling me what Photoshop and Illlustrator are for. Macromedia has no problem explaining the benefits of Flash or Dreamweaver.
If it really wants designers and developers (let alone browser makers) to get behind the new spec, the W3C should shuck off its modest, academic shell and begin selling the community on the benefits of and thinking behind the spec it is now calling XHTML 2. The spec may have tremendous benefits, but I’ve been doing this work for a while and I can’t see any. I come in contact with many geeks who know more about web technology than I ever will, and none of them can articulate an “XHTML 2” benefit either. (Well, maybe one geek I know can articulate XHTML 2 benefits, but I rarely understand what he’s saying.)
We need W3C’s help (or someone’s—someone who gets the practical benefits of “XHTML 2” and can write about them in clear, human-friendly language) to understand how this new thing they’re proposing could benefit us and our clients. But first we need the W3C to call the new spec something other than XHTML 2.
But will the dogs eat it?
It remains to be seen how much of the proposed “XHTML 2” spec will make it into a final Recommendation. It also remains to be seen whether developers and browser makers will rally ’round the flagpole of XHTML 2 or ignore it. Since the proposed spec is not final and is not yet supported by any browser—and mainstream browser support for it might be years away—the whole issue is interesting but somewhat irrelevant.
The sky is not falling. No browser will stop supporting XHTML 1 for years, maybe decades, to come. For that matter, no browser will stop supporting HTML 4 for years, maybe decades, to come. So why use XHTML at all?
XHTML 1 takes what we’ve long used and recreates it in XML so it can work better with other forms of XML-based markup and with XML applications and web services—marrying the old to the new. That’s what’s forward compatible about it. If you work with XML-based applications and web services, or expect to do so in your lifetime, it makes sense to use human-friendly XHTML 1.
My hope is that W3C will change the name of XHTML 2 to indicate that it is a different (and alternative) markup language, not a dead end for the XHTML we currently know and use.
My hope is that the language I know as XHTML will continue to be gently upgraded in parallel with that different, alternate markup language.
The standards I use every day work for me, and I owe most of them to W3C. I’m giving that organization the benefit of the doubt—and telling them my concerns about XHTML 2.0. If we all do the same (trust the process, provide honest feedback), we might see results we like. :::
10 January 2003 :::
[6 pm | 11 am]
Two more chapters of Forward Compatibility have left the building.
“It’s your birthday this weekend,” she said. “Think of something you want to do.”
“Write more chapters,” we said. :::
Last of the 45° angles
A tiny moth, no bigger than a baby’s fingernail, fluttered through a wee air crevice in our transparent Apple keyboard and was unable to find its way out again. We tried shaking it loose. We tried prying open the keyboard. No go.
Days passed.
The little fellow has taken up permanent sentry duty beneath our fingers, his corpse set at a crisp 45° angle to the keyboard’s Up arrow key.
Apple’s Pro Keyboard is like something out of Kubrick’s 2001: clean, sterile, futuristic. Every model but ours. Ours has a dead moth in it. :::
Little Verdana, happy again
This site’s body text has returned to the land of unjustified Verdana. Reload and see. If you miss the justified Georgia, click the third button on the style switching widget, above right. Requires cookies and rudimentary DOM compliance.
Why the switch? Small Georgia looked swell in the non-antialiased environments for which it was designed, and in operating systems that antialias text only very subtly (i.e., Mac OS 9). But in modern environments like Windows Cleartype and Mac OS X 10.2+ Quartz, especially at higher resolutions, small Georgia turns wispy as smoke, its edges faint as a ghost’s whisper. That’s why the switch. The new default (identical to our 1998–2001 default of 11px/1.5 Verdana) looks equally good in Quartz, Cleartype, OS 9, and traditional non-antialiased environments. Verdana is just that way.
Now that justification is off, an implied ragged right line at the edge of the body text troubles the eye vis-a-vis the left-aligned right-hand sidebar. This could be fixed by moving the sidebar column to the left instead of the right (and then right-aligning all sidebar elements). With a left-hand sidebar massed against a strong, implied vertical line at its right edge, and right-hand body text starting from a strong, implied vertical line at its left edge, the eye would once again be pleased, and the distinction between the two sections would be ever so subtly reinforced.
That would be a good little design detail, but it’s not going to happen, at least not for a while.
Some of you will ask why our new default style uses pixels instead of “accessible” relative sizes. Okay, it sounds ridiculous to us, too, but the fact is that this site is a geek magnet and a bunch of you will ask. In fact a bunch of you will ask even after we post this explanation. But that can’t be helped. Anyway, on with the answer.
We reverted to pixels because, in the newest crop of Mac browsers, text set in “accessible” relative sizes may end up borderline illegible. Hence inaccessible. We still use relative sizes in the Georgia style to avoid potential legibility/accessibility problems in IE/Win, the only modern browser that doesn’t allow users to resize text set in pixels. We hope at least one of these choices will work for you, and we hope browsers will become more, not less, consistent. Speaking of which, two inexplicable changes to the way IE5/Mac works under OS X are driving us nuts and making simple development tasks much harder. For those interested in such things, our two sorrows (and possibly yours) are described below. :::
Source of woe
Under OS X, IE5/Mac no longer allows you to view source in your XHTML editor of choice. (Or, if it does allow you to do so, the Way is shrouded in mist.)
Since browsers first climbed from the primordial muck, designer/developers have been able to view source in their third-party web editing tool of choice by adjusting a browser preference or two. The time-honored method for telling IE5/Mac to view source in your editor of choice:
First, open Explorer’s Preferences. Go to File Helpers and click Add. In a new, blank dialogue box, type “Source Code” under Description, “.html” under Extension, and “source/html” under MIME type.
In the File Type area, click Browse to locate your web editor of choice. Select it, and the File type and File creator areas will be filled in automatically. Under Handling, choose Post-Process with Application. Hit the second Browse button, select web editor one more time, then hit OK.
View: Source (or Command-E) will open any page’s source in your favorite web editor.
That’s how it’s always worked. But not in OS X. In OS X, the browser downloads the source file to your chosen Downloads folder, where it sits, unopened and unannounced. If you don’t open the Downloads folder, you won’t think anything has happened. You could hit Command-E a dozen times (and download a dozen copies of the file) without having the slightest clue that the browser was doing anything at all in response to your request.
We’ve written to the Mac Internet Explorer Talk mailing list in hopes that another web designer has come across and solved this problem. If we get an answer we’ll share it here. :::
Throw out the script
Under OS X, IE5/Mac also no longer displays JavaScript files as plain text in the browser. Instead, when you attempt to view a JavaScript file by typing that file’s URL into the location window, IE5/Mac (OS X) downloads the file and then launches a “helper” application. Even if you manually edit preferences and instruct the software to “view in browser,” it just won’t do it.
Bizarrely, our IE5/Mac launches Adobe LiveMotion 2.0 (a scriptable animation tool that has been called the lazy man’s Flash) to display JavaScript files—including our own JavaScript files, written by hand in a text editor.
More bizarrely still, IE’s preferences say it is supposed to view JavaScript files in Dreamweaver (which is also installed on our machine).
Needless to say, we did not set either of these preferences, and also needless to say, they seem to contradict each other (Macromedia versus Adobe and all that). It would seem that both Adobe and Macromedia override Internet preferences when you install their applications. And once they do that, the browser becomes hopelessly confused, and you cannot edit its preferences back to any semblance of rationality.
So while, in OS 9, IE5/Mac used to display JavaScript files quite handily, now it insists on using some kind of helper or other to display files of MIME type application/x-js, and if you change the settings or tell the browser to display the file internally, you get error dialogs followed by the launching of three or four different programs on your hard drive. :::
Icicles in the sky
Wednesday 34th Street west of Madison Avenue was blocked to traffic, ostensibly because icicles were falling from the radio tower of the Empire State Building, and anything falling from that height could flatten a pedestrian like a moth in a keyboard.
If anything was falling from it.
Her office sits katty corner to the Empire State Building; our apartment sits two blocks away. Long into the night, cops guarded every intersection of 34th Street, including those far beyond range of falling icicles.
If any icicles were falling. :::
8 January 2003 :::
[2 pm | 11 am]
This reporter for a widely read computer publication used to contact me every time news about web standards began to brew.
“A new version of Opera is coming out next week,” he might tell me. “What’s your reaction?”
“Well, it’s coming out next week,” I’d say.
“Right,” he’d agree. “So what do you think of it?”
If I didn’t give this reporter an answer, the only people quoted in the article would be a PR guy from Opera and a developer in Steubenville who built sites strictly for IE/Windows. Also if I didn’t give him an answer, he’d never contact me again.
I got fairly good at spinning bubbles for this reporter. But I never liked doing it. Six months ago I asked him to contact two other members of The Web Standards Project instead of me, as part of a process of separating the style of myself from the structure of WaSP.
My book on web standards must be finished within the next three months. Client work and speaking engagements fill that same time period. The only way to get the book done is to shut off the noise and dig in. For two days I’ve been working on three chapters about modern markup. I’ve scarcely checked email. I haven’t looked at the web at all, except to confirm a few facts. By not looking at the web for two days, and by not checking a sudden profusion of reader mail, I missed the kind of news this reporter used to ask me about.
Namely, the news that yesterday Apple released a new (beta) web browser called Safari. It’s based on Konqueror, which means it’s designed to support standards, and also means it suffers from some of the same CSS bugs that afflict Konqueror.
The first time I used Safari to view A List Apart, the style sheets failed to load. I refreshed and then everything was fine. Safari even managed to handle the Flash Satay object embedding method that sometimes fails in IE/Win. It understands the DOM-based scripts at Happy Cog. They’re very simple scripts, but Opera couldn’t handle them until its 7.0 beta. Whether Safari fully supports the DOM or only understands parts of it remains to be seen.
Safari properly displays the image-free CSS banners at the top right of this page. Safari does not display the title attribute to the IMG or A elements (or any other element). Win some, lose some.
Safari sports a Bug Reporting button at the top right, where most browsers offer a brand doohickey. Apple expects us to discover bugs and is making it easy to report them. That’s a good thing. Safari may also install itself as your default browser without asking. That would not be a good thing. I installed a couple of Extensis OS X upgrades this morning. The installer prompted me to register the applications. When I clicked the Register button, Safari launched, instead of my default browser.
In the 24 hours since Safari came out, some designers have already tested it fairly extensively. Dive Into Mark has compiled a bug list, including the application/xhtml+xml MIME type bug from which several mature browsers also suffer. (That’s the bug that has prompted certain geeks residing on the astral plane to advise against using XHTML and to toss about the popular phrase, “considered harmful.”)
Matt Haughey notes that Safari defaults to the old Mac 72 ppi display instead of the 96 ppi standard used by most other modern browsers regardless of platform. This means that text set with relative sizes, as the W3C and accessibility experts recommend, may be too small in Safari. (Zeldman.com and Happy Cog use relative sizes.)
This switch back to 72 ppi is particularly puzzling since, in OS X, Apple has abandoned the pixel as a unit of measurement. When you set type preferences in OS X, you’re asked to do so in terms of point sizes—even though points are a unit of print, not screen, measurement. (More on why Safari currently uses 72 ppi.)
There’s danger that some developers will sniff for Safari and serve it an alternative style sheet, though that risk is somewhat minimized by the fact that Safari, being limited to OS X, is unlikely to capture a whopping chunk of the market. Safari identifies itself as Mozilla/Gecko, which could create as many problems for the browser detection crowd as Opera’s tendency to identify itself as Explorer unless the user tells it to do otherwise.
Safari’s switch to 72 ppi also slightly increases the likelihood that Mac-based designers will keep specifying their text sizes in pixels, since pixels render accurately 99.9% of the time, regardless of browser and platform differences. This in turn may anger some IE/Windows users, since IE/Win does not allow users to increase the size of type set in pixels. IE/Win is the only modern browser that does not provide that option. IE5/Mac was the first browser to offer it.
Safari is a beta. It’s important to remember that. For a product still damp with afterbirth, it feels remarkably well put together. But that doesn’t mean it’s ready for prime time. I used to get snotty mails from Omniweb users when their browser failed to properly handle web standards on one of my sites.
What’s striking to anyone who’s been paying attention is that every browser maker today knows standards compliance is not an optional extra but a baseline requirement. That is the good news. The bad news is that those of us who use standards to design and build sites may find ourselves crafting a fresh set of workarounds for Safari. I hope not. The purpose of web standards is to write once, publish everywhere. Not write once, shoehorn in a bunch of hacks and tricks, and then publish.
Safari looks good, loads fast, and seems to be making a true effort to support web standards. It’s too early to say much more than that. :::