Christopher Schmitt, Kimberly Blessing and Eric Ellis speaking at the 2009 SXSW Interactive festival.

Designing Our Way Through Web Forms

Although forms make the Web go around, they are often ugly due the generic way in which browsers display them, not to mention irritating to our site's visitors when they don't work as expected. In this session, panelists will provide specific details on ways to successfully create compelling forms for your users.

Twitter search for #formsxsw

Read the rest of this entry »

Canonical URL links

From Yoast and very cool:

Google, Yahoo and Microsoft have just announced a new tag, which we can use to tell the search engines which URL it should have for the current page. This is probably best explained with an example, so here goes.

Suppose you have read my Twitter Analytics post, and you've started tagging all the URLs you spread on Twitter with Google Analytics campaign variables. So at some point, Google enters your site through this URL:

http://yoast.com/twitter-analytics/?utm_source=twitter&utm_medium=twitter
&utm_campaign=twitter

If it did, in "old times," this would mean you'd have a duplicate content issue: the same content indexed under two different URLs. An issue SEOs have been trying to solve on web pages for ages, which sometimes created huge limitations. This is where the new tag comes in. You add this code to the <head> section of your page:

<link rel="canonical" href="http://yoast.com/twitter/analytics/" />

Read the rest of Yoast's post and learn more about canonical URLs at http://yoast.com/canonical-url-links/. Google's official post on canonical URLs is at http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html.

To make things easy for us, Yoast has already prepared a WordPress Canonical URL plugin , as well as a Magento extension and a Drupal module! Thanks, Joost!

While I appreciate Yoast blogging about this and their work in preparing the plugin, extension and module, one small critique. Technically, this is not a new "tag," rather it is simply a new value for the rel attribute of the existing link tag.

Slides from my presentation on HTML validation, microformats and jQuery to WebTechNY on 8 October 2008:

Thanks to everyone who attended!

While it's nowhere near close to new, I discovered the <wbr> (word break) tag today. The need for a tag like this occurred on a client's website: the title of one of their publications, which included two relatively long words separated by a slash, was poking outside of the side navigation in IE 6. Since the title looked fine in other browsers, I wanted a way to "suggest" a line break after the slash to IE without forcing a line break on every browser. <br> was out.

Enter the <wbr> tag. <wbr> "marks a place where a line break can take place. It does not necessarily always result in a line break; rather, it says that line breaks are allowed at this place." To use <wbr> in XHTML, use the XML syntax for empty elements: <wbr />.

Not all browsers support <wbr> (including Opera), however IE 5.5–7 and Firefox 2–3 do. Opera compatibility can be achieved via the following CSS rule:

wbr:after { content: "\00200B"; }

QuirksMode.org has a browser compatibility table for <wbr>. While not mentioned there, <wbr> does work in Chrome.

Note to standardistas—<wbr> is not in any of the HTML specifications. This means it will cause validation errors.

References

I probably shouldn't be so critical, but it's Saturday night and I'm at home working. During a brief Wikipedia break (computer jargon), I decided to read the standardista entry and followed an external link to webstandardistas.com.

I'm not sure what I expected to find, but I guess it wasn't a placeholder for a forthcoming Friends of Ed book. Regardless, it was disappointing to see that while these standardistas did have a valid DOCTYPE, it was neither HTML 4.01 Strict nor XHTML 1.0 Strict, but XHTML 1.0 Transitional. It was also disappointing to see inline JavaScript and CSS in the head instead of an external stylesheet.

And, while it was only a single error, it was the use of an incorrect inline JavaScript onsubmit (they have it incorrectly specified as onSubmit) handler that causes the page to not validate!

I'm also not sure how I feel about the use of h3 and p tags within unordered lists. Is this really necessary? Why not just have multiple uls below the headings? Or instead of the li with child p construct, use definition lists?

Finally, there's no server side validation on the "Keep me posted form"!

Standardistas and accessibilitistas: This call to action via 456 Berea St concerns a disturbing direction the next HTML specification is heading. Roger Johansson writes:

What is currently going on in the W3C HTML Working Group is very disappointing and something I never expected to see when I joined it. I was naive enough to think that everybody joining the HTML WG would be doing so out of a desire to improve the Web. Unfortunately, that does not seem to be the case […]

In Roger's opinion, if nothing is done, "the next version of HTML will do nothing to improve the Web," and conscientious designers will be "better off sticking to HTML 4.01 Strict."

So, if you have an interest in improving the accessibility of HTML, want more semantic and less presentational markup, and are good at arguing your case, apply for HTML Working Group membership by following the instructions for joining the HTML Working Group. Do it now.