As a follow up to my guide on computer graphics: “Vector vs. Raster”, I’ve written this brief guide to modern web design techniques. Such is the nature of the Internet that this information quickly becomes obsolete as new technologies supersede old ones, but I hope it will answer a few of the more commonly asked questions here on Neowin.
This guide won’t teach you how to be a good designer. It won’t even teach you how to code. Its aim is to give a rundown of the current trends in web design, the “web zeitgeist”, as it were. Hopefully it can set new web designers off on the right track to avoid problems further down the line.
Both this guide and my previous guide are in a state of constant revision and I welcome any and all feedback. My aim is that this topic can be referenced to and new users guided here for answers to quick questions often seen the Web and Graphic Designers Corner.
Web design as a long and somewhat convoluted history. Back in the late mid-to-late 90s when the Internet was starting to become widely available to more than government agencies and geeky teenagers, the “browser wars” started. This effectively was a battle between Microsoft Internet Explorer and Netscape Navigator. Wikipedia can give you more information on this, but the basic outcome was that both Microsoft and Netscape started inventing HTML elements to stay ahead of the game. At that point, following W3C recommendations wasn’t seen as a priority and it was more important to gain users by adding multimedia elements specific to each browser. Examples include the dreaded <blink> tag in Netscape, and the countless multimedia additions and even whole scripting languages (VBScript) introduced by Microsoft.
Thankfully, times are a’changin’. Albeit slowly. Today, while there are still numerous incompatibilities, browser developers are striving to make their browsers more standards compliant to present pages in a uniform manner. With the growing popularity of Mozilla Firefox and other alternatives, Microsoft has been forced to rethink its strategy with Internet Explorer and, as such, has big plans for Internet Explorer 7. It is hoped that this new version will fix many of the IE-specific bugs that plague developers and require so-called “hacks” in CSS to fix.
As I type this in November 2005, there is a movement among developers, headed by recommendations from the W3C, to separate content from presentation. But what does that actually mean?
Consider a bedroom in a house: let’s say it has a chair, a table, a bed and a window. That’s the content of the bedroom. But what type of chair is it? What are the dimensions of the table? Is the bed a double or a single? Or maybe a king-size? Are there curtains? This is the presentation of the content of the bedroom.
Current web trends encourage the separation of the content layer from the presentation through a technology known as CSS. CSS stands for Cascading Style Sheets, and is a method of defining rules for elements on a web page. Things like the colour of the element, the amount of padding around it, the font used for text. It is suggested that an HTML page should be near-enough bare of any mark-up (code) that gives presentation information, which should be in a separate CSS file.
Why bother? A valid question: it sounds like just an added hassle, and an extra file to upload. But the benefits are huge: if done properly, you can change your entire site appearance by editing one file. Because all pages in your website link to this presentation CSS file, you can edit that and immediately the entire look and feel of your site changes.
It’s beyond the scope of this article to go too far into the rules of CSS, but there is one area I feel needs clarification as it is often misunderstood. When you want to style an element you define your presentation rules the CSS file and give it a style name: either a class or an ID (prefixed by “.” or “#” respectively). But which should you use? The answer lies in the element: if it’s something that’s repeated a number of times on your page, for example a particular text style or image style, give it a class. If it occurs just once, for example a DIV containing a header graphic, give it an ID. Classes are for repeated styles, IDs are for something that only occurs once per page.
HTML, XHTML, Transitional, Strict… these terms are thrown around quite openly without much thought for their meaning. Some developers would say “Oh, code it in XHTML because it’s better”… but why? XHTML is an evolution to standard HTML which is in its fourth revision, and is designed to supersede it. It’s meant to unify developers and force them to produce cleaner code that simply makes more sense. It disallows tags that aren’t closed, rejects element attributes that aren’t part of the standard, and generally is stricter.
XHTML Transitional is a slightly more relaxed version of XHTML Strict – it allows things like the target attribute of anchor tags, which have an XHTML equivalent that isn’t widely supported by current browsers. Aside from all this, “Transitional” makes sense – as a developer community we’re in transition from HTML 4 to XHTML 1, so it makes sense that we use a transitional doctype for now to maintain optimum compatibility as well as reaping the benefits of XHTML.
So what’s different about XHTML? There are three main differences you would come across daily with XHTML:
Self-closing tags – in the past, you could put the break tag (<br>) and horizontal rule tag (<hr>) on their own in HTML markup. In the quest for clean code, however, this equates to a tag that isn’t closed, so XHTML has changed this to a self-closing tag for semantic purposes, written “<br />” and “<hr />” respectively.
Strictness on custom attributes values – values that are IE-specific and not part of the XHTML specification such as “absmiddle” for the align property of an element will be ignored. Use CSS for this.
Semanticity – make sure your code makes sense! HTML defines elements for a reason. Use paragraph tags (<p>) for paragraphs, lists (<ul>, <ol>) wherever you have a list, and header tags (<h1>, <h3>) for headers. Remember, you can style any element in your CSS file if you don’t like the default way it’s presented by the browser, but use tags for their intended purpose. Also of note is that you can style lists to display horizontally rather than vertically – a navigation menu could be an unordered list displayed horizontally. After all, it is a list of links.
In order to help developers produce clean code, a tool was developed by the W3C called the “Markup Validation Service”, or just “Validator”, which scans through the code of a web page and checks it against the latest HTML specification. I find this very helpful in designing pages as it can highlight problems that may be invisible to you on your browser but could plague users of other browsers. You can find this service here:
Tables are not evil. Web designers frequently complain about the use of tables on a web page without fully explaining their reasons, and as a result confuse less experienced designers. There is nothing wrong with using tables in your HTML code – but only if you are displaying tabular data. The W3C discourages you from using tables for layout purposes, which became the standard for web designers for many years due to their cross-browser compatibility. Now, CSS is there to define your layouts. Keep tables for data, and CSS for layout. This reiterates my point about using HTML tags for their intended purposes.
We're getting a bit technical by delving into the world of AJAX but I think it's worth mentioning. AJAX is by no means a new technology: it's been around for a number of years but it's only now that it is becoming popular. This is mainly thanks to the efforts of GOogle who have brought it into the mainstream with its implementation in Gmail, Google Maps etc. AJAX stands for "Asynchronous JavaScript language and XML" and is a technology for creating interactive web applications. AJAX seeks to bridge the gap between web applications and desktop applications by reducing the constant refreshing of pages that occurs when working through an online application. By sending and receiving data to and from the server in the background of the web page and using Javascript to update the page dynamically, a much richer experience is possible for the user who can see the results of their inputs on-the-fly.
Question
Rob Veteran
As a follow up to my guide on computer graphics: “Vector vs. Raster”, I’ve written this brief guide to modern web design techniques. Such is the nature of the Internet that this information quickly becomes obsolete as new technologies supersede old ones, but I hope it will answer a few of the more commonly asked questions here on Neowin.
This guide won’t teach you how to be a good designer. It won’t even teach you how to code. Its aim is to give a rundown of the current trends in web design, the “web zeitgeist”, as it were. Hopefully it can set new web designers off on the right track to avoid problems further down the line.
Both this guide and my previous guide are in a state of constant revision and I welcome any and all feedback. My aim is that this topic can be referenced to and new users guided here for answers to quick questions often seen the Web and Graphic Designers Corner.
Web design as a long and somewhat convoluted history. Back in the late mid-to-late 90s when the Internet was starting to become widely available to more than government agencies and geeky teenagers, the “browser wars” started. This effectively was a battle between Microsoft Internet Explorer and Netscape Navigator. Wikipedia can give you more information on this, but the basic outcome was that both Microsoft and Netscape started inventing HTML elements to stay ahead of the game. At that point, following W3C recommendations wasn’t seen as a priority and it was more important to gain users by adding multimedia elements specific to each browser. Examples include the dreaded <blink> tag in Netscape, and the countless multimedia additions and even whole scripting languages (VBScript) introduced by Microsoft.
Thankfully, times are a’changin’. Albeit slowly. Today, while there are still numerous incompatibilities, browser developers are striving to make their browsers more standards compliant to present pages in a uniform manner. With the growing popularity of Mozilla Firefox and other alternatives, Microsoft has been forced to rethink its strategy with Internet Explorer and, as such, has big plans for Internet Explorer 7. It is hoped that this new version will fix many of the IE-specific bugs that plague developers and require so-called “hacks” in CSS to fix.
As I type this in November 2005, there is a movement among developers, headed by recommendations from the W3C, to separate content from presentation. But what does that actually mean?
Consider a bedroom in a house: let’s say it has a chair, a table, a bed and a window. That’s the content of the bedroom. But what type of chair is it? What are the dimensions of the table? Is the bed a double or a single? Or maybe a king-size? Are there curtains? This is the presentation of the content of the bedroom.
Current web trends encourage the separation of the content layer from the presentation through a technology known as CSS. CSS stands for Cascading Style Sheets, and is a method of defining rules for elements on a web page. Things like the colour of the element, the amount of padding around it, the font used for text. It is suggested that an HTML page should be near-enough bare of any mark-up (code) that gives presentation information, which should be in a separate CSS file.
Why bother? A valid question: it sounds like just an added hassle, and an extra file to upload. But the benefits are huge: if done properly, you can change your entire site appearance by editing one file. Because all pages in your website link to this presentation CSS file, you can edit that and immediately the entire look and feel of your site changes.
It’s beyond the scope of this article to go too far into the rules of CSS, but there is one area I feel needs clarification as it is often misunderstood. When you want to style an element you define your presentation rules the CSS file and give it a style name: either a class or an ID (prefixed by “.” or “#” respectively). But which should you use? The answer lies in the element: if it’s something that’s repeated a number of times on your page, for example a particular text style or image style, give it a class. If it occurs just once, for example a DIV containing a header graphic, give it an ID. Classes are for repeated styles, IDs are for something that only occurs once per page.
HTML, XHTML, Transitional, Strict… these terms are thrown around quite openly without much thought for their meaning. Some developers would say “Oh, code it in XHTML because it’s better”… but why? XHTML is an evolution to standard HTML which is in its fourth revision, and is designed to supersede it. It’s meant to unify developers and force them to produce cleaner code that simply makes more sense. It disallows tags that aren’t closed, rejects element attributes that aren’t part of the standard, and generally is stricter.
XHTML Transitional is a slightly more relaxed version of XHTML Strict – it allows things like the target attribute of anchor tags, which have an XHTML equivalent that isn’t widely supported by current browsers. Aside from all this, “Transitional” makes sense – as a developer community we’re in transition from HTML 4 to XHTML 1, so it makes sense that we use a transitional doctype for now to maintain optimum compatibility as well as reaping the benefits of XHTML.
So what’s different about XHTML? There are three main differences you would come across daily with XHTML:
In order to help developers produce clean code, a tool was developed by the W3C called the “Markup Validation Service”, or just “Validator”, which scans through the code of a web page and checks it against the latest HTML specification. I find this very helpful in designing pages as it can highlight problems that may be invisible to you on your browser but could plague users of other browsers. You can find this service here:
http://validator.w3.org/
Tables are not evil. Web designers frequently complain about the use of tables on a web page without fully explaining their reasons, and as a result confuse less experienced designers. There is nothing wrong with using tables in your HTML code – but only if you are displaying tabular data. The W3C discourages you from using tables for layout purposes, which became the standard for web designers for many years due to their cross-browser compatibility. Now, CSS is there to define your layouts. Keep tables for data, and CSS for layout. This reiterates my point about using HTML tags for their intended purposes.
We're getting a bit technical by delving into the world of AJAX but I think it's worth mentioning. AJAX is by no means a new technology: it's been around for a number of years but it's only now that it is becoming popular. This is mainly thanks to the efforts of GOogle who have brought it into the mainstream with its implementation in Gmail, Google Maps etc. AJAX stands for "Asynchronous JavaScript language and XML" and is a technology for creating interactive web applications. AJAX seeks to bridge the gap between web applications and desktop applications by reducing the constant refreshing of pages that occurs when working through an online application. By sending and receiving data to and from the server in the background of the web page and using Javascript to update the page dynamically, a much richer experience is possible for the user who can see the results of their inputs on-the-fly.
Check out Wikipedia's entry on AJAX for further reading, and Google Suggest for an excellent example of AJAX at work.
Edited by JoelLink to comment
Share on other sites
17 answers to this question
Recommended Posts