Front-end Coding Standards by asafwewe


More Info
									Front-end Coding Standards: Guidelines for XHTML/CSS developers

Front-end Coding Standards
Guidelines for XHTML / CSS Developers

Nixon McInnes, Brighton Media Centre, 21-22 Old Steyne, Brighton, East Sussex, BN1 1EL
web:, phone: 0845 345 3462, fax: 0845 345 3463

                                                                                         Page 1
Front-end Coding Standards: Guidelines for XHTML/CSS developers


              1)    Overview
              2)    Browser compatibility
              3)    XHTML 1.0
              4)    CSS
              5)    Semantic structure
              6)    Tables
              7)    Resizable text
              8)    Accessibility
              9)    Minimum mark-up
              10)   Correctly implemented forms
              11)   Summary

                                                                  Page 2
Front-end Coding Standards: Guidelines for XHTML/CSS developers

1. Overview
All websites developed at Nixon McInnes must adhere to accepted web standards. We make a claim that our
sites are standards compliant, so it is inexcusable for us to deliver code that is either invalid or in some way does
not meet a given specification.

It is a primary requirement that any front-end coder working for Nixon McInnes can code to the standards laid out
in this document. We allow a certain flexibility for you to use your own conventions for indenting, comments, etc.
but you must be able to code to the level specified and understand the issues documented.

Please take the time to familiarise yourself with these standards as it will ensure we can deliver sites “right first
time” and avoid lengthy rounds of bug-fixing and re-writes.

If you are unsure about any of the points raised in this document, or do not feel confident in your abilities to
deliver front-end code developed to these standards, you must be honest with us up front and tell us. We can
only go by your word: stating that you code to these web-standards and then later delivering something that
falls short will be unacceptable.

All front-end code must adhere to the following defined standards:

        •   XHTML 1.0 Strict
        •   Non-hacked CSS 1.0 plus as much CSS 2.0, 2.1 and 3.0 that is consistently supported by all modern
            browsers. In practice, until IE7 becomes mainstream, this generally means sticking to CSS 1.0

All designs must also fulfill the following criteria:

        •   Semantically structured HTML
        •   No presentational HTML -- all styling must be done using CSS
        •   No tables except for the rendering of tabular data
        •   Resizable text (and by implication, a flexible layout, even if constrained within a fixed sized design)
        •   Accessibility features such as access keys, skip navigation, useful tabbing index, etc.
        •   The minimum amount of HTML tags necessary for the given design
        •   Correctly implemented forms

                                                                                                                 Page 3
Front-end Coding Standards: Guidelines for XHTML/CSS developers

2. Browser compatibility
It’s a never-ending battle to ensure that techniques we use will work consistently across modern browsers. Our
target platforms for development are:

        •   IE 5.5+ Win
        •   Safari 1.0+
        •   Firefox 1.x
        •   Mozilla 1.7+
        •   Netscape 7.1
        •   Opera 8.0+

It’s useful but not essential to test in the following browsers:

        •   Opera 7.5
        •   Amaya 8.8+

We do not support:

        •   IE 5 Mac
        •   AOL

A note about Netscape 8: It uses either the FireFox Gecko engine or IE depending on user preferences. As long as
you test FF Gecko and IE6 you’re covered with NN8.

                                                                                                          Page 4
Front-end Coding Standards: Guidelines for XHTML/CSS developers

3. XHTML 1.0
XHTML 1.0 Strict is the preferred mark-up language for all web sites. XHTML 1.0 Strict allows for no
presentational parameters, so it ensures that the mark-up is kept small. All presentation should be developed
using CSS. This means you can no longer use attributes such as align=”left” or color=”red”. Note that
XHTML 1.0 Transitional does allow some presentational mark-up but we no longer use it at Nixon McInnes. If you
are familiar with the transitional DTD but not the strict DTD, you must learn the differences and implement the
strict DTD on all projects.

