Peer review: Guidelines for front-end (XHTML & CSS) coding

This is one for the techies (normal service will be resumed soon)

We've produced a set of guidelines for front-end coders, primarily for freelancers that we use for this kind of work, but also to ensure consistent quality from our in-house team and to bring new employees up to speed quickly with what we expect.

It's not meant to be an XHTML/CSS tutorial - there are plenty of these already out there. This document is intended to be a reasonably concise guide to quality and best practice.

We thought it might be useful to the wider web development community and so we are releasing this under a Creative Commons license.

The document below is a draft, and we're looking to the web development community for peer review. If you can spare the time, please review it and post feedback as comments to this blog entry. This will help us to create a more useful set of guidelines for us all to use. We will credit in the document all those who have helped with this. Thanks in advance for your help.

Download Nixon-McInnes-Front-End-Coder-Standards-2006_10_06.pdf

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5  License.

Comments

[Alex Farran]

Looks good to me. Nice and clear and not too long. Here are my notes:

Section 5 DIV-isions
Typo "front end end"

Section 8 Javascript

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

We do use javascript for form validation, but it's always backed up by
server side validation. The form validation JS/PHP code I wrote makes
it easy to define both at the same time. "Don't rely on javascript
for form validation" might be better.

Section 9 Minimum markup
I think this can be taken too far. Sometimes it can be a bit more
readable / maintainable to have one more div or span than is strictly
necessary. Maybe some examples would help here.

Section 10 Correctly implemented forms
The name attribute is missing from the first two fields. They won't
work without them.

Section 11 Summary
"No body" => "Nobody"

[Rob Crowther]

Excellent document, I have a few suggestions though:

I agree with the poster above about the form validation, while it should be validated server side there's no reason not to do it with Javascript too.

Section 4: In 'Hacks & Conditional Comments' you say not to use hacks and use conditional comments instead, but in 'Float Clearing' you recommend the use of the Holly Hack. I assume you mean the technique rather than the hack itself, if you see what I mean.

Section 8: In 'Skip Navigation' you recommend hiding the link via CSS but give no explicit guidance. In this case you should hide it by position rather than by display:none as the most popular screen readers will respect the display:none and not mention the hidden link. I'd been doing this wrong for a long time myself. Perhaps also worth mentioning the Fangs extension for Firefox in this regard.

[James B]

The last sentence in Float Clearing paragraph has a typo. I believe the reference to "no now methods" should read "now new methods".

Regards,

James

[Paul Watson]

3. XHTML 1.0 (page 5) / JavaScript (p14)

Your example in the first bullet point uses JavaScript inserted in the body of the page. Accessibility and 'graceful degrading' would be better served if an external JavaScript file was linked to in the 'head' of the document, with the JavaScript itself inserting the event handler into the DOM on window load.

Starting each page with a URL qualified DTD declaration - I totally agree, but is it worth mentioning that the declaration must be on the very first line of the file (no empty lines above it) otherwise IE will render the page in Quirks Mode?

8. Accessibility (page 13)

You might want to explain the difference between the abbr and acronym tags. Also acronym is being deprecated in XHTML 2 for some reason (abbr will take over all of its functions) so maybe you should move towards just using abbr for all abbreviations and acronyms?

Look forward to seeing the finished guidelines.

[wikedcurly]

1) Don't forget FF 2.0!

2) With XHTML 1.0, it's best to not have any javascript in your HTML. You don't have presentational markup, so why would you have behavioral markup? Use JS to attach event handlers to elements with certain ID's or classes. See YUI library or JQuery for good examples.

3) Don't use conditional comments in CSS. I can't think of many reasons you would need conditional comments if you are familiar enough with CSS and how it behaves in different browsers. Odds are you can tweak your CSS to work on all major browsers without conditional comments.

4) For clearing floats, you don't need the Holly Hack for IE, you just need to trigger the property hasLayout to force the container to expand to it's floated children. I use zoom:1; to trigger it. It has no side affects on other browsers. Using the :after pseudoclass and adding a hidden period to the DOM works with other browsers.

5) Using heading in sequence I'm not so sure about, seems very limiting.

6) I think putting content above navigation in HTML might make your site annoying for screen readers. If you do that, add a 'jump to nav' hidden link above your content.

7) For font scaling, percentages are usually best. EMs tend to 'jump' large amounts, making it hard to find the right font size.

8) You mention if an image is purely decorative use an empty alt text. If it's purely decorative, it should be added with CSS.

9) Also remember to make sure your site is readable with images turned off. Use background colors to supplement design when images are unavailable.

Overall, I'm pretty impressed at this document. Most companies (even web design ones) are still in the stone age using tables for layout. You are definitely headed in the right direction. Since you are interested in best practices, check out http://developer.yahoo.com It has a great library of CSS, JS and general topics about web development.

Good luck and good work!

[Mike]

Generally a good guide. Didn't read every section, but seems to be pretty well on the money.
A few thoughts though:

1) JS should be used for form validation, but it should not be relied upon. It's a usability convenience, and can be quite a big one!

2) I believe HTML is a better choice than XHTML. This doc basically sums up my feelings why:
http://www.sitepoint.com/forums/showthread.php?t=393445
You can still keep colours and whatnot out of HTML. You can still validate HTML.

3) Single quoted attributes are also valid, and can avoid complex, hard-to-read escaped strings in the server side code. Swapping between double and single quoted attributes in a given document is also acceptable.

4) This was probably mentioned anyway -- use LABEL tags for form elements; particularly radios and checkboxes.