In the linkdump to end all linkdumps, Joe Clark has posted a massive list of bookmarks for standards and accessibility testing. With links covering everything from color deficiency to progressive enhancement, Joe's bookmarks are worth poring over for an hour or eight — an excellent, exhaustive resource.
Patrick Griffiths points out a few flaws with those thinking that tables are easier for layout than Cascading Style Sheets (CSS), in his entry, Tables My Ass.
One myth is that CSS is 'hard'. It isn't hard. Well, not any more difficult than any other approach. The problem is that experienced web designers started out by using tables for layout and then had to completely change their approach to do things the CSS way.
In the comments following this piece is a nice resource for form layout, which shows tables may not be necessary when designing forms.
Cameron Adams, offers up his Accessible, stylish form layout (24 March 2004) which includes a link to Form Layout Templates an experiment and tool to show how forms can be manipulated into columns and orientations with CSS. Comments following the entry offer additional resources well worth checking.
Last week, Google reignited the syndication wars by relaunching Blogger with support for the Atom syndication format and API in the free service, but RSS support only in the paid Blogger Pro. A few days later, the W3C fanned the flames by offering Atom a home. Some, including Microsoft über-blogger Robert Scoble, have asked the WaSP to help firefight.
While the WaSP members are still considering an official response, it looks to me like this boils down to two would-be standards in a pissing contest, and I didn't join WaSP to referee the urination olympics. I joined because I was tired of pissing contests, tired of having browser makers pee on my head and tell me it was raining.
WaSP, for me, is about saying "you helped make the rules, now play by 'em. No buggy, incomplete implementations and no proprietary gewgaws that prevent me from authoring to a standard and having my document work in every app that claims to support that standard. No peeing in my pool."
Same goes for content authors: you wanna use proprietary gewgaws, fine. Do that. Just don't take a standardized technology like HTML and cobble it into some unholy mess that just happens to work on your favorite browser and nowhere else. No peeing in the pool.
In the case of the syndication wars, it isn't at all clear to me whose pool is getting peed in. It looks to me neither of the contestants is a standard yet—and there's the rub.
In the end, it doesn't matter one iota if there are one, two or ten formats available. Network effects will sort the winners from the losers and eventually people will settle on one—or a few, if there's a need (GIF and JPEG, for example, coexist because they do different things).
What matters is that whatever formats get used are unencumbered by licensing issues and are maintained by an org that can reasonably claim to approximate an industry consensus within its committees.
The first matters because licensing costs and intellectual property issues make usage prohibitive for hobbyists and raise barriers to accessing the information encoded in those formats.
The second matters because it reduces the chance the format will be driven by the needs of one company or developer at the expense of others and help prevent the format from being hijacked for stupid reasons (like, say, driving an upgrade cycle).
Thus far, neither RSS nor Atom qualify, though both are moving in that direction: Atom is pursuing adoption by the IETF, and as mentioned above has been asked to join the big W3C tent. Dave Winer has transferred the RSS 2.0 specification to the Berkman Center for Internet & Society at Harvard Law School, who have in turn released it under Attribution-ShareAlike Creative Commons License. Dave has also established the RSS Advisory Board to oversee and promote the development of the specification—an interesting approach, but one that appears to lack a mechanism for broad representation of those with an interest in the spec.
When Atom actually gets its working group in the W3C or the IETF, or when RSS gets the sort of stewardship that can reasonably claim to have attained a broad consensus, then I'll feel differently. Until then, speaking only for myself, I say keep your pissing contest outta my pool.
In Non-Standard Code Hurts The Bottom Line, D. Keith Robinson highlights some of the long-term perils of failing to adhere to established standards for web development.
It can be tempting to view web standards only in terms of the initial development process - and it's this perspective that can lead to the belief that strict adherence to standards is more time-consuming than conventional methods. In a lot of cases this can be true - it's often much quicker to hack a page together any-old-how than to worry about dotting the I's and crossing the T's. However, it's necessary to take a long-term view to see how such development practices can wind up costing more, if not costing the entire project.
Keith highlights some of the real-world problems he has encountered on his projects and concludes that web standards are not only his bag, baby, but should be yours too. And who's to argue with a conclusion like that?
If content is king then valid pages must be the poor suckers down in the dungeon. The Webby winners were announced today, and while certainly some of the most content-rich, culturally valuable, and technically helpful sites are on the roster of winners, there is only one valid home page among 'em, and that's the site for the blogging tool, LiveJournal.
Two sites came very close, our friends at Fray just need [make that needed - they fixed it after reading this post!] to add the
type attribute to their
script element to fix the problem. Fedstats.gov has two instances of the value
"absmiddle" in an HTML 4.01 Transitional document. Get rid of that, and they're good, too.
Unfortunately, the remaining 50 some-odd sites are suffering from multiple conformance problems, some more serious than others. But instead of downplaying the importance of these great sites, better to see what we can learn from them to improve our markup practices.
The majority of problems found demonstrates common issues developers are either unaware of or struggling with currently. It's important to point out that often these problems do not originate with the site developers, rather, the content management systems and ad servers they are using.
Whether we're developing sites or CMS solutions or ad server markup, we all need to get our proverbial acts together. The good news is that most of these things are easy to repair. Common problems found on Webby Award sites include:
- No document encoding. Ideally, encoding is done on the server. But there are alternatives, and while the lack of encoding isn't specifically an issue with validation, it should be addressed. This helpful WaSP asks the W3C will explain why.
- Encoding mismatches. This problem is popping up more and more now that the W3C's validator has been upgraded. What this means is that the encoding on the server is conflicting with the encoding in the document. If you have the appropriate encoding on the server, please do not add it to your document via the
DOCTYPE. This may well be the most common error with all non-conforming web sites on the web today. Including a
DOCTYPE cannot be seen as frivolity, but as necessity. They are necessary for validation, and in those browsers with
DOCTYPE switching, they provide developers with a means to offer those browsers standards-compliant rendering.
- Use of
language attribute in
script elements. The
language attribute was deprecated in HTML 4.01 and should not be used in HTML 4.01 Strict, XHTML Strict, or XHTML 1.1. The only problems removing the
language attribute in
script elements could cause involve much older browsers, so in almost every contemporary case, just get out of the habit of using it. Do be sure, however, to include the
type attribute in
style elements. The
type="text/css" value is required in the
style element: <style type="text/css"> . . . </style>
alt attribute. C'mon people now, smile on your sister over here. Just how long are we going to have to fight this battle? Make it easy on yourselves, if you've got an image, include the
- Mixed HTML and XHTML syntax. This one is an interesting issue I'm seeing pop up a lot. It's likely that many sites are in the process of conversion and simply haven't updated their syntax in certain documents. But I have a nagging doubt in my mind that part of the problem might be arising from documents that are being worked on by numerous people, and there's no style guide for the site to help guide their practices.
- Proprietary attributes for presentation such as
leftmargin in the
body element. Only in very few cases should we fall back on proprietary attributes. CSS is a far smarter, better means of managing presentation. Even if you have to support older browsers, clever use of very streamlined tables for layout along with CSS can reduce or eliminate the need for these types of attributes.
- No escaping entities. Also an extremely common problem, if you're using XHTML, you'll want to escape any ampersand in URLs or embedded scripts: www.mysite.com/blah&story.html becomes www.mysite.com/blah&story.html. This will not affect the link or script performance, but not escaping the ampersand in XHTML documents will definitely cause your documents to be invalid.
Congratulations to all the Webby winners. The content and design of many of the winning sites is worthy of royal acknowledgement. Correction of these common errors is a prize worth fighting for despite those royal honors, resulting in more accessible, usable, fast-loading and compliant sites.
I18n — you may have seen this abbreviation before, and you might even know that it stands for 'Internationalization', but do you know how to do it?
With 3 new Working Drafts published over the past few days, the W3C has begun addressing content authors directly via their Internationalization GEO program. (This means you.)
The "Authoring Techniques for XHTML & HTML Internationalization" set includes: "Specifying the Language of Content", "Characters and Encodings", and "Handling Bidirectional Text".
Unless you enjoy reading technical documentation in your spare time, just bookmark these for the next time you're asked to work with non-English content. They'll be indispensible then, and probably not a moment sooner.
Blogger, Google's popular weblogging service, has just been thoroughly redesigned — and after looking under the hood, it becomes quickly apparent that they've drunk deeply from the web standards kool-aid. In their own announcement of the redesign, Blogger notes that their new blog templates are
all CSS based, standards compliant, and usability tested.
Needless to say, we're darn impressed.
Doug Bowman, whose Stopdesign agency architected the redesign alongside Adaptive Path, has an in-depth and insightful post on the new Blogger.
Old news to some no doubt, Richard Rutter reveals that the DOM Inspector built in to Mozilla can be used for, among other things, sniffing out CSS bindings.
Ever been stuck looking at an element and scratching your head wondering which, exactly, of the 20 possible cascading style rules is affecting its positioning? This is for you. Simple, elegant, and probably already installed on your computer.
Those who have followed the WaSP for several years will remember the Browser Upgrade Campaign, a spirited attempt to get rid of old, weak, and infirm browsers that lacked support for Web standards through encouraging people to upgrade to new, strong, and healthy browsers with strong bones and a shiny coat and decent support for Web standards.
However well intended in theory, in practice, the tools we provided were often used (and abused) to deliver a resounding “screw you” to people who, like all of us, were just trying to use the browser they had to get a job done. No more evident is this sort of sad event than in our abuse mailbox, where we have received a small, but steady, stream of incomprehensible messages from the customers of banks, cellphone companies, and the like, who are just trying to pay their bills or get help with a new ringtone.
For example, this message just came through today:
From: firstname.lastname@example.org (Bob Morley)
Date: Fri, 7 May 2004 06:48:45 -0400
Subject: PROBLEM GETING INFO ON WIRELESS ACCOUNT
WHATS 109 SEE CINGULAR.COM
MEAN MY PHONE SAID 109 SEE CINGULAR.COM BUT IT WAS
Sadly, we tried to contact Cingular by the usual role accounts the last time this sort of thing came through, and the messages bounced.
You see, it’s not just Web standards that need to be supported, it’s basic Internet conventions, too. Like having and monitoring postmaster, abuse, and webmaster accounts in any domain that supports email or Web service. Or, barring that, providing some contact information on said Web site.
And, in case it’s not clear yet, it should be possible, in this age of Web-browsing cell phones, for a paying customer to visit your Web site in any browser they choose, and for them to get useful content, not a slap in the face for using the very products they’re presumably paying you to use.
For shame, Cingular, and everyone else who has failed to observe basic Internet conventions and Web standards, for shame for telling paying customers they can’t use your Web site with the browser you gave them.
Announced today, the W3C has released a big upgrade to their popular markup validation service:
(The new release) features new documentation and navigation, and offers helpful explanations and recovery mechanisms instead of fatal errors.
To the unpaid volunteers who maintain our trusty steed, a big round of thanks and praise for making it better.
In a nostalgic nod to the past, John Allsopp of WestCiv praises they that went before us as he pays respects to a small group who worked with CSS before CSS was workable.
Message To The Messengers sheds some light on the work done in the late 90's by a crew that eventually formed WaSP's own CSS Samurai. An interesting read for those of us who came after, and a nice memory jogger for those who were there.
This one's for anyone in search of a standards-compliant, in-browser XHTML editor for their CMS (or weblog tool, or webmail client, or... you get the idea)
XStandard was built with standards and accessibility in mind:
XStandard manages rich content in any language, has strong accessibility features, and supports popular editing options including tables, wrapping of text around images, and file drag & drop into the editor.
Sounds good. Must be expensive? It's not, and even if the license is too much for your project, a Lite version is available free of charge.
Once you've got your copy, head on over to Accessify Forum, where they've set up a special XStandard support forum.
While we all know a big goal of the W3C's work is to separate our presentation from our document's structure, Matthew Thomas points out that sometimes the proper elements to do the job don't exist.
When semantic markup goes bad showcases logical flaws in, for example, replacing all instances of
<b> elements in your markup with
It's true, the proper elements for the job don't always exist in the various flavours of HTML and XHTML. Your approach in dealing with these cases will vary depending on how you see the world. What's clear from Matthew's analysis is that simply steamrolling ahead with global use of
<strong> is the wrong approach.
Mark Pilgrim's been diving into using CSS to style his Atom feed. He's got an interesting discussion about what he's done plus examples on his weblog. But you have to use a real browser to see it work - I'm sure you're all as shocked and surprised as I am to learn that bit of news.
Down under, The Web Standards Group is busy as ever with their new “Ten Questions” interview series in which lots of famous people are interviewed about issues facing today's web designers and developers.
This week, learn what Keith Robinson, Editor-in-Chief of Digital-Web Magazine has to say about editing a major web publication, reverting to table-based layout in sheer frustration during a design project, and what he refers to as “The Golden Triangle.” I'll leave you to follow the link and find out exactly what Robinson means by that.
Also, take a look at a new article by Trenton Moss, What is Web Accessibility. The title of the article is a bit of a misnomer because the author never actually defines web accessibility, leaving that to the Pilgrims and Clarks of the world. Poor titling aside, Moss does a nice job of categorizing the types of needs that should be addressed when building accessible sites.
Looking for a web standards job?
This morning while reading an unrelated article about finding a job that suits work standards, I thought why not use Google to find openings for web standards jobs? My Google search terms, *job openings web design standards guidelines accessibility* returned results that included The Web Accessibility Center (WAC) at Ohio State University's website.
The WAC deserves some recognition. The center offers web design assistance for faculty, staff, and teaching assistants via news, training, and presentations. There are several good topics and resources listed.
In the News and Events area, an upcoming presentation, Intelligent STEPs to Redesign and Retrofit, will show that by using the Section 508 STEP tool, it is possible to fix an existing website without starting over from scratch. STEP508 means “Simple Tool for Error Prioritization” and helps you find crucial pages or areas within a site that need conversion or attention first. There is also a site report and progress function to the tool. Training schedules, more information, and download(windows) for STEP508 are avialble at the Section 508: STEP508 web page.
Refine those skillsets! Another real benefit for learning and using web standards, guidelines, and accessibility is preparation for working in the field with added experience that will be needed by many, finding that job that fits your standards which benefits all.
Ohio State University - great work. It would be good to see more educational institutions on the same path.
Related: Tools helpful for site repair and or standards can also be found at the W3C QA: The QA toolbox page.
The Synchronized Multimedia Integration Language (SMIL) - pronounced smile - is an XML-based W3C specification that offers numerous creative and practical uses for web-based multimedia applications. But, SMIL has been frowning along for years now with no significant activity or momentum.
If you've been wondering whether SMIL was headed off to that great idea that was never implemented spot in specification heaven, you're not alone. Fortunately, the W3C recently announced the relaunch of the Synchronized Multimedia Activity (SYMM). Hopefully, this will give web developers interested in creating compliant multimedia reason to smile again.
You can read more about SMIL at the Synchronized Multimedia page at the W3C. The multimedia company Real, most well-known for its early entry into the web-based multimedia marketplace, has a developer section on SMIL that provides tutorials, samples, and tag references.