Wednesday Oct 24, 2007

Front-End Quiz Part 8, ALT Attributes

For a propane supplier's website, which use of the alt attribute value is best?

  1. <img src="mountains.jpg" alt="mountains.jpg">

    This provides no useful information in cases where the image can't be seen.

  2. <img src="mountains.jpg" alt="mountains.jpg, 400x300, jpeg image">

    This provides no useful information in cases where the image can't be seen, and adds noise to the page's content.

  3. <img src="mountains.jpg" alt="aren't they pretty?">

    Aren't \*what\* pretty? By definition, the user can't see the image if the alt text is showing.

  4. <img src="mountains.jpg" alt="mountain scene">

    If the image were followed by the text "We can deliver propane to your door seven days a week." then the text "mountain scene We can deliver propane to your door seven days a week." would be displayed when the image wasn't present, which would be weird.

  5. <img src="mountains.jpg" alt="a mountain scene, taken March 2004, near Evergreen CO">

    If the image were followed by the text "We can deliver propane to your door seven days a week." then the text "a mountain scene, taken March 2004, near Evergreen CO We can deliver propane to your door seven days a week." would be displayed when the image wasn't present, which would be weird.

  6. <img src="mountains.jpg" alt="We Are Colorado's Best Propane and Natural Gas Supplier.">

    This is good, possibly, depending on context. Alt text doesn't necessarily need to reflect the content of the image! It's truly ALTernative content. If the image were followed by the text "We can deliver propane to your door seven days a week." then the text "We Are Colorado's Best Propane and Natural Gas Supplier. We can deliver propane to your door seven days a week." would be displayed when the image wasn't present, which would be a great use of alt="". However note that context and intent should be taken into account when deciding alt text, and it's certainly not something that's machine-decidable.

  7. <img src="mountains.jpg" alt="">

    This is iffy. Sometimes it might be best to leave the alt attribute blank.

  8. <img src="mountains.jpg"> (no alt attribute)

    This is bad. There should always be an alt attribute, even if blank. This at least makes it explicit that the image adds no meaning to the page.

Wednesday Aug 22, 2007

Front-End Quiz Part 6, Separating Content, Behavior, Presentation

Where/how is content best separated from behavior and presentation?

  1. On the client-side, using semantic HTML plus external JS and CSS files.

    This is where I set up camp. Server-side methods exist for separating content, presentation and behavior, but they have different ideas of what "presentation" and "behavior" mean. In terms of separating out the visual presentation and client behavior layer, CSS and unobtrusive JavaScript should be the first line of defense.

  2. On the server-side, using features of your rendering framework/MVC architecture.

    If, by "presention" you simply mean HTML code, and by "content" you mean information stored in the application, and by "behavior" you mean controller logic, then yes. On the other hand, if you're coding font tags, layout tables, spacer images, onclick="" and onload="" attributes directly into your JSPs or page renderers, then I think that's a serious red flag. With CSS handling the visual details and unobtrusive JavaScript handling client interactivity, your web renderer is free to focus on saying "now a heading," "now a list," "now a submit element," etc.

Wednesday Aug 15, 2007

Front-End Quiz Part 5, Users who Disable JavaScript

What's the best approach for dealing with the approximately 7 - 10% of visitors who disable JavaScript?

  1. Preemptively send them to a sorry, but you must activate JavaScript in order to use this site screen.

    Not a good way to make friends. This is like saying, "go away, we don't want you" or, "we only want 93% uptime for our website." I think the business case for this is rare indeed.

  2. Condition your plan on building it to work without JavaScript, then use JavaScript as an enhancement.

    I like this approach the best. This is known as the "progressive enhancement" method, and it's the best way to build bullet-proof websites in the modern age.

  3. For each feature needing JavaScript, use an inline this feature requires JavaScript <noscript> section.

    Still not very friendly. This is marginally better than blocking access to the whole site.

  4. Place a block of alternative content in a <noscript> section containing equivalent functionality.

    Workable, but inefficient. <noscript> functionality is really a suboptimal solution, since it requires you to basically code your functionality into the page twice.

  5. Just let certain features break, it's not really that big a deal.

    Possibly confusing. Not only do visitors not get the functionality they were looking for, now they're confused as well, without any explanation of why it won't work.

  6. Avoid using JavaScript in the first place.

    Maybe not the best, but it's an option. JavaScript offers a lot of capability that has come to be expected on the web. Your site might seem outdated without it.

Tuesday Jan 02, 2007

How this Blog Design was Created

