Check it out. Start here and hit your right arrow key until you start to see the same things twice.

Based on shortcuts.js

R.nav = { 
	init: function(){
	
		var bod = document.body;

//are we on a gallery page?
		if (bod.id == "detail" && bod.className == "art") {

//add an event 
//use your library method of choice, please 
//we don't want to mess things up for other people
			document.onkeydown= R.nav.navigate ;

		} 

	},

	navigate : function(e) {

//normalize the event that comes in
//it's either the first argument to the function
//or it's window.event
		e = e || window.event;

		var obj;

//test to see what object initiated the event
		if(e.target) {

			obj=e.target;

		}

		else if (e.srcElement) {

			obj=e.srcElement;

		}

//was it a text node?
		if(obj.nodeType==3) {

			obj=obj.parentNode;

		}

//if it was an input or textarea, we want people to be able to
//use the arrow keys, clearly.
		if(obj.tagName == 'INPUT' || obj.tagName == 'TEXTAREA') {

			return;

		}

//get the numeric code of the key pressed
		if (e.keyCode) {

			code = e.keyCode;

		}

//ie doesn't understand event.which, apparently
		else if (e.which) {

			code = e.which;

		}

//test the code to see if it's a right or left arrow
//and navigate accordingly. The ids prev and next 
//match the rel attributes, by the way
		if (code == 37){

			document.location.href=document.getElementById("prev").href;

		} else if (code ==39){

			document.location.href=document.getElementById("next").href; 

		}

	}

};

But, they’re the gateway to making real money on the web, so they’re kind of important.

Hopefully, after today you’ll know all about forms and will love them.

Let’s take a look at our example form:

<form action="http://www.drunkenfist.com/304/wp-comments-post.php" method="post" id="commentform">

  <fieldset>

    <legend>Contact Info:</legend>
    <p>

      <label for="author">Name (required)</label>

      <input type="text" name="author" id="author" value="" tabindex="1" />
    </p>        
    <p>

      <label for="email">Mail (will not be published)(required)</label>

      <input type="email" name="email" id="email" value="" tabindex="2" />
    </p>
    <p>

      <label for="url">Website</label>

      <input type="url" name="url" id="url" value="" tabindex="3" />
    </p>

  </fieldset>
  <p>

    <label for="comment">Comments</label>

    <textarea name="comment" tabindex="4"></textarea>
  </p>
  <div class="button">

    <input name="submit" type="submit" id="submit" tabindex="5" value="Submit" />  
  </div>

</form>  

This sample is based on the default WordPress theme. It’s maybe not as complicated as a sign-up form, but it does show the basics. On to it then.

Use Labels

Labels are great for accessibility, they make forms more usable and they provide hooks for CSS. What’s not to like?

Labels allow you to associate text with form input elements. Screen readers will read the label to indicate what each form element is. Labels also create a much larger hit area for check boxes and radio buttons, that helps people with reduced vision as well as regular users.

Test it out:

My checkbox

My no-label checkbox

So, yeah, use labels.

Fieldsets and Legends

I don’t use these all the time, but they’re nice to use on longer, single page forms. The group like form elements together both visually and logically and provide a handy heading to describe the section in the form of the legend.

Visually they’re nice and they provide real context for grouped form inputs.

Check one out:

(You like that CSS3 in there, don’t you?)

Here’s the markup for that example:

<fieldset>

  <legend>Contact Info:</legend>

  <p>

    <label for="author">Name (required)</label>

    <input type="text" name="author" id="author" value="" />

  </p>

  <p>

    <label for="email">Mail (will not be published)(required)</label>

    <input type="email" name="email" id="email" value="" />

  </p>

  <p>

    <label for="url">Website</label>

    <input type="url" name="url" id="url" value=""  />

  </p>

</fieldset>

Tabindex

Tabindex is an interesting case. I’ve seen the attribute offered up as a best practice in a few places, but the reality is unless you’ve got a screwed up source order, you don’t really need to use them. Looking at the example (which is based on WordPress’ default theme) you can see that the order of the inputs is exactly the same as the tabindex. Which means the tabindex is superfluous.

