Coding with Jesse

Web Standards, Best Practices, or Professionalism

Over the last few posts, I've been trying to redefine "Web Standards", or rather, expand the definition to include things outside the validation of HTML and CSS. I wanted to talk about the larger picture of doing things the Right Way. Then, Jim left this comment:

Please, do yourself a favour and stop treating "web standards" as a meaningless buzzword that you use as a synonym for "code I like". [...] It means one thing and one thing only: to comply with rules described in "the" standards (in reality there's many standards to choose from).

I have to admit, he's absolutely right. "Web Standards" refer to the actual specifications for web technologies, notably HTML and CSS. Indeed, the Web Standards Project are only advocating adherance to the W3C Standards for XHTML, XML, CSS, etc.

I asked Jim for a better term, and citing this blog post he suggested "Best Practices". This really expresses the intention here, that we should be doing things a certain way because it's the best way.

I've been thinking about this a lot since, and went back to Molly's infamous post where she coined the term "New Web Professionalism" to describe this Right Way Of Doing Things. This is just expressing the same concept in different words, and it's never the words that matter. It's what the words represent. As an industry, we need to encourage a certain level of quality, a certain, shall we say, standard.

So, Web Development Best Practices? Web Professionalism? Web Professional Standards? I hate buzzwords as much as anyone, but it seems like we need one here, some piece of jargon that lets everyone else understand what it is we're talking about. Don't we?

Then again, a buzzword is the last thing we need here. It would only distract from the underlying point. We can still refer to Accessibility, Web Standards (that is, valid HTML and CSS), Semantic Markup and Unobtrusive Javascript. And by doing so, we won't forget what it is we're talking about. We won't end up with some empty marketing speak promising something as vague as "Best Practices" when they have completely ignored Accessibility.

I won't go so far to rename my last posts, but for now on I will be much more clear when I talk about these and other Best Practices, and will forever hestitate to throw around the term Web Standards to mean anything except valid code (which, to be honest, is the least interesting topic amongst Best Practices).

Published on February 9th, 2006. © Jesse Skinner

How do web standards benefit visitors?

Why do web standards matter? It's easy to say that web developers who ignore standards are unprofessional, but it's not so easy to explain why.

(If you haven't yet, read my last post to see what I mean by 'web standards'.)

Web standards are fun, cool, exciting. Right? This might be reason enough to use them on your own web sites, but you won't be able to convince your clients to use them just because they're cool (that is, unless your clients really wants to impress their web developer friends).

What do your clients care about? Visitors, of course. The people actually using the web site. If they don't notice a difference, what's the point, really? Sure, your visitors might judge your web site with the W3C Validator, but face it, only other web developers are ever going to view source. On this web site, my visitors ARE web developers. But what about the 300 billion other web sites?

Now, hold on a sec, I didn't just say we should go back to designing with nested tables and invisible GIFs! I'm just saying we need to focus on the goal here: benefiting our visitors. So how do web standards benefit our visitors?

  1. Faster web pages.

    The site will download faster because the HTML will be smaller. If there is a single external CSS file for the entire web site, visitors can download it once and cache it, making the whole site download faster. Also, browsers can draw borders and background colours using CSS a lot faster than downloading border and background images.

  2. Usable by more visitors.

    If you've separated design from content, users without CSS can still get the content and use the website. If you've separated the site's behaviour from the content, users without JavaScript will still be able to use the site without a problem. If you addressed accessibility, you allow visitors with disabilities to access the site. The last thing we want to do is turn visitors away just because of how they choose to surf the web.

  3. Search Engine Optimization.

    How can people benefit from your web site if they can't even find it? (That is, unless your web site doesn't benefit them at all, in which case web standards aren't going to make any difference.) The search engines don't award points for design. All the extra tags and attributes will just distract away from the content. Using text instead of images and using semantic HTML (especially h1 tags) lets the search engines better index the content and interpret the structure, and this will help the page rank higher in search results.

These should be reasons enough to stick with web standards when creating web sites, and certainly enough to convince sceptical clients that web standards are the best choice. Next, I'll list some ways using web standards benefit web designers and developers.

Update: When I say 'web standards', I really mean 'Best Practices'. Read more here.

Published on February 1st, 2006. © Jesse Skinner

The Standard Web

I'd like to talk about web standards in the future, but I realised I need to first define what it is I'm talking about. So, this is what I mean by using 'web standards':

  1. Make sure your HTML and CSS validate.

    The point is simple: if you're using a standard format, use it correctly. However, just because your page is valid doesn't mean it's perfect. For this, the W3C's HTML Validator and CSS Validator are your best friends.

  2. Separate the design from the content.

    Use CSS to describe how things should look (fonts, colours, widths and heights, borders, etc.) Also, take as many images as you can out of the HTML. Don't use images to display text. Ideally, put all the CSS in an external file, but it's up to you how you organise your code. Just be aware of the tradeoffs.

  3. Separate behaviour from the content.

    Don't use event attributes (onLoad, onMouseOver, etc.) Ideally, put the JavaScript in an external file. Like with CSS, this isn't so important and is up to you. However, it is important that your web site works without JavaScript, if possible. Again, just do your best.

  4. Use HTML the way it was intended.

    By this I'm talking about using HTML semantically. Don't use tables unless you're showing spreadsheet data. Use h1-h6 tags for the headers on your page. Use blockquote only when you're quoting, not for the indentation. Just try to use the full range of HTML tags when appropriate. Sometimes you simply need to use divs and spans, but avoid catching Divitis.

  5. Make your site accessible.

    Accessibility is a very important standard, in some places it's actually the law. If you've already taken care of the last four points, chances are your site is already very accessible. Grab an accessibility checklist, and take look at your web site through the eyes and ears of all potential visitors. What does the site sound like with a screen reader? What happens when you increase the font size? Are you using any terminology without giving definitions? This is a big topic, but it often gets forgotten.

This is what I mean by 'web standards'. These are all just guidelines, and there are obvious exceptions to every rule. Next, I'll go into the benefits of following these rules.

Update: I've chosen to go with the term 'Best Practices' to describe what I've discussed here, of which 'web standards' are only a subset. Read my discussion here.

Published on January 31st, 2006. © Jesse Skinner

Web Content Accessibility Guidelines 2.0

As announced yesterday in the W3C News:

The Web Content Accessibility Guidelines (WCAG) Working Group has released Working Drafts of the Web Content Accessibility Guidelines 2.0 and HTML Techniques for WCAG 2.0 and a First Public Working Draft of Understanding WCAG 2.0.

Unlike many W3C documents, these are actually quite readable and useable right away. They make some great points, some of which surprised me a bit. Web accessibility is often reduced to screen-reader functionality. This document goes quite a bit outside that narrow view and ensures that the web is fully accessible to users with a wide range of disabilities. These includes learning difficulties, cognitive limitations, speech difficulties and others.

As a result, following the advice in these documents seems like it would enhance the usability of the web for all users, even those without disabilities. Here are some of the more interesting points I noticed in these documents.

  • Guideline 2.5 - Help users avoid mistakes and make it easy to correct them. This is really great, general advice. It suggests validating input, providing context-sensitive help, and offering users a chance to review or possibly undo actions.
  • Guideline 3.1 - Make text content readable and understandable. Again, very useful and general advice that improves usability for all users. It suggests avoiding the use of jargon or words used in an unusual way. Also, the use of simple language summaries or diagrams to explain complex concepts to users with reading ability less advanced than "lower secondary education".
  • H46: Using null alternative text and no title attribute on img elements for spacer or purely decorative images. This makes perfect sense once I read it, but I had never given much thought to this being a real problem. I always thought about empty alt and title tags as a kind of work around. However, putting things like "side" or "blue bar" in alt tags on pure display images would just be annoying and unneccessary to a user with a screen reader.

If you haven't yet, I suggest giving these documents (at least the guidelines and techniques) a quick read. It's good to be reminded now and then of the simple ways we can make the web accessible and usable to everyone.

Published on November 24th, 2005. © Jesse Skinner