Center a table for IE and FF

Have you ever struggled with getting a table centred in a CSS (Cascading Style Sheet) container and just when you get it to work in Internet Explorer, it does not work in Mozilla / Firefox, and vice versa?

Here’s a hint to help you – use two nested division containers around the table, each formatted for a different browser, and add the appropriate classes to the Style Sheet, for example:

<div class=”center_ie”>
<!– IE needs this div (with style text-align: center) to centre the table; Mozilla / Firefox ignores this text formatting since a division should contain other objects, not text directly. –>
<div class=”center_ff”>
<!– Mozilla / Firefox needs this div (with width and margins set in the style) to centre the table; IE ignores it since it doesn’t understand margins too well. –>
<table>
…
</table>
</div>
</div>

Taking the Mystery Out of XHTML

Some authors find coding in XHTML 1.0 Strict (Extensible Hypertext Markup Language) a frustrating experience, since suddenly things that worked before in lower standards, are no longer working as expected. However, it can be plain sailing if the following 10 rules of XHTML are kept in mind:

1. Well-formedness
   Well-formedness is a new concept. Essentially this means that all elements must either have closing tags or be written in a special form, for example stand-alone tags are closed by adding a space and / before the end angled bracket, like this:
   <img href=”…” width=”…” height=”…” alt=”…” />
2. Properly nested tags
   All the elements must nest properly, e.g.
   <p>This is a paragraph with <span>some text in bold</span>.</p>
   Note that the start and end tags of <span> are both inside the <p> start and end tags.
3. Lower case code
   XHTML documents must use lower case for all HTML element and attribute names, and for character entity references.
4. Properly closed tags
   All elements must be properly closed with an end tag, for example:
   <p>This is a paragraph.</p>
5. Quoted tag attributes
   All attribute values must be quoted, even those which appear to be numeric, for example:  <td rowspan=”3″>
6. Closing empty element tags
   Empty elements must end with /> (and there must be a space before the slash). For example:  <br />, <img … /> or <hr />.
7. No spaces in attribute values
   Strip leading and trailing white space from attribute values, For example: rowspan=”3″ is correct, but rowspan=” 3 ” is not. Also, avoid line breaks within attribute values. These are handled inconsistently by browsers.
8. Name attribute deprecated
   Note that in XHTML 1.0, the name attribute of elements is formally deprecated. Use the id attribute instead for the elements a, applet, form, iframe, img, and map. There can only be a single attribute of type id per element in one file (page). If the same element needs to be identified repeatedly on one page, use the class attribute.
   NOTE: Many existing HTML browsers don’t support the use of id-type attributes, so identical values may be supplied for both of these attributes to ensure maximum forward and backward compatibility, for example:
   <a id=”foo” name=”foo”>…</a>.
9. Script or style element
   In XHTML, the script and style elements are declared as having #PCDATA content. Wrapping the content of the script or style element within a CDATA marked section avoids the expansion of the < and & entities. Thus:
   <script type=”text/javascript”>
   /* <![CDATA[ */
   ... unescaped script content ...
   /* ]]> */
   </script>However, it is even better to reference the script from an external file. Then the syntax is
   <script type=”text/javascript” src=”some_file.js”></script>
   Scripts contained in the HTML file often give rise to validation errors due to the strict rules of XHTML 1.0.
10. Character entity codes
    Authors should use & # 3 9 ; (without the spaces) instead of &apos; for an apostrophe to display as expected in browsers. Beware of hyphens and dashes, these often fail in browsers. Use & # 4 5 ; (without the spaces) for a hyphen, &ndash; for a short dash, and &mdash; for a longer dash. Beware: &ndash; and &mdash; are not included in the ISO-8859-1 character set!

Here is an example of the syntax and structure of an XHTML document with the most commonly-used meta tags included:

<!DOCTYPE html
PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd” >

<html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en” lang=”en”>

