24 October 2002

Late this afternoon we completed jury service. Our case was criminal. The circumstances and people involved were deeply tragic.

The juror seated to our right had a case of the sniffles. Now we’ve got it. A sourvenir of having served. Our cold will go away in a few days. Other effects of the case will last much longer. Nobody left the courtroom skipping or laughing.

In a free moment this morning, we solved one of the technical problems mentioned yesterday. As it has for centuries, this site once again validates as XHTML and CSS and complies with U.S. Section 508.

On returning from the courthouse we solved a few other problems afflicting this preliminary layout. Text is now selectable in all browsers we’ve tested. The CSS layout holds up in compliant browsers and looks remarkably similar in Netscape 4. The fix was trivial, requiring only a few minutes’ thought.

We also replaced presentational XHTML elements with structural ones. Web designers use presentational XHTML primarily to avoid vertical spacing problems in old browsers. The hell with that.

This preliminary layout was designed in sRGB gamma, an IEC/W3C standard color space for the web.

In theory sRG approximates “typical” PC gamma. In practice, few computer users bother to calibrate their monitors, and default gamma settings range widely. We design on Macs but always inside the sRGB color space.

We’ve avoided setting font sizes on body text, not only to give you more control, but also because we find the (default) large type refreshing after eight years of small type. We think big text emphasizes written content, which is what this page is about. It looks best if you turn on antialiasing, which is off by default in Windows and on by default in Mac OS.

Nothing is cast in stone and anything here could change tomorrow. With civic duty behind us, we intend to keep playing and see what happens. :::

23 October 2002

Jury Duty continues to absorb our time and attention, leaving us limp as a dishrag at the end of the day. Hence no work on the redesign here, few emails answered, etc.

Some readers have complained about the background color, which is dark in some gamma settings. You’ll have an option to change it once we finish the design.

The diamond character used to indicate permanent links fails in the Windows version of the Microsoft font used for the body text and also fails in other Windows web fonts due to laziness on the font developers’ parts. (The character works in Mac versions of these same fonts.) We've replaced it with a heart ::: that may also not work. Our PC is temporarily out of commission, so we’re firing blind.

Text is not selectable in IE5/Mac and is selectable only with great difficulty in IE6/Win and in addition there is a horizontal scrollbar in IE5/Mac. Why? Simple. IE/Win does not like absolute positioning. IE/Mac does not like it either. Ironically, absolute positioning works well in Netscape 4. Seems absolute positioning is the only part of CSS1 that Netscape attempted to get right in their 4.0 browser. Which makes sense in a way. In 1998, when Netscape 4 was dumped on the world like an incurable virus, semantic markup and separation of presentation from structure were not high on most people’s wish lists. Absolute positioning promised visual control, and that’s pretty much all most of us cared about.

Absolute positioning is not bad in itself, and though some CSS purists consider it a lame hack, its use makes sense for non-liquid layouts like this one. But IE belches it up like a bad day at Taco Bell.

To work around IE’s difficulties, we tried an alternate scheme using margins instead of absolute positioning. But that layout failed in Mozilla and Netscape 6, which overlaid content on top of backgrounds.

It may be possible to fix that by writing the absolutely positioned elements later in the markup and starting the markup with those elements that are not absolutely positioned. So doing would have the added benefit of providing text browser users, screen reader users, and Palm Pilot users with content instead of navigation at the beginning of each page. But we’ll need time and fresh brain cells to try that experiment and as we may have mentioned, Jury Duty leaves us neither.

Finally: to make a page more accessible, form controls should be associated with their labels via the XHTML LABEL element. We’ve been doing this for over a year, and the requisite markup is as simple as it gets:

<label for="search">Search:</label>

But when we include that markup in this layout, the W3C validator declares that our XHTML is invalid due to “ERROR X.” We can find no description of “ERROR X” in the CSS Validator FAQ, nor does there seem to be an XHTML validator FAQ, nor can we explain why the validator considered the exact same markup kosher in our previous layout and on a half-dozen other sites on which we’ve used it. Our half-baked theory is that the W3C validator contains a bug that’s being triggered by some ASCII character sequence elsewhere on this page. For now we seem to face a Sophie’s choice: valid XHTML with decreased accessibility, or compliance with Section 508 at the cost of a (possibly mistaken) validation error.

