Browser differences are a fact

Although they are supposed to give a similar end result, the W3C specifications browser-makers follow are 'recommendations' and not ultimatums. There is room for negotiation, and whichever browser maker you are loyal to has taken the liberty of defining default styles to items which you may not be aware of. There comes a time when you realize you’re having more difficulties than you should. Separating content and layout is supposed to lead to less browser fussiness, right?

Level the Playing field

As a designer, you need to be aware of styling differences and take steps to get browsers agreeing before adding embellishment to your markup. This article goes over the importants of keeping the browser out of the legacy quirks mode and using simple CSS rules to initialize compliant browsers into a common style. For example, you may have noticed on certain sites that Opera renders an unordered list way to the left of the position Mozilla Firefox and IE render it. This issue is totally avoidable with very little effort. You may want to look at information on neutralizing the default CSS of different browsers.

Using :hover

Once you get used to CSS for styling you begin to appreciate the :hover pseudo-class much more. Except when you load the page in IE, which only supports a:hover. PeterNed has written an IE behavior, which is basically a JavaScript globally applied to specific tags, that solves this issue quite cleanly. Absolute purists be warned: it is a slippery slope into browser-specific styles. I would not suggest including this in your base template for a website, but when you really need the capacity, it is available. Hopefully IE7 will take away the need for this hack.

Stay Current

Surely the task of tracking CSS bugs as they are released is too huge for one person. So don’t worry about it, just check positioniseverything.net every once in a while and get the info you need.

Archived at my site

Whether you realize it or not, semantic markup and search engine optimization (SEO) go hand in hand. The purpose of clean, meaningful markup is organize you data so that it is identified more clearly to humans and software alike. The purpose of SEO is to increase the readability of your markup to search engines. Those two aren’t far removed from each other because search engine optimization is simply correcting for non-semantic markup after the fact. Consider that when trying to pitch it to a client.

I have summarized a few simple markup practices that will dramatically ‘optimize’ your information for search engine consumption, and guess what– More people will actually understand and receive it too! Before you peruse the items and decide it will impede your design options or flexibility, allow me to correct your misconception.

Use lists - group things meaningfully, not just visually

Using the unordered list (<ul>) is a perfect way of grouping related items, be they navigation links or gallery thumbnails. If the numbering is important use the ordered list (<ol>). There are other lists available in XHTML 2, such as the super-cool and rather anticipated navigation list (<nl>), which is for, you guessed it, navigation! Even though the <ul> was not designed specifically for it, the W3C currently recommends the practice of using it to group menu items. If you think it can’t look slick or some common menu style isn’t possible with the <ul>, try browsing these CSS <ul> menu examples

Use those header tags properly!

This is a simple yet ridiculously misused method of organizing your content. The header tags should be used to guide and label the flow of content on your site. Don’t take my word for it; the W3 clears this up quite nicely, explaining the fundamental use for header tags in the validator results when ‘Show Outline’ is selected:

Below is an outline for this document, automatically generated from the heading tags (<h1> through <h6>).
. . .
If this does not look like a real outline, it is likely that the heading tags are not being used properly. (Headings should reflect the logical structure of the document; they should not be used simply to add emphasis, or to change the font size.)

The outline option is a very useful tool that I recommend to everyone.

Use <abbr> and <acronymn> tags

As outlined in a previous article, these two tags semantically associate abbreviations and acronyms with their full descriptions or terms. Not only do visual users have a reminder if they are uncertain of a term, but screen readers can skip situations where acronyms like NATO might be spoken to the user as a string of letters.

Use metadata tags for links, images etc

Using title and alt attributes is considered by many to be staple optimization. However, when using proper semantic markup, it should happen regardless of your efforts to optimize as it is the last resort for many situations including elements improperly loading, plug-ins not available, styling or client-side scripting disabled, or text and non-visual browsing.

Semantic Markup: Optimizing for Now and the Future

While the additions of hidden links or keywords may be a cute trick today, search engines are becoming smarter all the time, and hacks that worked yesterday may not work today. In fact, it may hurt your standing if it is widely considered an underhanded practice! Google puts it best when they recommend that you ask yourself Does this help my users? Would I do this if search engines didn’t exist? Sticking to semantic markup means your sites will be optimized for now and in 5 years with no further effort on your part. It may just be me, but that seems like the only way to go.

Archived at my site

