MY GLAMOROUS LIFE: Tragicomic fodder from the life of Zeldman. A LIST APART: Design, code, content. For people who make websites. LES MISC: Articles, essays, and miscellanies. TAKING YOUR TALENT TO THE WEB: A Guide for the Transitioning Designer.
DAILY REPORT: Web design news for your pleasure.
STEAL THESE GRAPHICS: Free art for your desktop or personal site. FUN HOUSE: Entertainment for you. ASK DR WEB: Tips for web designers. Since 1995. 15 MINUTES: Interviews with movie stars and cyberstars, 1996-1999.
Happy Cog.

Current ALA: Using XML
Current Relaunch: Happy Cog Studios
Recent Glamour: Life During Wartime
Recent Essentials (clickety-click)

19 July 2002
[11 am | 1 am]
In Issue 147 of A List Apart, For People Who Make Websites: “Using XML,” by J. David Eisenberg. More than a rule book for generating your own markup, XML is part of a family of technologies that work together in powerful ways. In an unusual tutorial, ALA contributing author J. David Eisenberg creates an XML-based markup language from scratch, using off-the-shelf tools to transform it for a variety of formats, including HTML, PDF, SVG graphics, and plain text.

You may already have heard that a video company based in Austin, Texas, claims to own the patent on JPEG images, plans to charge royalties on the format, and has already convinced one big company (Sony) to pay. We can only hope Slashdot is right, and that “this ambush of the digital imaging industry will probably stand as the worst public relations nightmare a company can inflict upon itself.”

The AllTheWeb search engine now lets you customize your Search experience via user-defined style sheets. Create a CSS file, post it online, and voila! Searching 2.1 billion web pages (including PDFs), AllTheWeb claims to dethrone Google as the world’s largest search engine. It’s certainly one of the fastest, and in a quick vanity test we found its results relevant. We plan to work with the makers of AllTheWeb as they extend their support for CSS.

Ian Lloyd’s free online Form Element Code Generator helps you create individual form elements containing all the markup required to make them accessible.

Making a Commercial Case for Adopting Web Standards (aka MACCAWS) is an emerging community of web professionals working to do what their name suggests. We think that’s great and encourage like-minded individuals to contribute their ideas. We’re avoiding the group ourselves—mainly because we’re writing a book on this very topic, and need to finish nailing down our own ideas before we start reading other people’s. But don’t let that stop you. We’ve heard only good things about this group.

Sometime ALA contributor Peter-Paul Koch has compiled ten ways to hide CSS from browsers. Hat tip: CSS-Discuss and numerous Daily Report readers. :::

18 July 2002
[4 pm | 2 pm]
Look, Ma, no tables: Lycos Europe will soon move to a new layout that validates as XHTML 1.0 Transitional and uses CSS for layout. (Netscape 4 users will get a plain text version with no formatting.) Can a standards-compliant Google be far behind? Reported by Tom Gilder in W3C’s public evangelist archives. Hat tip: ’Tek.

On our shelf: Eric Meyer on CSS (New Riders: 2002) is a great new book by a master with a rare gift for explaining even complex things in ways anyone can understand. Creative, inspiring, and practical, it focuses on the kinds of projects we all create, and its tips (and ways of thinking) can be applied to many projects beyond those discussed.
        For instance, prior to reading this book, we used the id attribute sparingly on commercial projects. Reading Meyer showed us how to harness the power of this humble two-character attribute to achieve higher levels of design control while writing cleaner, leaner markup that makes sites easier to transport beyond the desktop browser. It’s as powerful on traditional sites built with (X)HTML tables as it is on pure CSS layouts.
        Meyer may be a CSS geek but he lives in the real world (heck, he lives in Cleveland, how much more real can you get?) and though his book inspires creativity, it’s aimed at working designers with jobs to do and deadlines to meet.
        We love this book. You will, too. Some character named Zeldman wrote the Foreword.

Testing your site’s WAI or Section 508 accessibility compliance just got easier, thanks to Brandon German’s free bookmarklets. Drag them into your browser’s Bookmarks or Favorites for one-click Bobby testing against a specific WAI level or U.S. Section 508 guidelines. (Geeks with nothing better to do, Brandon’s site meets WAI single A guidelines, so you needn’t bother to check.)

A tale of copyright. Under the Digital Millennium Copyright Act, author Curt Cloninger’s Playdamage was required to stop displaying an image owned by Getty and remotely hosted by a non-profit group that may or many not have paid for the right to use the image on their server.
        A standup guy, fine writer, and fixture on the design circuit, Curt went through hell with his hosting company, nearly losing his site over the disputed image. Curt views the entire debacle as a free speech issue. We love Curt but find his opinion naive.
        Getty licenses images. That’s its business. If you want to use its images, you pay for them. If you haven’t paid, you can’t use Getty’s images, any more than you can eat your neighbor’s lunch or drive a stranger’s car. Though he wasn’t hosting the Getty image, Curt was displaying it on his site, and he hadn’t paid for the right to do so. This is not a case of The Man coming down on The Little Guy. It’s a case of pay to play, with clearly established rules.
        We do wonder, however, if Getty takes the same line with Yahoo or Google’s Image Search as it did with Curt’s site.

