Web Page Authoring Guidelines for

Dynamic Web Applications

Explore the guidelines for authoring Web pages that are targeted for
building dynamic Web applications.
By Srinivasa Rao Chintala, Enterprise Solution Architect, Wipro Technologies

Today, almost all IT organizations are working on development of dynamic Web-
based applications. During the execution of those projects, most of them have to
convert static pages to dynamic pages in their project lifecycle. To have a smooth
execution and better understanding, these companies need some guidelines in this
area. In this article, I'll describe the page development guidelines for Web designers
targeting dynamic Web applications.
Problem context

Dynamic Web applications typically have the following two activities in their project
lifecycle:
1. Developing static pages for look and feel (by Web designers).
2. Converting static pages to dynamic pages (by Web programmers).

Ideally, a company will combine these activities into one, with a proper
understanding/methodology between Web designers and programmers. This will
happen when most of the integrated development environments (IDEs) support the
technologies and methods for bridging this split (such as supporting Struts tag
libraries for building the user interface). In that case, the activities will merge, and
page authors can directly provide the page design, which Web programmers can
reuse as-is.

However, most IT projects are still undergoing the two activities. The reasons for this
trend may be the lack of tools and knowledge in the specific industry or corporation,
and sometimes the customer initially wants the application user interface for
approval from business users. Sometimes, another organization -- interacting with
business users for requirements -- will handle the Web page authoring activity. Even
worse, if a third-party organization develops the user interface, the round-trips (for
corrections, enhancements, and clarifications) will cause major effort loss and delays
in project execution.

This article is aimed at projects that split the activities. I'll explain the guidelines to
promote best practices and avoid project delays. I've found these guidelines are
useful for addressing more painful areas during development -- such as look and
feel, browser compatibility issues, readability, and data loading problems -- and
maintainability issues during the post-implementation phase of the Web application.

Much of the information available concentrates on best practices in the areas of Java
Server Pages (JSP)/Active Server Pages (ASP), Java Servlets, Enterprise JavaBeans
(EJB)/COM/DCOM, JDBC/ADO technologies, but less information exists on practices
for authoring Web pages for dynamic Web applications. I've based this article on my
project execution experience, and tried to fill the gap.

Web page authoring guidelines

Because Web page authoring involves mainly HTML, JavaScript, and Cascading Style
Sheets (CSS), I'll explore the guidelines in those areas. I've arrived at these
guidelines by looking at the system from the point of view of a few nonfunctional
requirements (such as maintainability, manageability, readability, performance
visibility, and response size).



HTML guidelines

This section provides guidelines for HTML design and constructing user interfaces.

Browser compatibility:
1. All HTML tags should be compatible across different versions of browsers.
2. Avoid using the COLSPAN / DIV /PRE attribute. These work in only a few
browsers.
3. Netscape Navigator doesn't support dotted and dashed border styles.
4. Using negative margins to overlap text can cause unpredictable results and isn't
recommended. Use Cascading Style Sheets (CSS) positioning or layers to overlap
text.
5. Avoid using the IFRAME tag (it works in Internet Explorer only).
6. Ensure that all HTML tags are closed. If not, Netscape Navigator sometimes won't
render the page.

HTML/table design:
7. Avoid nested tables to the maximum extent, if possible. If you author them as
non-nested tables, table rendering will happen as soon as the browser receives
content for that specific table.
8. If you use a WYSIWYG editor, it will speed development. But, if you use any
tools/editors, you might have to remove unwanted code it places. Otherwise, you
could get a sluggish response from the server over the network.
9. Most of the time, a single static page will be converted to multiple dynamic pages
that might assemble during runtime to present the whole page. This practice
typically leads to alignment problems if you don't consider this requirement earlier.
10. The Web programmer has to be able to convert or divide these single static
pages into multiple dynamic pages with ease. Hence, apart from concentrating on
look and feel, take a look at the HTML code complexity.

Image guidelines:
11. Use .JPEG files for photographs and .BMP for artworks with many colors.
12. You should use .GIF files mostly for line art or text with only a few colors.
13. Decrease the total number of graphics, and try to use the same set of graphics in
most of the pages.
14. All images have to be compressed per Internet/Web standards without losing the
quality. This practice reduces the size of images, and ensures pages load quickly.
15. All image tags should contain WIDTH and HEIGHT attributes. This will facilitate
quick loading of images.
16. Don't try to size images using CSS.
17. Get approval for images, colors used, and size of the images and buttons from
business users.
18. Try to minimize the use of images (e.g., consider the Google.com site). If they
aren't required, use buttons instead of images.
19. Sometimes, you can achieve images' look and feel with simple HTML elements
and by applying styles appropriately. In these specific cases, avoid using images.

Readability/maintainability:
20. Every page must have a title significant to the screen. You can add a heading to
each page, if required.
21. All HTML tags and attributes should adhere to some defined naming standards
(mutually agreed upon by the Web page authoring team and programming team).
22. Indent HTML tags appropriately. Avoid empty tag elements.
23. Provide comments wherever possible for better readability.

Nice-to-have features:
24. You should implement tab order for all the form fields. This improves the
usability of the site as it handles input in the old client-server manner.
25. Don't hard-code colors or font properties. Use CSS.
26. Never use absolute path names. This will make application manageability more
complex when the deployment location changes.
27. Implement maximum length for all the form fields.
28. Always use input controls (such as Input Box, Text area, etc.) within forms. This
ensures the data is carried to the server automatically.
29. Use mostly the POST method for all HTML forms. Use the GET method when it's
specifically required. The POST method can carry huge amounts of data to the
server.
30. You have to show required fields in the form with (*) or pointer image* (project
specific). This will prevent the user from realizing the form field is mandatory after
he gets the error from the server.
31. Avoid horizontal scrolling (project-specific), as this can impact the user's
experience on the site.
32. Never fix the width of the body/table/td with pixels or points. Use percentages.
33. If it isn't required, avoid setting background colors to the maximum extent.
34. If possible, don't use frames (project-specific). Frames can affect the user
experience if you don't take proper care. For example, if you open another site in the
"body" frame, the whole site will appear in that frame only if the proper care has not
been taken. If the newly opened site itself has frames, the viewer will get into
clustering of frames in one page.
35. Use META tags to define the various characteristics of the page and keywords.
These will be useful for indexing by search engines.

