Advertise here with BSA

Let’s start off with a simple task. Most web users can find the primary navigation on the image below, but take a few moments to see if you can find the secondary navigation.

If you had a problem definitively identifying it, you aren’t alone. Even information architecture (IA) experts like Lou Rosenfeld, Steve Krug, Jesse James Garrett, and Jakob Nielsen don’t agree as to what "secondary navigation" is.

When working with website stakeholders, it’s important to have a clear and consistent shared vocabulary for discussing website navigation and IA. It avoids confusion and mistakes.

In addition, having clearly labeled navigation types to choose from can help people organize the information more easily.

For us professionals, having standardized nomenclature allow us to discuss and explore the subject more easily.

In this article, we’ll look at the current status of website navigation terminology.

What Do Experts Agree On?

Let’s start with what everyone agrees on. The experts all agree that most sites have some sort of main navigation. This navigation is usually (but not always) consistent across all web pages of the site, so it’s always there when your site’s visitors need to access it.

It’s usually situated where most of your users go to find most of the information they need, and is often presented as a horizontal bar at the top of the layout or as a vertical list of links on the left- or right-hand side of the layout.

Steve Krug (author of the groundbreaking usability book, Don’t Make Me Think!) and Jesse James Garrett (who many of you might know as the person who coined the term, "Ajax") call this global navigation, but most others call this primary navigation.

Both terms make sense to me, and while I’ve always felt that "primary navigation" is the most logical name to refer to this type of navigation menu, I must concede that "global navigation" may be more descriptive and versatile.

Secondary and Tertiary Navigation

In the book, Information Architecture for the World Wide Web, Peter Morville and Louis Rosenfeld defined secondary navigation as navigation that’s "subservient to the primary navigation."

This always made a lot of sense to me, and our company has adopted the primary/secondary/tertiary navigation naming convention. It’s worked very well for us and is something that most of our clients understand very quickly and easily.

Secondary (and tertiary) navigation are often thought of as "subservient" to primary navigation. This can be visually represented using a flyout navigation or using a left-hand secondary navigation.

Not everyone agrees that secondary and tertiary are inherently "subservient" navigation, so I’d be curious to hear if there’s an industry-wide agreement on this.

What About Everything Else?

While the primary/secondary/tertiary navigation scheme works great for most of the navigation items on your website, it simply doesn’t work for all of them.

The least controversial of the other common navigation is the footer navigation. Regardless of whether it’s a mirror of the primary navigation, a whole new navigation, or just some links to auxiliary pages like the site’s Terms of Service (ToS) page, most people agree to call this the footer or the footer navigation.

The other place where all experts seem to agree on is that navigation items should be clearly labeled based on what their purpose is. Garrett calls additional navigation items courtesy navigation, Krug calls them utilities. Other people call them secondary navigation items but that term tends to fall apart conceptually on larger sites, so I would advise against that.

There’s also that navigation menu often found at the top-right of many sites. You know, the one with link items like "Login," "Help", "Search," "Contact Us", etc.?

For this navigation menu, I’ve always used meta navigation to refer to them. But in talking to other usability experts, that term changes depending on what region you’re in.

Meta navigation on Microsoft’s website.

Regardless of what you call these additional navigation items, it’s important to be flexible and recognize when "standards" don’t apply. Louis Rosenfeld, who’s been traveling the world advising people on usability for 15 years now, gives a great example of the importance of flexibility: he says that "in a faceted system (think the Epicurious recipe database’s navigation), there is no ‘primary’ — they’re all equally weighted."

In fact, most web apps, or websites that deal with managing large subsets of data like The New York Times, Amazon.com, or Google, might find that even the primary navigation is hard to pin down.

Sets of navigation highlighted on a Google search results page.

Instead, sites like these are controlled by a collection of panels or blocks which are customized to a user’s experience. In these cases, the user is less likely to browse through the site versus actively looking for the web pages they need, relying on featured content presented to them based on their site activity and site search for navigating the site.

What Standards Do You Use?

With all this different nomenclature flying around the Web, we’d like to hear back from readers. Do you call it "primary" or "global" navigation? What does "meta navigation" mean to you? How many of the sites you work on have a clearly defined primary navigation? Do you think we could be more effective as designers and developers if we standardized our navigation nomenclature a little more?

Share your thoughts and opinions in the comments.

Related Content

• Is It Time to Rethink Website Navigation?
• Guide to Website Navigation Design Patterns
• 50 Examples of Drop-Down Navigation Menus in Web Designs
• Related categories: Web Standards and User Interface

About the Author

Jason Mark is an educator, business owner, and author. His Massachusetts-based firm, Gravity Switch, continues to be the leader in web, iPhone and iPad development in New England, and Jason keeps their carbon footprint down by bicycling to work year round. Follow him on Twitter @jasonnmark.

Advertise here with BSA

As web designers and developers, we pay so much attention to what’s directly on the screen (or in our code) that the <head> of a document and what’s inside is often considered as an afterthought.

While in many cases it’s true that what appears on the screen is the most important part of a website (the content is what people visit a site for), the "thinking code" inside the <head> of our documents plays an important role.

This article will examine exactly what can fit inside a website’s head.

Mastering the Mind

The head of an HTML document is a busy area, and while it may not have the range of elements that the <body> can flex, it can actually engineer a range of its own elements to play vital roles in how a site will operate or how it can interoperate with other sites.

Depending on the website, there might be plenty going on inside its head.

So what are your options and how can they benefit your website? Well there’s quite a lot actually!

There are ways to add useful metadata into your documents (for search engines and other web robots to find), icons that you can supply web browsers for extra visuals (like favicons or device-specific icons for the iPad/iPhone), ways to allow the syndication of your content, and even stylistic and behavioral references that include external stylesheets and scripts.

In essence, the <head> of our HTML documents give the markup below it extra meaning.

Thinking code has many purposes, and not all of it is regulated by an official W3C specification!

Head Elements Gone Rogue

One thing that is unique to the head of our HTML is that it’s adoption and usefulness is determined on convention and popularity. Metadata, for example, relies on search engines and social networks to acknowledge and use the data, and link references require browsers to take advantage of them. Some things that can be included inside the head of our documents aren’t even officially supported by W3C specifications — such as <meta name="Googlebot"> that is a proprietary meta tag for Google’s spiders — but because of the nature of the elements, they are valid markup.

Independent Elements

The first elements we should talk about are those which are independent in the sense that they just serve a single purpose.

One of these elements is so mission-critical that you are required by HTML standards to include it: the <title> tag.

Below are five of the seven (excluding meta and link, since we will talk about them later) head elements:

Example:

<title>Six Revisions - Web Development and Design Information</title>

A document’s title should be unique on every page and should adequately describe its content.

While having a title in your document is required (if you follow W3C standards), the other tags might be of limited use to you.

For example, external stylesheets (instead of <style> tags) and an htaccess file (as opposed to <base>) are better options for declaring CSS style rules and declaring the base directory.

Mighty <meta> Tags

Of all the elements that appear in a document’s head, none is as ubiquitous as <meta> elements.

These elements — while being highly desired for search engine optimization– are more of a pseudoscience affair, as the influence they have on search engines aren’t publicly disclosed.

With the exception of the <meta="http-equiv" content-type=""> that specifies the document’s MIME type, they are all optional.

Getting the page’s encoding correct (through content-type) is important.

IE6 can take advantage of a special http-equiv value called imagetoolbar

Below are some examples of http-equiv values:

Example:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Of course, http-equiv isn’t the only attribute that can provide useful information. And even though keywords are presumed to be ignored by Google and description is only used to represent SERP listings (not acting as a ranking factor), there are no set standards for what values should be used.

