Apologies for the cliche, but this being my first ever blog post I thought it was quite suitable.
My name is Wayne Zammit and I'm currently studying for a degree in Internet Application Development with the University of Middlesex. The purpose of this weekly blog is to share thoughts on the practical work I'll be carrying out during the "Developing Web Applications" module of this course.
So, with the introduction out of the way it's time to go on to this week's topic: HTML & CSS.
This first post will focus around what I learnt from an old friend of mine: "CSSZenGarden.com". I first came across this website several years ago while I was learning CSS and without any shadow of doubt, it was (and still is) my best mentor. Like many things in life, you can only really learn CSS if you get your hands dirty and try things out. CSSZenGarden.com is all about demonstrating what can be done when there is total separation between content and layout.
Way back when I started developing websites, like most fledgling web developers I based my web pages on HTML table layouts. They were (relatively) simple to develop, rendered well across browsers and basically got the job done...until a client decided to move that left-hand side menu to the right-hand side of the page! A simple and reasonable request that was far from simple to accommodate as it meant changing every table in every web page, a daunting and time-consuming task to say the least. This was a time when classic ASP was not yet classic (it was all the rage) and things like Master Pages were still unheard of. It was just a horrible mix of 'include' files, page content, server side code and styling...a mess that somehow translated to a website. I wasn't going to do the same mistake twice and decided it was time to get serious with CSS and really learn it, especially how to achieve table-less layouts. That's when I came across CSSZenGarden.com and I never looked back.
Now although the notion of separating content from layout sounds simple, in my experience it rarely is. A lot of thought has to be given as to how the page will be structured into components that might need to be independently styled, now or in the future. For instance, it might sound sensible to group your website banner and top navigation into the same <div> element called "page-top" but what if that top navigation became a side-bar some time down the line? You would need to re-group the top navigation into another <div> such that it could be positioned independently of the banner. That might still mean changing a lot of web pages depending how they are structured. This might sound fairly obvious but it's often taken for granted and might have an impact on the overall cost of the change.
There are other more subtle issues such as how to name your styles. In the previous example the element was called 'page-top' which implies that the element is positioned at the top of the page. That sounds fairly logical but what if that element were to be re-positioned somewhere other than the top of the page? The style name would become very misleading, especially to new developers who are maintaining the page or style for the first time. Something like "page-banner" would make more sense. I also find that naming styles this way helps me to identify the various components that define the structure of a web page.
However, the worst problem I faced when transitioning to CSS layouts was getting a page to render correctly across browsers. Mozilla browsers and IE (up to ver.6) had very different implementations of the "box model" (interpretation of element width and padding) which meant a lot of ugly CSS hacks to get the page to look the same on both browser families. Thankfully today there is much more coherence in the way browsers interpret CSS and most browsers have debugging utilities that help developers get the job done faster.
Separating content from layout however, has many advantages: maintenance costs are dramatically reduced; web pages load faster because they are smaller in size and also become much more accessible as they are easier for screen readers to interpret. It is also makes it much simpler for websites to become "sinkable", where visitors can personalise the look of a website to their liking. Ultimately the end result is well worth the effort!
Subscribe to email feed
