Ruthsarian : Blog : Layouts : Labs : Contact

Plaine

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 marked strong or 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?

Wrong.

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 DIVs 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.

And so...

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 HTML and 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.

Source Ordered?

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.

plaine.css
visual_consistencies.css

Presentation vs. Content
The Semantic Web

It is my belief that if you decide to use this layout, you could do much better in terms of color and design. Borders and color choices that I make are usually more for utility than to grab viewers. Do not hesitate to make changes to the design of this or any other layout you find here.