HTML Best Practice
Doctype
As a standard I recommend all HTML code has a doc type of XHTML Transitional and thus all HTML mark-up is compliant with that doctype.
i.e.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-GB">
This means all HTML tags must be XML compliant and have a closing tag. It also means tags need to close in the correct order and not be nested.
i.e. Example of self closing input tag
<input class="dim" type="text" id="google-web-string-H" name="q" value="Search for?" />
AA Compliant
This means best practice coding should ensure HTML tags are marked up correctly and alternative content is visible to screen readers etc.
i.e.
All images should have an alt tag.
<img src="/img/logos/logo-form.gif" alt="DatingDirect"/>
Form input items should have a corresponding label.
i.e.
<label for="frmSrchPostcode">Postcode:</label>
<input class="txt-field-new" name="frmPostcode" id="frmSrchPostcode" value="e.g. SW6" type="text">
Page Size
Ideally the page document should be under 120Kb. This includes scripts and CSS.
Images and objects should be kept to a minimum so the entire page size is ideally under 250Kb.
CSS
Ensure content is separated from styling by placing all styles within a separate style sheet
i.e.
< style type = "text/css" media = "screen" >
@import "/styles/vm-all.css";
</ style >
This means inline styles should be avoided and instead styling classes should be added to the html element.
i.e.
<div class=”marker-style”><p>This is the content</p></div>
Javascript
Please make sure your javascript includes are formatted correctly.
i.e.
< script type = "text/javascript" src = "/script/general.js" ></ script >
Screen resolution
Try and support 1024x768px resolution and up.
This means on a 1024x768 screen the content fits flush and no horizontal scroll bar is initiated. To do the content will need to be no greater that 1000px including padding.
Browser Support
Again as a base try and support the following browser and operating systems.
Windows XP, 2000, NT, Vista browsers
- Internet Explorer 6
- Internet Explorer 7
- Firefox 2.0 and up
- Opera
Mac 9, OSX browsers
- Firefox
- Safari
- Opera
HTML GUIDE
- Use well-formed HTML.
- Pick good names and ID values.
- Indent consistently.
- Limit line length.
- Standardize character case.
- Use comments judiciously.
- Use Well-formed HTML
Although Web browsers are generally forgiving and can ignore many mistakes, rendering most HTML as the document author intended, it is still a good idea to use well-formed HTML code, for a number of reasons.
Well-formed markup code is a concept that has gained importance with increased implementation of XML. While browsers did not, in general, enforce HTML language rules very closely, XML parsers do. Code is considered well formed when it is structured according to the rules for XML 1.0. These rules relate to character case, tags, nesting, and attribute values.
In general, when most browsers encounter an unrecognized or extraneous tag, they ignore them. However, different browsers might deliver results in different—and unpredictable—ways. In addition, future versions of browsers might adhere to standards more closely than do current versions. Finally, code that includes such elements can be harder to read and understand, making maintenance more difficult.
Lowercase names —To be well-formed, element and attribute names must be in all lower case. In versions through 4.01, HTML is not case-sensitive. However, XML is case-sensitive, and it follows that the XHTML 1.0 recommendation is also case-sensitive. So, to ensure that code keeps working and to maximize reusability, this must be planned for.
Closing tags —All nonempty elements must have corresponding closing tags. Empty elements—those previously signified with a single tag, such as <hr> and <br>—must be followed immediately by a corresponding closing tag, or the tag must end with "/". For example, <hr></hr> and <hr/> are both examples of well-formed code.
Nested elements —All nested attributes must be properly nested—for example:
<center><b>Some text</b></center> Note that the <b> tag and its corresponding closing tag, </b>, are both nested inside the <center> and </center> tags.
If elements overlap, then they are not properly nested, as illustrated in the following code:
<center><b>Some text</center></b>
While many browsers have accepted overlapping elements and given the expected results, they have always been, strictly speaking, illegal in HTML, and future versions of browsers might not support them.
Attribute values —Attribute values, even numeric attributes should be quoted—for example:
<input name="txtName" type="text" size="1">Code validation: Another step toward improving HTML code is to validate it against a formal published grammar and to declare this validation at the beginning of the HTML document. For example, the following line declares validation against the public HTML 3.2 Final grammar:
Pick Good Names and ID Values
Use a consistent scheme for assigning the value of name and ID properties. They should be as short as reasonably possible, but without giving up descriptive power. Also, use mixed-case property values to help readability (see Listing 2). In this code snippet, the check box names express not only what the purpose of the element is, but also information about the element's type. The code also illustrates the use of mixed case to help readability.