You've read this before...
The vision behind the creation of the World Wide Web was a system that made access to information fast and easy. It was a perfect choice to build this system on top of a global computer network that we call the Internet. Information could travel fast and it had the potential to reach everyone in the world.
The Web has two key components: HTTP and HTML. HTTP is a protocol used to identify, locate, and access information. HTML is a language used to define the structure of information.
Web developers are information managers. It is our job to enforce the vision of the web: fast and easy access to information.
Along the way the Web became a human-centric, visually-focused system. That's not necessarily a bad thing. A lot of information can be conveyed to a human in a visual medium very quickly. That certainly does seem to achieve the vision of the web, doesn't it?
Actually, no. It completely misses the mark. We can get a small glimpse of a larger problem when we look at users who have impared vision. Typically these users rely on a screen reader (a program that dictates the text within a document) to gain access to the information, however it's not very easy. Many web pages rely on tables and other tricks to provide a visual format to the web page that, to the eyes, is (or should be) pleasing. The problem is that this visual format requires the author to break up the information into small parts and place them in odd places inside the HTML document; usually out of sequence The result is the screen reader delivers information in the order present in the HTML source, not on the screen. The user is left confused and unable to easily access the information on a given page.
The problems with screen readers is only a small example of the greater problem: web pages are being designed with visual presentation in mind. The result is any non-visual client may be unable to understand the information it receives. I'm not talking about just visually-impared people; hell, I'm not even talking about just people. I'm talking about anything without eyes, like a computer program.
The screen reader problems are one example of how computers cannot easily understand the information being provided. And I consider comprehension of information to be a key component in defining accessibility.
This is why we use CSS. CSS takes all the presentation logic and separates it from the HTML document. This allows the HTML document to just define the structure of information.
With these simplified HTML documents we have a linear flow of information; from the
top down. We can assume that a heading
will provide a topic to the elements that come after it. We know that items
em are important and deserve special
attention. We know that a table will contain tabular data. With this knowledge,
a computer can easily pick apart an HTML document and identify relationships
within the information and operate on them however it wants. The screen reader
will be able to follow the flow of information and present it aurally to a user
in logical order.
So with CSS we don't have to worry about mucking up our pages, right?
CSS brings a new take on an old problem. CSS doesn't work so well across differnt browsing platforms. To keep compatible with the various browsers out there, CSS authors are left to using CSS hacks that often involve the introduction of redundant elements to an HTML document.
And with CSS, we're still visually focused on page design. This isn't a bad thing, but it makes us do bad things to our HTML documents. The extra elements needed to make a page render correctly (visually), have no other purpose and add no new structure to the document. We're adding bloat and potentially obfuscating the underlying information.
At least that's what I hear.
My take is that added HTML elements aren't as bad as the days of table-based
layouts. I may have 20 nested
DIV elements but the information
still flows in a linear fashion within the HTML document. Many elements
do provide some structure. I define information boundaries with them. The
#masthead element will contain the title and related information.
The column elements will contain the main content for the page. The footer
will contain.. whatever goes on feet. A menu will contain links and navigational
elements for the site. So some
DIV or other such elements do serve
to increase the structure of the information.
It's when you have 3 nested
just to create a border around an element that things start to get out of hand. HTML
document authoring isn't an exact science. There is a kind of black-art to it;
it's almost a religious affair. It boils down to what you believe is best.
The ultimate goal of this layout that you see here, Plaine, is to be sparse on presentational markup. Some people have taken the content vs. presentation battle to the obvious conclusion that perhaps there should be no markup at all. Very curious, but I'm not taking it that far.
What you see here is 1
DIV per obvious block. Each of the two columns has
a second, child
DIV because it was the only way to get a consistent
gap between the content and borders of each column.
Because of the sparse markup, I've had to leave behind the key feature of a background color on the right-hand column. That could be implemented with a repeating background image if so desired. Also some old bugs have shown back up. Various IE text bugs showed up, as well as some off-by-one bugs seen in Mozilla/FireFox. These are easy to resolve using added markup, but in this case, not so easy.
I make use of the
BODY elements within the CSS
because I need every block element I can find to get things working. I'm using
the skidoo trick for the side column
by first defining a right-side padding on the
BODY of 200px. I then
extend all the horizontal elements ( masthead, footer, etc.. ) to the right by
setting a negative right margin of 200px.
The border between the two columns is generated by overlapping the left-hand border of the right-hand column with the right-hand column of the left hand border. This was fun because it's one of the first CSS tricks I used when trying to get a multi-column layout.
More horizontal bars can be added; existing ones can be removed, as long as you leave the footer in there. A three-column layout would require some extra markup that might defeat the purpose of this layout.
Not really. The right-hand column does come second in the HTML source, but any content I put into the top menu or breadcrumbs trail would still appear before the content of the page in the source. So it isn't really source ordered to begin with and even if it were the top-page elements would still get in the way.
Work In Progress
This is not a final version of this layout. I haven't added any list-based navigation elements yet, nor have I explored what kind of visual fun can be had with this. I have not tested this on any browsers but Opera 7, FireFox 1 and IE 6. Everything else is up in the air.
I'll look at doing a left-side column version of this one at some point as well. I went right-side because there were some tricks I could utilize and the layout I was trying to originally create (before I got sidetracked into making Plaine) had the side column on the right.
So there you go. Enjoy and don't forget this whole damn layout is in the EXPERIMENTAL folder for a reason.