I’ve actually set up a Jira issue to remove those from my theme. See, even I can learn something from these articles

Optgroup

The optgroup is a really nice way to organize select elements. Check this one out:

Choose your favorite super hero?

Mr. FantasticInvisible WomanThe ThingThe Human Torch
SupermanBatmanWonder WomanFlashGreen LanternAquamanMartian Manhunter
Captain AmericaIron ManGiant-ManHawkeyeThe VisionThe WaspWonder Man
CableAngelThe BeastBansheeColossusCyclopsHavokIcemanPhoenix NightcrawlerProf. Charles XavierPolarisStormWolverine
DaredevilSpider-Manthe Hulk

And here’s what the code looks like:

<label for="super">Choose your favorite super hero?</label>

    <select id="super" name="super">

        <optgroup label="Fantastic Four">

            <option value="1">Mr. Fantastic</option>

            <option value="2">Invisible Woman</option>

            <option value="3">The Thing</option>

            <option value="4">The Human Torch</option>

        </optgroup>

        <optgroup label="JLA">

            <option value="5">Superman</option>

            <option value="6">Batman</option>

            <option value="7">Wonder Woman</option>

            <option value="8">Flash</option>

            <option value="9">Green Lantern</option>

            <option value="10">Aquaman</option>

            <option value="11">Martian Manhunter</option>

        </optgroup>

        <optgroup label="Avengers">

            <option value="12">Captain America</option>

            <option value="13">Iron Man</option>

            <option value="14">Giant-Man</option>

            <option value="15">Hawkeye</option>

            <option value="16">The Vision</option>

            <option value="17">The Wasp</option>

            <option value="18">Wonder Man</option>

        </optgroup>

        <optgroup label="x-men">

            <option value="19">Cable</option>

            <option value="20">Angel</option>

            <option value="21">The Beast</option>

            <option value="22">Banshee</option>

            <option value="23">Colossus</option>

            <option value="24">Cyclops</option>

            <option value="25">Havok</option>

            <option value="26">Iceman</option>

            <option value="27">Phoenix </option>

            <option value="28">Nightcrawler</option>

            <option value="29">Prof. Charles Xavier</option>

            <option value="30">Polaris</option>

            <option value="31">Storm</option>

            <option value="32">Wolverine</option>

        </optgroup>

        <optgroup label="independent">

            <option value="33">Daredevil</option>

            <option value="34">Spider-Man</option>

            <option value="35">the Hulk</option>

        </optgroup>

     </select>

</label>

If you’ve been reading along with me you’ll definitely see why I like the optgroup. It provides both visual and programmatic organization to the list. You don’t need them all the time, but when you do it’s great to have in your toolbox.

HTML5

HTML5 has introduced a ton of new input types an attributes. They’re really cool. They’re far more specific than type=”text” and will allow for plenty of enhancements from the browser vendors. Here’s a small sampling:

type=”search”

Indicates that the text is a search box.

type=”url”

Indicates that the field should contain a URL.

type=”email”

Indicates that the field is expecting an email address.

type=”datetime”

A date picker. This will save a ton of code as people will be able to rely on native date pickers instead of Javascript driven ones.

type=”color”

A color picker.

placeholder attribute

Indicates text that should be treated as a placeholder.

And there are plenty more where that came from.

Had enough of forms? I have. Next time, I’ll be going through some of the new HTML5 elements. Because they’re cool.

Writing about CSS and JavaScript will be fun. I’m excited. More excited than I am to write about forms at least. Which isn’t to say I won’t kick ass when writing about forms. It’ll be great.

Ignore me.

On with the show:

B, Strong, Em, I

From the just in case you were wondering what’s up with strong and em and why people use them over b and i department:

The b (bold) and i (italic) tags have been in HTML forever. I haven’t figured out when they first appeared, but they were promised as part of the documentation to the fist web site in August 1991 and later codified as part of the unofficial HTML1 spec in 1993, so 1992 is as good a bet as any.

