Thirteenth Parallel /archive/seperating-structure/
There has been a lot of talk recently about how web sites should be designed. Here at Thirteenth Parallel we believe sites should be accessible to as many people as possible. That means, producing sites that convey the information contained within them correctly, no matter what browser or device is viewing them. Now this doesn’t mean they have to look the same. For example, with this site we have decided only to provide the dynamic content to the latest browsers, however the site degrades nicely right down to a text-only client.
This article discusses how we might produce sites such that they degrade gracefully while sticking to the World Wide Web Consortium’s (W3C) recommendations. It is by no means a definitive resolution but rather our interpretation of a very long discussion and provides a guide on how to take a step in the right direction!
After all, this is new to all of us.
Over the last few years the World Wide Web Consortium (W3C) has laid down a series of recommendations about how the web should be used. Gradually the browser manufacturers are moving towards supporting these as de facto standards.
This makes our lives as developers a hell-of-a-lot easier! Instead of having to code for every possible browser, learning the intricacies of each object model and the various ways they handle cascading style sheets (CSS), we can produce clean, functional code that works in all browsers that support the W3C document object model (DOM).
This is all very well. However, we still want our sites to show up nicely in the older browsers and the multitude of products that can now access the web but do not support the W3C DOM (for example phones, TVs, fridges?). We can achieve this by layering the technologies the way the pioneers of the web first intended.
The whole idea of the Hypertext Mark-up Language (HTML) was to provide a platform for information transfer that was independent of the user’s computer and operating system. It is a tagging language that describes the structure of a document. It was also intended that the document's structure was intuitive and consistent; the goal being that as well as being human-readable, the code would be machine-readable, allowing software to infer what the page is about - this is now one of the ambitions for the eXtensible Mark-up Language (XML) as the use of HTML has been corrupted over time.
As technologies are added to “improve” the interactivity and appearance of the web, they create new layers that wrap around the existing core. If a user-agent, perhaps your telephone or electronic wallet, does not understand a particular level of technology it just ignores it (in theory at least!). Now, advanced documents can be written in such a way that even when one of these layers is removed, the document remains meaningful because the core content is understood by all user agents.
So, how do we do this?
In 99% of cases your content is your site! Before you even think about layout, style and colour schemes write your content.
If you write your content in such away that it is understandable before you add any style sheets then you are on the right track. Use standard HTML elements; use the H1-H6 tags for headings, use lists, and avoid tables for anything other than displaying tabular data. There is a reason these tags were invented, use them!
Now you need to test it. It may look ugly, but if the content isn’t easily viewable and easy to navigate then you need to go back.
The reasons for doing this are not just to be “hard core”. If you define a logical structure for your documents they will be easier to understand. This is especially important if you work as part of a company. If your pages are a mass of HTML tags with no noticeable structure it will be a nightmare for other developers to come along and figure out how to update the site. I have recently experienced this with pages that have been hacked (god I hate using that word these days) together in DreamWeaver without any attention paid to the source - I’m not saying it is bad to use “what you see is what you get” (WYSIWYG) editors. Just make sure you clean up the code afterwards.
Another important advantage will become clear when you get bored with your current design. It is most likely your content will remain pretty much untouched; all you want to do is change the layout, insert some flashy pictures and add a new colour scheme. If you have defined your structure well there will be limited changes to the document saving you a lot of time and effort, which you can then put to good use making the site look nice.
Now you may have already done this in step 1 as a matter of course. If you haven’t then we’re going to make the page valid XHTML.
XHTML extends HTML 4, modularising it and making it valid XML. If you want to learn more about implementing XHTML check out the recommendations at: http://www.w3.org/TR/xhtml1/. However, I will briefly discuss some major points.
- Your page must validate against one of three document type definitions (DTD) which should be specified in a DOCTYPE declaration prior to the root element. The three different versions are strict, transitional and frameset:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-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 XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
- The root element of the document must be <html> and have an XHTML namespace, e.g.
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en" lang="en">
- You must ensure the tags are well formed, lowercase and nested properly (all tags must be closed, e.g. <p></p>, <br />, <img />
- There are many others, for which I advise checking the W3C recommendations
Again this is not just to be “hard core” but has an important role in the design. If your HTML is well formed and validates to a particularW3C DTD your page will more than likely render correctly in the major browsers. It also makes the code easier to parse and manipulate using code, this is important if you decide to add dynamic components to your site.
If we are going to add some dynamic behaviour later on we need to create two style-sheets. Firstly we need a “basic” style-sheet for general layout and styling. Then if we would decide to add a script that needs specific styling we can add a “complex” style-sheet that prepares the html elements that will be used by the script.
We include them as follows:
<link rel="stylesheet" type="text/css"
href="style/basic.css"> <script type="text/javascript"
src="behaviour.js"></script>
Then in the JavaScript file, along with all our other code, we can place:
if (document.createElement
&& document.getElementsByTagName) {
var link = document.createElement('link');
link.rel = "stylesheet";
link.type = "text/css";
link.href = "style/complex.css";
var head =
document.getElementsByTagName('head')[0];
head.appendChild(link);
}
Getting your structure to appear how you want it is the tricky part. You need to manipulate the tags that you have already, using CSS. It may be a good idea to group structural elements inside layers, but this is something that you need to figure out for yourself. I have listed some excellent CSS resources at the end of this document.
It is also worth noting that by laying out your HTML in a structured form it no way limits the capabilities of your design. You may have to figure out some tricks to achieve what you want but it is possible. I have also listed some sites that are good examples of what I’m talking about.
In my view this is the fun bit. This is where you make the HTML ... Dynamic.
Like CSS this is something you really have to learn for yourself (again I’ve listed some good resources at the end) but I’ll list a few pointers.
Firstly, keep all your code outside your document. This is really for neatness, but also helps you keep behaviour logically separate from structure and style.
It is necessary to block out browsers that aren’t compatible with your code.
In the Thirteenth Parallel site we have a function that initiates all the
dynamic behaviour, at the top we have the following code:
(note that long lines of code have been wrapped to fit our layout.
where that happens, these line wraps are marked »»)
if (!document.getElementById
|| !document.getElementsByTagName
|| typeof document.getElementsByTagName »»
("head")[0].innerHTML == "undefined") {
return;
}
This checks for features that the site requires in order to run properly, if they are not present then the script doesn’t run. Instead of checking for a particular browser we are checking for objects. Theoretically this means our code will work on any browser that supports those objects now or in the future.
I should quickly note, before several of you send me emails, that innerHTML is a proprietary function invented by Microsoft and available in Mozilla. While it is not specified in the W3C DOM we are using it in our site to make our life easier. In some people’s eyes this is a Very Bad Thing, the ultimate evil. However, we’ve weighed up the factors involved and found in favour of using it (for the time being at least).
Be careful in the way you reference structural elements in your page. Use class names wherever possible. You can then loop through all the elements in a page using the function getElementsByTagName(). The following example adds a mouseover event to all table cells that have a certain class:
var td=document.getElementsByTagName("td");
for (var i=0; i<td.length; i++) {
var el = td[i];
if (el.className == "specialcell") {
el.onmouseover = function() {
this.className = "specialcellOver";
}
el.onmouseout = function() {
this.className = "specialcell";
}
}
}
If you want a link to perform some code, give an alternative. For example, if I wanted a window to popup when I clicked a link I could do the following:
<a href="javascript:doPopup('somepage.htm');">
Open some page</a>
What would happen if a browser that didn’t have JavaScript enabled tried to follow this link? It’d fall over. The following code is much better:
<a href="somepage.htm"
onclick="return doPopup('somepage.htm');">
Open some page</a>
In this case the browser can still follow the link to the next page, and if doPopup returns false it will cancel the link.
It is important to test your site on a wide range of platforms, browsers and
operating systems. If you’ve designed your site properly you will only have a
few tweaks to make. Here are a couple of unusual browsers that you might like to
check out:
Lynx - text only browser
WebTV - emulator of
the TV based internet browser
As you can see this isn’t rocket science and I hope you can see the advantages for developing in this way. As I said at the start it is not a definitive guide but rather a guide to a step in the right direction.
It should also be noted that in the industry it is still quite common to see specifications that require Netscape 4 compatibility. It is very hard to explain to a client why the extra interactivity they have paid thousands of pounds for works in one browser but not another. However, if you follow this process you could “bolt on” distinct layers of style and behaviour that are only present for browsers that support document.layers.
Important W3C pages
XHTML 1 specification
XHTML Validator
CSS2 specification
CSS validator
CSS
Rich in style
DevGuru CSS2 Reference
NYPL Style Guide
Blue Robot
cac6982 (a new style and layout throughout February)
DHTML/JS
DevGuru
JavaScript reference
DhtmlCentral
WebFX
Other Resources
Detailed description of
character codes
Owen Briggs’ Design Rant (what started me (us) thinking about this)
(note from Michaël: Actually, Owen’s article is awesome but a long time before it became famous,
I asked Aaron something like this: ‘What of dynamic xhtml, what do I need to know to start using it?’
and he gave me a surprising reply in this thread on DHTMLCentral.
This is what got me thinking in earnest about these principles, and some weeks later I applied them in skriptlab v3.)