Search engines like Google can use a <meta description=""> in its results.

Below are a few more types of <meta> tags:

Code Example:

<meta name="description" content="Six Revisions is a blog that shares useful information about web development and design, dedicated to people who build websites." />

While it’s true that meta tags don’t have a strict set of standards, conventions have come into existence to help decide which tags and values should be used.

Search engines (who pick what they feel are worth recognizing), social networks (that use the data to categorize a site) and organizations like the DCMI (trying to reduce our confusion) are responsible for such efforts to help in such situations.

Metadata isn’t a science, but the geographical positioning elements can seem like one.

Below is a list of the most widely adopted Dublin core metadata elements:

Example:

<meta name="DC.Creator" content="Jacob Gube" />

Note: As denoted in an article I wrote called "5 Web Files That Will Improve Your Website," you can actually place all of the relevant DCMI terms and metadata references into a handy, cacheable RDF file. While having meta tags outside the HTML head may sound strange, it’s a recognized way of serving repeating information (such as the site’s creator or site’s spoken language).

The effects meta tags have is of having semantic richness in your HTML documents, making your site all the more interoperable and meaningful to user agents, web robots, and web services.

Luxury <link> Tags

The simple purpose of the link element is (exactly as it sounds) to provide the browser with a location to an external resource that relates to the document in some way.

This element has so many purposes — from providing links to external stylesheets to indicating that RSS feeds are available, licensing of a web page, right across to referencing a favicon for your lovely web design.

Without the link element, Internet Explorer wouldn’t immediately know this feed exists.

Whilst many link conventions have been established, none are more grounded in the rich, textured history of HTML as the stylesheet. As you are already aware, if you have an external CSS file that contains your site’s CSS, you use the <link> element to reference that file within the document’s head. This allows the web browser to load the file, process its contents, and then apply your styles to the document’s objects.

Below are the two primary ways you refer to a CSS file:

Example:

<link rel="stylesheet" href="style.css" type="text/css" media="screen" />

None of the unique style in this design would work without the CSS file it uses.

Since the evolution of CSS3 (and the way Internet Explorer works), a unique level of complexity for stylesheet references have been forged. Not only can you wrap this element within conditional comments, but with media queries, you can apply the code only if certain conditions are met by the user agent.

It’s important that while stylesheet references take much of the glory for the link element, we also mention additional ways to make use of this flexible method of enhancing a site.

A classic example of how such elements can be used is defined by the Opera browser’s "navigation bar" which actively seeks out link references with certain rel values like index, author and home to provide a site-wide method of linking to specific places which may be of use to the end-user (via the browser).

While it’s only found in Opera, or through a plug-in/add-on/extension in other browsers, it can be really helpful in the right hands.

Opera has a navigation menu that links to important document or site sections.

Below are the various navigation links that Opera supports:

Example:

<link rel="index" title="Six Revisions" href="http://sixrevisions.com" />

Web browsers can do so much with link elements. It’s extraordinary.

Opera isn’t the only browser that can take additional advantage of the link element. In fact, all of the below have been adopted by browsers to reference external files which can impact either the way your website looks or functions.

Example:

<link rel="shortcut icon" type="image/vnd.microsoft.icon" href="favicon.ico" />

Examples of what can be included can range from OpenID (a universal authentication system) right through to referencing a document or profile setup by the microformat community (such as XFN) which relay semantic information about your pages.

Just because their effects are not visible doesn’t mean they don’t exist.

Below you will find a range of non-standard link references:

Example:

<link rel="license" title="Creative Commons Attribution 2.0 UK Licence" href="http://creativecommons.org/licenses/by/2.0/uk/" />

As a best practice you should always consider your link options carefully as referencing external files may increase the HTTP requests your web pages make to render a web page, thus slowing down page response times. Use only what you need and know why you need them.

Wrapping Up

While the contents of a document’s head could technically be limitless, it’s worth knowing what parts will give you a genuine benefit and which parts will simply be extra bloat you don’t need.

As a general rule, the best principle you can follow is to try and keep the head clean and well structured, but to also strike a balance between keeping things simple and doing what is best for your visitors.

While many people leave their heads as empty as possible, a better plan is to weigh up your options and use whatever enhances the user’s experience.

Behind the scenes in the head of a web page, there are a lot of cool things going on. Don’t overlook it.

Related Content

• 5 Web Files That Will Improve Your Website
• Problems with Using Website Validation Services
• Structural Naming Convention in CSS
• Related categories: Web Standards and Web Development

About the Author

Alexander Dawson is a freelance web designer, author and recreational software developer specializing in web standards, accessibility and UX design. As well as running a business called HiTechy and writing, he spends time on Twitter, SitePoint’s forums and other places, helping those in need.

Advertise here with BSA

Most of the web pages you encounter is presented to you via HTML, the world wide web’s markup language. In this article, I will share with you 20 best practices that will lead to clean and correct markup.

1. Always Declare a Doctype

The doctype declaration should be the first thing in your HTML documents. The doctype declaration tells the browser about the XHTML standards you will be using and helps it read and render your markup correctly.

I would recommend using the XHTML 1.0 strict doctype. Some developers consider it a tough choice because this particular standard is less forgiving than loose or transitional doctype declarations, but it also ensures that your code abides strictly by the latest standards.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

2. Use Meaningful Title Tags

The <title> tag helps make a web page more meaningful and search-engine friendly. For example, the text inside the <title> tag appears in Google’s search engine results page, as well as in the user’s web browser bar and tabs.

Take for instance, the following example:

<title>Six Revisions - Web Development and Design Information</title>

The example above appears like the following image in Google’s search engine results page:

3. Use Descriptive Meta Tags

Meta tags make your web page more meaningful for user agents like search engine spiders.

Description Meta Attribute

The description meta attribute describes the basic purpose of your web page (a summary of what the web page contains). For each web page, you should place a consise and relevant summary inside the meta description tag.

For example, this description:

<meta name="description" content="Six Revisions is a blog that shares useful information about web development and design, dedicated to people who build websites." />

Shows up in Google’s search engine results page as follows:

Don’t try to spam your description with repeated words and phrases because search engines are intelligent enough to detect that. Instead, just try to be simple and straightforward in explaining the purpose of your web page.

Keywords Meta Attribute

<meta name="keywords" content="web design, web development" />

The keywords meta attribute contains a comma-separated list of key words and phrases that relate to your web page. These keywords make your web page even more meaningful.

Again, just like with the description meta attribute, avoid repetition of words and phrases; just mention a few words that aptly describes and categorizes your web page.

4. Use Divs to Divide Your Layout into Major Sections

Consider dividing your web page into major sections as the first step in constructing a website design.

Doing so from the start promotes clean and well-indented code. It will also help you avoid confusion and excess use of divs, especially if you are writing complex and lengthy markup.

5. Separate Content from Presentation

Your HTML is your content. CSS provides your content’s visual presentation. Never mix both.

Don’t use inline styles in your HTML. Always create a separate CSS file for your styles. This will help you and future developers that might work on your code make changes to the design quicker and make your content more easily digestible for user agents.

Bad Practice: Inline Styles

Below, you can see a paragraph element that is styled using the style attribute. It will work, but it’s bad practice.

<p style="color:#abc; font-size:14px; font-family:arial,sans-serif;">I hate to separate my content from presentation</p>

6. Minify and Unify CSS

A simple website usually has one main CSS file and possibly a few more for things like CSS reset and browser-specific fixes.

But each CSS file has to make an HTTP request, which slows down website load times.