Later on the concept of “phrase elements” was introduced. They were meant to add “structural information to text fragments” Two of those, strong and em are basically new versions of good old b and i minus the typographic baggage.

Fast forward to 2000. The W3C publishes the Web Content Accessibility Guidelines. In the section on emphasis they state:

Checkpoints in this section:

* 3.3 Use style sheets to control layout and presentation. [Priority 2]

The proper HTML elements should be used to mark up emphasis: EM and STRONG. The B and I elements should not be used; they are used to create a visual presentation effect. The EM and STRONG elements were designed to indicate structural emphasis that may be rendered in a variety of ways (font style changes, speech inflection changes, etc.)

This recommendation stuck. A lot of code has been written with strong andem and all good IDEs use them when you press the b and i buttons on the toolbar. They’re pretty standard now.

And that’s how we got to strong and em.

And now you know.

Interestingly, b and i are making a comeback in HTML5, having been given a new semantic lease on life. More on that in a couple of weeks.

The Lang attribute

As we saw way back in the third entry in this series, your HTML document should signify its language on the opening html tag. Simple enough. So, what happens if you need to use some text from another language? You pull out the lang attribute and mark up your text accordingly. Here’s a block of text which will illustrate what I’m talking about.

I’m a big fan of movies. For a few examples of the genres I like, check out my writing on French crime drama (Du rififi chez les hommes), Hong Kong martial arts (精武英雄/Fist of Legend), and Japanese samurai cinema (座頭市物語/Zatoichi)

Here’s what that little snippet looks like marked up:

I'm a big fan of movies. For a few examples of the genres I like, check out my writing on French crime drama 
(<a href="http://www.drunkenfist.com/movies/indy-foreign/rififi.php" lang="fr">Du rififi chez les hommes</a>), 
Hong Kong martial arts (<a href="http://www.drunkenfist.com/movies/hong-kong/fist-of-legend.php"><span lang="zh">
精武英雄</span>/Fist of Legend</a>), and Japanese samurai cinema 
(<a href="http://www.drunkenfist.com/movies/japan/tale-of-zatoichi.php"><span lang="ja">座頭市物語</span>/Zatoichi</a>)

See the several instances of lang, with the appropriate language code? It’s a simple enough pattern, but it’s also very important. It gives computers and screen readers clue that the language contained therein should be handled differently than the surrounding text. That’s a positive.

Span

I used a couple of spans in the above example. That’s one of handful of cases where I use them. I’ve got nothing against a span or two. I just don’t use them very often.

There’s a point to this little aside- To my mind, if you can find a pattern that describes your content better and allows you to execute your design, go with the semantic pattern and skip the span (or divs.) Training yourself to think that way will (hopefully) lead you to writing HTML that is richer in meaning and easier for other authors to understand.

Use Structural Elements Wherever Possible

There are several structural elements I try to use where applicable:

ABBR

Indicates an abbreviated form. Use the title attribute to indicate the full or expanded form.

Acronym

Indicates an acronym. Use the title attribute to indicate the full or expanded form.

Cite

Contains a citation or a reference to other sources.

Code

Designates a fragment of computer code.

Blockquote

Designates a quoted passage. Use the cite attribute to indicate the source.

There are a few more that I’ve literally never used. The above come up pretty regularly, at least in the content I deal with. Of those, I use blockquote and code most regularly. I feel a bit guilty at not using the other ones more often.

Such is my life.

That’ll do it for now. I might get a bolt of inspiration and tack onto this post from time to time, but for now…. done.

Next week. FORMS.

A few months ago I was both pleased and surprised to discover a web developer who didn’t really know how to lay out a page using tables. He had a sense of how it might work, but had never really done it. I was having him help out with an HTML email (where tables are still the safest bet) and the whole thing was a novelty for him. Looking at it, this makes sense as he’d been at the job for only a few years so he learned entirely in the modern era and he was lucky enough to only learn from good sources. Still, it was a new phenomena for me- encountering a developer who was purely from a CSS-based layout world.

Yes! We’re winning.

