Writing Semantically correct HTML

“I see dead HTML tags”

Seriously. Sometimes I’m amazed at how the Web is still able to function with the absolute junk with which web pages are built.

CSS is almost 10 years old, but it still doesn’t render uniformly across browsers (even latest ones). And the fact that it is severely crippled doesn’t help either (you can’t even vertically center text without applying half a dozen hacks!).

JavaScript, the poor thing got crippled during its inception due to the infamous browser wars. It’s precariously carrying the burden of Web 2.0 on its worthy yet twisted shoulders.

HTML … well that’s what this post is all about. HTML on the web has gone through many phases. First there was the plain text phase, with newly introduced presentational tags such as <font> and <color>. Then came the Era of the Table. We’d see tables within tables within tables within tables being used to keep the layout of a page in place. Tables were the easiest thing to use for column layouts back then.

But then came CSS with its call to developers to shun tables and use divs and CSS rules for layout. Most of that stuff fell on deaf ears. So now we see a web where a large number of sites are made by developers who are either infected with divitis, or they haven’t looked beyond tables and inline styles. Either everything is a <div> in these sites, or a table element. Headings, lists, blocks of text, you name it, it’s a div/table.

What I want to list in this post are some rules to remember while writing HTML, such that the resulting HTML:

• Has semantic meaning. The next developer to work on your markup will get a good idea of what it represents if your HTML is semantically correct and has ‘meaning’ (rather than a huge table within table within table…)
• Is short and concise
• Is primarily the structure of your page (as opposed to having presentational and structural properties)

The first thing to keep in mind is to use the correct tag at the correct place.

<h1> – <h5>: These tags should be used for your page name and other section headings. You can set these tags to both inline and block displays to suit your needs. They are SEO friendly as well.

<div>: You should use the divider primarily for layout purposes. A basic rule of thumb should be that if a div itself has any content in it, then you should rethink your use of it, and maybe replace it with a list item (if you’re making tabs or a ‘collection’ of items), span (inline text formatting), paragraph (block error messages) or maybe you don’t even need an encompassing tag for your content (think unnecessary boxing of images into divs).

<ul>, <ol>, <li>: Very versatile tags, should be used for both vertical and horizontal (tabs) lists. Also consider using lists for structures of data such as galleries, menus and draggable items. They work really well when floated as well.

<span>: Tag of choice for formatting inline text. It is essential however that you know that you don’t have to use it every time. There are other tags, such as <i>, <pre>, <dfn>, <code>, <strong> etc that you can use in most cases. Remember that you should use these tags according to the context of your site, e.g. <strong> doesn’t necessarily have to be ‘bold’ text. You can give it any style that applies to emphasized text in your page’s layout. Note that these tags will give structure to your data, through CSS you will set their presentational properties, and actually define what, say a <strong> tag will look like.

<label>: I’ve seen many forms that don’t use this tag. I’ve seen JavaScript that is doing what this tag automatically does for you in your forms (click sets focus to related input field). This should not be so. Your forms should always make use of this tag to describe what the user should input in a field. Be sure to use the ‘for’ attribute to link a <label> to its <input> tag.

<p>: This tag should be considered when you’re writing welcome/instructional/advert text on your webpage. Note that usually this text is encompassed in a div or other structure. <p> works just fine in these cases.

<table>: Use for displaying tabular data only. Remember to use the <thead> and <tbody> children tags.

<a>: Use for links. Also work really well in block display, so consider using them where you might be using divs with onclick events and cursor set to pointer.

These are the most commonly used tags out there. Be warned that you will need to swallow the bitter pill of CSS to make full use of some of the above tags, especially divs and list items.

Hopefully this rant makes some sense to you and will help you in structuring your pages better. If you think I got something wrong, comment and be heard!

Fix for the Firefox/CSS one page printing bug

I ran into Firefox’s CSS printing bug that would only print one page and let the content overflow (without clipping the page). The actual bug is documented here by Mozilla.

After scouring the Net for a fix, I found that it can be caused due to a number of reasons. Here’s the list of fixes that should help you out if you’re facing this bug:

Floating Elements
You need to unfloat all floated elements in your CSS for print media, like so:

.my-floated-elements {
float: none !important;
}

