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 29, 2007

Front-End Quiz Part 7, Doctypes

Which HTML doctype is best?

  1. HTML 3 or lower, or just don't use a doctype.

    \*Shudder\* With an ancient or missing doctype, your web page will be rendered in quirks mode, making proper CSS design more buggy and difficult.

  2. HTML 4.01

    My personal choice. As of 2007, HTML is still a perfectly current, valid standard, and is extremely well-supported and well-understood on the web.

  3. XHTML 1.0 or 1.1

    There are actually some problems with XHTML. As of 2007, try to serve true XHTML, and your website will probably fail for lack of visitors, simply because Internet Explorer (IE) currently doesn't support it. Many sites these days claim to be built in XHTML, but most fail the validator, and almost all are served as text/html to support IE, causing them to be understood by all browsers as nothing more than syntactically weird-looking HTML. In other words, it is HTML in all but name. As a best case scenario, let's assume that on September 2008 IE 8 will ship with true XHTML support. That means XHTML won't be a feasible option for websites until the last users of Internet Explorer 7 (released 2006) finally upgrade. In other words, extremely optimistically, it will be, say, 2010 or later before true XHTML is a viable option. Until then, why fake it? All of that said, there are some good reasons to use today's faux brand of XHTML. Most commonly, content might need to be treated as XML on the server-side, even if it's served as text/html to the client. This is where I think XHTML shines today.

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.

Wednesday Aug 08, 2007

Front-End Quiz Part 4, CLASS and ID attributes

What are the purposes of the class and id attributes?

  1. Presentational hints for CSS, for example <span class="green"> and <div id="leftcolumn">.

    Not a very good approach, IMO. This is the classic mistake of mixing content and presentation. For example, if you want to switch to "orange" instead of "green," then your CSS will have to change from{color:green} to{color:orange}, which is, well... weird.

  2. General-purpose semantic hints, for example <p class="warning"> and <div id="nav">.

    I overwhelmingly prefer this approach. This allows the utmost flexibility in evolving the presentation and behavior layers independently of the content, plus it has a self-documenting effect on the HTML source code.

  3. To replace outmoded HTML tags, for example <div class="heading"> instead of <h1>.

    Run away! Run away! I hesitate to say that any one development approach is evil, but this comes close. HTML elements such as <h1> have a structural meaning used by search indexers and user agents of all kinds. Breaking away from all but ultra-generic generic <div> and <span> tags breaks searchability and accessibility, as well as the ability to meaningfully syndicate your content via RSS or Atom. It prevents use of your content in ways that you don't anticipate, and in contexts that you might not have considered.

Wednesday Aug 01, 2007

Front-End Quiz Part 3, Adding Events to Elements

What's the best way to add JavaScript "onclick" event behavior to a link?

  1. Add an onclick="" attribute to the <a> tag.

    My opinion: this is a nasty, outdated way of doing things that needs to be euthanized ASAP. It's the most prevalent method as of 2007, but mixing scripting commands with HTML is just as bad as mixing presentational commands with HTML, and for the same reasons. Presentation should be removed from content via external CSS files, and behavior should be removed from content via external JavaScript files. Even if it seems justifiable to throw in a quick onclick="" attribute for convenience's sake, it risks getting accidentally overwritten by more sophisticated event attachment methods that deploy via external scripts.

  2. In a script, use document.getElementById("someId").onclick = function() { ... }

    Better, but still nasty, IMO. This method is a vast improvement over inline event handler attributes such as <a onclick="">, but it still only lets you assign one event handler per element, and succumbs to the common problem of events being accidently overwritten, since there is only a single onclick property per element.

  3. Use event attachment, preferably via some kind of event library that abstracts away browser differences.

    My personal favorite. Event attachment lets you assign an arbitrary number of events to the same element. This is especially useful for the window "onload" event, which often needs to spawn multiple actions.


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


« July 2016