The <abbr> and <acronym> tags are extremely useful tags that seem to be completely ignored by the majority of the web development populous. I want to tell you why they are useful (and necessary!) for properly communicating to the users that visit your site. I would also like to discuss sensible practice for these tags.

They have been around forever (present in HTML 4 through XHTML 2, although <acronym> is deprecated in the latter), but nevertheless they are used very sparingly by even standards-minded individuals. Their purpose is simple: to provide the full meaning of an abbreviation or acronym without necessitating a change or explanation in the copy of your design. Obviously, in the interest of creating semantic markup, you should use the tag that fits the situation (I worked for the Krannert School of Mgmt while earning my degree in Purdue’s CGT program). Now that we’re all understanding the basics, I pose a few questions.

What are you talking about? Why should I bother?

First off, why use them? I just described what they did, but why is it important? Well, in an earlier article I mentioned search engine optimization (SEO). What if you were not familiar with that term? You would have to look it up, which is an inconvenient task, distracting you from my point and probably causing minor frustration. What if you are using a screen reader? A screen reader is not a dictionary, and a page with many abbreviations will sound strange having all those letters read one at a time to the user. These two tags sidestep that awkwardness, providing the screen reader with whole words to speak instead of possibly meaningless letters. The last and possibly most important is SEO. By giving your acronym or abbreviation a meaning, you are telling the search engines that the acronym is associated with your term. It doesn’t take a rocket scientist to figure out that this is a Good Thing™.

These tags are easy. The syntax requires a single attribute, either title or full for both tags, although certain versions of XHTML will contain much richer functionality in good times yet unseen.

<abbr full="abbreviation">abbr</abbr>
or
<acronym title="Three Letter Acronym">TLA</acronym>


OK, so you’ll at least give it a try? Excellent. You are now in the murky waters of unestablished conventions. You may not want to just plaster the tag on every Mr. and Dr., and then again you may want to. Anyone claiming that you should or shouldn’t doesn’t really know, because as I stated before the group of people that use these tags could probably fit in an elevator together and as such there is no solid data for best practices. You’ll just have to use your best judgement, and that may not be easy.

When do I use these? Balancing backward and forward compatibility

As I pointed out earlier, the W3 is killing <acronym> for some reason. Although an acronym is logically a type of abbreviation, it is semantically different that an abbr, so why they’re doing this is beyond me. Especially when Internet Explorer does not support <abbr>. So as a standalone tag, you can make it work for users now, or you can make it work for future browsers. Furthermore, something like Inc. is not an acronym, and you should avoid tagging content with markup that is deceptive (although it’s not as deceptive as using tabular data tags to position elements on a page, HA). I can’t offer a solution really because it is your design and you need to decide which users should benefit the most from it. If you are looking for inspiration on simultaneously satisfying the needs of the old browsers, the future browsers, and the non-sighted, I suggest you take a peek at Colin Lieberman’s ALA article entitled The Accessibilty Hat Trick: Getting Abbreviations Right.

Not that I am an expert, but I find that a combination of visual explanation and use of the appropriate tag is best for conveying your information. Notice above, where I mentioned SEO, first spelling it out, then providing the common acronym. Thereafter, I have simply used the acronym. Users will be introduced to the concept before the acronym and will not even need to mouse over to figure it out, although if they forget they can be reminded quickly. Screen readers will still have a reference and people who are hearing this will still hear it as full sentences.

Another nice touch is to use the CSS property cursor: help;. You may see that the cursor changes to a question mark when you mouse over some of my abbreviations. This isn’t automatic. Given that some browsers will underline the <abbr> and <acronym> to help visual users discover them, I feel it provides useful feedback distinguishing it from a link. Wow, with all that, I end up delivering more text than if I had just spelled it out! Well, on this blog unfortunately I don’t have a choice. However, if you’re designing and styling the site, you just need to write it once in the stylesheet and you’re set:

abbr, acronym
     {
     cursor: help;
     }


Then you’re back down to just the tag and its contextual meaning. Obvously this would be a convenient place to turn that default border-bottom off that occurrs in some browsers if it suits you, but I usually leave it for usability’s sake since it is a piece of hypertext.

Closing Thought

As developers and designers jump on the standards bandwagon, we will see more sites incorporating this feature. As I said before, it is often useful, sometimes necessary, and always advantageous for those of us concerned with delivering content to the widest audience possible.

Archived at my site

