HTML
What are the benefits of using web standards?
A site that has been built to web standards generally will be:
- Less bandwidth intense
- Future-proof
- Extensibility
- Easier to maintain
- Compatible with newer browsers
- Accessible
Coding Standards
1. A DOCTYPE specification MUST be used at the beginning of the web page
Example: for HTML 4.01 Strict
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”
“http://www.w3.org/TR/html4/strict.dtd”>
or for XHTML 1.0 Transitional
<!DOCTYPE html
PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
A DOCTYPE (short for ‘document type declaration’) informs the validator which version of (X)HTML you’re using, and must appear at the very top of every web page. Doctypes are a key component of compliant web pages: your markup and CSS won’t validate without them.
Netscape 6 and above, Internet Explorer 6 on Windows, and Internet Explorer 5 for Macintosh all support DOCTYPE switching. This is a technique where these browsers can be switched from Quirks mode (which emulates buggy implementations in earlier generation browsers) to Standards mode (which more strictly adhers to the Standards). For new content, use a DOCTYPE which will invoke Standards mode in Netscape Gecko and Internet Explorer 6 AND TEST FOR COMPLIANCE!!! This will ensure that your designs work similarly in these browsers as well as in any other browsers which support the Standards.
<!–[if !supportLineBreakNewLine]–>
<!–[endif]–>
2. Tags and attributes MUST be in lower case
This is because XHTML documents are XML applications. XML is case-sensitive. Tags like <p> and <P> are interpreted as different tags.
This is wrong:
<BODY>
<P><A href=”My Link”>This is not correct</A></P>
</BODY>
This is correct:
<body>
<p><a href=”My Link”>This is correct</a></p>
</body>
3. Elements MUST be nested correctly.
This is wrong:
<p><b>This is not correct</p></b>
This is correct:
<p><b>This is correct</b></p>
4. Attribute values SHOULD always be quoted.
This is wrong:
<table width=640><tr><td>This is not correct</td></tr></table>
This is correct:
<table width=”640″><tr><td>This is correct</td></tr></table>
5. All pages MUST have a page title. This title will match the heading title at the top of the content section.
Example:
<title>Nevada Department of Transportation Homepage</title>
The template for the Internet site automatically meets this requirement by including a PageTitle variable, which is used in both the <title> tag, and using the variable for the heading.
Note the following code excerpts:
<% PageTitle = “Put page title here” %>
<title><%= PageTitle %></title>
<h1><%= PageTitle %></h1>
6. All pages MUST have the following “meta” tags:
<meta name=”author” content=”Author’s Name”>
<meta name=”description” content=”Page Description”>
<meta name=”keywords” content=”Search Keywords”> ‘Like Software, computer
<meta http-equiv=”content-type”
content=”text/html; charset=iso-8859-1″> ‘This states the encoding type
<meta http-equiv=”content-language” content=”en-us”> ‘ English US
7. Modularize code SHOULD be used, so that changes made in one place will affect everywhere
CSS (Cascading Style Sheets) – Which help the page to change it settings (Appearance)
Pieces of the web page that are used more than once or on more than one page are easier to maintain if they are written in a separate module and then “included” in all the pages using an “Include File” or “server.execute” statement. There is nothing special about an include file; its just a piece of asp or html code. But if you write it generically enough, then you can include it on any page you want as many times as needed.
<!– #include file=”includes/MyDataConnection.asp” –>
for includes within directory structure or
<!– #include virtual=”/includes/MyDataConnection.asp” –>
for includes from root structure of web site
Things that work well as includes:
common functions
data connections
copyright statements
application or subdirectory navigation
anything else you need on more than one page.
Another method of including pages is to use Server.Execute. The syntax is:
<% server.execute “/includes/MyDataConnection.asp” %>
It should be noted that an “Server.Execute” statement transfers control to another html page and then returns control to line after the calling statement.
Degree of separation between content and presentation
1 The site SHOULD use CSS for all presentation aspects (fonts, color, padding, borders etc)
Use style sheets to control layout and presentation
2 All decorative images SHOULD be in the CSS
The aim for web developers is to remove all presentation from the html code, leaving it clean and semantically correct.
Accessibility for users
1. “alt” attributes MUST be used for all descriptive images
Provide a text equivalent for every non-text element
2. MUST have equivalent HTML page for site where flash or other technology are used.
3. The site SHOULD use relative units rather than absolute units for text size?
Use relative rather than absolute units in markup language attribute values and style sheet property values.
4. All aspects of the layout SHOULD be consistent if font size is increased?
Try this simple test. Look at your website in a browser that supports easy
Increase of font size. Now increase your browser’s font size. And again.
And again… Look at your site. Does the page layout still hold together? It is
Dangerous for developers to assume that everyone browses using default font
Sizes.
5. All links MUST be descriptive?
Link text should be meaningful enough to make sense when read out of context – either on its own or as part of a sequence of links. Link text should also be terse.
6. All web pages SHOULD be tested in different resolutions (600×400, 800×600, 1024×768 ).
7. Every website SHOULD be designed to reasonably accommodate visitors with disabilities.
At a minimum, all pages within an NDOT (Nevada Department of Transportation -LOOK and FEEL) website must comply with the current version of Priority 1 guidelines established by the World Wide Web Consortium’s Web Content Accessibility Guidelines. If possible, all pages should also comply with the federal Section 508 Standard and W3C Priority 2 guidelines.
Accessibility for devices
1. The site SHOULD work acceptably across modern and older browsers? i.e., all web pages MUST be tested in different browsers.
Page which run successfully in iExplorer need not run in Netscape or does not have same appearance. (So before starting to build the developer should know what browsers could be used).
2. Content MUST be accessible with CSS ‘switched off’ or ‘not supported’?
Some people may visit your site with either a browser that does not support CSS or a browser with CSS switched off. In content is structured well, this will not be an issue.
3. Content MUST be accessible with images ‘switched off’ or ‘not supported’?
Some people browse websites with images switched off – especially people on very slow connections. Content should still be accessible for these people.
4. The site SHOULD work well in Hand Held devices?
This is a hard one to deal with until hand held devices consistently support their correct media type. However, some layouts work better in current hand-held devices. The importance of supporting hand held devices will depend on target audiences.
Basic Usability
1. There MUST be a clear visual hierarchy
Organize and prioritize the contents of a page by using size, prominence and content relationships.
2. Heading levels SHOULD be easy to distinguish.
Use header elements to convey document structure and use them according to specification
3. The site’s navigation SHOULD be easy to understand.
Your navigation system should give your visitor a clue as to what page of the site they are currently on and where they can go next. (This basically refers to index)
4. The site’s navigation SHOULD be consistent.
If each page on your site has a consistent style of presentation, visitors will find it easier to navigate between pages and find information
5. The site MUST use consistent and appropriate language.
The use of clear and simple language promotes effective communication. Trying to come across as articulate can be as difficult to read as poorly written grammar, especially if the language used isn’t the visitor’s primary language.
6. The site SHOULD have a sitemap page and MUST have a contact page.
Most site maps fail to convey multiple levels of the site’s information architecture. In usability tests, users often overlook site maps or can’t find them. Complexity is also a problem: a map should be a map, not a navigational challenge of its own. So the site SHOULD have a map and it MUST be easy to find.
7. For large sites there SHOULD be a search tool.
While search tools are not needed on smaller sites, and some people will not ever use them, site-specific search tools allow users a choice of navigation options.
8. There SHOULD be a link to the home page on every page in the site
Some users like to go back to a site’s home page after navigating to content within a site. The home page becomes a base camp for these users, allowing them to regroup before exploring new content.
9. Links MUST be underlined
Users should easily understand that the text has a hyperlink.
10. Visited links MUST be clearly defined?
Most important, knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again.
Site management
1 Does the site have a meaningful and helpful 404 error page that works from any depth in the site?
You’ve requested a page – either by typing a URL directly into the address bar or clicking on an out-of-date link and you’ve found yourself in the middle of cyberspace nowhere. A user-friendly website will give you a helping hand while many others will simply do nothing, relying on the browser’s built-in ability to explain what the problem is.
6.2 Does the site use friendly URLs?
Most search engines (with a few exceptions – namely Google) will not index any pages that have a question mark or other character (like an ampersand or equals sign) in the URL… what good is a site if no one can find it?
One of the worst elements of the web from a user interface standpoint is the URL. However, if they’re short, logical, and self-correcting, URLs can be acceptably usable
6.3 Does the site’s URL work without “www”?
While this is not critical, and in some cases is not even possible, it is always good to give people the choice of both options. If a user types your domain name without the www and gets no site, this could disadvantage both the user and you.
6.4 Does the site have a favicon?
A Favicon is a multi-resolution image included on nearly all professionally developed sites. The Favicon allows the webmaster to further promote their site, and to create a more customized appearance within a visitor’s browser
Favicons are definitely not critical. However, if they are not present, they can cause 404 errors in your logs (site statistics). Browsers like IE will request them from the server when a site is bookmarked. If a favicon isn’t available, a 404 error may be generated. Therefore, having a favicon could cut down on favicon specific 404 errors.
CSS
Style sheets allow us to control the rendering – e.g. fonts, colors, leading, margins, typefaces, and other aspects of style- of a web document without compromising its structure.
Best Practices
- Write clean CSS code assuming a standards-compliant browsers
- Avoid the use of CSS hacks (CSS hacks take advantage of browser bugs to perform magic such as “hiding” CSS Rules from specific Web Browsers, or kicking browsers that don’t follow the specs into line)
- Test your pages with both Netscape and Internet Explorer 6.0
- Use CSS to remove all presentation from the html code, leaving it clean and semantically correct
- Place links to purely decorative images in the CSS, not in your XHTML
- Use CSS positioning for layout, limit the use XHTML tables to data
- Use XHTML elements to mark up your code based on semantics; avoid the overuse of divs, spans, and classes
- Test your page with CSS disabled
- Use meaningful identifier and class names.
- Avoid choosing identifier names like “red” if there is a chance it might change to a later time to a different color
- Use relative-length measures; avoid the use of absolute-length measures whenever possible
The following Coding Technique for CSS SHOULD be followed
BODY {
background: white;
color: black;
font-family: Arial, "MS Arial", Helvetica, Verdana, "MS Verdana",
Swiss, Univers, Futura, "ITC Avant Garde Gothic",
"ITC Stone Sans", "Gill Sans", "Akzidenz Grotesk",
"MS Trebuchet", sansserif;
font-size: smaller;
font-style: normal;
font-variant: normal;
font-weight: normal;
margin: 1em;
text-align: left
}
H1 { background: white;
color: red;
font-size: medium;
font-weight: bold }
LI { list-style-image: none;
list-style-position: outside;
list-style-type: disc }
B { font-weight: bold }
P { margin: 1em } <!- - em Takes the relative value- - >
A:link { text-decoration: underline }
A:visited { text-decoration: underline }
A:active { text-decoration: underline }
.html { background: yellow;
color: blue;
font-family: Courier, "MS Courier New", Prestige, "Everson Mono", monospaced }
Note:
<!–[if !supportLists]–>1) <!–[endif]–>A line space between tags.
2) The properties for each tag SHOULD be in separate line (As it increases the readability)
Scripting
JavaScript & VBScript
Coding Conventions for Scripting
Naming conventions
<!–[if !supportLists]–>o <!–[endif]–>Use meaningful identifier names with Hungarian Notation as shown below
|
Subtype |
Prefix |
Example |
|
Boolean |
Bln |
blnFound |
|
Byte |
Byt |
bytRasterData |
|
Date (Time) |
Dtm |
dtmStart |
|
Double |
Dbl |
dblTolerance |
|
Error |
Err |
errOrderNum |
|
Integer |
Int |
intQuantity |
|
Long |
Lng |
lngDistance |
|
Object |
Obj |
objCurrent |
|
Single |
Sng |
sngAverage |
|
String |
Str |
StrFirstName |
|
Variable Scope |
Prefix |
Example |
|
Procedure-level |
None |
dblVelocity |
|
Script-level |
S |
sblnCalcInProgress |
Set and follow a few simple rules about naming identifiers. For example, use mixed-case naming for variables and functions (see Listing 4). The standard JavaScript convention is that class names are capitalized, as in Array() and String(), but methods are mixed-case, with a lowercase first atom, as in toString() and getItem(). Functions are mixed-case, with all atoms proper case, while statements are usually lowercase, as in switch, throw, and if.
Note:
It’s a good idea to limit the length of identifiers short (meaningful and abiding above rules), because the script code will be downloaded as text to the client. The shorter the text string, the shorter the time required to download.
-
- Avoid overuse of global variables
- Comments
- Use single-line comments (double forward slash // delimiter) to summarize the actions of blocks of code.
- Proceed every function with a prolog comment that describes its purpose.
- Grammar
- Use single quotes for string literals so HTML attributes may use double quotes
- Consider using the <noscript> tag to provide alternative text for JavaScript disabled browsers
- Use parentheses to indicate the precedence of operators
- White space
- Use 3 or 4 spaces indentation to highlight the code’s control structure
- Place one statement per line to enhance readability
- Place a blank line before inline comments to enhance readability
- Place a blank line between functions to enhance readability
- Place JavaScript functions in external (*.js) files and link to them from your XHTML document
Other Considerations
Format Code Consistently
Personal styles for the use of indentation, character alignment, and delimiters abound. For example, Listing 5 illustrates three common conventions for placement of brackets in JavaScript code. Not one of these is superior to any others, but the consistent use of one formatting scheme throughout will enhance the readability of the code as shown below :
function Fun() {
}
function Fun()
{
}
function Fun()
{
}
In addition, use indentation and whitespace to make code easier to read. For example, indent the contents of loops and if statements, the case statements in a switch block, the contents of a try-catch block, and the contents of functions. Use white space between functions and to set off logical blocks of processing.
Also remove all unused code from client-side scripts. Not only does excess code make the program harder to read and understand, but it also increases the download time and exposes intellectual property unnecessarily.
Use Comments Judiciously
Finally, as is the case with HTML code, there is a trade-off between the need for thorough commenting of source code to improve its maintainability and reusability, and the efficiency of the application. Like HTML, client-side script code is sent as a string from the server to the browser, where it is parsed and executed by the scripting engine. Comments add nothing to the functionality of the code on the client, but they do increase the amount of data being transferred.
For effective code comments, place an empty line before the comment. Indent comments with the code that they are documenting, and keep comments as short as reasonably possible.
August 10, 2007 at 4:52 am
Smart Parwez!
Great Presentation, But you might have organized it in to pages!