<head>
<meta http-equiv=”content-language” content=”en” />
<meta http-equiv=”content-type” content=”text/html; charset=ISO-8859-1″ />
<meta name=”keywords” content=”keyword 1, keyword 2″ />
<meta name=”description” content=”Short description of the website.” />
<meta name=”author” content=”Author name” />
<meta name=”rating” content=”general, 14 years” />
<link rel=”shortcut icon” href=”favicon.ico” />
<link rel=”icon” href=”animated_favicon1.gif” type=”image/gif” />
<link rel=”stylesheet” type=”text/css” href=”styles.css” />
<title>Page title</title>
</head>
<body>
… page content …
</body>
</html>

Further examples of Document Type Definitions (DTDs) can be found at www.w3.org/QA/2002/04/valid-dtd-list. Read more about the XHTML 1 standard at www.w3.org/TR/xhtml1.

Successful Web Design Part 2: The Code

Once we have planned the website in detail, we can begin the task of coding it all. By now we have all heard of standards, but what are they, and which should we use?

1. HTML standards

   The web browser needs to know according to which standard it must interpret the code on the page. This information is given in the DOCTYPE declaration at the top of the file. If there is no document type declaration, the browser will assume the lowest standard. There is an amazing number of websites out there with no document type declaration!

   Here is an example of the syntax of the declaration:
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" >

   For the lower standards the browsers will attempt to self-correct errors the webmaster may have made in the coding, for example when the closing tag of a tag pair was omitted. This may lead to very unpredictable results on screen.

   The higher the standard, the stricter the rules are for the webmaster about what code is acceptable, but that means it is easier for the browsers to interpret the code. The benefit to the webmaster who uses a strict standard is that the different browsers are likely to interpret the code correctly, and the website will be displayed as intended in the different browsers (without having to resort to clever code or hacks to force different browsers to behave as you would like them to).

   The standards are (listed from more relaxed to strict):

   • HTML 4.01 Transitional
   • HTML 4.01 Frameset - The use of framesets are being discontinued since the behaviour of frames on many browsers can be unpredictable. Search engines will find frames out of context of the frameset.
   • HTML 4.01 Strict
   • XHTML 1.0 Transitional
   • XHTML 1.0 Strict - This Extensible HTML standard is very similar to HTML 4.01 Strict, but a definite improvement. It is currently well-supported by browsers.

2. CSS standards

   One of the main features of the XHTML standard is that the formatting tags are discontinued. This means that all formatting must be coded in the Cascading Style Sheet (most features of the CSS2 standard are currently well supported by browsers).

   The use of a CSS for formatting is a requirement for accessibility - page content is more accessible to screen readers if the formatting is separated from the content.

   The main layout of the page is controlled by divisions (the <div> tag), the positioning and formatting attributes of which are specified in the CSS. Tables may be used to control layout, but once again, the formatting of such a table is specified in the CSS.

   Other benefits of using a CSS are:

   • It is easy to make a global change to the format of a recurring element, since all pages read formatting instructions from the same CSS file.
   • Removing the formatting from the HTML file means the code is more efficient and the page will load faster.
   • One website can have more than one CSS, e.g. one to display elements on screen and another to print information from the pages (perhaps omitting elements like menus, specifying a narrower page width to fit the printed page, etc.).