In other news, eBay is buying PayPal, Microsoft plans to charge for MSN8, and Apple will charge for .Mac, formerly known as iTools and formerly free. We predict that Pixel Industries will buy PixelFlo, Pixel Surgeon will acquire Pixel Industries, Adobe and Macromedia will sue each other, Scorsese will take another year to finish “Gangs of New York,” and Jakob Nielsen will somehow profit from all of it. :::

17 July 2002
[4 pm | 11 am | 10 am]
WestCiv announces the return of their free, self-paced courses in standards-based web development. (Current free course: HTML 4.0 and XHTML for CSS.)

Better Living Through XHTML, our ALA tutorial on browser and authoring tool gotchas when converting from oldschool web design methods to XHTML and CSS, has been translated into Dutch by Marrije Schaake and published in the new issue of Naar Voren.

In Defense of Search: “In my consulting ... I see organizations of all shapes and sizes investing heavily in taxonomy design while giving almost no thought to the search system. Why? Because taxonomy design is the current rage. Because many people don’t understand how search can be improved. Because search engine configuration is often ‘owned’ by the IT group rather than by the folks responsible for design, usability and information architecture. And because Jared keeps slamming search.”

Two comments on yesterday’s Report, followed by a known bug in the display of same:
        (1.) If you use pixels to control font sizes and supply a Style Sheet Switcher that lets readers choose a more legible typeface, you’ll combine the design control you and your clients crave with the accessibility features some readers require. But only if the design makes it obvious to any visitor that they can change the fonts by pushing a button, and only if their browsers support the technology that’s used to drive the Style Sheet Switcher—or provides its own accessibility features. For instance, Opera doesn’t support the Style Sheet Switcher on the Daily Report, but Opera lets its users Zoom any page whose text they find too small to read.
        (2.) As noted many times in these pages, visually impaired IE/Win users can tell their browser to ignore font sizes altogether (Tools > Internet Options > Accessibility), thereby getting you off the hook if you use pixels to control your font sizes. But many IE/Win users are unaware of this feature in their browsers, and this all-or-nothing approach may do more visual harm than good, removing cues that help readers grasp hierarchical relationships between various text elements. (If you use good, structural markup, hierarchies may be obvious even with sizes turned off; but few working designers use good, structural markup.)
        To satisfy the demands of accessibility within the context of normative practices in commercial web design, IE/Win needs to do what IE/Mac did in March, 2000: implement Text Zoom, so visitors can resize any web text. Will Microsoft ever make this change to IE/Win? We can only hope.

Y’all can stop writing in about the glitch in yesterday’s Report. It’s a known bug in IE. When you apply a CSS style to an ordered list, IE/Win gets confused and displays all the numbers as “1” instead of 1, 2, 3, etc., sometimes even sticking the numbers in the wrong place on the page. Thanks to Ben Darlow and the many others who wrote in about this—as hundreds of readers do every time we type a simple, numbered list and IE bungles it.

Mozilla users, wipe that smirk off your face. No browser is perfect. If Mozilla acts up (for instance, losing the ability to display images, parse styles, and support the DOM after you install a plug-in), you may be able to restore normal viewing by running “Flush Memory” under Mozilla’s Debug menu and then refreshing. (Hat tip: Timothy Martens.)

Opera users, wipe that smirk off your face and ask the makers of Opera when they plan to add DOM support to their browser. Qualms about theoretical renderings of pixels aside, Opera is a fine browser and many of its features are well conceived. But its lack of support for the nearly four-year-old DOM Level 1 Recommendation hurts its users by preventing them from fully interacting with modern web pages. Opera’s lack of DOM support may also encourage designers and developers not to take the browser seriously.

Yesterday we met with one of our creative heroes, and it looks like we’ll be collaborating with him on a web project this summer. ALA updates have fallen off schedule due to our many web projects and our book, but a fine new issue is on its way soon. (We had a new issue ready to go last week but cancelled it on discovering problems in the code it advocated.) :::

16 July 2002
[noon | 11 am]
File Under: Accessibility. Published a few months back, Happy Cog’s Colophon explains our keyword-based approach to accessible text sizing on the web (a variation on the Todd Fahrner method) and includes style sheets and screen shots. In a nutshell, it’s a means of specifying font sizes for web pages without taking away the visitor’s control, a subject also discussed in yesterday’s Dive Into Mark.

It’s not perfect. Nothing is.

Designers need small text. It’s not just a fetish. Most sites require us to cram tons of text above the fold—the part of a web page that’s visible before scrolling. On commercial sites, we typically control font sizes with pixels, a practice that works reliably on all but two browsers. (Opera abstracts pixels, making text smaller than specified, and one incremental version of Navigator 4 gets pixels wrong just because.)

But in the browser that ate the web, pixels and accessibility suffer from irreconcilable differences.

