HomePage | RecentChanges | Preferences | Newbie Help

Category Design FAQ

Before this question can be answered correctly, it is necessary to clear up a few misconceptions about web development and its associated languages.

The separation between content (HTML) and its presentation (CSS) is advantageous to website developers because changes to the presentation and layout will not affect the content of the website, only how it is presented to the user. Changing the colour scheme from red to blue does not change the content in any way, only the presentation of that content.

With that distinction in mind, what website designers should focus on is using cascading style sheets for their design, but in such a way that the HTML page does not rely on the stylesheet to display. The stylesheet is used by browsers that understand them. This method makes your HTML pages available to a wider audience, plus has the side effect of simplifying the HTML markup, thus making future updates much easier.

Designing for the web requires some practical thought. There won't be a situation where a website will look the same in all user agents, this is a myth perpetuated by designers from a Desktop Publishing background, see WebIsNotPaper. Every user that visits your site will have his own combination of hardware, software, user preferences, and connections. There is simply no "one right answer" to web design other than:

Design for the World Wide Web, not for a browser.

You won't always know what browser your users are using, whether or not they are using a monitor (not to mention if is graphical or at least _this_ big). You won't know how many pixels are available (if there are any pixels at all!) -- Google's site indexer has no concept of pixel placement, it sees your website as a stream of text.

So there are two accurate answers to "Which resolution should I design for?":

And nothing in between. Limiting the list of "supported" browsers will only cause problems later (owing to corporate pressures and newer browser releases). Web designers who develop websites for an Internet Explorer only audience will be in for a shock when AOL switches over to a Mozilla browser and these sites fail to work.

The concerning question is how well cascading stylesheets are implemented in browsers. It shouldn't be a problem at all since HTML should be written without requiring CSS to be available, which results in a bland looking presentation in non-CSS browsers.

The problem arises from a business, or marketing, perspective when a website looks great in Internet Explorer, but looks like a "hello world" attempt at HTML in something like Netscape 4. Here there are three methods of resolving the contentious problem:

  1. Managing Business Expectations: This involves teaching business people what the web really is, explaining why it is different from DTP, and also why it is bad to mingle presentation elements with content.
  2. HTML3.2 compromise: This tends to be the most common solution, including presentational elements in the content (such as using tables for layout, and styling attributes). This harks back to the HTML 3.2 days -- not an efficient compromise and definitely a step backwards. It does hinder the futurability of the website.
  3. Browser dependent compromise: Keep with a fully CSS level 1 and level 2 solution, but use Javascript for non-compliant browsers to emulate the missing or buggy CSS features. The addition of browser-dependent JavaScript does make the decision to use CSS a little bit easier, as long as due care is taken not to imply a JavaScript requirement on browsers that comply adequately with CSS styling - so browser-detects using objects is a key factor in this deployment.
  4. Non-compliant browser detection: Another idea that has some merit is that being used by Dan 'Chip' Ciammaichella (detailed on "Dancing With Crawlers" http://www.chipcom.net/searchengine1.php) of delivering clean HTML and a suggested CSS stylesheet to all browsers, but doing a browser sniff specifically for Netscape 4 and other identifiable problem browsers and returning a tables based layout in these special cases. With a proper separation between content and presentation, there's no duplication with this solution, just a simple straightforward template based approach. An improvement on this method to cater for the multitude of buggy CSS implementations is offered in [Greytower]'s Customising CSS http://www.greytower.net/en/archive/articles/customcss.html

(Zeldman offers another solution in his article Fear of Style Sheets -- http://www.alistapart.com/stories/fear/ )

CSS can't handle every conceivable layout requirement just yet, but as the support improves CSS will play a large role in making things easier for the web designer, the maintenance and update team, the web master and the audience as a whole. Take heed of the following practical advice from Bertilo Wennergren:

If some fancy design idea doesn't work well in practice due to bugs or bad browser support, then do something simpler; do not resort to bad coding (i.e. tables), nor to invalid code. Do something simpler, and wait for better times. After all, the content is what's important.

Companies and businesses are so tied-up in knots about the look and branding of their company on-line that they miss that content is an important part of branding. No-one wants to be seen as the flashy company with no substance.

Design resources:

Isofarro says: This raises the question, do we keep a reference to these resources here, somewhere else or get rid of them. I am a hoarder by nature, so I'm loath to get rid of anything that may be of some use to someone. We clearly can't just pretend table based layouts didn't exist. Ideas?

Putting them down here, with your comment, should put them into their proper historical context. -- Jerry Muelver

Older table-based resources (for those forced into stone-age webdesign):

HomePage | RecentChanges | Preferences | Newbie Help
This page is read-only | View other revisions
Last edited June 25, 2003 10:49 am (diff)

This FAQ is happily hosted by Betadome Digital Media