A solution to this problem is to minify (take out unneeded characters such as spaces, newlines, and tabs) all your code and try to unify files that can be combined into one file. This will improve your website load times.

A problem with this approach is that you have to "unminify" (because it’s hard to read unformatted code) and then redo the minification process every time you need to update your code. So it’s better to do this at the end of your production cycle.

Online tools to minify and optimize CSS can be found on this list of CSS optimizers.

Also, always put your stylesheet reference link inside the <head></head> tags because it will help your web page feel more responsive while loading.

7. Minify, Unify and Move Down JavaScript

Like CSS, never use inline JavaScript and try to minify and unify your JavaScript libraries to reduce the number of HTTP requests that need to be made in order to generate one of your web pages.

But unlike CSS, there is one really bad thing about external JavaScript files: browsers do not allow parallel downloads, which means the browser cannot download anything while it’s downloading JavaScript, resulting in making the page feel like it’s loading slowly.

So, the best strategy here is to load JavaScript last (i.e. after your CSS is loaded). To do this, place JavaScript at the bottom of your HTML document where possible. Best practice recommends doing this right before the closing <body> tag.

Example

8. Use Heading Elements Wisely

Learn to use <h1> to <h6> elements to denote your HTML’s content hierarchy. This helps make your content more meaningful for screen-reading software and search engines, as well as other user agents.

Example

<h1>This is the topmost heading</h1>
<h2>This is a sub-heading underneath the topmost heading.</h2>
<h3>This is a sub-heading underneath the h2 heading.</h3>

For blogs, I really recommend using the <h1> element for the blog post’s title instead of the site’s name because this is the most important thing for search engines.

WordPress Code Example

<h1 class="entry-title"><?php the_title(); ?></h1>

9.Use the Right HTML Element at the Right Place

Learn about all the available HTML elements and use them correctly for a semantic and meaningful content structure.

Use <em> for emphasis and <strong> for heavy emphasis, instead of <i> or <b> (which are deprecated).

Example

<em>emphasized text</em>
<strong>strongly emphasized text</strong>		

Use <p> for paragraphs. Don’t use <br /> to add a new line between paragraphs; use CSS margin and/or padding properties instead.

For a set of related elements, use:

• <ul> (unordered lists) when the order of the list items are not important
• <ol> (ordered lists) when the order of the list items are important
• <dl> (definition lists) for item/definition pairs

Don’t use <blockquote> for indentation purposes; use it when actually quoting text.

10. Don’t Use Divs for Everything

Sometimes developers end up wrapping <div> tags around multiple <div> tags that contain more <div> tags, creating a mountain of divs.

Under the latest draft of the W3C HTML specification, a <div> is a meaningless element that should be used "as an element of last resort, for when no other element is suitable."

But many use it even for menial things like displaying inline elements as block elements (instead of the display:block; CSS property).

Avoid creating mountains of divs by using them sparingly and responsibly.

11. Use an Unordered List (<ul>) for Navigation

Navigation is a very important aspect of a website design and the <ul> element combined with CSS makes your navigation menus semantic (because, after all, a navigation menu is a list of links) as well as beautiful.

Also, by convention, an unordered list for your navigation menu has been the accepted markup.

An Example of an Unordered List

<ul id="main_nav">
<li><a href="#" class="active">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Portfolio</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Blog</a></li>
<li><a href="#">Contact Us</a></li>
</ul>

CSS to Style the Unordered List into a Horizontal Navigation Bar

 #main_nav { position:absolute; right:30px; top:40px;}
  				 #main_nav li { float:left; margin-left:2px; }
  				 #main_nav li a{ font-size:16px; color:#fff; text-decoration:none; padding:8px 15px; -moz-border-radius:7px; -webkit-border-radius:7px; border-radius:7px;}
  				 #main_nav li a.active,
  			#main_nav li a:hover{  background-color:#0b86cb;  }

Output

12. Close Your Tags

Closing all your tags is a W3C specification. Some browsers may still render your pages correctly (under Quirks mode), but not closing your tags is invalid under standards.

Example

<div id="test">
<img src="images/sample.jpg" alt="sample" />
<a href="#" title="test">test</a>
<p>some sample text </p>
</div>

13. Use Lower Case Markup

It is an industry-standard practice to keep your markup lower-cased. Capitalizing your markup will work and will probably not affect how your web pages are rendered, but it does affect code readability.

Bad Practice

<DIV>
<IMG SRC="images/sample.jpg" alt="sample"/>
<A HREF="#" TITLE="TEST">test</A>
<P>some sample text</P>
</DIV>

Good Practice

<div id="test">
<img src="images/sample.jpg" alt="sample" />
<a href="#" title="test">test</a>
<p>some sample text </p>
</div>

14. Use Alt Attributes with Images

Using a meaningful alt attribute with <img> elements is a must for writing valid and semantic code.

Bad Practice

<img id="logo" src="images/bgr_logo.png"/>

<!-- has an alt attribute, which will validate, but alt value is meaningless -->
<img id="logo" src="images/bgr_logo.png" alt="brg_logo.png" />

Good Practice

<img id="logo" src="images/bgr_logo.png" alt="Six Revisions Logo" />

15.Use Title Attributes with Links (When Needed)

Using a title attribute in your anchor elements will improve accessibility when used the right way.

It is important to understand that the title attribute should be used to increase the meaning of the anchor tag.

Bad Practice

<!-- Redundant title attribute -->
<a href="http://blog.com/all-articles" title="Click Here">Click here.</a>

When a screen reader reads the anchor tag, the listener has to listen to the same text twice. What’s worse is that it doesn’t explain what the page being linked to is.

If you are just repeating the anchor’s text or aren’t intending to describe the page being linked, it’s better not to use a title at all.

Good Practice

<a href="http://blog.com/all-articles" title="A list of all articles.">Click here.</a>

16. Use Fieldset and Labels in Web Forms

Use the <label> element to label input fields. Divide input fields into logical sets using <fieldset>. Name a <fieldset> using <legend>. All of this will make your forms more understandable for users and improve the quality of your code.

Example

<fieldset>
    <legend>Personal Details</legend>
    <label for="name">name</label><input type="text" id="name" name="name" />
    <label for="email">email</label><input type="text" id="email" name="email" />
    <label for="subject">subject</label><input type="text" id="subject" name="subject" />
    <label for="message" >message</label><textarea rows="10" cols="20" id="message" name="message" ></textarea>
</fieldset>

17.Use Modular IE Fixes

You can use conditional comments to target Internet Explorer if you are having issues with your web pages.

IE 7 Example

<!--[if IE 7]>
<link rel="stylesheet" href="css/ie-7.css" media="all">
<![endif]-->

IE 6 Example

<!--[if IE 6]>
<link rel="stylesheet" href="css/ie-6.css" media="all">
<script type="text/javascript" src="js/DD_belatedPNG_0.0.8a-min.js"></script>
<script type="text/javascript">
  						DD_belatedPNG.fix('#logo');
  				</script>
<![endif]-->

However, try to make your fixes modular to future-proof your work such that when older versions of IE don’t need to be supported anymore, you just have to update your site in one place (i.e. take out the reference to the ie-6.css stylesheet).

By the way, for pixing PNG transparencies in IE6, I recommend the DD_belated PNG script (the JavaScript method referenced above).

18.Validate Your Code

Validation should not be the end-all evaluation of good work versus bad work. Just because your work validates doesn’t automatically mean it’s good code; and conversely, a work that doesn’t fully validate doesn’t mean it’s bad (if you don’t believe me, try auto-validating Google or Yahoo!).

But auto-validation services such as the free W3C markup validation service can be a useful debugger that helps you identify rendering errors.