Overflow
Overflow must be set to visible for elements that have might have fancy overflow settings:

.css-element {
overflow: visible !important;
}

It’s always good to set this property for the <body> tag (or any other topmost parent element that is housing contents to be printed). Additionally, in some cases, overflow: scroll might work in some cases instead of overflow: visible. It greatly depends on your layout.

Position
If your elements are positioned absolutely, then you might need to position them relatively:

.css-element {
position: relative;
}

Height
If the height of your body is set to 100%, that may also cause a problem. Try unsetting this property.

UPDATE
Thanks to Gérald Champavert for pointing out that  setting width to ‘auto’ for container divs might also help in solving the problem.

Standards Compliant Web Development Starter

With browsers paying more attention to web standards, and W3C working towards more mature ones, now is a great time for developers to embrace these standards, and make their lives easier.

So what does it take to ditch your table layouts, inline styles, deprecated HTML tags and rampant Javascript snippets? LOTS of reading, LOTS of patience and a shoulder to cry on. Commitment to code quality and standards doesn’t hurt either, but more on that later.

So to make this journey of the everyday web developer easier, here’s a linkfest of references scattered across the web that will (should =p) help in getting up to speed with the latest web standard compliant coding techniques.

To get in the mood, it’ll help to read 12 Lessons for Those Afraid of CSS and Standards first.

Separation of Content and Presentation

• What’s that??? (hint: you’re already doing that if you’re not using the <font>, <strike> and other presentational HTML tags)
• An interesting read.

XHTML
Basics

• W3Schools – the home of web standards.
• Differences between HTML and XHTML – there are very few differences when it comes to everyday development. Something good to know.
• Get the proper DOCTYPE for your XHTML page.
• Check which tags are deprecated.

Layout (Floating & Positioning, CSS Columns and Tableless Forms)
Basically you’ll be using <div> for layout and positioning of content, <span> for formatting different looking text, <ul>, <ol> & <li> for ordered items (lists) and <fieldset>, <label> & <input> for your form elements.

• Tableless forms
• Understanding floats
• CSS Float Theory: Things you should know
• Faux Columns

CSS

• CSS FAQ – nice but slightly boring
• Practical CSS Layout Tips, Tricks & Techniques – good to read before converting your tables to divs.
• 20 CSS Tips and Tricks – be sure to have a look before Googling your problem.

Javascript (a little bit of Ajax as well)
Basically you’d want to have your Javascript separated from your XHTML, it’s called Unobtrusive Javascript if you like buzzwords. Benefits include code reuse, better OO design, less loading time for pages etc.

• Using Javascript for good, not evil – short presentation, contains the gist of unobtrusive javascript.
• Unobtrusive Javascript – very good reference before you get started on your Javascript design.
• If you’ve never picked up a proper Javascript reference, and have learnt it from snippets, these lectures by Douglas Crockford are a must see. These will change the way you code Javascript, guaranteed!! (Yes, I will keep recommending these lectures for ever and ever and ever … )
• Code Conventions and best practices
• Mastering JSON (Javascript Object Notation) – lightweight and way cooler than XML.
• Ajax Patterns – Ajax is already pretty messed up, doesn’t hurt if we follow these patterns and stay away from the pitfalls.

CheatSheets!

• CSS
• Javascript
• HTML Entities – using ‘…’ instead of ‘…’ and other wacky stuff

Sites to follow
Before turning to Google for your searching needs, consult these sites.

• A List Apart
• Veerle’s blog 2.0 – Webdesign – XHTML CSS | Graphics Design
• Web Developer’s Handbook

When coding for the web, it is important to strike a balance between standards and practicality. It may take you twice as long to code something which is standards compliant, then something you can cook together while bending the standards. Differences in the 4 major browsers (IE, FF, Safari & Opera) also won’t make you life any easier.

Be sure to comment any links that you think are useful!!

CSS Architecture – Less is Good

Was handed the task of deciding on how to organize CSS for a project. Since the site is already up and running, with 5 different stylesheets for the entire thing (don’t ask), and we were supposed to redesign the organization of the CSS, so I thought, hey, lets just follow how it’s being done right now.