XHTML is much more stringent than HTML. When writing XHTML, you must ensure that:

        •   Tags, parameters and event handlers are declared in lowercase. For example
            <A HREF=”test.html” onMouseOver=”someFunction();”>
                would become
            <a href=”test.html” onmouseover=”someFunction();”>
        •   Values are double quoted (alt=”Image” instead of alt=image)
        •   All tags are closed. This means that all paragraph tags must be closed with a </p> for example. Note
            that some elements do not have content and are considered empty. They don’t require a closing tag,
            but must be closed using a slash within the opening element before the closing bracket, for example
            <input type=”text” /> or <br />. (Note that a later revision to the spec does allow other
            non-empty elements to be closed in this way if they don’t contain content, but as many browsers don’t
            understand this, it should be avoided)
        •   All character entities are escaped correctly. In particular, you cannot use & as a word connector with
            out converting it first. For example, you can’t have <p>Terms & Conditions</p>, it must be
            <p>Terms &amp; Conditions</p>

Each webpage must start with a URL qualified DTD declaration and HTML prologue. Here is the correct DTD
declaration you must use (note that the ᄀ symbol indicates the line has wrapped but in your HTML file it should
continue on one line)

        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"ᄀ

        <html xmlns="" xml:lang="en" lang="en">

It is imperative that you validate your XHTML during front-end development. Use the official W3C validator which
can be found here:

The Firefox browser offers a fantastic development platform for front-end coders. Using this browser with the free
extension “Web Developer Toolbar” is highly recommended as it allows you one-click validation from within the
browser among other very useful tools.

                                                                                                             Page 5
Front-end Coding Standards: Guidelines for XHTML/CSS developers

4. CSS
All design and presentation of the sites we produce must be undertaken using CSS. It is not acceptable to use
any presentational HTML.

You can use extra HTML elements that have no semantic meaning if the design requires them and you can’t find
any other way of doing what you want.

Keep all your CSS rules in external css files. Inline styling is to be avoided unless you only have one or two rules
that need a temporary override on a particular page. Do not embed any CSS in back-end templates or CMS files.

