<h1></h1>
<h2></h2>
<div class="post"></div>
<div class="post"></div>
<div id="menu"></div>
<h1></h1>
<h2></h2>
<div class="post"></div>
<div class="post"></div>
<div id="menu"></div>
It's too late to request a voter registration card by mail in Missouri, but you have until October 6 to register at the office of your local election authority.
In St. Louis contact Gary Stoff or James O'Toole by phone at 314-622-4336, or visit the election office at 300 N. Tucker downtown.
In St. Louis County contact Judy Taylor or David Welch by phone at 314-615-1800, or visit the County election office at 12 Sunnen Dr in Maplewood.
More Infomation
It's not hard to get an appreciation for the things designers take for granted following Tantek's experiments with undohtml.css, Eric Meyer's extended thoughts on Mozilla's default styles, and 5 minutes of poking around the web without Firefox's html.css. A look at this site conjured feelings of guilt and laziness for having not created a more explicit stylesheet, one that more accurately specifies exactly the kind of look I'm going for.
It's not as bad as it looks.
It turns out that 90% of the ugliness caused by disabling html.css (on 90% of the non-table-based sites I visited, including this one) is due to the lack of styles explicitly specifying block elements, an oversight that causes everything to appear inline. It's a mess. The following CSS mimics Mozilla's default block-level settings:
/* block elements */
html, body, div, map, dt, isindex, p, multicol,
dl, dd, ul, menu, dir, ol, blockquote, address,
center, listing, plaintext, xmp, pre, hr, marquee,
h1, h2, h3, h4, h5 {
display: block;
}The above list contains non-standard and deprecated elements, but represents the full list of Mozilla's defaults. Add/remove elements to taste. I've created a file called default.css containing these rules, which I'm now importing into this site's primary stylesheet.
I've also included Mozilla's styles for elements hidden by default, taken directly from html.css:
/* hidden elements */
area, base, basefont, head, meta, script, style, title,
noembed, noscript, param {
display: none;
}There are several other things going on in html.css, but the above styles go a long way toward getting your pages to render as expected with the default styles disabled, which at least makes it easier to see what else you've taken for granted.
Update: Eric Meyer has some additional thoughts. His minimal stylesheet includes rules for tables and lists:
li {display: list-item;}
table {display: table;}
caption {display: table-caption;}
tr {display: table-row;}
col {display: table-column;}
colgroup {display: table-column-group;}
tbody {display: table-row-group;}
thead {display: table-header-group;}
tfoot {display: table-footer-group;}
td {display: table-cell;}
th {display: table-cell;}I've moved li {display: list-item;} from my primary stylesheet, where I misplaced it before this entry, to my default.css. My current design makes no use of tables, but I've added Eric's table styles, too, just for the hell of it.
Evolt's "Ten CSS Tricks You May Not Know" is great stuff. The last of the ten tips describes a way of extending menu divs the length of neighboring content areas made popular by Dan Cederholm. But they get one thing wrong:
Unfortunately the only solution to this is to cheat, and assign the body a background image of exactly the same colour and width as the left column.
Not true. I've been using an alternative method to extend menu divs for over a year. The page you're looking at right now -- unless this site's design has changed since the day of this post, of course -- uses this technique.
It works by specifying the background color of body or a wrapper div to be the same as the desired background color of the menu, then offsetting the content div. No image necessary.
Matt Webb perfectly articulates my attraction to Atom:
Atom says: Given everything else is in flux, here's our one fixed point. The post. The metadata of the post. The relationships between posts. That's it.
Out of that single abstraction everything else can crystalise.
The crystallization of which Matt speaks is, of course, the most promising reason to use Atom. I've only met two kinds of people: 1) those who think the most important thing is to formalize all data, aggregate it, distribute it, and then go crazy doing interesting things with it, and 2) those who find me boring at parties (since this is the type of thing -- often, unfortunately -- I like to talk about at parties).
A key feature of future blogging tools, as Matt sees it:
A templating system. Probably a cgi script that does XML transforms (so I can trade templates with people, because we all know we're operating on collections of Atom documents), or a Movable Type-like templating tool.
Some of this site's templates are already XSL-Transformations acting on Atom documents. They'll all be standard XSLT, eventually -- when I find a Perl module that supports everything I want do do with XSLT, I guess -- and they'll all be operating on Atom. At which point I'll make them available to the rejoicing masses, who'll bask in the new interwebtopia. And you'll say, "Look! I wrote an Atom transformation, too, and look how it does all these interesting things." And I'll think you're very clever and be inspired to do my own interesting things.
That's how it looks in my head, anyway.
Fundamentally, this is not a new idea, but Atom actually makes it seem possible.
I joined Flickr when it launched earlier this year, but I'm just getting around to moblogging there. It's important to me to keep this site clearly focused on the Web -- Web standards, Web programming, Web ephemera. But check out my Flickr photoblog for something completely different.
Update: There's an Atom feed, too.
I'm now generating an Atom feed for every entry on this site. To access the feed for a particular entry simply add .atom to the end of its archive URL. For example, this entry's Atom feed can be found at /2004/06/modified.atom Comments are included in the feeds of those entries that have them.
Supporting Atom should be easy. And it is, mostly. But I did run into some problems supporting feed-level modified. This element is required in Atom 0.3, but even the format's most high-profile supporters disagree on its use. I suspect most of the confusion is a result of poor tool support. Look at how WordPress, Movable Type, and Textpattern arrive at a modification date:
WordPress (wp-atom.php)
<modified><?php echo mysql2date('Y-m-d\TH:i:s\Z', get_lastpostmodified('GMT')); ?></modified>
Movable Type (Atom Index Template)
<modified><MTEntries lastn="1"><$MTEntryModifiedDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></MTEntries></modified>
Textpattern (atom.php)
tag(date("Y-m-d\TH:i:s\Z",$last),'modified');
They're grabbing the most recent entry and hoping its modification date happens to be the date of the last updated entry in the entire feed. They'll be right most of the time, I guess. Most of the time. Isn't that the kind of ambiguity Atom is supposed to suppress?
These tools are getting it wrong because it's not as easy as you think to arrive at a feed-level modification date. Here are a few things you can't do:
At the very least, the spec should be written more clearly, in terms authors of publishing tools -- programmers -- can understand. If tools should use the modification date of the most recently modified entry, then the spec should say that. Specifications should be written such that people who think programmatically can translate the words into an algorithm. This a great example of how spec text is confusing, even when you're asking for something that seems simple, like the date of the most recent modification.
But making the spec more clear, while still a good idea, will make no difference if publishing tools can't natively produce the required information. If aggregators absolutely must know when a feed was last modified, let them figure it out -- based, presumably, on entry-level dates -- on their own. It's clear publishing tools will resort to including whatever is easiest for them to generate, anyway, even if it's the wrong date.
Why does this matter so much? It wouldn't if atom:modified weren't required. Is there a compelling reason this element isn't optional?
Clamoring for a Gmail invite? I've got two. I'll give one each to the first two people who comment on this entry. Be sure to leave your email address; it won't be displayed. Consider it thanks for reading.
Update: Read this comment for information on getting a Gmail invitation.
Brian Garside's message to those who would point out validation errors by e-mail -- don't do it! -- has generated a lot of back-and-forth at Dave Shea's mezzoblue. For the record, I want you to point out my validation errors. I can't catch everything and I appreciate those who care enough to take the time.
Unfortunately, the resulting discussion has led Keith Robinson to "retire" as a standards advocate, citing frustration with those of us who demand 100% standards compliance from our standards-gurus. Keith has felt this way for a while, as evidenced by his much-linked rant from last year. I didn't get it then, and I don't get it now. Jacques Distler on the importance of validation:
Not [the point] of the the Web (nor of the internet, nor of life), but it is *surely* the point of Web Standards. I am *baffled* that anyone can *advocate Web Standards* and simultaneously hold that validation doesn't matter. Maybe you mean something different by the term *Standards.*
You can't support standards without, well, supporting standards! What's so frustrating about Keith's stance is that it gives designers with less experience an excuse to ignore difficult errors, all while patting themselves on the back for making an attempt. You can't, by definition, support standards without adhering to the rules outlined in the standards. By definition.
I like Keith and read his site regularly. He says a lot of smart things about the Web every week, but his retirement from standards happened a long time ago, the day he decided to support only parts of standards and not others.
Yes, folks, there are other things to worry about. This Web thing isn't easy. But standards are a baseline. They make things easier, not harder. That's the message.
I've been blogging for one year. When I wrote the first entry to this weblog I was in a wheelchair, having just returned home from the hospital after breaking both legs and my back's third lumbar vertebra in a car accident. I'm doing much better, close even, after what likely will have been a final leg surgery a few weeks ago, to a full recovery.
The accident was the impetus to return to school, start this weblog, and generally quit fucking around. I'm having a lot of fun writing here, and it's still exciting to hear from readers. It's been a long year, but this weblog has helped make it a good one.
So, thanks to all who've visited in the last year. Come back soon.
The news this morning, as reported by both sides of the larger syndication debate, is that the W3C's Atom pitch seems to have done little to abate the format's IETF inertia (Dave Winer's take; Sam Ruby's take). Matt May explains why he thinks the W3C is the appropriate home for Atom:
A W3C Recommendation comes with a test suite, which is hugely beneficial on specs that require a great deal of interop. It comes with proof of interoperable implementations, developer testimonials, and publicity. Not bad for free.
I'll let those familiar with each organization discuss the internal differences between the two groups. But while everyone close to the format contemplates completion schedules and decision-making guidelines -- important matters, to be sure -- I'm wondering which body will accelerate adoption of the format. To the average developer the W3C means Web standards. XHTML, CSS, and even XML, of which Atom is a vocabulary, are each W3C standards. The obvious consequence of hosting multiple successful, pervasive formats is that the W3C has become the Web's de facto standards body (second only to the WaSP in a Google search for "web standards").
Most developers are familiar with both the style and format of W3C documentation and with the validators that support it. Content producers, especially the newcomers who are summarily directed to a W3C validator the first time they ask for help with CSS, will be more likely to find and support Atom if it's in turn supported by the same group that brought them every other standard with which they're familiar.
Everything I create on the Web for the foreseeable future will be marked-up with XHTML, styled with CSS, and syndicated with Atom. It would be nice -- not necessary, but nice -- to find all three formats in the same place.