Category: "HTML / CSS"

Engineering a Design

The CSS/HTML architecture has a serious impact on the cost of development, integration, and maintenance of a web site.

Divide the page into a few areas.

  • Top/header - the area that spans the top of the page
  • Bottom/footer - horizontal span across the bottom of the page
  • Middle - that which is between the header and footer

Thus, the HTML would be:

<div id="header">
<div id="middle">
<div id="footer">

Next, subdivide the middle into three columns - left, center, right, like so:

<div id="left">
<div id="center">
<div id="right">

Set up the layout in a base .CSS file. This should be a browser independent CSS file. Also create two other .CSS files, one for IE, one for Firefox to override any browser specific issues.


Place the colors in a color .CSS file. Place color (image) related dimensions in the color file, name your image files with their dimensions (x,y convention - where x=width, y=height).

background: #fff url('bg-1x768.gif') repeat-y top left;

You should have 5 files:

  1. index.htm
  2. base.css
  3. color.css
  4. ie.css
  5. ff.css

Adjust the layout dimensions in base.css, using background colors to help you see. Once you have the layout stable, and as you would like it, under all the browsers you want to support (usually IE6, IE7, FF), begin integrating it with the other components. This approach can be used to skin a blog, build an application, or build a simple site.

If you find you are copying index.htm, over and over, and then modifying it - you’re working too hard. Switch to a hierarchical architecture using either SHTML, PHP or other languages that allow you to include content from different files. For example:

include 'header.php';
include 'left.php';
echo '<div id="center"><p>Page content here</p></div>';
include 'right.php';
include 'footer.php';

The assumption is that header, left, right, and footer.php would be the same for all the pages on the site. This approach allows you to modify the file once and affect the whole site.

Even if you have a very simple, small site, these practices will be helpful. Web sites tend to grow. They change, and if you have a good architecture, you can change them in a cost-effective manner.

Extend the capacity of a web server with careful common component management

Many web companies use a common, core set of javascript libraries and applications which use hierarchical CSS architectures.

If the live server is used for development (which is a very cost-effective approach), thousands of requests are made for the same files.

To reduce this, common components can be sourced from a single point, which the HTTP headers set to cache them with far-future expire dates.

In addition to reducing bandwidth consumption during the development phase, it also reduces it for live sites.

If there are related sites on the same server - the benefit is extended.

This is a small CDN (content delivery network), which allows distribution of customized files for a company, or custom code. It also simplifies management of the common code core, since updates only have to be made to one file.

This saves disk space as well, and speeds page loads.

If there is an issue with having content from a different URL, rewrite rules can be used to hide the true source of the files, while retaining the advantages of a single source.

With additional creative configuration, an application can be used to support multiple accounts. This is riskier, and I don’t recommend it - unless you can be sure you will never change the application. I would try it with this blog software (b2evolution), because from what I’ve seen - it would be very successful.

Rapid Development Strategies

Web sites have become exponentially more complex and the expectations of site visitors have soared as well.

The only way to build powerful pages is to use sophisticated tools, quickly and effectively.

:!: Choose tools that have decent documentation and a good community. You will need help. Be ready to reciprocate.

B) Use sample code. Everytime you have to learn something new, start with someone else’s posted code. It might not work exactly as you want it to, but you can tweak it, one piece at a time, until it does.

:>> Be very aware of the code architecture. Use an MVC approach, since it is likely you will have at least two views - through a template or HTML and AJAX/JSON.

:crazy: Abandon ideas that are too difficult. This isn’t lazy, it is smart. You’re smart, if you can’t get something working quickly, find another one. Many smart people posted great ideas - use them (and share yours). Abandon tools or libraries that don’t work quickly, too. There is one caveat - if you can see a tool’s potential and are humble enough to admit the problem is a learning curve, it may be worth persisting a little longer. eZ publish is a great example of this - it was well worth learning.

:idea: Be creative.

|-| Use abstract data structures and concepts. Multi-dimensional arrays are incredibly powerful.

:lalala: Be persistent, if it is almost working, keep trying. Try things that don’t make sense, because sometimes, they work - and well.

:oops: Don’t be afraid to be wrong.

:!: Use every available resource, carefully. LAMP is a stack of technology and some parts are better suited for tasks than others. Don’t use bash for page design, don’t use javascript to write large amounts of HTML.

:?: Explore, learn, try. Very little of what I have learned has been useless. Even mistakes and bad ideas are valuable, to avoid.

:yes: Be independent. Don’t ask for help right away. Try to solve your own problems, then ask.

Admin console user interfaces

  • Should give the user the information necessary to make decisions on the page displayed, as well as links to access additional resources
  • Should be consistent, throughout the application
  • Should be configurable
  • Should be attractive, polished, and easy to work with
  • Must include the requisite security
  • Should help the user enter valid data, and protect the server from malicious submissions
  • Should include AJAX
  • Should include a template system
  • Usually require access control management
  • Should have password recovery
  • Should not offer actions the user cannot perform, buttons should be suppressed or disabled visibly
  • Should make use of common navigation methods through lists and data sets

Web client side development tips

As web pages become increasingly complex, more logic is running on the client side, which requires debugging and resolution of browser compatiblity issues. Even with a great tool like dojo, a page may be processed differently and require fixing.

FireFox is my favorite browser for developing web applications. Get the FireBug plugin as well, and YSlow.


  • console.debug(variable/expression/string) - allows you to monitor the state of the code as it executes
  • Breakpoints are okay, but it is often faster to let the code run and track it with console.debug
  • alert(variable/expression/string) - can be used as a break point. It is a great way to stop the code and then restart it to isolate problems
  • Comment out code to isolate problems
  • Use the FireBug console to evaluate code and expressions
  • Use the FireBug console to navigate through objects, probing to find properties and methods. Get the commands to work on the console, then add them into the code
  • Use FireBug, under FireFox, to solve problems with IE, once you have identified them
  • Send extra values back in JSON to debug server side logic under AJAX
  • Inspect the POST data to see what was passed down
  • Use a single function to handle all AJAX errors, and then an alert and echo to display text from the server. Include code to disable this for security
  • Create browser specific CSS files from the start, and use server-side logic to deliver them. Use these files to override the other CSS files for browser issues
  • As mentioned before, use server side logic to detect the browser (if possible) and deliver appropriate HTML and javascript. A good example is plugin player code. The objective is to only send the code for the browser in use to the client
  • Set padding and margins to zero
  • Keep things simple
  • Use background colors and the layout area of FireBug to solve layout issues. Keep CSS as lean as possible.
  • Clear the cache/temporary Internet files for CSS updates and JS changes that in separate files