Web School
web development guidelines
This is a short run down on the "correct" way to write Web page code. It lists common standards, best (relative) practices, and general guidelines.
The World Wide Web Consortium (W3C) is an independent standards setting organisation. W3C was created in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its inter operability. This is the best site to visit to see what the current standards are. Previous protocols and standards are available at the W3C site for reference.
Language specific standards
Follow one of the links below to see development guidelines for the specific coding language.
Once you have the various languages sorted you might also need to know how to do cross-browser scripting.
Some aspects of writing Web documents are not standards but are just good practices. Below is a list of the fundamentals. These apply to all web documents no matter which coding language is being used.
Document names should be descriptive but limited in length. For example a page on automobile accessories could be named autobits.html. People do not like typing in really long url's. There is no true limit on the length of a URL however, it is good practice to try and keep url's short, especially where pages are deeply embedded in folder after folder.
Name your documents (and all linked documents, including images) using lower-case. Many browsers/servers are case sensitive and it can be very difficult to work out an authors format of naming documents when some letters are upper-case and some are lower-case. A page name may look nicer or be more easily read if it is AutoBits.htm but if a person is typing it in and not following a link then they may not get the case correct and therefore get an HTTP 404 Page Not Found error.
Do NOT use " " (spaces) in document names. Especially if you want your site to work in Netscape. Netscape sometimes has issues with spaces when they are not correctly URL encoded ("+" or "%20").
Try to avoid "-" (hyphens) and "_" (underscores) in names. These don't always come across well when trying to tell a person a URL over the phone. And underscores can not usually be seen if the link is underlined. Which looks like it could be a space or an underline. They can be a good way of separating words in a page name but use them with discretion. Hypens and underscores are the preferred choice to capatalization and spaces. e.g. auto_bits.html
Make the suffix the same in all documents in a site where possible. e.g. name all documents ".htm" or ".html". Do not mix a site up with both suffixes. Some languages, like Active Server Pages (ASP), require the file to have a different suffix. ASP sites will render a document with no ASP in it (e.g. HTML only documents) even if the suffix is ".asp". So with sites where suffixes are important for some document types and work equally well with the same suffix in other documents, then name them all with the same suffix that will allow all your documents to work.
Top of Page | Fundamentals
This is very important. Make the title descriptive using just a few words. Some search engines use the title to search on. Most search engines when returning results of a search use the title as the main description. This can make all the difference on whether someone will actually go to your site after a search.
The title of your page needs to sit in the <head> section of your code between <title> and </title>. This title is what will be displayed in the title bar of the browser and taskbar of windows based systems.
Top of Page | Fundamentals
First of all, what should be in an HTML document?
This is the basic layout.
<html>
<head>
<title>Descriptive Title of Page</title>
<meta name="Author" content="Development by dij8 (http://dij8.com)">
<meta name="Description" content="1-5 sentence description of site">
</head>
<body>
Content of site
</body>
</html>
As the code is written it is a very good idea to indent certain lines. Basic rules for indentation are to indent one tab (2 to 4 spaces) for each element contained within another element. The prime example of this are tables. A new line should be written for each row and data element and they should be indented for each sub element.
See example below:
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td valign="top">Information in cell</td>
<td valign="top">Information in cell</td>
</tr>
<tr>
<td valign="top">Information in cell</td>
<td valign="top">Information in cell</td>
</tr>
</table>
Layout like this makes the code much easier to read later should any changes be necessary. Especially for someone who didn't write the original document.
Top of Page | Fundamentals
In most cases, graphics should be in Graphical Information File (gif) or Joint Photographic Experts Group (jpeg/jpg) format -- commonly supported formats for most Web browsing software.
Images may be used as tags or links to other documents, but must include the alt="brief description of graphic" for text-only and accessibility modes.
Top of Page | Fundamentals
The ALT attribute is mostly used in images. Most people recognise it as the words that appear when the mouse is moved over the image.
However, it is not limited to this feature. If the image can't be displayed, maybe because the user has turned off download images, then a short descriptive name can be useful. In addition to that is its use with accessibility features. Sight impaired people are not normally considered as a possible web site audience. However, they are an audience that needs to be catered for and when they can't see an image, speech synthesizers and Braille readers use image alt attributes to describe it.
Top of Page | Fundamentals
When a web page is developed the author may know exactly what every name, ID, and variable is even though all they have used is "a", "b", "c", et c. Should the site need more development at a later date even the author may not remember so clearly what each of these are referencing. This becomes nigh on impossible for another person who has to do later development on a previous authors work.
Use descriptive names. Forms are good examples of elements that require names or ID's. A typical form may ask for a users name, address, phone number, and email address. These form elements could have descriptive names like username, useraddress, userphone, and useremail.
It is also a good practice to make these names, ID's, and variables reasonably generic. This makes it easier to reuse the code for similar projects. e.g. Variables within a script may look cool for Coca Cola when named cokecanselection, cokebottleselection, and cokevenderselection but a more generic version like product1selection, product2selection, and product3selection would better suit easily adaptable code for later use.
In using generic names obviously there must be some compromise in how descriptive one can be. As the example above shows, even with generic names it is still possible to have at least some form of reason within a description.
Top of Page | Fundamentals
How important getting all your code right and how strictly you should follow the guidelines is completely dependent on your target audience. And this should always be your first consideration. If you specifically want to make your code harder to understand and read (and therefore copy) then layout can be changed dramatically and variables and page names can be somewhat cryptic just to make it harder.
Links below point to various validators. These check your code follows strict guidelines. However, if you follow these guidelines then it may be that you can not achieve some of the things you want to. If your target audience is Internet Explorer only users then there are code snippets that can be used that will not be validated because they are not a part of the standard. Just a part of Internet Explorer. And the same to can be done if your target audience is Netscape. This is particularly true with Cascading Style Sheets. Both of these browsers have implemented this differently and Internet Explorer especially has included many styles that are not a part of the standards.
The top ten mistakes in web development, as linked below, is also largely dependent on your target audience. Consider both sides of the fence carefully and choose what you want to achieve and who you don't care about excluding with at least some education in your mind.
Lastly, you may want to check various browser statistic sites to show you who is using what and how many people you may be losing if you exclude certain guidelines. It is imperative when you check statistics that they state the date the statistics are taken from. There are plenty of sites out there that display statistics that are two years or more old. You should also look for information on how the statistics are gathered.
These are just some of the places where you can get browser statistics.
http://www.w3schools.com/browsers/browsers_stats.asp
http://www.cen.uiuc.edu/bstats/latest.html
Top of Page | Fundamentals
Top of Page | Fundamentals |