While writing HTML, make a habit to validate frequently; this will save you from issues that are harder to pinpoint (or redo) once your work is completed and lengthier.

19. Write Consistently Formatted Code

A cleanly written and well-indented code base shows your professionalism, as well as your consideration for the other people that might need to work on your code.

Write properly indented clean markup from the start; it will increase your work’s readability.

20. Avoid Excessive Comments

While documenting your code, the purpose is to make it easier to understand, so commenting your code logic is a good thing for programming languages like PHP, Java and C#.

But markup is very much self-explanatory and commenting every line of code does not make sense in HTML/XHTML. If you find yourself commenting your HTML a lot to explain what is going on, you should review your work for semantics and appropriate naming conventions.

Related Content

• How to Make an HTML5 iPhone App
• Cheat Sheets for Front-end Web Developers
• 5 Good Habits That Will Make You a Better Coder
• Related categories: Web Development and Web Standards

About the Author

Saqib Sarwar is a freelance web developer with over 7 years of web development experience. He specializes in XHTML, CSS, PHP and WordPress development. He loves to write well-structured and clean code that validates. Get in touch with Saqib through his freelance business/blog, 960Development as well as follow him on Twitter as @saqibsarwar.

Advertise here with BSA

I love a good domain name. I sometimes look wistfully back at my youth and think about the swell URLs I would have bought if I had an inkling about what the Internet would become.

Today you’re lucky if you find a relevant, memorable domain that isn’t parked or in use — luckier still if it’s short.

With the traditional TLDs — top-level domains such as .com, .net, .org, and to some extent, locals like .ca and .co.uk — it’s getting more difficult to obtain short domain names without some creativity.

Every so often a new TLD shows up and there’s a gold-rush frenzy. When the .me extension came out, for instance, there was a bidding war on the domain name, aweso.me — a creative twist for a short and memorable URL.

I’ve long been waiting for a chance to snag a short domain name — and this is a story of how I was recently able to do so.

The Boring Technical Part

In May 2010, ICANN — the organization responsible for managing domain names and IP addresses — brought Internationalized Domain Names (IDN) to life.

This allows participating extensions to use characters and symbols from other alphabets. This is due to Unicode working with Punycode conversion.

What this meant is I was able to score the amazingly short URL ◉.ws, as well as ◉.◉.ws — in context, there are only 6 single letter domain names in existence today.

The Catch

It’s not all fun and games though. The obvious shortcoming is that ◉ (a Unicode dingbat symbol described as "fisheye") and other symbols aren’t exactly easy to type.

Secondly, most browsers (Opera and Safari are the exception) will change that character into the Unicode string: our nice circle dingbat character becomes http://xn--z1h.ws/ — not super presentational.

Email addresses using special characters (e.g. arley.mcblain@◉.ws) doesn’t work at the moment. When the actual symbol is used, Microsoft Outlook instantly crashes, and with the Unicode string, it will just throw back an error.

Lastly, and perhaps the most dumbfounding, the special characters render differently in browsers and seem immune to our CSS font styling wiles.

Font difference for the ➲ symbol – IE8 on left vs. Chrome on right.

This standard is new, there’s a lot of catching up to be done.

Why Use IDNs?

Sure, taking advantage of IDNs isn’t perfect, but it has its uses. Short URLs are not only useful on services like Twitter where every character counts, but they are a status symbol. Symbols may not be practical, but it’s cool.

I guess if you’re really fussy and find the useless symbols thing too silly, you could be practical and actually use this for what it’s for: allowing you to buy domains in other languages with accents and other previously impossible characters.

Phénoménal!

Making Your Own

If you’re interested in obtaining your own short URLs using IDN, here are the steps you should take.

Step 1: Find the Symbol You Want

A great place to start is by checking out this list of Unicode characters on Wikipedia. It’s not a complete list, but it’s pretty extensive and is a good starting point.

Step 2: Test the Symbol on a Web Page in Different Browsers

Before spending a penny, you might want to test what the character looks like in the different browsers on a demo page (like this) to prevent the browser-related madness I highlighted above.

Step 3: Check Availability

I ended up using Domain Site to check and register the domain name. Since this is relatively new, your domain name registrant might not have the capability of registering IDNs.

Step 4: Set Up the Domain Name with Your Host

Your web host will likely require that you convert the symbol to the Unicode string first. Easy enough, just use a Unicode converter tool.

Share Your Short URLs

If you were inspired to grab a short URL because of this article, link to it in the comments and show us what you got.

Related Content

• 12 Excellent Tools for Picking a Domain Name
• 250 Quick Web Design Tips (Part 1)
• 15 Tools for Monitoring a Website’s Popularity
• Related categories: Web Standards and Website Management

About the Author

Arley McBlain is a web designer, web developer, in Burlington, Ontario, Canada. If you’d like to keep in touch with the author, check out his personal site, ArleyM, and follow him on Twitter as @ArleyM.

Advertise here with BSA

The amount of code that developers encounter regularly is staggering. At any one time, a single site can make use of over five different web languages (i.e. MySQL, PHP, JavaScript, CSS, HTML).

There are a number of lesser-known and underused ways to enhance your site with a few simple but powerful files. This article aims to highlight five of these unsung heroes that can assist your site. They’re pretty easy to use and understand, and thus, can be great additions to the websites you deploy or currently run.

An Overview

Which files are we going to be examining (and producing)? Deciding which files to cover was certainly not an easy task for me, and there are many other files (such as .htaccess which we won’t cover) you can implement that can provide your website a boost.

The files I’ll talk about here were chosen for their usefulness as well as their ease of implementation. Maximum bang for our buck.

We’re going to cover robots.txt, favicon.ico, sitemap.xml, dublin.rdf and opensearch.xml. Their purposes range from helping search engines index your site accurately, to acting as usability and interoperability aids.

Let’s start with the most familiar one: robots.txt.

Robots.txt

The primary function of a robots.txt file is to declare which parts of your site should be off-limits for crawling.

By definition, the use of this file acts as an opt-out process. If there are no robots.txt for a directory on your website, by default, it’s fair game for web robots such as search engine crawlers to access and index.

While you can state exclusion commands within an HTML document through the use of a meta tag (<meta name="robots" content="noindex" />), the benefits of controlling omitted pages through a single text file is the added ease of maintenance.

Note: It’s worth mentioning that obeying the robots.txt file isn’t mandatory, so it’s not a good privacy mechanism.

This is how the robots.txt file interacts between a search engine and your website.

Creating a Robots.txt File

To create a robots.txt file the first and most obvious thing you will need is a text editor. It’s also worth pointing out that the file should be called robots.txt (or it won’t work) and it needs to exist within the root directory of your website because by default, that’s where web robots look for the file.

The next thing we need to do is figure out a list of instructions for the search engine spiders to follow. In many ways, the robot.txt’s structure is similar to CSS in that it is comprised of attribute and value pairs that dictate rules.

Another thing to note is that you can include comments inside your robots.txt file using the # (hash) character before it. This is handy for documenting your work.

Here’s a basic example telling web robots not to crawl the /members/ and /private/ directory:

 User-agent: *
 Disallow: /members/
 Disallow: /private/

The robots.txt exclusion standard only has two directives (there are also a few non-standard directives like Crawl-delay, which we’ll cover shortly).

The first standard directive is User-agent. Each robots.txt file should begin by declaring a User-agent value that explains which web robots (i.e. search crawlers) the file applies to.

Using * for the value of User-agent indicates that all web robots should follow the directives within the file;  * represents a wildcard match.