CSS should be as compact and legible as possible. Try and avoid spelling out all the rules separately and
condense as many as possible using CSS shorthand. For example, instead of writing this CSS:

        body {
                 font-family: Arial,Verdana,Helvetica,sans-serif

you can use shorthand to condense it:

        body {
                 font:italic small-caps normal 2em/3em Arial,Verdana,Helvetica,sans-serif

Due to poor support in IE for CSS2+, it’s advisable to rely only on CSS 1 capabilities for all important design
elements. It’s acceptable to use advanced CSS selectors for ‘nice-to-have’ effects in compliant browsers, as long
as it won’t diminish the experience for IE users who can’t see them. Otherwise, you must use classes.

Descendant selectors
Many front end developers new to CSS throw classes around with abandon. We’d recommend against this – it
makes the code harder to maintain and usually ends up in a CSS soup.

A better way is to use descendant selectors on an identified parent element. Consider this HTML

        <div class=”container”>
               <ul class=”list”>
                     <li class=”listitem”><a class=”anchor” href=””>My item 1</a></li>
                     <li class=”listitem”><a class=”anchor” href=””>My item 1</a></li>

        You might style the CSS for this fragment like this:

        div.container {

        div.container ul.list {

        div.container li.listitem {

                                                                                                              Page 6
Front-end Coding Standards: Guidelines for XHTML/CSS developers


        div.container a.anchor {

However, a better way to style this is by identifying the parent element and then styling all it’s children -- this is
known as descendant selectors.. This means you don’t have to litter the HTML with tons of redundant class
information and makes it much easier to maintain. It’s much better to have shorter, more maintainable HTML and
longer CSS than the other way around. Here’s the code:

        <div id=”container”>
                     <li><a href=””>My item 1</a></li>
                     <li><a href=””>My item 1</a></li>

        #container {

        #container ul {

        #container li {

        #container a {

The beauty of using descendant selectors is that you can style up discrete chucks of HTML and be certain that
the cascade won’t mess up other elements that might contain similar children. They really come into their own
when you define a lot of styles globally to be inherited by all children, and then only override certain aspects of
style for particular children that may be containers for other children.

Hacks & Conditional Comments
It has become commonplace to employ hacks to get around CSS rendering bugs in IE5 and 6. The most common
of these is the * html hack which allows specific targetting of IE. The old Voice Family hack and variants have also
been used extensively to correct box model problems in IE<6. The resulting CSS files end up messy and difficult
to maintain.

These techniques are now actively discouraged. Indeed, Microsoft have fixed the * html selector bug in IE7, so we
can no longer rely on it.

Instead of using hacks to target IE, you must now use conditional comments. These are variations of HTML
comments that only IE understands, and they can be used to feed override CSS styles to IE and no other browser.
This code fragment from the document <head> shows their usage:

        <link rel="stylesheet"          type="text/css" media="screen" href="css/master.css" />
        <link rel="stylesheet"          type="text/css" media="screen" href="css/team.css" />
        <!--[if IE]>
        <link rel="stylesheet"          type="text/css" media="screen" href="css/ieonly.css" />
        <!--[if lt IE 6]>
        <link rel="stylesheet"          type="text/css" media="screen" href="css/ie5only.css" />

                                                                                                                Page 7
Front-end Coding Standards: Guidelines for XHTML/CSS developers

There are some key operators you can use to target specific versions of IE:

<!--[if lt IE 6]>
The lt means less than, so this statement will match anything lower than IE 6

<!--[if gt IE 6]>
The gt means greater than, so this statement will match anything higher than IE 6

<!--[if lte IE 6]>
The lte means less than or equal to, so this statement will match anything lower than and including IE 6

<!--[if gte IE 6]>
The gte means greater than or equal to, so this statement will match anything higher than and including IE 6

You can also match dot versions of the browser and use NOT operators by adding ! in front of the operators
above. For more information, see here:


Float Clearing
This can be a big issue in designing layouts that work correctly. As a front-end coder, you should already be
aware of the issues involved and you probably have methods of dealing with it. Many front-end coders are still
using extra elements in their HTML to clear floats. We discourage this as there are no now methods available
using pure CSS which avoid extra HTML mark-up.

        •   For Internet Explorer, you can use the Holly Hack:
        •   For compliant browsers, you can use the containing floats CSS2 approach:

Multi column layouts / source order
Although we have no strong feelings about the approach you use for multi column layouts, it is good practice to
develop your HTML with the content appearing before the navigation. Consider using the One True Layout for
your multi column designs:


It is imperative that you validate your CSS during front-end development. Use the official W3C validator which can
be found here:


The Firefox browser offers a fantastic development platform for front-end coders. Using this browser with the free
extension “Web Developer Toolbar” is highly recommended as it allows you one-click validation from within the
browser among other very useful tools.

                                                                                                           Page 8
Front-end Coding Standards: Guidelines for XHTML/CSS developers

5. Semantic structure
A well-formed, semantically structured HTML document is less easy to develop than you might imagine. It should
however be of prime focus in your mind when developing websites. A well formed document is much more
accessible to a wider variety of devices and is also more usable. Well formed documents degrade well in older
browsers and can be handled more easily by assistive technologies such as screen-readers. Properly structured
documents are also much more easily indexed by the top search engines such as Google and MSN Search.

What do we mean by semantically structured? The word semantic is defined as “Of or relating to meaning,
especially meaning in language”. So we’re looking at the meaning of the structural elements of HTML.

Websites that were built in the 90s and early 00s often did not take into account the meaning of the HTML
elements used to build a page. Elements were often used for presentational reasons. For example <h1> tags
(which signify the top level heading of a page) were often used in inappropriate places simply because they
rendered as large text.

Web development has finally shifted away from this immature methodology. Developers are realising that
elements themselves should be used to convey meaning and structure, quite apart from the content they contain.

There are some basic things you must try and achieve in your well-structured XHTML:

       •   The main title of the page should be defined using <h1>
       •   Other levels of headings should follow accordingly, but you must use them in sequence. You must not
           use <h4> if you haven’t used <h3> before hand. If you need to use a smaller heading tag purely for
           presentational purposes, i.e. font size, then style it using CSS
       •   If you are presenting a list of items, then use the correct list constructs <ul>,<ol> or <dl> -- do not use
           paragraph or other tags. Navigation menus are generally lists, so always structure these accordingly
       •   Be aware of source order: try and design your page so that the most important content is first in the
           HTML source and that secondary elements (navigation, side bar info, etc) appear lower in the source.
           CSS can usually help with a solution here, though it is a tricky thing to do well.

Here is an example of a well-structured XHTML document (minus the DOCTYPE and HEAD declarations):

       <div id=”banner”>
       <div id=”content”>

       <div id=”topnav”>

       <div id=”sidebar”>

                                                                                                               Page 9
Front-end Coding Standards: Guidelines for XHTML/CSS developers


       <div id=”footer”>


Most XHTML/CSS layouts use <div> elements to group related elements together. Some front end-end coders
have a tendency to use far too many of these which are often redundant. This is usually down to a poor
understanding of CSS inheritance and lack of good structural mark-up. Make every effort to reduce the amount of
<div> elements in your pages – it’s easier to develop the CSS for simpler HTML and then expand it later if you
need to.

Additionally, please identify in your HTML the starting and ending of <divs> using comments, like this:

       <!-- start CONTENT -->
       <div id=”content”>

                <!-- start INTRO -->
                <div id=”intro”>

                </div><!-- end INTRO -->

       </div><!-- end CONTENT -->

                                                                                                          Page 10
Front-end Coding Standards: Guidelines for XHTML/CSS developers

6. Tables
Tables were once great. You could slice and dice a lovely Photoshop design into lots of small elements, place
them in table cells, and be pretty sure your design would look consistent across all browsers. Factors such as
consistent column lengths and resizing to fit the screen were all handled by the table and it didn’t require a lot of
thought to get a design from drawing board to code.

Things have changed. People have realised that table based sites are inherently inaccessible. The way the HTML
for a table is designed makes it very difficult to convey meaning through it’s structure. Tables that are used for
design are usually read incorrectly by screen readers. Tables are often ignored by search engines.

As technologies like CSS have matured, developers realised that they could ditch the tables in favour of better,
well formed documents that used only the correct HTML elements in their proper place (see the section on
Semantic Structure above). It’s no longer acceptable to use tables for layout purposes.

Some guidelines on using tables:

        •   No tables to be used for presentational purposes, without exception.
        •   Tables must still be used for tabular data -- do not create a similar structure using <divs> or other
            constructs. It’s both redundant and inefficient.
        •   When using tables, use the correct child tags. Use <th> for column headings, <td> for data cells.
            Add as much secondary markup as is required to fully structure the table, such as <thead>,
            <tbody> and <tfoot>
        •   For accessibility, ensure your table has a title and summary

                                                                                                              Page 11
Front-end Coding Standards: Guidelines for XHTML/CSS developers

7. Resizable text
The web is not print. As a designer or developer, you do not have – and should not have – complete control over
how your website is viewed. Users have all sorts of different requirements and preferences ranging from screen
size to colour schemes. While you can certainly create a design that looks great using the browser defaults, you
should not assume that all users will see it that way, and must recognise that you do not have ultimate control.

Many users choose to change their browser’s default text size. If viewing a website on an especially large screen
resolution, such as 1600x1200, the chances are the default text size is too small. Most browsers allow some form
of control to change the text size which can be invaluable.

Some CSS styling attributes prevent text from resizing in certain browsers. Using the px (pixel) measurement will
prevent Internet Explorer from resizing the text. Other browsers can resize text regardless of the measurement
used, but it’s best to set your text size in a relatively resizable format. The best way to do this is:

Set the main text size on the body tag as a percentage of the browser default, for example:

body {

This will apply to all elements. It’s usually best to set a size that you want your main text content to appear in --
such as your paragraphs, lists, etc.

Then, declare sizes for all your other elements as a percentage of this size -- you can do this using % or ems,
which are pretty consistent across most browsers. For example:

h1 { font-size:200% }
h2 { font-size:165% }
h3 { font-size:125% }

If you are careful about the cascade you should not need to define too many elements sizes.

Flexible layout
A secondary consideration when designing with resizable text in mind is “How will the page layout change?”

This can be a tricky thing to get right and really comes down to trial and error and experience. Sites that use a
fixed-width design can often break quite badly if text is resized too large. Conversely, liquid layouts can look very
strange if text is resized too small.

The best that you can do is to try and design defensive CSS. This simply means that you should assume users will
break your design with their preferences. Do not design with the assumption that you have ultimate control over
every pixel on the screen; you don’t.

                                                                                                                Page 12
Front-end Coding Standards: Guidelines for XHTML/CSS developers

8. Accessibility
Accessibility is a very broad subject as it encompasses not only how you code a site but how well you write your
content. For the sake of this document though, we’ll focus on what goes inside the angled brackets, not outside.

Accessibility encompasses a number of topics, including some that have already been discussed:

        •   Code structure and semantics
        •   Ease of use of the interface, including tabbing indexes
        •   Correct usage of tags and descriptions
        •   Backup content for imagery
        •   Summary content for screen-readers

These areas are all closely related, so rather than looking at each individually, here is a list of things that you must
do to achieve an accessible web page:

Skip Navigation
If your site has navigation elements before the main content, provide a “Skip to main content” link for screen
readers. This is a link that is usually hidden using CSS, but will be available to a screen reader to jump past the
navigation and go straight to the content.

Tab Index
The tab index of a document starts with the first link in the document and works through them all in the source
order until the end. This is often unusable and counter-intuitive to how elements appear on screen. So ensure that
the tabbing order of links and active elements is logical, by using the tabindex attribute. Form elements should
be tabbed through in the order a user expects to complete it, not necessarily in the order of the tags in the HTML.

If your content uses abbreviations or acronyms, they must be expanded using abbr and acronym tags

All images must have an alt attribute. Alt attributes should be meaningful and describe the contents of the
picture without being verbose.

If the image is purely decorative, alt attributes should be marked as empty using alt=””. Don’t put something
like alt=”This image is for decoration only” as it will be read by the screen-reader and is
intensely annoying..

Do not use images for spacing or other similar effects – all these should be done using CSS.

If an image is particularly complicated (such as a diagram or table), you must provide a full description for it. This
is done using the longdesc attribute. The longdesc is simply a link to another HTML file that describes the
content of the picture. However, to pass accessibility validation, any image that uses a longdesc attribute must
also be followed by a “d-link” – a simple link that also links off to the description file. For example:

<p><img src="rex.jpg" alt="photo of Rex the cat" width="300" height="300"
longdesc="rex.html" /><a href="rex.html">[d]</a></p>

                                                                                                                Page 13
Front-end Coding Standards: Guidelines for XHTML/CSS developers

Image Replacement Techniques
There are a number of clever CSS techniques that allow the use of graphical text for headers but leave the
unformatted text in the HTML for search engine and accessibility purposes. These techniques can be used, but
make sure the CSS for hiding the HTML text does not use display:none or visibility:hidden as some
screen-readers will not read the text with those attributes. Instead, absolutely position the element off screen.

When using tables, ensure it’s purely for tabular data. Do not use for presentation purposes. You should also:

        •   Use the summary attribute of table to briefly explain the purpose of the table.
        •   Use the th element for table headers. If the headers themselves are abbreviated, use the abbr
            attribute to expand them.
        •   For complex tables, use the scope attribute on table headers to indicate what they pertain to, and the
            headers attribute on table cells where there isn’t an obvious correlation with a given header.

Use of colour should fulfil the following criteria:

        •   Text should be readable with high contrast. Either use a light background with dark text or vice-versa.
            Very light text on a light background is virtually impossible to read for most people, it can be even
            worse for those with colour-blindness.
        •   Do not use red and green together to make distinctions between key functionality - a small percentage
            of people will not be able to perceive the distinction. Instructing them to click the green box for yes or
            the red box for no, for example, should be avoided.

The WAI site contains a list of colour-blindness tools that let you see sites as people with different types of colour-
blindness would:

JavaScript is permitted but keep it’s use to a minimum. Pages should still be functional with JavaScript disabled.
Use it sparingly, for non-essential functionality or special effects.

Do not use JavaScript for form validation -- it should be done server side.

                                                                                                              Page 14
Front-end Coding Standards: Guidelines for XHTML/CSS developers

9. Minimum mark-up
This is very straightforward. Do not use more HTML tags than you really need. Unless a design really needs an
extra wrapper <div>, there’s no need to put one in. Keep the HTML as simple as possible and try to avoid using
extra elements – always try to solve your design issues using CSS. CSS is your friend and you’d be amazed at
some of the things you can achieve, even with very few HTML elements.

                                                                                                       Page 15
Front-end Coding Standards: Guidelines for XHTML/CSS developers

10. Correctly implemented forms
XHTML is much more strict when it comes to implementing forms. In HTML 4 and earlier, you could simply place
<input> elements in a <form> element and it would be considered valid. This is no longer the case – all input
elements must be contained within another semantic element within the form. There are also considerations for
best practice that are not part of the strictness of XHTML but really help with accessibility. So you should ensure
that you do the following:

        •   Group related fields together using the <fieldset> element (this will stop the validator complaining
            you’ve got <input> tags in the wrong place and aids accessibility)
        •   Name your fieldsets with a valid <legend>. You can hide this using CSS if you don’t want it to
            appear on screen.
        •   Create <labels> for every element and ensure you associate the label with it’s corresponding field
            using the for attribute where appropriate. This is especially important on radio buttons and
            checkboxes so that the user can click the label as well as the control to select the option.
        •   For formatting, do not use tables. We have found that CSS styled definition lists work well for forms
            that have column of labels and then a column of fields, and it’s a reasonable semantic use of <dl>,
            <dt> and <dd> elements.
        •   Ensure that radio buttons share the same <name> tag so that the mutually exclusive functionality
            works correctly

Here’s a sample of a correctly constructed form. The elements shown must be included as a minimum.
Formatting using <dl>, <dt> and <dd> is optional.

<form id=”myform” method=”post” action=”script.php”>

<fieldset title=”User data” id=”userdata”>

<legend>Enter your details:</legend>

                <label for=”name”>Name:</label>
                <input type=”text” id=”name” />

                <label for=”email”>Email:</label>
                <input type=”text” id=”email” />

                <label for=”option1”>Option 1:</label>
                <input type=”radio” id=”option1” name=”options”>

                <label for=”option2”>Option 2:</label>
                <input type=”radio” id=”option2” name=”options”>

                <label for=”option3”>Option 3:</label>
                <input type=”radio” id=”option3” name=”options”>

                <input type=”submit” value=”Submit” />



                                                                                                            Page 16
Front-end Coding Standards: Guidelines for XHTML/CSS developers

11. Summary
If you adhere to these rules, the sites you build will function well, be accessible, be search engine friendly, be
more usable and be future proof. It may seem that some of the rules are tricky to implement for little gain, but they
all help towards better websites.

Our goal is to develop the best, most up-to-date sites on the web. The quality of the HTML and CSS we produce
directly affects that, so low quality code = low quality site. No body wants that, so please do your bit to ensure
your work helps us achieve that goal.

Matthew Hill
Web Designer / Developer at Nixon McInnes
6 October 2006

                                                                                                             Page 17

To top