Type set in pixels can be resized in IE5/Mac, Mozilla, Netscape 6/7, and Opera, but unfortunately not in IE/Windows. If you’ve spec’d small fonts in pixels, visually impaired IE/Win users may be unable to read it. For anyone who cares about accessibility, this is IE/Win’s worst flaw, but Microsoft seems unlikely to change it. To create small text that stays accessible in IE/Win, another method is needed.

W3C, some CSS books, and blowhards on mailing lists will tell you to use ems. Try it some time, particularly on nested elements, and be sure to test on multiple browsers.

Others, who don’t design websites for a living, will advise you never to set text smaller than the user’s default. You may follow this advice on your personal diary site or weblog, but it’s too restrictive for most projects, especially the ones where they’re paying you.

That leaves CSS keywords and the workarounds that love them.

Technically, the Happy Cog method works for everyone, but it may frustrate two classes of visitors:

  1. IE/Windows users who set their browser’s default size below medium. For them, the text at Happy Cog will initially be too small. They can easily resize it—that’s the whole point—but they may leave the site in disgust, never realizing that a bigger size was a click away.
  2. Macintosh users who switch their browser preferences back to the old Mac default of 12px/72ppi. For them, too, the text at Happy Cog will initially be too small. Like their Windows-using brethren, they can easily resize it, but may quit the site instead and whine about the whole thing on their blogs.

We won’t even get into the part about how some fonts that look nice at small sizes (cough, Verdana, cough) are hideous at 12px or larger, further restricting the limited pool of typefaces from which you can draw while indirectly encouraging you to set everything at 11px Verdana forever (particularly since Arial is hideous at any size and many visitors moan when you use Georgia).

This would all be idle whining if it weren’t about accessibility and usability and the near impossibility of achieving these goals without sacrificing aesthetics.

What have we learned? Pixels are reliable but pose an accessibility problem in IE/Win. CSS keywords combined with workarounds will solve the accessibility problem but frustrate an unknown percentage of your visitors. Other methods fare even worse, making them more or less useless. So it goes. :::

15 July 2002
[6 pm]
Mr Zeldman regrets that he cannot chat today. Mr Zeldman has sent his publishers two chapters of Forward Compatibility: Designing and Building With Web Standards (New Riders, 2003). Mr Zeldman spent Sunday making pretty things in Photoshop. Mr Zeldman has a funny name for this activity. He calls it “front-end design.” Mr Zeldman let the dogs out. Mr Zeldman has a meeting tomorrow. Mr Zeldman gets mail. “Electronic mail.” He gets more mail than the mayor of New York. Mr Zeldman cannot read his mail today. Mr Zeldman thanks you. Mr Zeldman loves you. Tomorrow, tomorrow, tomorrow. :::

13 July 2002
In Standards Stalled Over Royalty Disputes,’s Paul Festa covers the patent and royalty dilemma facing the W3C and anyone who owns, designs, or builds websites. The issue has been building for over a year and will come to a head next week.

Are you now, or have you ever been, an HTMLMinimalist? Jarrod Piccioni’s Minimalist Web Project is collecting sites designed with the Miesian idea that less is more. :::

12 July 2002
[11 am]
Wednesday’s Brainstorms and Raves examines the human cost of stealing content, design, and bandwidth from other people’s sites — a cost we know well. This site’s Pardon My Icons collection (1995–97) gets hundreds of thousands of daily hits from kids who attempt to use our icons as avatars in teen chatrooms.
        Our icons don’t show up in these chatrooms (we’ve manipulated .htaccess files to discourage bandwidth theft), but our server still gets hit every time any viewer opens a chatroom page that attempts to display one of our icons by including its full URL.
        Your referrer logs may tell you when a blog with 1,000 readers links to your site. Our referrer logs display almost nothing but failed attempts by heavily trafficked chatroom pages to load our images.
        Partially to prevent this traffic from impacting your attempt to read our site, we’ve been paying for high-level commercial hosting since 1996. The upside is, Google notices all the traffic and ranks our site fairly highly as a result.

A few readers have complained about the cost of tickets to Meet the Makers. We remind you that Meet the Makers events are free to any designer or developer who requests “VIP” tickets.

Regarding recent coverage of Cast’s Bobby accessibility validator, a reader said: “Bobby proves a site can be accessible yet unusable.”
        HTML compliance issues aside, Cast’s Bobby is probably as good a tool as could be built, given the slippery algorithmics of accessibility testing. And the online version of Bobby is free, bringing accessibility testing within reach even for those who have no budget.
        But Bobby’s deceptively simple interface is confusing and could use work. The options that make Bobby usable are unusably hidden. When longtime Bobby users hack Bobby’s URLs because they don’t know the tool’s tests can be modified in any other way, that indicates a usability problem worth fixing.
        We also remind you that, unlike CSS and HTML validators, no accessibility validator can grant your site an unconditionally clean bill of health. Human judgement is always required. :::

The author and his opinions.
Over [counter] served!   Copyright © 1995–2002 Jeffrey Zeldman Presents.
XHTML, CSS, 508.  Reset bookmarks to Ahead Warp Speed.