If you don’t know what I’m talking about when I talk about tables for layout, move along. There’s nothing to see here.

Anyway, tables.

Tables

Tables are for Tabular Data

Here’s a table full of data.

And here’s the markup:

<table class="dataTable">

<caption>Boston Celtics Individual Scoring Highs</caption>

  <tr>

      <th scope="col">Total</th>

      <th scope="col">Player/Opponent</th>

      <th scope="col">Date</th>

      <th scope="col">Result/Score</th>

  </tr>

  <tr>

  <td>60</td>

   <td>Larry Bird vs. Atlanta (at New Orleans)</td>

   <td>03/12/85</td>

   <td>W/126-115</td>

 </tr>

 <tr>

   <td>56</td>

   <td>Kevin McHale vs. Detroit</td>

   <td>03/03/85</td>

   <td>W/138-129</td>

 </tr>

 <tr>

   <td>53</td>

   <td>Larry Bird vs. Indiana</td>

   <td>03/30/83</td>

   <td>W/142-116</td>

 </tr>

 <tr>

   <td>51</td>

   <td>Sam Jones at Detroit</td>

   <td>10/29/65</td>

   <td>L/106-108</td>

 </tr>

 <tr>

   <td>50</td>

   <td>Paul Pierce vs. Cleveland</td>

   <td>2/15/06</td>

   <td>L/109-113**</td>

 </tr>

 <tr>

   <td>50</td>

   <td>Larry Bird vs. Atlanta</td>

   <td>11/10/89</td>

   <td>W/117-106</td>

 </tr>

 <tr>

   <td>50</td>

   <td>Larry Bird at Dallas</td>

   <td>03/10/86</td>

   <td>L/115-116</td>

 </tr>

 <tr>

   <td>49</td>

   <td>Antoine Walker at Washington</td>

   <td>01/07/98</td>

   <td>L/108-110</td>

 </tr>

 <tr>

   <td>49</td>

   <td>Larry Bird vs. Portland</td>

   <td>03/15/92</td>

   <td>** W/152-148</td>

 </tr>

 <tr>

   <td>49</td>

   <td>Larry Bird at Phoenix</td>

   <td>02/15/88</td>

   <td>W/107-106</td>

 </tr>
</table>

The important bits are as follows:

• Use headers. The TH tags signifiy that those cells are headers. That makes them computer-readable, imparts meaning for screen readers and you can style them. Win-win-win.
• Use the scope attribute which indicates whether the header is related to the col(lumn) or row.
• Use a caption to describe the contents of the table
• It’s not shown, but for complicated tables it’s useful to provide a summary attribute. A summary can describe, in greater detail than the caption, the purpose or structure of the table.

And there you have it, a quick jaunt through the wonderful world of data tables. We’re nearing the end of the tour through the body and then it’s onto CSS and JavaScript. Which will be super fun.

Comfy?

On with it then.

Links <a>

The link is the engine of the web. The concept of Hypertext (the H in HTML) itself is expressed in the power of the link. Google is Google because of the power of links. There is no better place to start.

Basic usage

<a href="http://www.drunkenfist.com/"  
        class="contact" 
        title="my personal site" 
        rel="me">DrunkenFist.com</a>

Write Good Link Text

For body copy you want to write link text that is descriptive of the link destination. generally this means a short phrase (5-10 words, depending on who you ask) that clearly describes the link. For that reason “click here” is generally not the greatest link text. For a live example and more on this topic take a look at link chapter of the the US Government’s Research-Based Web Design & Usability Guidelines. It’s full of really interesting tips on handling links.

For the SEO-minded, the above advice has the added bonus of generally including keywords which flow link juice and context to the targeted page.

Use Good Title Attributes

Not every link needs a title attribute, especially if it’s well written link text, but they can be used on some links to enhance the positive “scent.”

Learn common rel attributes and use them to your advantage

Rel attributes add computer readable information about the type of link. Here are some examples that I use. Definitions are from the Microformats site. Comments from me are in italics.

alternate

