info [ AT ] redcardinal [ DOT ] ie
The Quick & Easy Guide to Better HTML
We all want good looking websites that work well for our visitors. Happy visitors = happy site owners. But what happens when the code that runs your website is so poor that it breaks the design in some browsers? Or worse still, keeps some visitors out of your site altogether?
Bring on the code
It’s all about the code. Writing good code is easy. When you know how, that is. Behind every website you view are a number of coding technologies that make things tick. Hyper-Text Mark-up Language (HTML) and Cascading Style Sheets (CSS) are probably the most important and common of these, and form the backbone of virtually every web page.
So many ways to view
With a variety of browsers (Internet Explorer, Firefox, Safari etc.) and an increasing number of platforms (pc, tv, hand held devices etc.), the need for a consistent user experience has never been more important.
That’s where standards come into the equation. At their most basic level, web standards exist so that the widest set of users can access and use your data via the broadest number of channels.
What’s the fly in the ointment?
Web standards seem to be very elusive for many websites on the Internet today.
After testing the Golden Spiders nominees, I thought it might be helpful to detail the top coding problems that ‘broke’ so many of the websites considered to be Ireland’s best.
(Some of the following is somewhat technical, so you can skip to my conclusions if you wish.)
Document Type Definition
Every HTML document should contain a Document Type Definition (DTD) before the <html> tag. The DTD tells the User Agent which rendering mode to use when displaying the page.
The most common DTD DOCTYPEs currently in use are:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">If your website doesn’t contain something similar to one of the above on every page then it will not validate.
It is possible to use proprietary attributes and still ensure validation. To do so your site should carry a custom DTD. More details on custom DTD schema can be found here.
Character Encoding
Character encoding tells the browser what characters the page will be displaying to the user. Remember that visitors can originate anywhere on the globe, and not all will use Latin characters.
Letting the browser know the Character Encoding required (or ‘charset’) can be achieved in two ways:
1. within the HTTP header sent by the server (e.g. using .htaccess on Apache);
2. within the HTML document header, e.g.:<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">It is extremely important that if set by both the server, through the HTTP headers, and within the HEAD section of a HTML page that the charsets match. A mismatch will invalidate the page.
If you want to test your site this tool will show you whether the charset is set on your page.
Closed or self-closing tags
If you look at the code behind any web page you will see a bunch of tags like
<div><a href="www.somesite.com">Click here</a></div>Most recent HTML specifications require tags to be closed. So you can see in the example that there was an opening
<div>followed by an opening<a>(with a href attribute set), some text, and then the closing</a>followed by a final</div>.So each tag was opened and then closed. Notice also that the tags were nested. The closing
</a>preceded the closing</div>. Had it been any other way the code would not validate.XHTML requires all tags to be closed or self-closing. So it is important to ensure that all your elements are closed, e.g.
<head [...] />or<div> [...] </div>.Lower case tags
The XHTML 1.0 specification requires that all element and attribute tags be in lower case. So if your document uses a XHTML DTD then you can not use a mix of upper and lower case mark-up throughout your document.
Whenever I see mixed case mark-up I immediately think of ‘cut ‘n paste’ coding, which in my view is an extremely lazy and dangerous way to author web pages. If you are going to cut and paste, you have 10 times more reasons to validate your page afterwards.
If you take a look at the source code of your own web pages (in IE6 select Tools->View Source, IE7 select Page->View Source, FF2 View->Page Source) and see something like this:
<head>
<title>...</title>
<META HTTP-EQUIV="TITLE" CONTENT="...">
<META NAME="KEYWORDS" CONTENT="...">
<META NAME="DESCRIPTION" CONTENT="...">
<META NAME="ROBOTS" CONTENT="index, follow">
<META NAME="AUTHOR" CONTENT="...">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META HTTP-EQUIV="PRAGMA" CONTENT="no-cache">
<link href="..." type="text/css" rel="stylesheet" media="all">
<link href="..." type="text/css" rel="stylesheet" media="all">
</head>I would be slightly concerned about the overall quality and standard of coding produced by your development team / design agency.
(The fact that this style of coding appeared in some of the nominee sites for ‘Best Web Design Agency’ is somewhat disconcerting.)
Proprietary tags, attributes and CSS
Unfortunately in the early days of the Internet the browser vendors were less interested in standards (*glances at IE*). This led to a number of proprietary tags and attributes coming into existence. Recent years have seen considerable improvements to the browsers we use. Unfortunately many designers and developers have not kept pace with the times.
Generally, the use of proprietary code has one major outcome – the code will only work in one brand of browser. While Internet Explorer enjoyed 95% dominance of the browser market during the 1990′s this was fine. But now that new standards-compliant browsers such as Firefox have a 15-20% market share, you can understand why proprietary code has become such an important issue.
For example, the use of
leftmargin, topmargin, marginwidthormarginheightattributes in thebodytag involves proprietary code. Similarly, theembedtag is a proprietary tag.If you would like to see an excellent example of what can happen when a web site works only in one browser take a glimpse at what happened Enterprise Ireland.
CSS Hacks
Unfortunately different browser platforms have a nasty habit of rendering content in non-standard ways (*glances again at IE*). It’s a feature of life that hacks are often required to make pages render consistently cross-browser.
Placing hacks in CSS files has a nasty habit of breaking any validation performed on that file. A far more effective way to introduce hacks is to use conditional includes.
Conditional includes are special commands that are only read by Microsoft browsers. Such an include might look like:
<!--[if lt IE 7]>
<link href="path/to/IE/lte6/stylesheet.css" media="all" rel="Stylesheet" type="text/css" />
<![endif]-->For a good guide to using conditional includes and their syntax see quirksmode.org.
WCAG Accessibility
They say that the Internet is a great levelling ground. Not just for business, but also for people with disabilities. That’s why Accessible web pages are so important.
WCAG 1.0 and Section 508 are the most common accessibility standards used on the web today. They dictate certain coding requirements that apply to accessible web pages. For instance:
All image elements must contain an ALT attribute. Even spacer images must contain at the least an empty ALT attribute –
alt="";And a very common error is the omission of proper labels for form elements:
Form input elements should be accompanied by a corresponding label, e.g.
<label for="fname">First Name</label><input type="text" name="firstname" id="fname">If you would like to learn more about Accessibility please visit WAI. diveintoaccessibility.org/ offers an excellent primer on web site accessible.
Legal Color Names
Many people don’t realise that there are just sixteen legal color names in HTML 4.x and XHTML. If you use color names in your mark-up and they don’t appear in the following list your document will not validate, and you run the risk of inconsistent rendering across browsers/platforms.
The Legal Color Names (with HEX values):
Aqua (#00FFFF)
Black (#000000)
Blue (#0000FF)
Fuchsia (#FF00FF)
Gray (#808080)
Green (#008000)
Lime (#00FF00)
Maroon (#800000)
Navy (#000080)
Olive (#808000)
Purple (#800080)
Red (#FF0000)
Silver (#C0C0C0)
Teal (#008080)
White (#FFFFFF)
Yellow (#FFFF00)Unescaped special characters
Unfortunately certain characters have a special meaning to the computers that run the Internet. In particular the ampersand (&) and the less-than and greater-than characters (<, >) cause problems when they are left unescaped.
The inclusion of these characters on your HTML page will invalidate the mark-up. In all cases they should be properly escaped to either their equivalent HTML entity or ISO Latin-1 code. In the case of the ampersand & or &, less-than < or <, and greater-than > or &62;.
For a full list of HTML special characters see here.
So what’s the solution?
My own personal opinion is that those responsible for coding and designing websites need to take web standards more seriously.
The fact that web sites nominated for ‘Best Web Design Agency’ failed to validate (and one or two had truly awful coding) is indicative of the wider issues faced by Ireland’s Internet community.
On the other side of the fence, those commissioning new sites should start to consider, as a decision criterion, the quality of the underlying code and the impact on areas such as Accessibility and compatibility poor code can have.
Design and development briefs should include web standards as a requirement. In fact this is one of the easiest metrics to collect for subsequent evaluation.
Failing the above I think a quote from theMenace is particularly apt:
If we don’t have regulation (which we never really can) then we need 1) peer honesty and 2) client education.
Well said.
Standards are the best thing to happen to web design and development since the birth of the browser, there’s on doubt about it. They give designers/coders a way of ensuring universality and are a great aid to accessibility. However, browsers and client technologies have a long way to go before universal standards compliance is seen as the norm. We’ve come a long way since the days of 18kb JavaScript browser detection scripts – but we’re still not out of the woods yet! IE needs to get its act together – either that or every web designer needs to boycott it. Compliant browsers need standardised ways of displaying page elements, particularly form elements (Opera, I’m looking at you – IE isn’t without fault either).
Until standards can be considered universal with regard to the client technologies that real-world users are using, then people will still use excuses for taking shortcuts.
Comment by Mojo — November 12, 2006 @ 11:14 am
“My own personal opinion is that those responsible for coding and designing websites need to take web standards more seriously.”
I fully agree, but clearly they don’t want to or NEED to. And did we ever even stop to ask do they even KNOW about them?
I am sure you will agree that the web design and development world has changed a lot in the last few years. A LOT. And it is still changing(Look at the proposed new directions/split (X)HTML is going in). I am starting to think that maybe, just maybe feel free to call me naive, SOME of these designers/developers don’t really know about standards and their importance.
I know you are going to quote me on the designers that quote themselves on compliance but I’m talking about the rest.
To be a decent web designer or developer in a REAL company and not little johnny sitting at home in his bedroom, you need to be VERY disciplined and very educated these days. In the past, you could open up frontpage and whip up a website in a few mins. Nowadays it’s different. The “NEW BREED” of designers and developers have not really hit the big time yet. When I say that…. I’m talking about major industry recognition to the point of a GS award. I personally studied web design, development and accessibility in college and not ONE of my classmates would even DARE produce something that’s non compliant or accessibly. Most people chose a final year project in the accessibility field.
I have a feeling that things are going to change. And VERY soon. Either the companies at fault are going to adapt to the upcoming, more educated clients or they will be replaced. It’s a fast paced market. Besides, all the money made from the publicity the GS awarded companies are getting will probably go into re-training their designers and developers anyway.
(Sorry, I started off with a one line response to MoJo but as usual, I got a bout of the verbal).
Comment by Dave Davis — November 13, 2006 @ 2:03 am
Maybe I should start my own blog
Comment by Dave Davis — November 13, 2006 @ 2:04 am
Dave
Keep commenting – you have something good to say
Rgds
Richard
Comment by Richard Hearne — November 13, 2006 @ 9:16 am
Comment by Dave Davis — November 13, 2006 @ 9:29 am
Well said. I’ve been (doing my best to) build sites using standards for a few years now, and I’ve found a few nice benefits…
1) Bug fixing – if something is going wrong, making sure the code validates really helps find the issue or eliminate the code side of it from the problem
2) Multiple devices – my site works great on my mobile, my PSP, and my mac with no messing about or browser detection.
3) Speed of development – once you build up a nice bag of tricks, you can really improve your workflow. It’s a lot easier to re-use the menu methods in different sites if you’re using standards and seperating your content from presentation.
What really gets me pulling my hair out though is the little differences between the browsers – all of them. I’m still trying to find the best way to work around them all. I like the idea of having external files, but I find there can be subtle differences between IE6, 7, Opera, Safari & Firefox (e.g. legend tag), which can mean a lot of different external files. And I don’t want to go back to browser checking and alternate stylesheets.
Comment by Stewart Curry — November 13, 2006 @ 9:47 am
Hi Stewart
I feel your pain. I think the more obscure (and therefore less used) tags seem to be the ones that cause most issues.
You don’t see the use of LEGEND too often these days. I’ve seen a few nice CSS workarounds to get the same effect.
I think that we have to accept small rendering differences across browsers, but the upside is that it isn’t as bad as it was 4 or 5 years ago
Richard
Comment by Richard Hearne — November 13, 2006 @ 10:05 am
Some great points here I think Richard.
It is terrible that people in the industry don’t really know where the industry is – or is going.
I think in part the problem is the search for the quick buck, or the big buck for that matter.
A company that can deliver a “working” site with a corporate front will get the contract over a clever, accessability-orientated company if they have some experience or an “Award” under their belt.
Maybe the problem is the same that exists in other industries – workers trying to hold on to the old ways – possibly reluctant or overwhelmed by the new information to adapt.
I’m possibly not the best person to give my opinion, considering that I have learned standards/CSS/PHP etc. just as they were coming into mainstream.
I had the advantage of not having previously ingrained ways to develop and code, which helped to adapt and learn with the new standards.
But hey, when it comes down to it the standards aren’t all that hard and if I can do it well then I’m sure anyone can – especially a commercial company.
So no excuses, and let’s hope that the awards will be different next year.
Regards,
David
Comment by David Doran — November 16, 2006 @ 11:14 pm
Don’t think you gave the url of the website to let people validate their own pages …
http://validator.w3.org/
Comment by Paul Browne - Technology in Plain English — November 28, 2006 @ 4:21 pm
I enjoyed this post. I learnt a lot from it. I use html tidy for a lot of my code. It always returns something to me that looks good and I was wondering what your thoughts are on this. My site is at http://www.psychic-aus.com if you want to look at the source. Thanks for a great page.
Comment by TerryG — March 27, 2007 @ 1:38 pm
I have a large section on the left side of page that is the menu written in html. I have read it might be better to have a separate css file for this to load thus reducing the amount of html for the spiders to go through. One I don’t know how to do this and two do you think this is a better approach.
Comment by TerryG — April 21, 2007 @ 11:53 pm
The main thing you need to do Terry is get rid of font tags, inline style tags, tables and redundant code. I believe if you used a flexible CSS layout with compliant code you could reduce the page size by 30-40%.
Comment by David Doran — April 22, 2007 @ 8:19 am
Hi David, Yes I did exactly as you said. I put in a nice little css menu and it did reduce the size by 40%. Its made a huge difference and it looks a lot better and works well.
Comment by TerryG — May 8, 2007 @ 1:28 pm