Earlier this month we pointed to Jacques Distler's mini-treatise on marking up abbreviations in HTML. Lars Holst's Abbreviations, Acronyms, Initialisms echos the conventions suggested by Jacques, supplying extensive research along the way. Lars has written the definitive piece.
Jacques, nail. Lars, hammer. Coffin, shut.
First Jason Kottke argued that semantics and standards aren't the same, to which the design community responded, for the most part, by collectively wondering if anyone had been arguing that they were.
Now D. Keith Robinson's More Important Than Web Standards argues that there are aspects of Web design negligibly affected by the pursuit of standards:
I would also assert that whether or not a site is tableless or validates, in general, has absolutely no impact whatsoever on the success of a Web site.
Here is a list of some things that I feel are more important than Web standards:
- Clear, concise and measurable goals
- A solid information architecture
- Clean, functional and user-centered design
- Well thought-out, audience appropriate content
- Interaction with your users/readers
And here we are again, scratching our heads and wondering who it was that argued in the first place that the above goals are less important than Web standards. Jeffrey Zeldman writes:
Using markup and style sheets correctly doesn't make your site compelling, attractive, well-written, or easy to navigate, and nobody claims it does. Building with standards is simply a baseline. Who claims it is more than that?
It's possible to give attention to every item on Keith's list and follow Web standards. And why wouldn't you? Standards make our lives easier, not harder. That's why some of us in the community are passionate, maybe overzealous, about their use. Standards don't do it all, but they're a great place to start.
Paul Hammond's thoughtful letter to "tabless recoders" -- those who redo table-based sites in CSS -- is the best thing we've read this week. Paul makes the important argument that designers who have had their sites redone will feel far from flattered, even insulted. But the piece makes its most meaningful point near the end:
There's one other little thing: CSS can do so much more than tables ever could, and your work is showing none of this. In fact, it's hinting at the opposite, that CSS doesn't give us any new toys to play with and people can probably get away without learning it, as long as nobody looks at the source.
Paul's right; it's the original CSS projects, like the CSS Zen Garden, that spread unstoppably through the community, inspiring and challenging scores of designers. And providing inspiration is what anyone claiming to be an ambassador for CSS should be doing.
For your enjoyment: Guide to an Effective Weblog (For Web Designers).
We identify with Drew McLellan's thoughts on being listed, along with us and several others, as an example of what Joe Clark calls International Compliant Style:
I guess to be cited as an example means that I have executed my design style well. My site is in the IC-Style, not emulating it. That has to be good.
On the flip side, Joe is saying that my design is a mass-produced unoriginal. That said, simple, clean, easy-to-read and 'less is more' are hardly original concepts, so I'm pretty happy in my unoriginality.
One of Joe's observations in particular struck a chord with us:
Just as you'd expect Republicans to be guys who wear dark suits and Saab owners to recycle, it wouldn't surprise you to learn that designers and developers concerned with doing everything just right are unwilling to fuck up their layouts, make their sites hard to read (except for the preponderance of grey type), or even dabble in the demonic underworld of the colour palette.
We know what it's like to obsess to the point of fearing new design elements. It's hard enough following a simple aesthetic.
Oh, and it made our day that Joe Clark -- that Joe Clark! -- noticed our little weblog.
In Thursday's entry, Styling RSS with XSL, we said:
Unstyled RSS isn't particularly useful when viewed in a browser. Styled feeds, on the other hand, include accessible links.
Anne van Kesteren uses XSL to transform RSS LINK elements into actual links, but there's more than one way to do it. Bill Humphries points us to an Apple Developer Connection article that offers another solution: the DOM.
In an interview shortly following espn.com's redesign using Web standards (An Interview With Mike Davidson of ESPN), Associate Art Director Mike Davidson cited reduced file sizes as an immediate benefit:
We reduced the size of our front page code by about 50%, and by using absolute positioning, we are able to display important parts of the page before other parts may have fully loaded yet.
In Jeffrey Veen's fantastic new article for Adaptive Path, The Business Value of Web Standards, Veen also lauds reduced file sizes as a quantitative effect of using standards:
When we stripped away the fonts, tables, and little images used as design elements on our home page, we reduced the size of the code from 20.9K to 9.2K. Now, this may not seem like a lot, but it would aggregate to quite a bit if our site generated heavy traffic.
It's nice to see the design community expressing the economic benefits of Web standards. If businesses aren't impressed by increased accessibility, simplified maintenance, or faster downloads, we think they'll warm to the idea of saving money.
Two days ago Anne van Kesteren noted that he's now using XSLT to serve a formatted and styled version of his RSS 2.0 feed to browser visitors. Russell Beattie admits this morning to recently seeing this technique for the first time at allaboutsymbian.com. We like the idea for two reasons.
Unstyled RSS isn't user friendly when viewed in a browser. Russell says it best:
Having links on pages to RSS for those who have no idea what RSS is, is a real user-unfriendly thing to do. The monkies don't like when they click on links and receive a boatload of XML in their face.
A styled feed will surely make more sense to the novice user.
Barring any incompatibilities -- we're looking into it -- we'll be styling our feeds shortly.
Intersmash Design Challenge Number One charged designers with duplicating the print effect of, in the contest's words, "an image nestled between two columns as the text effortlessly glides around it on both sides." Daniel Sheppard's winning entry is worth a look.
Also, we've finally made good on our threat to use more friendly URLs. This is the first post to make use of "slugs" similar to those used famously by Mark Pilgrim.
Bob Easton's discovery that screenreaders will almost always skip content hidden to visual browsers via display: none, including skip navigation links, turns out to be not much of a problem thanks to techniques introduced by Jon Hicks and Tom Gilder. Problems arise. The community fixes 'em. Of course, this would be a nonissue if we'd all followed Joe Clark's advice:
You're not going to like this, but to make a lengthy list of links accessible, your "Skip navigation" link must be visible. It doesn't have to be intrusive, but it has to be apparent and self-explanatory in all browsers.
In comment spam news, earlier this month Simon Willison created a simple blacklist for blocking spammers, a technique that's previously been used to solve a similar problem, and that's now garnering some support. Other proposed solutions include distributed systems that look for identical comments across several sites (a logistical nightmare), and simple visual tests that can't be passed by automated systems (an accessibility nightmare). It's been almost a year since the last round of comment spam discussions. But we're all still waiting for things to get worse.
Jacques Distler's "<abbr>, <acronym>, Accessibility & Automation" presents thoughts on the perennially discussed subject of marking up abbreviations. Many have argued that lack of Internet Explorer support for <abbr> is reason enough to markup all abbreviations (acronyms and initialisms) with <acronym>. Jacques disagrees: "...if these two elements are to be treated differently by aural browsers, then, on Accessibility grounds, you should be mindful of using the right one in each case."
In addition to using <abbr>, Jacques points out that it is necessary to markup all occurrences of abbreviations, not necessarily to provide definition, but to give cues to screenreaders. Jacques's technique for achieving this bears repeating here:
The best way to achieve these varied goals is, the first time you use the abbreviation, to give its definition,
<abbr title="Cold Dark Matter">CDM</abbr>, but on subsequent uses, to merely mark it up as<abbr>CDM</abbr>. This will satisfy the screenreaders, and can be hidden from visual browsers with code like
abbr, acronym {border:none;}
abbr[title], acronym[title] {border-bottom: 1px dotted black;}
Our practice in the past has been to provide any abbreviation's definition on only its first occurrence (in any context, like, say, a weblog entry) with <acronym>, a method, as Jacques mentions, that meets WCAG. Jacques has convinced us to embrace <abbr> and mark all abbreviations, not simply first occurrences.
Evan Goer has said about Jacques that he believes he "may well be the only person on the planet who understands the XHTML 1 specification and uses it properly." We're glad he's helping the rest of us get it right, too.
CSS Zen Garden curator Dave Shea posted today about an unfortunate struggle with someone who, in his own words, has been "using the [Zen Garden] designs wholesale (graphics and all)" and who "continues to grow more belligerent with each new e-mail." Keith Robinson asks: "Whatever happened to professional pride and the desire to do what's right?" Obviously, Dave's pest lacks these qualities. But what he's doing, despite Dave's protests, is wholly protected by the Zen Garden's Creative Commons Attribution-ShareAlike license. The license is unambiguous in allowing artists to reproduce a work provided attribution is given.
We're not commenting on Dave's situation to choose sides. We'd merely like to bring focus to two important aspects of Creative Commons licenses we've given thought to in the past and that have come up as a result of the discussion at mezzoblue. (Keep in mind that we're not lawyers. What follows should not in any way be taken as legal advice.)
Creative Commons licenses are inclusive. Additional provisions are irrelevant. From the Attribution-ShareAlike 1.0 license, section 8e:
This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.
Creative Commons licenses are perpetual, irrevocable. From the Attribution-ShareAlike 1.0 license, section 7b:
Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work).
In other words: A license from Creative Commons is final and forever.
This isn't the first time someone has found problems with a Creative Commons license after using it; Jacques Distler called it quits after Dan Bricklin pointed out liability issues. These cases underscore the need to fully understand a license before using it. It's fruitless to complain later about use for which you've explicitly granted permission.
The html element's id attribute, we recently discovered, is missing from XHTML 1.1. Anne van Kesteren noted today that it is possible to use the id attribute on the root element by extending XHTML's DTD. Adding attributes, it turns out, is quite easy. Anne's solution:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/tr/xhtml11/DTD/xhtml11.dtd"
[ <!ATTLIST html id ID #IMPLIED > ]>
We're using this fix to include our CSS Signature in XHTML 1.1 documents.
The Web Standards Project hinted today that they'll be imminently focusing on XHTML:
With all the attention being given to what should be an old issue, it's becoming clear that we require better information in order to make good choices when it comes to the languages we use to author our documents. So backroom discussion this week at WaSP has led us to the decision that we should dig more deeply into XHTML: Why it is, what it's best used for, how to use it properly, what the differences between versions are, and what XHTML 2.0 will bring (or deny) us.
We can understand why the WaSP thinks that using XHTML properly should be an old issue, but can't imagine why anyone would think that it really is. The meager number of valid XHTML sites, we think, is an obvious indication of a lack of community understanding. Many of us are using XHTML incorrectly. Almost all of us are serving it incorrectly.
An important point made by the WaSP -- a point we've tried to make here -- is that conforming to Web standards doesn't mean conforming exclusively to XHTML:
Choosing to author to standards really means understanding as much of a given specification as possible, using it intelligently, and validating documents to test for conformance. Whether you're using XHTML 1.1 or HTML 3.2 to do this is really irrelevant.
The WaSP should begin serving its own XHTML documents with the proper MIME type, or prove that it believes one standard is as good as another and revert to valid HTML 4.01.
Bonus CSS Links
In Making the Absolute, Relative Douglas Bowman explains a notoriously misunderstood CSS technique: absolute positioning.
Listamatic is a fine collection of CSS tabs.
In Bulletproof XHTML, the most recent installment of Dave Shea's A Second Voice, X-Philes maintainer Evan Goer writes:
The lack of XHTML applications has a more insidious effect in that it raises the cost/benefit ratio for converting to XHTML. We can convert, but most of us won't be doing anything with it -- the benefit is low.
The cost of converting to XHTML is indeed high. And, let's face it, we're not currently using specialized markup (like MathML) that would be inaccessible with HTML. So, why do we use it? Two reasons immediately come to mind:
application/xhtml+xml to browsers that support it, we're forced to create well-formed documents. There are no free passes. Every entry to our weblog must contain well-formed markup. This is a feature, not a bug, of XML.We are able to realize the above benefits, please note, only because we're using the proper MIME type to serve our XHTML documents as XML. XHTML as text/html, we've come to understand, is largely useless.
Evan, again:
In short, switching your site to XHTML is not a no-brainer, and the trade-offs and decisions only multiply when you get down into the details. Each designer must weigh these costs and benefits individually. There is no "right" answer.
Anne van Kesteren's weblog has been home lately to a few fantastic posts related to important differences between XHTML 1.0 Strict and XHTML 1.1. We're repeating a few here for future reference.
Media Types
From the W3C's August 2002 note on XHTML Media Types:
'application/xhtml+xml' SHOULD be used for serving XHTML documents to XHTML user agents. Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as 'text/html' and XHTML documents as 'application/xhtml+xml'.
Specifically of interest is that XHTML 1.1 SHOULD NOT be served as text/html.
Further Reading:
text/html and application/xhtml+xmlCharset
From XHTML Media Types:
Therefore, while it is STRONGLY RECOMMENDED to specify an explicit charset parameter through a higher-level protocol, authors SHOULD include the XML declaration (e.g. <?xml version="1.0" encoding="EUC-JP"?>).
And from the XHTML 1.1 spec:
XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16.
Further Reading:
Stylesheets
From XHTML Media Types:
The XML stylesheet PI SHOULD be used to associate style sheets.
Further Reading:
meta http-equiv
From XHTML Media Types:
Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/xhtml+xml' as well for that matter).
Jacques Distler asks: "Is it bogus just for setting the content-type and charset, or are all such declarations bogus?" There's every indication that this rule applies only to setting the content-type and charset.
Further Reading:
<html> id attribute
From a post to www-validator@w3.org
XHTML 1.1 is based on XHTML Modularization and thus disallows <html id='...' ...> XHTML 1.0 *Second Edition* had been changed in this respect and allows the html element to have an id attribute.
Further Reading:
<html id=""> by Anne van KesterenWe use Anne van Kesteren's solution -- an internal subset of the DOCTYPE -- to extend XHTML. There has been some question as to whether browsers, Internet Explorer specifically, will resort to Quirks Mode in the face of custom DTDs or extended DOCTYPEs. (Keep in mind that Gecko browsers SHOULD, in the parlance of the W3C, get documents served using the application/xhtml+xml media type, which invokes Standards Mode in those browsers every time.) This is most likely not an issue. Much more information on this subject is available: Extending XHTML: Target and Strict.
You may also get some mileage out of this list of changes to XHTML between versions 1.0 Strict and 1.1.
We'll add to this list if necessary. For the record, the XHTML 1.1 version of our home page currently meets all the above requirements