Designates substitute versions for the document in which the link occurs. When used together with the lang attribute, it implies a translated version of the document. When used together with the media attribute, it implies a version designed for a different medium (or media).

You’ll see this in links to translated pages as well as in invisible link elements pointing to feeds and the like in the head of the document.

me

the referenced document represents the same person as does the current document.

Google uses this information to help put together some of their “social” profiles. It can be interesting or creepy depending on your attitude towards such things.

next

Refers to the next document in a linear sequence of documents. User agents may choose to preload the “next” document, to reduce the perceived load time.

I use this on the navigation of my gallery pages.

nofollow

indicates that the destination of that hyperlink SHOULD NOT be afforded any additional weight or ranking by user agents which perform link analysis upon web pages (e.g. search engines).

Used to help sculpt page rank. It used to be a more valuable tool.

prev

Refers to the previous document in an ordered series of documents. Some user agents also support the synonym “Previous”.

Like next I use this in my gallery pages.

tag

indicates that the [referenced document] is an author-designated “tag” (or keyword/subject) for the current page.

In use on this very page

toc

Synonym of contents (from “Table Of Contents”)

Another one in use on my gallery pages

Images <img>

Mark Pilgrim has a great post (which in turn is a part of his HTML5 book) on the introduction of images to the web.

Basic Usage

<img src="http://media.drunkenfist.com/img/art/graffiti_art/alphabet/graffiti-letter-b.jpg"
        width="593" 
        height="593" 
        alt="image, rob react, graffiti letter b" >

There are a couple of things to keep in mind when you’re working with images.

1. Always provide a height and width. This will speed up your site as browsers will be able to render a “placeholder” box and flow content around it before the actual file has been downloaded. This can be significant if you’re providing big images as content (think “art gallery”) as they can up to a few seconds to fully load. Owing to the nature of my personal site, I spend a lot of time thinking about how to serve big images on the web and this is a very clear win.
2. For content images (but not decorative images- which you shouldn’t be using anyway*), always provide alt text. This is both the right thing to do (it’s a primary step to making an accessible web site) and it will help computers (the most important of which are search engine spiders) understand the content of your images. I can tell you from personal experience image search traffic can be a hell of a traffic boost.

   This article looks at writing good alt text.

Image Formats

One thing that people often have trouble with is figuring out what image format to use. GIF? JPG? PNG? Here’s what I do.

Use JPGs for Photographs, Paintings, Etc.

If it got smooth transitions from light to dark, has a ton of colors and/or generally looks “real” your best bet is to use a JPG. The P ins JPG is for “Photographers” so it makes sense.

Here are a couple of examples of typical JPG images:

Use 8 Bit PNGs For Interface Images or Other Images With a Limited Number of Colors

If it’s got a limited number of colors (up to 256), I use an 8 bit PNG. For me this means most of my interface images are generated as 8 Bit PNGs. A good example of that is something like a site sprite

I also output crisp black and white line art as 8 Bit PNGs:

Use 32 Bit PNGs For Images with Special Transparency or Opacity Needs

The images on top are 32 Bit PNGs, see how the natural drop shadow and variable opacity works on top of the checkerboard? Move your mouse over the div and you’ll see it clearer as the background image will shift. Such is the power of 32 bit PNGs. These are larger file size (those bits come at a price,) so they can’t be used everywhere, but they’re really useful for special cases like this one.

I rarely use GIFs anymore.

Image Compression

I use Fireworks for image production, which does a really good job, by default, at image compression. With some occasional tweaks I’m able to get really good results. If you don’t have Fireworks, or patience to tweak images individually, I suggest using Smush.it on your images. Actually I suggest, using Smush.it even if you are using Fireworks and have a bunch of patience. Saving 5% is saving 5% especially if it’s this easy.

If you’re running the YSlow plugin, it’s available from the tools menu. It will cut your images down to size with very little effort.

*You should use CSS for styling. That includes decorative images. I’ll get into that once I tackle CSS. That’s coming soon! I swear.

That’s it for now. Next time we’ll look at a few more HTML elements. Should be a grand old time.