The Disallow directive points to the folders on your server that shouldn’t be accessed. The directive can point to a directory (i.e. /myprivatefolder/) or a particular file (i.e. /myfolder/folder1/myprivatefile.html).

There is a specification for robots.txt, but the rules and syntax are exceptionally simple.

Robots.txt Non-Standard Directives

Of course, whilst having a list of search engines and files you want hidden is useful, there are a few non-standard extensions to the robots.txt specification that will further boost its value to you and your website. Although these are non-standard directives, all major search crawlers acknowledge and support them.

Some of these more popular non-standard directives are:

• Sitemap: where your Sitemap.xml file is
• Allow: opposite of Disallow
• Crawl-delay: sets the number of seconds between server requests that can be made by spiders

There are other less supported directives such as Visit-time, which restricts web robots to indexing your site only between certain hours of the day.

Here’s an example of a more complex robots.txt file using non-standard directives:

 Allow: /private/public.html
 Comment: I love you Google, come on in!
 Crawl-delay: 10
 Request-rate: 1/10m # one page every 10 minutes
 Robot-version: 2.0
 Sitemap: /sitemap.xml
 Visit-time: 0500-1300 # military time format

Whilst not a standard, there is an extension for robots.txt which has mainstream support.

Favicon.ico

A favicon (short for "favourites icon") is a small image (like a desktop application’s shortcut) that represents a site.

Shown in the browser’s address bar, the favicon gives you a unique opportunity to stylise your site in a way that will add identity to browser favourites/bookmarks (both locally and through social networks).

The great thing about this file is that every major browser has built-in support for it, so it’s a solid extra file to provide.

This is how the favicon.ico file affects your site visually through the browser such as IE.

Creating a Favicon.ico file

To create a favicon, you’ll need an image or icon editor. I am a fan of Axialis IconWorkshop, but there are free editors like IcoFX that do the job well.

You can also find quite a few free online favicon tools by viewing this list of web-based favicon generators.

You need to have a 16x16px icon (or 32x32px, scaled down) that matches what you want to see in the browser.

Once you are done creating your icon’s design, save the file as "favicon.ico" in the root directory of your web server (that’s where browsers look for it by default).

Note: It’s a good idea to use the .ico file type, as some browsers don’t support PNG, GIF or JPEG file types.

To make this file work properly, refer to the location of your favicon in the <head> tags of all your HTML documents, as such:

 <head>
 <link rel="shortcut icon" type="image/vnd.microsoft.icon" href="favicon.ico" />
 <head>

The rel attribute values of "shortcut icon" or "icon" are considered acceptable and the MIME type of "vnd.microsoft.icon" (as of 2003) replaced the older type ("image/x-icon") as the official standardized favicon MIME type for .ico files on the web.

Note: While Internet Explorer (and some other browsers) will actively seek out your favicon in the root directory of your site by default (which is why you should have it there), it’s worth adding the above code into the <head> of your HTML just to make it explicitly known by other types of browser agents.

There are multiple online tools which can create a favicon from existing images.

Favicons in Apple Devices

Another standard (of sorts) has appeared in light of Apple’s iPod, iPad, and iPhone. In this situation, you can offer a 57×57 PNG, ICO or GIF file (alpha transparency supported) that can be displayed on the devices’ Home screen using the web clip feature.

Apple also recommends that you use 90-degree corners (not rounded corners, which the devices will do for you automatically) to maintain the "feel" of such icons.

To make this file work properly, place the following code into every page within your <head> tags:

 <head>
 <link rel="apple-touch-icon" href="images/icon.png" />
 </head>

For users of Apple devices, a specially produced "favicon" can be produced.

Sitemap.xml

One thing website owners worry about is getting their website indexed correctly by the major search engines like Google.

While the robots.txt file explains what files you want excluded from results, the Sitemap.xml file lists the structure of your site and its pages. It gives search engine crawlers an idea of where things are on your site.

This is how the Sitemap.xml file interacts between a search engine and your website.

As always, the first recommended course of action to produce a Sitemap is to create the XML file that will contain its code. It’s recommended that you name the file as "sitemap.xml" and provide it within the root directory of your website (as some search engines automatically seek it there).

It’s also worth noting that while you can submit your Sitemap file location directly to search engines, adding the non-standard Sitemap directive to your robots.txt file can be useful as it’s widely supported and gives spiders a push in the right direction.

Below is a basic example of how a Sitemap looks like.

 <?xml version="1.0" encoding="UTF-8"?>
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url><loc>index.html</loc></url>
 <url><loc>contact.html</loc></url>
 </urlset>

Each Sitemap file begins with a Document Type Definition (DTD) that states that the file is UTF-8 encoded, written in XML, and uses the official Sitemap schema.

Following those formalities, you simply produce a list of your URLs that exist within your website’s structure.

Each URL must be contained within two elements: <url> and <loc>. This is a very simple specification to follow, so even less experienced developers should be able to replicate this basic mechanism with little effort.

To reference your Sitemap inside your HTML documents, place this code between the <head> tags:

 <head>
 <link rel="sitemap" type="application/xml" title="Sitemap" href="sitemap.xml" />
 <head>

Just like most XML-based schemas, there is a protocol and specification to follow.

Other Sitemap Tags

While you could limit yourself to simply listing every file, there are a number of other meta-information that can be included within the <url> tag to help further define how spiders deal with or treat each page in the site — and this is where the Sitemap’s true power lies.

You can use <lastmod>, for example, to state when the resource was last modified (formatted using YYYY-MM-DD). You can add the <changefreq> element, which uses values of always, hourly, daily, weekly, monthly, yearly, and never to suggest how often a web page changes (for example, the front page of Six Revisions has a value of daily).

There is also the <priority> tag, which uses a scale of 0.0 to 1.0 that you can utilize to indicate how important a web page is to a website.

Here’s an example of using the above tags:

 <lastmod>2010-05-13</lastmod>
 <changefreq>monthly</changefreq>
 <priority>0.8</priority>

Google Webmaster Tools allows you to submit your Sitemap to initiate its analysis of your site structure.

Dublin.rdf

Ensuring you provide metadata has become big business among SEO professionals and semantics advocates. The appropriate use of HTML, metadata, microformats and well-written content improves the chances of appearing in the right search results. They also allow an increasing number of browsers and social networks to aggregate and filter the data so that they can accurately understand what your content represents.

The Dublin.rdf file acts as a container for officially recognised meta elements (provided by the DCMI specification) which can augment the semantic value of the media you provide.

If you’ve ever visited a library and tried to locate a book, you know that you will often have to flick through the library catalogs to find books based on their subject, their author, or perhaps even their title. The aim of the DCMI is to produce such a reference card for your website that will help search engines, social networks, web browsers, and other web technologies understand what your site is.

This is how the Dublin.rdf file interacts with supporting social networking mediums.

Creating a Dublin.rdf File

To begin, you need to produce the file itself (which we shall name "Dublin.rdf"). In order to maintain consistent meta details about the site (as opposed to individual DCMI meta tags for specific pages and resources), we shall create an RDF file (formatted as XML) with a reference within the HTML document to indicate that the information is available. While you can embed DCMI meta tags within HTML, RDF allows you to cache the data.

When a supporting spider or other resource that acknowledges the DCMI core sees the file, they can cache and directly relate to the information.

This doesn’t mean you shouldn’t use traditional meta tags, but the file can serve as a useful supplement.

 <?xml version="1.0"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc= "http://purl.org/dc/elements/1.1/">
 <rdf:Description rdf:about="http://www.yoursite.com/">
 <dc:contributor>Your Name</dc:contributor>
 <dc:date>2008-07-26</dc:date>
 <dc:description>This is my website.</dc:description>
 <dc:language>EN</dc:language>
 <dc:publisher>Company</dc:publisher>
 <dc:source>http://www.yoursite.com/</dc:source>
 </rdf:Description>
 </rdf:RDF>