I decided to go the total web-standards-nerd route in creating this blog design. Semantic HTML, source-order, accessibility, and unobtrusive JavaScript were all factors from the outset.

The first thing I did was to customize the "Basic" theme. This gave me a starting point. I removed all presentational information, starting with the CSS code. Then I went through the HTML and removed presentational hints. For example, layout tables, <center> tags, &nbsp; characters, etc. Even things like class="left-bar" had to go. "Left" is too presentational, and I relaced it with "sidebar," since it might be argued that "sidebar" is a semantic hint. (Yes, that's how much of a nerd I am.) Fortunately there wasn't much presentation baked into the HTML to start with, because most Roller themes are pretty good about separating content and style.

Next to go was JavaScript. I had just removed the presentational layer, and now it was time to remove the behavioral layer. These layers would be added back in later via external files, once the HTML-only blog was proved working.

Wherever possible, I made the HTML as semantic as possible; selecting and organizing tags elements by meaning and structure. Source-order sensibilities were used, placing more important things higher in the source code. Headings/sections were arranged such that if you removed all but the headings (<h1> - <h6>) you'd get an outline of the page. <p> was used to contain all logical fragments of text. <div> was used to delimit sections. <ul> was used to build lists. It turns out, semantic HTML is really pretty brainless and straightforward, once you yank out presentational noise.

Once the blog was purified, it was boring-looking, but usable. No columns, just black Times New Roman text that strung all the way across the browser screen on a white background, with blue hyperlinks. It was nekkid! Time for some clothes. An empty CSS file was <link>ed to the blog, which I began populating, resulting in the current design.

As you may know, it's easy to do CSS design in Firefox, Opera and Safari, all of which understand and render CSS beautifully. But then you inevitably have to do battle with IE. Most designers approach the IE problem by peppering their CSS file with hacks. Hacks are oddly structured CSS commands that, due to IE bugs, either can't be understood by IE or can only be understood by IE. Instead of doing this, I used conditional comments to load corrective stylesheets into just IE. Conditional comments are an IE-only feature that look like regular HTML <!-- --> comments to real HTML parsers, but have special meaning to IE. This way, I was able to quarantine IE-specific bigfixes to a couple small, IE-specific files.

Wednesday Dec 14, 2005

On the Importance of URL Canonicity

When designing a linking schema between their pages, web developers often fail to take into account the importance of URL canonicity. For example, when implementing a tabbed navigation design, it's tempting to switch the tab based on a querystring such as page.jsp?tab=1. Similarly, a CMS might use a URL like showArticle.jsp?article=123456. Also, most webservers accept two versions of a directory index URL, for example /foo/ and /foo/index.jsp. Finally, It's common for a website to exist at both and

All of these URLs create canonical issues, or ambiguity, regarding where exactly a piece of content lives. You might ask why there should be ambiguity when a given URL always gets you the same piece of content? In other words, if both /foo/ and /foo/index.jsp return the same content, what's the big deal? Well for starters there's the extra performance hit on your webserver because the browser cached one version and not the other. In fact, any caching system is impacted by non-canonical URLs.

Another problem with non-canonical URLs is in web analytics. Two versions of a URL might really be the same page, but a web analytics package doesn't know this unless you hard code a special rule about it somewhere. The fact is that, canonical or not, the world treats URLs as canonical, and so broken behavior results when they are not.

But what about querystring driven URL schemes? Isn't showArticle.jsp?article=123456 always the same? Strictly speaking, yes, so why should querystrings be bad for canonicity? When there are multiple variables inside a querystring, order generally doesn't matter. foo.jsp?cid=123&uid=456 is the same as foo.jsp?uid=456&cid=123, so in this sense canonicity is broken. But even if you take pains to ensure querystring values are always ordered consistently, the world at large doesn't know this. Querystring driven URLs are treated as ambiguous. For example, Google isn't as quick to index a querystring driven URL as it would be to index a URL that looks canonical.

Fortunately, options exist to make URLs more canonical. Most webservers have URL rewriting capability that can redirect to a given URL from the corresponding URL, or vice versa. And most webservers can be similarly configured with regard to the /foo/ vs. /foo/index.html issue.

For web applications where pages are dynamically assembled, it's possible to use path info instead of querystrings. Consider the following URLs:

Here, "articles" serves the same role as "showArticle.jsp." Correspondingly, "?article=123456" and "/123456.jsp" serve as the pointer to the content piece. The implementation of this is beyond the scope of this post, suffice it to say that the capability is built into most web application environments.

Finally, here are a couple of related links:


My name is Greg Reimer and I'm a web technologist for the Sun.COM web design team.


« July 2016