Lemon Foundation

Often, clients want a quick solution to an immediate need or problem they have, whilst suppliers need to deliver work as quickly as possible to cope with changing workflow demands, as well as delivering quality work to make the client happy.  The resulting temptation is often there to create something quickly, often resulting in bloated and hard to manage code.

In this situation the supplier has to decide whether to create and deliver something that both does their capabilities justice (for their on-going portfolio) as well as being the right solution to clients needs.  Often, the kudos of doing good work within the industry is just as important as making the client happy, and in a very small industry with a vocal community keeping things accessible and coded according to current industry standards is important.  In a perfect world, everything would be coded to W3C XHTML, CSS and WAI-AAA standards. 

But do clients actually want that?  And more importantly, are they willing to invest their budgets in it?

Clients often question the wisdom of using CSS against creating something quickly using a table based layout.  The reality is that in the case of the simple site, using a table based layout may indeed be quicker, and thus cheaper for the client while still producing the result the client is looking for, just as much as if the site were developed using strict CSS standards.  Additionally, this may not detract from the accessibility of the site if it is coded correctly, but may still have an effect on the way the site would be presented on differing platforms.  If however, the client is certain that their site will be viewed on browsers where this is not a problem, and they are willing to sign off on that, then this may not be too much of an issue.  As with most things, pick the right tools for the job and budget.

From the start, developing a web site of any substance where CSS handles the presentation requires some up front planning and design consideration.  This of course has a cost ramification and adds more complexity to the project (you might need a CSS specialist on board, you need to manage more code etc) up front.  But, in the longer term, this does create a platform which is easier to work with in the future.  Once the design has been planned, and the CSS delivered, you have a very powerful presentational layer which can be easily updated, changed and added to.

One of the problems with hard coding (code is written inline with html) style information into a web page, be it a web site, web application, or a one pager, is that once it is hard coded, it's not so much that it is difficult to edit, because it's not, but that the page in question will not degrade gracefully on older or more exotic platforms.  Additionally, there will probably be accessibility issues that need to be considered.

When you do this for a site that has 1 to 5 pages, managing is not too much of a problem.  But when you have a web site with more pages than that, and you could be talking anywhere upwards of 20 pages, management of the site does become painful and time consuming.  The whole joy of CSS is that you can abstract the way something looks (presentation) from the way the code is written (markup), and manage all this presentational code from a central place.

Most good web agencies by now should be re-using and further developing their structural and presentational code as much as possible, so that once you've done something once, you can do it again and again without having to re-invent the wheel.  Of course, the simpler the project, the easier this becomes.

Similarly, when you have more than one person working on a project (which is often the case), they're more than likely to have differing skill sets.  Abstracting presentation from markup enables the two developers to work synchronously - typically where one developer is writing the backend business logic, and where the other developer is writing the XHTML markup and presentational CSS.  In larger projects you could have more than one individual working on each aspect of the site and so separating aspects of the site build become vitally important for meeting deadlines and writing code that is portable, robust and manageable.