Like most XML files, this RDF document has a DTD — and within that, you have the description element (which links to the resource being referenced).

Within the description, as you can see from the above, there are several elements (beginning with the prefix of dc:) — these hold the metadata of the page.

There’s a whole range of terms you can add (see this list of DCMI metadata terms), it’s simply a case of adding the term’s name, then giving a value as denoted by the DCMI specification. You’ll end up with a library of useful data that can improve your site’s semantics and interoperability with other sites and applications!

To make this file work properly, place the following code into every HTML document within the <head> tags:

 <head>
 <link rel="meta" type="application/rdf+xml" title="Dublin" href="dublin.rdf" />
 <head>

The Dublin.rdf file makes use of the DCMI specification to provide meta information.

OpenSearch.xml

The ability to search a website is one of the most important ways people locate content.

The OpenSearch file allows you to add a custom search engine listing (on your own site) through the search feature that appears in all modern browsers. All of the major browsers can take advantage of OpenSearch; it’s pretty durable.

While you will still want to provide a search mechanism on your website, this core enhancement complements the user’s in-browser search capabilities.

This is how the OpenSearch file interacts with your site through the browser.

Like with all things we’ve discussed thus far, we need to produce the file for the code to be placed in.

As this particular type of file doesn’t have assumed name reservations like robots.txt or sitemap.xml, we could call the file whatever we like. However, the convention for OpenSearch files is to name the file, "opensearch.xml".

You’ll want to include the code below as your starting template, then proceed to customising the required tags such as <ShortName>, <Url> and <Description> (they are case-sensitive) to describe your site.

The example used below is for Six Revisions using Google Search.

 <?xml version="1.0" encoding="UTF-8" ?>
 <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
 <ShortName>Six Revisions</ShortName>
 <Description>Search this website.</Description>
 <Image>favicon.ico</Image>
 <Url type="text/html" template="http://www.google.com/search?sitesearch=http%3A%2F%2Fwww.sixrevisions.com%2F&amp;as_q={searchTerms}"/>
 </OpenSearchDescription>

The tags included above are:

• ShortName: the title you want for your search extension
• Description: explains the purpose of the search box
• Image: this isn’t required like the others, but I recommend referencing your Favicon with it so the search feature has a unique icon
• Url: requires a MIME type and a template attribute which links to the search terms

To make this file work properly, place the following code into every page within the <head> tag:

 <link rel="search" type="application/opensearchdescription+xml" title="Website" href="opensearch.xml" />

Other OpenSearch Tags

There’s a range of additional tags we can provide. Among these are:

• AdultContent: if the site has adult material needing to be filtered, set to false
• Attribution: your copyright terms
• Contact: an email address for the point-of-contact of your site
• Developer: who made the site?
• InputEncoding and OutputEncoding: The MIME type used
• Language: i.e. EN for English
• Query: for more detailed search terms
• Tags: keywords, separated by a space
• SyndicationRight: The degree to which people can request, display or send results

Example usage of these other tags:

 <AdultContent>false</AdultContent>
 <Attribution>Copyright, Your Name 2010, Some Rights Reserved.</Attribution>
 <Contact>None@none.com</Contact>
 <Developer>Your Name</Developer>
 <InputEncoding>UTF-8</InputEncoding>
 <Language>en-us</Language>
 <OutputEncoding>UTF-8</OutputEncoding>
 <Query role="example" searchTerms="terms" />
 <Tags>Example Tags Element Website</Tags>
 <SyndicationRight>open</SyndicationRight>

Simple, Small and Effective

While this guide represents a crash course in producing these useful files, it’s worth pointing out that taking the time to understand the syntax of any language is important in order to determine what the impact of these files on your website.

These files represent a truth that there’s more to a website than HTML, CSS, and JavaScript, and while producing these files will certainly not act as a replacement for your existing code workflow, their inherent benefits make them worthy of consideration to supplement your projects. Give them a try for yourself!

Related Content

• The Top 15 Google Products for People Who Build Websites
• Performance Comparison of Major Web Browsers
• Five Ways to Speed Up Page Response Times
• Related categories: Web Development and Website Management

About the Author

Alexander Dawson is a freelance web designer, author and recreational software developer specializing in web standards, accessibility and UX design. As well as running a business called HiTechy and writing, he spends time on Twitter, SitePoint’s forums and other places, helping those in need.

Advertise here with BSA

Amongst the basic skills that fledgling designers and developers should know is the art of website validation.

Website validation consists of using a series of tools such as W3C’s Markup Validation Service that can actively seek out and explain the problems and inconsistencies within our work.

While the use of such tools has benefits (in the sense of being an automated fresh pair of eyes), a worrying trend of either over or under-dependence keeps rearing its ugly head.

This article aims to underpin the inherent issues of validating your websites through automated web services/tools and how using these tools to meet certain requirements can miss the point entirely.

Current Practices

Before we begin critiquing the valiant efforts that our noble code validators undertake (they have good intentions at least), it’s important to note that with all things in life, a balance must be struck between the practical application of validation and common sense.

We live in a modern era of enlightened thought where web standards have become a white knight, always charging towards slaying code which fails to best represent our work.

But while current practices actively request and promote using these validation tools, no web-based tool is a substitute for good judgment.

The above code may not validate, but it’s acceptable to use if there’s no good alternative.

Not Using Valid Code

The case for under-dependence can be seen by examining the Alexa Top 100 sites and using some basic W3C validation tests.

The eye-watering number of errors these popular sites produce (which escalate into the hundreds) is rather unsettling for some.

The problems for those ignoring validation altogether has been well-documented to the detriment of end users (as has the justification for following web standards) and as ignoring validation entirely makes you as guilty as those using it as a crutch, it’s worth recommending not to forsake these tools even with their shortcomings.

Amazon.com’s front page doesn’t validate, but it doesn’t mean they don’t care.

Blindly Following the "Rules"

The case for overdependence is something we need to worry about too. Those who form drug-like addictions to making everything validate or meet a certain criteria just to please an innate need for approval are on the rise.

While ensuring your code validates is generally a good thing, there are professionals who take it to such an extent that they resort to hacking their code to pieces, ignoring new and evolving standards or breaking their designs just to get the "valid" confirmation. Quite a price for a badge.

And there are even people who think validation automatically means everything’s perfect, which is worse.

There are a lot of tools out there, but you should be wary about which you rely upon.

Context is King

The thing about validation tools that beginners (and some seasoned professionals) often overlook is the value of context.

The most common problem that validation tools encounter can be summed up in the sense that they are only machines, not humans.

You see, while checking if the code you wrote is written correctly, on the surface, may seem like a simple task, that sites meet disabled users’ needs, or that text on the screen is translated properly — the very obvious truth (for those who understand the mechanics involved) is that the complexity of how humans adapt cannot be replicated effectively.

What does this design say to a machine? Nothing! It only sees the code and that’s it.

You Can Make Decisions That Robots Can’t

If you’ve seen the "The Terminator" movie, you probably have a mental image of a not-too-distant future where machines can think like humans and therefore make decisions based on adaptive thought processes, such as being able to intelligently and emotively know what makes sense.

But unlike that film, the levels of which such tools can understand context and meaning (beyond what’s physically there) simply doesn’t exist today—though that’s probably a good thing as we don’t want the W3C validator going on a rampaging killing spree against <blink> tag users, right?

There may be a time where machines are as smart as humans, but that’s not today.