JavaScript guidelines

This section provides guidelines on using JavaScript while developing static Web
pages.

Browser compatibility:
1. Ensure the JavaScript code is compatible across different versions of browsers.
2. Only Netscape Navigator supports JavaScript Entities. Avoid using them.
3. Check for browser properties/versions to use specific scripts.
4. Always put JavaScript code between <!-- and --> tags so that a browser that
doesn't recognize JavaScript won't display JavaScript code.
5. Use the <NOSCRIPT> tag to provide alternative text for JavaScript-disabled
browsers
6. Before you work with any specific objects, check them with different versions of
browsers.
7. The Layer, Plugin, and MimeType objects aren't supported in Internet Explorer.
8. Netscape Navigator might not support the All object.
9. The Image object isn't fully supported in all versions of Internet Explorer.
10. The Arguments, Applet, and Embed objects are only available in JavaScript 1.1
and higher.
11. Use window.location.href = 'page.htm'; -- don't use location = 'page.htm'.
12. Correctly navigate "select" field (list-box) properties -- use the Netscape-
supported method. Don't use:

var property = document.formName.selectName.propertyName

Rather, use:

var property =
document.formName.selectName.options[document.formName.selectName.optio
ns.selectedIndex].propertyName

Readability/maintainability:
13. Include JavaScript and JavaScript functions within the HEAD tag.
14. Use JavaScript functions rather than in-line JavaScript.
15. If the JavaScript routine is big or reusable, store it in a separate file, and access
it from the HTML page.
16. Always check to ensure the function, object, and variable names used in HTML
match those in the JavaScript code.
17. Declare all global JavaScript variables at the beginning of the script.
18. Precede all local JavaScript variables by "var".
19. Trim all input values before processing them.
20. Follow defined naming conventions for JavaScript code (mutually agreed-upon by
the Web page authoring team and programming team).
21. Don't hard-code error messages/alerts in the script by using alert() function.
They should take from arrays or separate JavaScript file. This will facilitate an easy
change of messages by the customer, and facilitates internationalization for a
dynamic/static site.
22. Declare all event handlers as JavaScript functions. Use event names per defined
coding standards -- e.g., onClick().
23. Use script caching when a script is extremely large or embedded across multiple
pages.
24. Any JavaScript code that doesn't write out to the page should reside within the
head of the document.
25. To avoid confusion, always end single JavaScript statements with a semi-colon.
26. Use double quotes (") for HTML attributes and single quotes (') for JavaScript
string literals.
27. Give enough lines of space between the HTML code and the <SCRIPT> tag. This
helps to identify the JavaScript code within the HTML document.

Nice-to-have features:
28. Use JavaScript functions for client-side calculations, validations, formatting, and
common functionality such as menu development (project-specific).
29. Keep JavaScript functions separate based on context and based on the logical
portions of the page. This will help the programmer work with the functions.
30. Don't mention the JavaScript version in the script tag. Browsers will execute with
the highest version they support. If you want only the specific version, then mention
the specific version in the SCRIPT tag.
31. At a minimum, specify the LANGUAGE="JavaScript" attribute to avoid possible
conflict with any other client-side processing language -- e.g., VBScript.
32. Disabling JavaScript should not stop the application from delivering functionality
(project-specific).
33. Image swapping -- always check for the existence of the image object before
attempting to access any image properties
34. Not all browsers support the void() function. Create your own void function.
35. Avoid writing output multiple times to the document. Instead, concatenate the
data and then write it all at once.
36. When outputting HTML using JavaScript, always escape the forward slash ("/")
by placing a backward slash ("\") in front of it.

CSS guidelines

This section provides guidelines for creating Cascading Style Sheets while authoring
Web pages.
1. Write compatible style sheets that will work for all browsers.
2. Use JavaScript to detect the user's browser type and link different style
sheets (and write different lines of code, in some cases) accordingly.
3. You can't assign most styles to the <TABLE> or <TR> elements. Use the
<TD> element instead.
4. Pages must continue to work when you disable style sheets.
5. Follow the naming conventions mutually agreed-upon by the Web page
authoring team and programming team.
6. In most cases, don't use more than five fonts. Using more than that might
affect the presentation/appearance.
7. Don't use absolute font sizes in pixels.
8. Don't use the !important rule to override the user's settings. It might
confuse Web programmers.
9. Use external style sheets to apply a style across multiple pages, but try to
keep them small. Otherwise, rendering of the document may be delayed until
the external style sheet loads.
10. Use an embedded stylesheet when you want to define styles only for the
current page. Use inline styles to apply style properties to individual elements
on a page.
Final note

This article described the guidelines for Web page authoring for dynamic Web
applications. Although these are basic guidelines, neglecting them will lead to some
painful issues during project development and maintenance. Having these guidelines
handy will definitely benefit your team.

Although these guidelines are the outcome of live project execution experiences,
some might not be applicable based on the chosen project execution methodology or
technology (such as building rich user interfaces with Applets or Flash, etc.). The
guidelines will vary somewhat with the latest specifications and versions of browsers
and languages.