Since its inception, the web has always been a communication tool, although for a long time many individuals and companies have only seen it as a marketing venue, much like a big, animated billboard. I’m going to discuss the need for and benefits of designing a website using standards-based, semantic markup, and its implications in today's computing environment.

It's been a wild decade for those who have been involved in web development. At first, people treated the web as a magazine layout, needing identical end results in a wide range of software products. We all know the sad stories of spacer images, seemingly endless recursion of nested tables to achieve positioning, browser detection, and 47 occurrences of a font tag for one page of text, just so the webpage looks perfect.

Most of the major browser conflicts have been resolved, and we have a somewhat level playing field for delivering content, with emphasis on bigger issues like interoperability and device-independence. It's high time we started worrying about delivering the message before formatting the look. More and more people access your information in more and more ways every day. You do want them to get your message, right?

Additionally, everyone starts to worry about appropriating time and energy to search engine optimization (SEO) after making everything look right. What if I told you that 90% of your efforts could be avoided simply by actually following a few rules of thumb that you (should) already know?

Rule #1 - Listen to the Man

I’m talking about our buddy Timothy Berners-Lee, not the Haliburton executive staff. His original vision of the world wide web was a non-linear series of connections (links) between nodes (pages), made up of human-readable content for multimedia presentation spread across computers all over the planet. By human-readable we’re referring to the source code of the document itself, not the presentation layer that a browser displays, although that is super important too!

Throwing junk markup for presentation in your HTML is like throwing a spike strip on the Nascar track. The browser has a set of standards it follows for organizing the structure of your content, and your presentational markup is purposefully getting in its way. Multiply that by the dozens of devices you may receive requests from in any given day and whammo, the signal gets lost in the noise quite quickly. We’ve all heard it before, but Keep It Simple, Stupid. And don’t even start about your latest Web2.0 mega-project. If no one but Firefox 1.5 users can use it, your viral bittorrent-based AJAX framework for social networking is no more useful than the empty stapler sitting next to me.

Rule #2 - Create a hierarchy with your markup

There is a reason that those six header tags exist! Consider the following: your friend is reading a newspaper article to you, but instead of telling you the headline says this or the image caption says that he tells you that the big sans-serif text says this and the smaller bold text says that. Not quite as helpful, is it?

This articulation of communication is what semantic markup is all about. An explicit diagram of your information is delivered and understood by anyone or anything that happens to ask for it, instead of a mess which only a subsection of users with specific browsers can understand (which is admittedly the majority). Once you are projecting clear information, it becomes much more useful and flexible, whatever the viewer's needs.

Rule #3 - It’s not what you can see, it's the browser

I'm going to go out on a limb and say that most web developers are not literally blind. That makes it easy to forget that not all components of the web have the same advantages. Screen readers, search bots, PDAs, and cell phone browsers all face obstacles that prevent them from correctly interpreting unneeded frill markup in your HTML.

What if an image doesn't load properly, or a user has elected to turn image loading off? Does your layout depend on it loading to communicate some information? What about that table of price ranges for your service? How can a non-sighted person parse and retrieve the information he needs efficiently? What about your site navigation? Is there a failsafe in place for cases in which a user cannot or will not allow JavaScript to control the behavior of the menu?

These are all very common themes when making an effort to ensure the successful delivery of information to all who want it. Rather than relying on hacks and workarounds to 'fix' specific issues, it is much more simple to start from the bottom and design around your information, not your presentation.

An Example

As proof of the weight of this issue I am going to point to a wonderful semantic retooling walkthrough from the folks over at ALA. It is an excellent, professional example and the effects of the process are dramatic when it is finished. If nothing else skim the how-to then read about the bandwidth savings and SEO… I think you may start reading from the beginning then! It is interesting to note that the Slashcode team did indeed incorporate the concepts outlined by Mr. Frommelt and Slashdot has started enjoying the benefits of semantic information design. Remember, every site will need individual care to come up with the best solution.

There are volumes of literature to help you get into the groove of using standards-based, semantic markup. An excellent set of commentaries and tutorials can be found at A List Apart (ALA). Or, if you prefer reading paper you can get a dense chunk of ALA via Jeffrey Zeldman’s book Designing with Web Standards.

Once you've set up a site with semantic markup it makes the entire development process easier, from dynamic content to universal accessibility. But we’ll get to all of that at a later date…

Archived at my site