Bill Merikallio and Adam Pratt's Why Tables for Layout is Stupid makes the case for CSS layouts in a refreshingly original and attractive way; Derek Featherstone finds the missing <link>; the latest WaSP Asks the W3C answers the question, "Which should we use, HTML or XHTML, and why?"; and Evan Goer's HTML House of Horror provides humorous background on two historically abhorred HTML elements.
Simon Jessey of Keystone Websites explains serving XHTML with the proper MIME type (to browsers that support it) using PHP. We've blogged before about the wealth of information at Simon's company's site. It's definitely worth a look.
Also, preeminent tech blogger Sam Ruby recently converted his personal weblog to valid XHTML 1.1. The list of technically conforming sites is growing.
Simon Willison asks if HTML definition lists are appropriate markup for question-and-answer exchanges. Joe Clark points to the spec:
Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.
In other news, everyone on the planet reports (for good reason) the return of A List Apart; Chris Hester uses CSS to both create shadows and build a house; and Paul Bausch's latest article for O'Reilly, Fail-Safe Amazon Images, solves a not-so-obvious problem.
After several frustrating minutes struggling to download personalized student loan forms today (a task that should have been easy), D. Keith Robinson's Web Design - Nail The Basics First seemed exceptionally important. From the article:
Web design and development don't need to be that hard. Begin with the basics, code your site with standards, learn how to write for the Web, talk to your users, keep your design simple and then, and only then, think about adding those special features that your users probably don't need or want.
On a related note, we've convinced several friends to try Mozilla, only to later hear the now tired refrain: "Some sites just don't work in Mozilla." It's a source of neverending frustration for us that these friends blame the browser and give up on it, never knowing the true source of their dissatisfaction.
D. Keith's comments (and the article that inspired them, Why personalization hasn't worked, by Gerry McGovern) relate perfectly feelings we've had for several years. We vaingloriously believe it will be a good day for the Web when large organizations start thinking like us small-timers.
The conversations inspiring (and inspired by) FDML, a proposed "list of feeds" format, are quite interesting, especially those debates concerning feed auto-discovery. In September Jeremy Zawodny noted two possible auto-discovery methods:
I see two obvious ways that could happen.
The file, like /robots.txt could reside at a well known location with a well known name, say /feeds.opml or /rss.opml? This has the advantage of being very simple.
We add a new, optional <link> tag that tells tools where they can find a relevant OPML file that contains information about the various feeds offered. This has the advantage of being like what we do today and it provides a bit of flexibility.
Tim Bray sufficiently argues against option number one, noting that we shouldn't start grabbing namespaces, especially this early in the Web's development. Joe Gregorio agrees, deriding current namespace hogs robots.txt and favicon.ico. On a related note, Dave Winer considers a "folder for metadata" on the grounds that reserving one name (for one folder per site) is a small cost with lots of benefits. We'd agree if we had any reason to believe future generations won't find an excuse (like Dave has) to steal more names. Reserving namespaces should be avoided as a matter of principle.
Kalsey Consulting Group acquires the BlogSnob text ad exchange; Jacques Distler offers some relief to Movable Type users hit by comment spam; Max Design demystifies CSS floats in Floatutorial; emusic.com annouces that they'll no longer offer unlimited downloads; Sam Ruby proposes FDML, a format for providing a list of feeds; and Accessify introduces us to accessibleNet.org, a fine Web accessibility resource.
A while back we linked to Joe Clark's measured plea to ISSN registrars to allow weblogs in their records. Joe notes that once your weblog is in the international database of publications, anyone will be able to find it by, say, asking a librarian to look it up. Richard Rutter emphasizes this benefit in his notes on reappliying for an ISSN (after having been previously turned down), noting that "weblogs have already been quoted by book authors and referred to in academic papers and syllabi." He adds: "An ISSN would enable sites to be uniquely identified and cited in a consistent and accurate manner." We couldn't agree more.
We'll be following Richard's application to the British registrars and filing our own application here in the United States.
Simon Jessey annouced yesterday the official launch of his Web design company. We were astonished by the volume of information available at his company's site, which includes XHTML and CSS histories, and a glossary of common Web terms.
And it validates.
Speaking of which, we were wholly unsurprised by the results of Tecknetix's recent design challenge, which tested the Web sites of fifteen design firms for compliance to Web standards. Of the fifteen, nine had no doctype, six specified no content encoding, and none validated. Tecknetix sums it up like this:
I'm reminded of a child's riddle -- you are new in town and in need of a haircut. You approach the two barbers in town who happen to have their shops beside each other. One barber is sharply dressed with a million dollar haircut; the other is dressed casually with a ragged haircut. Who do let cut your hair?
Flash or substance - you choose.
Postscript
We'd be remiss not to point to Joel Spolsky's most recent article, The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), which, though not explicitly related to topics discussed above, is worth linking, nonetheless. Enjoy.
Standardice uses CSS to mimic magazine layouts; Ethan Marcotte, along with everybody else, talks about the effects of the Eolas ruling; Six Apart officially launches TypePad; Tantek Celik shows us how to pass external style sheets to 5.x versions of Internet Explorer only; Tim Beadle curates the validation Hall of Shame; Mark Pilgrim releases Dive Into Python 4.4; and serendipity lands us at the Best of CNN photoblog.
We've noted before that we don't use RSS to keep track of our favorite sites. We prefer blo.gs for two reasons:
On the other hand, we syndicate this site via RSS and Atom, write about RSS, and support its growth. We do this because we believe its potential stretches beyond a weblog updates service (and, in all fairness, because more than four times as many of our visitors access our recent content via aggregators than via browsers). Yahoo's new personalized RSS feeds, built on keywords you provide, are evidence of this potential. Tracking specific names, companies, topics, and so on, is far more useful than simple notification that a site has updated. As Simon Willison pointed out, Yahoo isn't the first to do this, but they're certainly the biggest. Time to scrape the dust off our aggregator.
Charles Miller convinced us tonight on IRC that RSS probably wasn't a target of Ian Hickson's comments on client-side transformations. We interpreted too literally, we think, Ian's comments on 'proprietary' formats. Though RSS is, by definition, a proprietary format, Charles correctly noted that it is also an open format.
In any case, we're having second thoughts about styling RSS via client-side XSLT. For one thing, we're worried that aggregators may attempt to interpret XSLT. We want to style RSS for the browser; we don't want styles in aggregators. Uncertainty is holding us back.
We'd love to hear your thoughts. We'd also appreciate any information regarding aggregator support for XSLT.
Ian Hickson shows why XSLT on the client side can be a bad idea. In Ian's words:
Transformations should be done on the server side, so that what is sent over the wire is in a well-known format (HTML, MathML, etc). The UA can then decide whether to display the content using the author's styling hints (CSS) or to display the content using its own rules (as Lynx does, as Opera typically does on hand-held devices such my mobile phone, as voice-based browsers do, etc).
Sound advice, to be sure. But we're careful not to rule out client-side transformations altogether. We still support transforming RSS feeds into usable documents via client-side XSLT. After all, RSS is practically useless in the browser without transformations. We recognize that this is probably obvious.
Update: After re-reading the above section of this entry we feel compelled to clarify. Server-side transformations are desirable; we submit only that it's worse to serve an unstyled, unformatted RSS document to browsers than to transform such a document client-side. We were worried that some developers may not realize that RSS is really a proprietary format. If you were going to send RSS over the wire anyway, you might as well transform it for browsers (especially if you are incapable of doing so server-side). Lynx wasn't going to be able to handle it, anyway.
In other news, Ben Trott announces XML::Atom, a Perl implementation of the Atom API; Anil Dash interviews Paul Bausch; Adam Kalsey helps his kids understand what he does for a living by helping them do what he does for a living; Ben Bishop releases Aura, a set of standards-compliant site templates; The WaSP points to The Bare Bones, No Crap, CSS Text Control Primer, by Wendy Peck; and James Robertson links an excellent article by Henrik Olsen most accurately described by its subtitle: How visual simplicity can harm usability.