3. Accessibility guidelines

   Follow the guidelines of the W3C's Web Accessibility Initiative (WAI). Read more about the WAI at www.w3.org/WAI. Here are the most important things we need to do to implement the WAI guidelines:

   • Use a scalable font (relative sizing) so that poor'sighted users can enlarge the type on screen. Read more about font sizes at www.w3.org/QA/Tips/font-size
   • Separate formatting from content - use a Cascading Style Sheet (CSS). The HTML file must not contain any formatting instructions.
   • Create pages that validate to formal standards for the web.
   • Skip to content - Place a small (1 px) image in the top left-hand corner of all pages after the first, with a bookmark link to the main content of the page. This helps disabled users making use of screen readers, to skip to the main content without having to listen to all the menu items again.
   • Provide alternative text descriptions for images (the alt attribute in the <img> tag). The alt text description must end with a full-stop - this helps determine correct voice inflection for screen readers.
   • Add the accesskey attribute to the recurring main elements on each page and define the access keys on the accessibility page. These keys act as short-cut keys for people who have problems with using pointing devices. For example, ALT-h will take the user to the home page if the accesskey="h" attribute is added to the home page link tag, for example:
     <a href="index.html" accesskey="h">Home Page</a>
   • Add the tabindex attribute to key elements on a page to define the direction of movement of the cursor on the page when the Tab key is pressed.
   • Add the lang attribute to the <html> tag to identify the language of the website for screen readers, like this:
     <html lang="en">
   • Organise the page so that it may still be read without the style sheet (it may not look good, but it must still make sense).
   • Use the clearest and simplest language appropriate to the website's content.
   • Avoid using image maps. If an image map is used, provide redundant text links for the active regions on the image map.
   • Use column and row headers for data tables. Add the summary attribute to the <table> tag.
   • Provide equivalent information and an alternative means of access if scripts are turned off or not supported.
   • Avoid using multimedia. If a movie our sound clip is included, provide an alternative text description of the multimedia content.
   • Ensure foreground and background colour combinations provide adequate contrast. If a background colour is specified, also specify the text colour for that element, and vice versa, for example:
     color: #3779b6; background-color: #fff;.
   • Use text rather than images to convey information. Text that is part of an image must be repeated in the text markup.
   • Use header elements to convey page structure and use them consistently.
   • Avoid causing content to blink.
   • Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.
   • Clearly identify the target of each link (don't use "click here" as the link text).
   • Provide metadata to add semantic information to pages and sites for example the <title> and <description> tags in the header of the file.
   • Provide information about the general layout of the site (e.g. a site map, table of contents or an index).
   • Use navigation mechanisms in a consistent manner.
   • If a table is used for layout, do not include attributes for visual formatting in the table element tags (put those in the CSS).
   • Specify the expansion of each abbreviation or acronym in a page where it first occurs (use the <acronym> and <abbr> tags).
   • Include non-link, printable characters (surrounded by spaces) between adjacent links.

4. Create a template for content pages

   Keeping all of this in mind, we are now ready to start coding the template page. It is a very handy time-saver to have such a template that can be copied for the creation of each new page during the development of the website.

5. Validations

   HTML and CSS validations can be done via file upload to the validation tool before pages are published to the web server, but accessibility validations can only be done after the pages are published.

   • Every page of the website needs to be validated for conformance to the HTML/XHTML standard declared in the DOCTYPE - validator.w3.org.
   • The CSS file needs to be validated - jigsaw.w3.org/css-validator.
   • Every page of the website needs to be validated for accessibility - read more at www.w3.org/WAI/eval/conformance.html#evaltools.

These are the basic guidelines. Keep them in mind and you are off to a good start, but there is still much to learn - good luck!

Successful Web Design Part 1: Layout

1. Goals

   • Why do we need this web site (what is the message, what are the expected business outcomes)? (Business Process model)
   • Who is the target audience and what are their expectations? (Information system Use Case model)
   • What do we know about the audience in general in terms of their skills, ability, and access to the internet (browser versions, bandwidth)?

2. Group and Prioritise

   • Make a list of all the different bits of information that needs to be conveyed to the website user.
   • Group related items together.
   • Prioritise the groups and the items inside each group – this will begin to give us an idea of the structure of the website and how the information should be presented on the different web pages.

3. Basic website pages

   Different kinds of pages have different jobs to do:

   • Home page – should be welcoming, uncluttered, provide links to key areas of the website (the main groupings). The user must immediately see what this website is all about, but beware of turning the home page into a sitemap!
   • Accessibility page – explains the measures taken on the website to comply with the W3C accessibility guidelines, e.g. what short-cut keys are available to the user, what HTML and CSS standards are followed.
   • Sitemap – create a sitemap (see XML-Sitemaps.com) for your website. This is a good way of getting search engine spiders to index the whole site, and it is a useful navigation tool for users with disabilities or as an alternative to dynamic menus.
   • Index page – can be useful for very large sites. It is like a sitemap, but provides links in the form of alphabetically listed keywords.
   • Content page – contains the information, feedback forms, etc.
   • Contact Us – an important content page, which should, when appropriate, include a map to the physical location of the business.
   • Form – the user completes the input fields and submits the information or request. The form is driven by JavaScript (for validations) and processed by Perl or some other suitable web programming language.
   • Form follow-up page – once the user submits a form, there must be a follow-up page to assure the user the form has been sent.
   • Privacy policy – if the user is expected to submit personal details, there must be a privacy policy page where he can get assurance about the protection of his privacy.

4. Plan the website structure

   • Now that we know what pages we need, draw a plan (or compile a document) of all the groupings with the group items that represent individual web pages. This is a refinement of what we did before. Now we decide the detail of what is going to be on each page.
   • The groupings will become the labels on the Main Menu of the website.
   • For each page, make a list of the anchors, other pages, or external sites this page must link to (think of the logical flow of the information).
   • Keep the hierarchy of the structure as shallow as possible – preferably no more than 2 layers deep, but on a large or complex site a third layer can sometimes not be avoided.
   • A note about page length: For a well-designed website, any one page should not be longer than 2.5 screens.

5. Plan the menu navigation

   • Decide on placement of main menu and sub-menu. What type of menu – plain text, or dynamic drop-down menus? Plain text menus are safer (they don’t require JavaScript), but drop-down menus free up more space on screen for the content.
   • If you are using a drop-down menu, it is a good idea to repeat menu text links in the footer. This is an aid both to search engine spiders (indexing robots) and to users with certain disabilities.
   • Decide on how to indicate to the user where he is, e.g. breadcrumbs or a simple marker or colour change on the menu and sub-menu.

6. Plan the design look and feel

   • Keep it simple, clear and uncluttered. Do not make the user think! Everything should be obvious and self-explanatory. Website users generally don’t read pages, they scan them. They often don’t make optimal choices, they choose the first reasonable option -
     this is a strategy called satisficing.
   • Decide on horizontal page placement on screen – left-aligned, or floating centred, etc.
   • Decide on width of content – for what screen size (monitor resolution) are you designing? Designing for a 800 pixels wide x 600 pixels high resolution is a good, safe median to use, although screens are commonly getting larger and website designs are following the trend. If you are designing for a specific target audience, you need to design for the size sceen the members of that audience will be using, for example large computer
     screens, or small mobile device screens. Referencing different cascading style sheets for different media means you can accommodate a variety of screen sizes and a printer.
   • Place the business logo preferably at the top left-hand corner of the screen on every page and make this a link to the home page. (This has become a convention amongst webmasters, and users have learnt to expect it.)
   • Decide on the size and placement of a banner for content pages.
   • Add a tag line (slogan, motto) to the home page and possibly the header or banner of all pages.
   • Decide what colours to use – limit it to white plus 2, or 3 at most.
   • Plan the use of colours to provide good contrast. Beware of clashing, garish colours. Keep in mind many users (10 % of all men) are red/green colour blind.
   • The home page (or doorway page) can look different, but all other pages must have the same layout for a consistent user experience.
   • Create a clear visual hierarchy -
     • More important elements must be more prominent.
     • Group logically related elements together visually.
     • Elements should be nested visually to show what is part of what (e.g. with headings and sub-headings).
     • Decide on a style and hierarchy for headings
       and use these consistently throughout the website.
     • Decide on the placement of the page heading – each page must have a heading. This is important high impact confirmation for the user about where he is.
   • Break pages up into clearly defined areas.
   • Cut down visual noise – pages must not be too busy, with too many elements clamouring for the user’s attention. Limit background visual noise – watch out for superfluous colours or lines that distract the user’s attention and make it harder to focus on the important message on the page.
   • Does the page need a footer? What information does the footer need to contain? A copyright notice is customary.
   • Decide on font type and size. Verdana is best for web sites, but include sans-serif as the second option in case Verdana is not supported by the browser. Use a scalable font size notation using relative length units such as percent or em.
   • Make it consistently obvious what is clickable and what is not.
   • “Above the Fold” design – place important elements or information on the first screen of a long page.
   • Content – use simple language and be as brief as possible while still conveying the message. Omit needless words. Users have a short attention span and are usually in a hurry. Don’t give them too many words to read (unless the web page intends to
     publish a book or article which, by its nature, is purely text-based).