Separation is the way to go

.. in modern web design

Maybe I should again apologize for the ''Building websites is fun post I did yesterday. I was maybe cheering to hard for a goal I scored as part of a great team. But once again, I could not have done without the rest of the team.

And it is just such a good feeling that things that you have put together prove to be working in real life. I guess that's why I became a developer in the first place: creating things. That's probably also why I keep up this blog.

Col. John "Hannibal" Smith (George Peppard)

I love it when a plan comes together.

What's all the fuss about?

So, what's all this fuss about then? What did I contribute to the project that works like it should? Why cheering for just doing the job I was hired for? Shouldn't things always work when I create them?

Uhm? Yeah, well, right. Ok, yes, sorry again. I just made another impression that successful development work is something to cheer about loudly and long just because it so rarely happens. Apologies to all colleagues around the globe.

OK, now stop apologizing and tell the handful readers what it was that I did.

What did I do?

In the process of building a new website for an insurance company I was assigned to make sure that the XHTML and CSS coming out of the site was as optimal as possible. More or less self assigned as I thought to have gathered some knowledge in that area. The team was already underway with several Proofs of Concepts of early phases of the site framework and I joined in time to take up my task King of XHTML and CSS. And happily so.

Just before last summer the graphic designs came to us and they were delivered mainly as Photoshop files and some early versions of cut up html. I then started to work on tweaking these to be lighter in markup by stripping out unnecessary bits and making sure stuff showed like they should in the two major browsers of that moment: Internet Explorer 6 and Firefox. I also checked to see if things were reasonable in Opera and on a Mac. But that was only on an occasional basis.

Plan of attack

The old website was a highly successful site (in its market) and was developed some years ago. Since then many tweaks and enhancements were added. The site ran in frames and the layout was largely table based. Good old fashioned Old School web design. In essence nothing wrong with that: it produced very good revenue.

For the new web site we opted to become more up to date. We moved from the classic ASP to ASP.NET and on the client side we opted for XHTML. As configuration was set high over old fashion programming we did not go with the standard .aspx files (in fact we have only one .aspx file). A complete framework was built that has several types of containers for the different types of pages. In the CMS one can pick the right container (template) for the page and the information will then be displayed correctly. There are quite a few webservices running in the background that glued all things together.

My role in this was taking the different page designs and translate these into XHTML and CSS which the other developers could then implement in containers and components of the framework. My most important focus was separating the structure of the page and the styling. The third aspect of a web page: behavior was already being handled by external JavaScript files.

Using the principle of separation of structure (semantics), style and behavior we were able to keep the site very lightweight for our visitors. The users don't for all the clever stuff we did in the background on our servers and load balancers. They just want to get the information quickly.

Structure & semantics

As far as was possible within the framework and the design the html was stripped to the minimum so it was still semantically correct and enough structure to allow the styling to make up the design. This was all implemented in various containers and components that show different types of content and controls. That gave a few restrictions and added a bit of extra fat, but the overhead was small and made for easier development of the server-side framework.

Styling

At first we had a huge CSS file. Later that was cut up into several as not all containers use all styling. We added a bit of intelligence to the containers and let them load extra stylesheets when needed.

We also added a print stylesheet that simply hides all unnecessary stuff like menus and also adds the URL to links through the content() styling. This proofed to be quite a simple approach and gave satisfying results really quick.

"Bad vision" styling

Then there was a little bit more work. The site needed also to be viewable by people with some kind of disability. We added a button for "bad vision" that would link in other stylesheets. The "normal" stylesheets had pixel based fonts and as you know that does not really resize very well in Internet Explorer and also the used background images and all measurements were not relative to font size. Resizing the font in your browser will lead to a broken page layout pretty quickly.

So everything needed to be em based. Then the layout was changed from fixed width to fluid so the browser window would be used to the full at any resolution and not just 800 by 600 the site was designed for originally.

We also dropped a lot of the background images to make it easier to read and added a "skip links" link. (This "skip links" link is hidden in the normal vision site which the more I think about that was maybe not the best decision.)

This special impaired version of the stylesheet did involve some work, but it was done without any changes to the html. The only change is that containers load an extra set of alternative stylesheets.

Benefits

The benefits of separating structure, style and behavior have become really apparent during the development of the different styles. It was very easy to update and also very flexible. I also did some research on bandwidth savings and a saving from between 10 to 20 % is made. That is taking into account the images that are part of the content. During the research I found that these images are nowhere near optimized for the web. SO if we could improve on that I guess that the savings could go up to around 30%.

Conclusion

By separating the different aspects of the web pages we have reduced on time spent making changes and will also save on bandwidth usage. So overall it is the right thing to do, not because it is hot or trendy, but because it saves both time and money.

Go ahead and have look at the new website.

Tags:

• separation
• structure
• semantics
• styling
• behavior