Meanwhile, we’re on Jury Duty. :::

22 October 2002

Jury duty consumes us. After a day in court we have no creative juice to expend on the redesign of this site, no strength to wade through email, or to perform even the most rudimentary tasks associated with our business. In short, we’re giving back to the democratic system from which we’ve benefited all our lives.

A few readers have taken the off-kilter portrait of Mao as an endorsement of the deceased Chinese leader’s policies. The NYC courts where we’re spending our days are housed in Chinatown. The layout in its unfinished state appeared to us as in a vision. We implemented what we saw.

Soon we will see more. :::

20–21 October 2002

New layout in progress, as you may have noticed. All CSS. No menu yet, as you may also have noticed. Fear not, we’ll get to it. We’re reorganizing the site to make more sense. The old stuff (over 60G of content) is still here in the same old places and will be easier to find when we finish the makeover. If you can’t wait, scroll down and flip back a page—the old menus await you there.

Goals of redesign: simplify. Increase focus, unity, and usability. Remove the extraneous. Be pretty.

Text is as big as your default font size preference, and can be resized up or down in any browser. On most systems it will be 16px tall.

The horizontal scrollbars that appear in some browsers are caused by CSS bugs in those browsers, not by layout errors. On the other hand, the Bobby Section 508 test that indicates an accessibility error is accurate. We’re working on it.

We’re on Jury Duty. More when we can. :::

17 October 2002
Pixelism

In yesterday’s Report we alluded to Mozilla’s inability to display all frames of GIF animations in Rollovers. Visit K10k with Mozilla and another browser. Mouse over the navigation buttons at the top left. Compare. (Some readers report that the bug does not occur in their version of Mozilla.) K10k has been reformulated in XHTML. Border attributes for which no compliant workaround has yet been found prevent it from achieving 100% validation. Our concern here is not Mozilla or K10k. Our theme will become clear as you read.

K10k is a layout-intensive site. It achieves its look via presentational XHTML (tables, frames) combined with style sheets, scripting, and images. Such sites would not ordinarily bother converting to XHTML let alone striving to validate. Yet it is precisely sites like K10k that may inspire a second wave of designers to incorporate web standards into their production workflow. When K10k validates, designers will see that it is possible to achieve pixel-precise control using standard markup and code.

Many would argue that pixel-precise control is antithetical to the web’s nature. Certainly, such control means nothing in the context of Lynx, screen readers, Palm Pilots, web phones, etc. But in desktop browsers, it sometimes means everything. To many designers, a few pixels make the difference between a professional effort and a sloppy failure. Many clients agree. Ours, for instance.

These clients want compliance and accessibility. They don’t expect their sites to look the same in 4.0 browsers and new ones. But they’ll fret over subtle rendering differences between IE 6 and Netscape 7. Are their concerns foolish? We think not.

We believe if the top of an image is supposed to align with the top of a block of text, it should do so. Likewise, if 50px of white space helps a visitor distinguish between a content area and a functional, task-oriented area, that 50px means something. Is 43px close enough? Sometimes yes, sometimes no.

In many cases it’s enough that there’s an appreciable block of white space. The amount may be based on ems or percentages. For many designs these loose, flexible values may be perfectly appropriate. But not for other designs. On some sites, precise visual alignments across a page convey an immediate sense of quality assurance. That notion of quality and precision may be a paramount brand value. Flexible, liquid design won’t communicate that brand value as effectively as a perfectly rendered grid.

Old-school pixelism wastes bandwidth on proprietary markup and excessive images and yields bloated, often inaccessible sites.

New-school pixelism provides precision when the design requires it. It does so without sacrificing accessibility or standards compliance and while conserving bandwidth. It is a reasonable alternative to Flash. To hope all designers and clients will one day stop striving for tightly controlled layouts is to miss the chance to persuade those who live and die by the pixel that standards are good for them, too. :::

Home, James.