Code Validation

The most notable form of code validation in use today is that of the W3C HTML and CSS validators.

The level of obedience from some designers and developers to ensure their code validates is best reflected in the way many websites actually proclaim (through the use of badges) to the end user that their code is perfect (possibly to the point of sterility).

Proclaiming the validity of your code doesn’t mean what you’ve produced is perfect.

This reminds me of the way software developers proclaim awards from download sites as justification to use their product. As I’ve mentioned previously, however, the W3C validator (despite its association) is not perfect.

Failing Because of Future Standards

It’s an established fact that the W3C validator not only examines the structure of your site but the elements or properties themselves (though they don’t understand semantic value!).

The key issue with such due diligence from these tools is that elements which are not recognised (such as those of upcoming standards like CSS3 or equally valid proprietary extensions) are often misinterpreted by developers as "unusable" or "not approved" and therefore get rejected.

Taking Stuff Out For The Sake of a Badge

It seems rather amusing to me that people are willing to omit the value of somewhat acceptable but non-standard code — CSS3 attributes specific to particular browsers, for example — to satisfy the validators, like they’re trying not to anger the Tiki gods.

What ends up happening is the validators themselves make it seem like legitimate practices which defies convention are automatically wrong, and this results in a strange psychological condition in which people too quickly limit their own actions for the sake of a machine (or the ideology it provides).

While it makes sense not to use deprecated/future-standards code, validators simply can only test against what they know.

Nothing says: "I want approval" like these well-known badges of honour from the W3C.

It should be made quite clear that people who proclaim HTML and CSS validation on the page are doing so to make themselves feel better. Unfortunately, none of your users (unless you cater specifically and strictly to web designers and developers) are likely to know what HTML even is, let alone understand or trust what the fancy validator badge is telling them!

Web Accessibility Validation

If you want a case where validators totally miss the point and where their limited testing ability is abused (to proclaim the work which is being tested against is complete), you need look no further than the accessibility validation services like Cynthia, the now debunked "Bobby" and their kin.

One key issue with validators are that they can only test against what they can see (in almost all cases this only accounts for source code).

While some of the issues in WCAG can be resolved with some helpful coding (like alt attributes on images), code doesn’t account for everything in accessibility.

Cynthia "says" your site meets WCAG guidelines, but it’s often missing several points!

The Only Way to Test for Accessibility and Usability is through People

Accessibility and usability are highly subjective issues that affect many people in many different ways, and often the way code is presented (or even the content) does not establish where key problems may lie.

Too often beginners actively use the checklist nature of these services to claim their work is accessible on the basis that a validator covered what it could (omitting the complexities which it cannot account for – such as the sensory criteria and their inhibiting factors). This key lack of understanding and the wish for a quick fix showcases that reliance of these tools isn’t ideal.

How many validators can tell you how easy to read your content is? How many of them run a screen reader over the top of your site to denote the way a blind user may find your information?

While some factors can be mechanically replicated, the problem is the tools primarily focus on code alone and therefore miss the bigger picture (and those who rely on them also get caught up in this lack of awareness).

Without the background knowledge of how such web or software applications function, a scary number of people simply use them as an alternative to properly learning what they’re doing.

Do you speak Latin? No? This content would pass as accessible, readable and valid!

The state of accessibility tools is so bad that I advise people not to use them in favour of proper human checking.

The myth that tools can do things at an equal skill level of a human is far from the truth and while the W3C validators can be helpful, accessibility tools are too biased to be credited.

Translation Troubles

Confusion (as denoted above) in relation to such validation tools comes in many forms. Whether it’s the mystical messages the W3C validator produces (which beginners may not understand), the lack of fair warning that these tools should be used "as part of a balanced diet", or that these tools are often much more limited in what they can offer than you would be led to believe.

One of the more comical examples of automated tools going crazy can be seen through translation tools such as those provided by Babel fish or Google, which again proves that nothing is better than humans.

Google Translate is popular amongst websites for giving "rough" language translations.

One of the key elements of human languages is that words can have more than one meaning (and deciding which instance is in use can be tricky for machines – a case of context).

In accessibility, the issues of vision can be anything from total loss of eyesight right down to a case of color blindness. Because of this, a language translator will simply go for a literal meaning of the word rather than the context in which it’s used which can reduce your content into a scrambled illegible mess which doesn’t help your visitors (especially if they have learning difficulties).

While of course translation tools aren’t code validators, they do in fact perform a similar service. By taking a known list of criteria (whether code, words or something else), they attempt to check that something accurately portrays what it’s intended to.

If, however, you use something it doesn’t expect (like a new word in translation tools or a new property in the W3C validator), it will report it as a failing on your behalf.

Such reliance on validation tools for "perfect" results is therefore unjustified and can limit yourself to the detriment of your audience.

A Translation Exercise to Test the Idea

If you take a block of content from a website, paste it into Google Translate, translate it to another language, and then translate it back into English, you’ll see for yourself how badly these validators of content conversion are at the job. It can give you hours (if you’re really that much of a geek) of comedy in a few sessions!

See how the same sentence has been wrongly translated? It’s not uncommon!

The Silver Bullet

Knowing that validation tools are far from perfect is an important lesson to learn. Many people assume that such tools are an all-knowing oracle that accounts for everything your users or browsers may suffer.

While it’s wrong to say that these tools aren’t useful, it’s important to understand that the validation tools should not be used as a guarantee of accuracy, conformance or accessibility (in your visitor’s best interests).

A valid site should never be achieved if it sacrifices the progression of web standards, unjustly acts as a badge of honour or attempts to justify the end of the build process.

Knowing how and when to use code and the difference between right and wrong is a tough process we all undergo during our education.

The truth about validators is that sometimes being invalid is the right thing to do, and there are many occasions where a "valid" website is nowhere near as valid as you might like to think it is in terms of code semantics, accessibility or the user experience.

I hope that all of this will serve as a wakeup call to the generation of coders who either ignore or abuse validation services. These tools are not a silver bullet or a substitute for being human!

Related Content

• Five Technologies That Will Keep Shaping the Web in 2010
• Best Practices for Hints and Validation in Web Forms
• What is The Future of Web Development?
• Related categories: Web Standards and Web Development

About the Author

Alexander Dawson is a freelance web designer, author and recreational software developer specializing in web standards, accessibility and UX design. As well as running a business called HiTechy and writing, he spends time on Twitter, SitePoint’s forums and other places, helping those in need.

Advertise here with BSA

Though W3C’s CSS3 specifications aren’t finalized yet, modern web browsers such as Mozilla Firefox, Opera, and WebKit-based browsers already have full or partial support for them.

As a web developer, it’s crucial to be well-informed about modern and future web standards. To help you stay ahead of the curve – here are 20 excellent resources on the topic of CSS3.

1. CSS3 Progress Report

The CSS3 Progress Report is a web page by the CSS Working Group outlining the current status of all the CSS3 modules. For would-be contributors, this may be a helpful resource in discovering places where you can potentially contribute.

2. Get Started with CSS 3

Web Monkey has a tutorial on how to get started with CSS3. It will give you an overview of some CSS3 features that are already supported by modern browsers. This is a great article to read for those that are just beginning to explore CSS3.

3. Progressive Enhancement with CSS 3

Opera – one of the web browsers in the forefront of supporting CSS3 specs – has an excellent tutorial on a progressive enhancement approach to CSS3 usage that discusses how you can utilize CSS3 for modern/cutting-edge browsers yet still have a design that’s accessible to older browsers that don’t support it.

4. Accessibility Features of CSS