So I google for half a day, reading through various blogs and articles. Architecting CSS and Redundancy vs Dependancy were a good read. I’m sure there’s some good stuff on A List Apart as well, though I didn’t get a chance to have a look. :/

Anyhow, I come up with a long and complicated proposal about how we should separate the CSS into 6 different files, based on different tag categories (based on the stuff I’d read online …), e.g.
layout.css has styles for <div>, <span>, <iframe> etc …
tables.css has styles for … duh … <table>, <tr> etc …

After deliberating over the design for a few hours, people with more experience in CSS said that I should go for the 1 stylesheet per UI look and feel instead of having 6 files for the entire thing. It would needlessly complicate managing styles.

I guess this is a common mistake made by people relatively new to CSS. Unlike other programing paradigms, in CSS, simplicity is good. Rather than having things modularized, decoupled, OODified etc etc, your concentration should be on deciding proper rule inheritance and re-usability. Organization over multiple files comes second to good rule selection and distribution.

My rule of thumb is that if you have > 3 stylesheets for 1 look and feel, you’re doing something wrong. Rethink. Beware the 3+ eyed CSS monster.

Link CSS class ignored in IE – quick fix

If you have a CSS rule like

body a {
/* default styling */
}

and there’s a case where you want to apply a different class to an anchor (link) by doing

CSS
a.myClass {
/* new style */
}

HTML
<a href="foobar.html" class="myClass">....</a>

then your efforts will be shot down by our good ol’ friend IE 6. To make it work in Internet Explorer, one technique is to use the id selector for your classes, like so

CSS
#linkContainer a {
/* new style */
}

HTML
<span id="linkContainer">
<a href="foobar.html">....</a>
</span>

You can use any other tag in place of the span, but I prefer it since it doesn’t have an effect on the layout mostly.

Images with border effects and onclick – IE problem

These days I’m working on an Ajax driven photo customization UI where the user can select from a range of frames that they can put on the photo. In the middle of the page is their photo, and in the right corner there’s a scrollable table with frames (2 in each row).

Everything’s hunky dory until I decide to add a border effect on frame images, so that on mouseover (or hover in CSS) the border increases (pretty standard stuff). I go ahead and add the following in the stylesheet and code respectively:

CSS:
img.frame {
border:#80A7D2;
border-width:1px;
border-style:solid;
margin:3px;
}
img.frame:hover {
border:width:2px;
margin:2px;
}

HTML:
<img class="frame" src="foo" alt="bar" onclick="doStuff()"/>

Problem
This gives me a nice border effect and the onclick of the <img> works as expected in FireFox. But when I verify this in IE, there’s no border effect whatsoever.

Solution Part 1
So I look at some legacy code elsewhere in the application, because there are areas in which this border effect is being used (albeit slightly differently), and what results is an encapsulation of the <img> tag with an <a> tag. The style is also changed to apply it to the anchor instead of the image:

CSS:
a.frame_holder {
border:#80A7D2;
border-width:1px;
border-style:solid;
margin:3px;
display:block;
}
a.frame_holder:hover {
border:width:2px;
margin:2px;
display:block;
}

HTML:
<a class="frame_holder" href="#"><img src="foo" alt="bar" onclick="doStuff()"/></a>

The border effect doesn’t work unless you set the display type to ‘block’. Another problem is the href=”#” which scrolls the page to the top if you click the link. Now that’s perfectly acceptable if you’re going to another page on clicking the link, since the scrolling never happens. But while using Ajax, you don’t want the screen to be scrolling to the top in the middle of an action.

Solution Part 2
What I eventually did was to replace the href=”#” with href=”javascript:;”, which is basically an empty line of Javascript. This stops browsers (tested on FireFox, IE 6 and Safari) from scrolling to the top.

So I end up with
<a class="frame_holder" href="javascript:;"><img src="foo" alt="bar" onclick="doStuff()"/></a>
instead of
<img class="frame" src="foo" alt="bar" onclick="doStuff()"/>
to make it work in Internet Explorer 6 (I have yet to test it on IE 7 *crosses fingers*).

UPDATE
Added reference to ‘javascript:;’ in the href attribute instead of ‘#foobar’. Thanks to Wade for reminding me. I was pretty green when I wrote this post, am a lot wiser now