With the rise in popularity of mobile hand held devices and non-traditional web browsers such as screen readers, the CSS Working Group puts accessibility as one of the leading issues that will be addressed in CSS3. This W3C document outlines some of the accessibility features and considerations that are inherent in current and future CSS3 specifications.

5. Introduction to CSS3 (Design Shack)

In this 5-part series, Design Shack gives readers an excellent induction to the world of CSS3. The article series goes through an overview of CSS3 in plain-speak and talks about some CSS3 techniques and topics such as borders and text effects.

6. CSS3 . Info

CSS3 . Info is an enormously comprehensive site about all things CSS3-related. They share news, interviews, and resources from around the web regarding CSS3. CSS3 . Info also has a demo section called CSS3 Previews so that you can see CSS3 modules and features at work for browsers that support them such as Opera and WebKit-based browsers.

7. CSS Advanced Layout Module

Learn about one of the more popular modules in CSS 3 specs: the Advanced Layout Module. This resource is W3C’s working draft and will show you just how great CSS3 will be for us developers.

8. Six Questions: Eric Meyer on CSS3

Six Revisions was fortunate enough to discuss CSS3 with celebrated CSS expert, Eric Meyer. In this interview, Eric Meyer talks about what excites him the most about CSS3, the modular approach to CSS3 specs development, and JavaScript’s relationship to CSS3.

9. CSS3 properties tests for webkit based browsers

In this live demonstration, you’ll find properties currently supported (and unsupported) by WebKit-based browsers such as Safari; it also provides you information about iPhone’s support of these properties.

10. WaSP Community CSS3 Feedback

This article is an excellent summary of the feedback received from the Web Standards Project (WaSP) blog post entitled, “Tell the CSS WG what you want from CSS3“. It’s a great read to see what web developers around the world think about current CSS3 specs.

11. CSS 3 attribute selectors

An exciting improvement in CSS3 is the ability for very complex and specific DOM selection. This tutorial on Dev.Opera shows you the potentials of the new attribute selection features in CSS3.

12. W3C: Selectors

W3C’s working draft of CSS3 Selectors is an excellent introduction into the concept of Selectors in CSS3.

13. Conversation with CSS 3 team

XHTML.com’s interview of Bert Bos (former chairman of W3C’s CSS Working Group) is an insightful look at CSS3 development through the eyes of a leading expert in CSS.

14. The fundamental problems with CSS3

This article by Matt Wilcox discusses some of the current issues surrounding CSS3.

15. CSS Working Group Blog

The people in charge of maintaining and developing CSS standards – the CSS Working Group (CSS WG)  -  has a regularly updated weblog that shares useful information about CSS3.

16. Rounded Corner Boxes the CSS3 Way

24 Ways, an annual online publication that puts out articles by top web professionals, has a tutorial on rounded corner boxes written by CSS expert Andy Budd. The tutorial showcases one of CSS3′s styling improvements: rounded corners without using CSS backgrounds.

17. Push Your Web Design Into The Future With CSS3

Smashing Magazine’s article on CSS3 by graphic/web designer Chris Spooner delves into crafting web designs that leverage current CSS3 specs. It’s an inspiring scrutiny of the things that you can do with CSS3 – right now.

18. Introduction to CSS3 Transparency

This article explores and explains the concepts CSS3 transparency; a concept that’s part of the CSS Color Module.

19. Styling Forms with Attribute Selectors

Dev.Opera showcases the benefits of attribute selectors in this “learning-by-doing” tutorial which deals with styling web forms.

20. 5 Techniques to Acquaint You With CSS 3

Practice makes perfect; this tutorial from NETTUTS shows you how to learn about CSS3 by using it. This article covers things like adding drop shadows to page elements and changing an element’s opacity.

Are you using CSS3 today?

Have you incorporated CSS3 into your web development practices? Where are you at in terms of learning about CSS3? Share your thoughts and experiences with all of us in the comment section.

Related content

• Resetting Your Styles with CSS Reset
• Structural Naming Convention in CSS
• Innovative (and Experimental) CSS Examples and Techniques
• 8 CSS Techniques for Charting Data

Advertise here with BSA

Testing for web accessibility (how usable a website is by individuals with disabilities) is an often neglected part of web design and development. Web accessibility is important not only because your content will reach a wider range of audience, but also because correcting web accessibility issues have secondary benefits such as cleaner and more semantic code and better indexibility on search engines.

In this post, you’ll find 10 free tools to help you evaluate and correct issues which decrease your website’s accessibility. There was a high emphasis on the ease-of-use during the selection of these tools.

1. Firefox Accessibility Extension

The Firefox Accessibility Extension is a Firefox toolbar that allows you to inspect every aspect of a web page to determine its accessibility. A helpful toolbar feature is the Text Equivalents menu which allows you to generate lists of elements such as images and links to see whether each are standards-compliant. You can also launch 3rd party applications such as the WC3 HTML Validator and Link Checker services directly from the toolbar.

2. aDesigner

aDesigner, developed by IBM, simulates the experience of visually-impaired individuals so that designers can better understand how a web page is interpreted by screen readers. It has a plenty of features including a summary and detailed report of compliancy to web accessibility guidelines and simulations for blind or low-vision impairment.

3. EvalAccess

EvalAccess is a web-based service for testing your website’s accessibility. You can either point to a web page, an entire website, or directly enter your HTML source code. It checks your mark-up against the WC3′s Web Content Accessibility Guidelines (WCAG 1.0) and provides a summary of the number of errors and warnings and a breakdown of each error.

4. WebAnywhere

WebAnywhere is a browser-based web application that works similarly to screen readers such as JAWS. It’s an excellent way to see how a web page is read and navigated by assistive technologies.

5. Web Accessibility Inspector

The Web Accessibility Inspector, developed by Fujitsu, is a desktop application that indicates web accessibility issues. You can specify a file, folder, or URL to run the inspection on. It has the "View on the screen" option which opens the web page in a browser window with markers that point out elements that have issues.

6. Vischeck

Vischeck simulates how a web page or image will look if viewed by people affected with color-blindness. It simulates three types of color-blindness. You can conduct the test by entering a URL or uploading images.

7. Accessibility Color Wheel

The Accessibility Color Wheel is a web-based tool to help you select the background color and font color. You can enter the hexadecimal values of the colors you want to test, or you can hover over the color wheel to select colors.

8. Colour Contrast Analyser

The Colour Contrast Analyser, developed by Juicy Studio, is a Firefox extension (currently in alpha) that checks all the elements in the Document Object Model for color contrast to insure that content is accessible by people who are color-blind or affected by other visual-impairments. It uses the color and brightness differences algorithm suggested by the WC3 "Techniques For Accessibility Evaluation And Repair Tools" (AERT).

Juicy Studio also has other web accessibility evaluation tools such as the Readability Test, CSS Analyser, and Image Analyser.

9. TAW Web Accessibility Test

The TAW Web Accessibility Test evaluates your website’s accessibility based on the WCAG 1.0. It marks trouble spots directly on the web page, allowing you to quickly see where the errors are. Clicking on the error/warning indicator will bump you down to a summary of the issue. It’s a great way to visualize the areas of a web page that needs work.

10. Web Accessibility Toolbar

The Web Accessibility Toolbar (WAT) is an extension for Internet Explorer or Opera that offers designers a ton of useful tools and features to help in the analysis of a web page’s accessibility. One helpful feature is the Greyscale (Colour > Greyscale) feature which renders the web page in black in white to help you find low-contrast spots in the design.

What’s your viewpoint on web accessibility?

How important is it in your web projects? Do you go out of your way to make your projects accessible? Share your thoughts in the comments section below.