Web development mistakes, redux
There have been a lot of comments on my recent post about common web development mistakes, and that’s great. Not all comments are of the kind I asked for, but that made for an interesting discussion, which didn’t get completely out of hand.
I’ve gone through the original list and added some mistakes mentioned in the more constructive comments, along with, and perhaps this should have been there from the beginning, my reasons for calling something a mistake and including it in the list. I’ve also added links to more information on some of the mistakes, for those who want to know more.
- DOCTYPE confusion
- Completely missing, incorrect, or in the wrong place. I have seen HTML 4.0 Transitional used in documents containing XHTML markup as well as in
<frameset>documents, DOCTYPE declarations appearing after the opening
<html>tag, and incomplete DOCTYPES.
- Why? Two reasons. First, it’s required, as stated in the W3C HTML 4.01 spec as well as in the W3C XHTML 1.0 spec. Second, modern web browsers use the specified DOCTYPE to decide which rendering mode to use. This is also known as “DOCTYPE switching”. For more consistent results across browsers, especially when using CSS, you’ll want browsers to use their “Standards compliance mode”. More info on DOCTYPE switching can be found in Fix Your Site With the Right DOCTYPE! and Activating the Right Layout Mode Using the Doctype Declaration.
- <span> mania
- A common way of styling something with CSS is to wrap it in a
<span>element with a class attribute and use that to hook up the styling. I’m sure we’ve all seen things like
- Why? It is, in most cases, completely unnecessary, has no semantic value, and just clutters the markup. Use heading elements for headings, put paragraphs in paragraph elements, mark up lists with HTML list elements. Use CSS to style those elements. If necessary, add class or id attributes.
- (too much) Visual thinking
- Treating the web as WYSIWYG – starting off by focusing on how things look instead of thinking about structure first, and presentation later.
- Why? While most people using the web are sighted, all are not. And there is no way of making the web WYSIWYG. There will always be variations as long as people use different browsers, operating systems, monitor sizes, screen resolutions, window sizes, colour calibration, and font sizes. The web is not print or television. Make your design flexible.
- Lack of semantics
- Non-semantic markup. Basing the choice of which HTML element to use on the way most graphical browsers render it by default, instead of on which meaning the element has.
- Why? This mistake is closely related to “<span> mania”, in that it does not make proper use of existing HTML elements to give content meaning. Without semantic HTML, it is much harder for non-visual user agents to make sense of the content. Semantic HTML also tends to be easy to style with CSS.
- Character encoding mismatches
- Specifying one character encoding in the HTTP header sent by the server, and using another in the document. This may confuse browsers and make them display the document improperly.
- Why? Because you want to make sure all your visitors can read your content.
- Bad alt attributes
- Missing or useless.
<img>elements with missing
altattributes can be found in billions on the web. Not quite as common are useless attribute values like “spacer GIF used to make the layout look good”, “big blue bullet with dropshadow”, and “JPEG image, 123 KB”. Remember, the
altattribute is required for
- Why? It’s required, and without it, any information in the image will be invisible to screen readers, text-only browsers, search engine robots, or users with images turned off. Note that alternate text should be relevant. Do not specify alternate text for decorative images or images used for layout. In those cases, specify an empty string,
- Invalid id and class attributes
Multiple uses of the same value for the
idattribute. Invalid characters used in
classattributes and CSS selectors.
For CSS (CSS 2.1 Syntax and basic data types):
In CSS 2.1, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [A-Za-z0-9] and ISO 10646 characters U+00A1 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit.
For HTML (Basic HTML data types):
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (“-”), underscores (“_”), colons (“:”), and periods (“.”).
- Why? Browsers that follow the specification will not display your document as intended. If a document has multiple occurrences of the same
- Browser sniffing
- Using scripts, server or client side, in an attempt to detect the visitor’s browser, and send or execute browser-specific code. Very commonly fails for reasons like new browsers, updated browsers, and user agent spoofing (Opera does this by default).
- Why? It adds unnecessary complexity, and will break eventually.
- Missing units in CSS
- Length values (horizontal or vertical measurements) require units in CSS, except when the value is zero. It’s not like in HTML, where you can type
width="10". In CSS, it has to be
width:10px;(or whatever unit you’re using).
- Why? It doesn’t work in browsers that follow the CSS 2.1 specification.
- Browser-specific CSS.
- Scrollbar styling, expressions, filters etc. Proprietary CSS that only works in Internet Explorer. Invalid, too.
- Why? Only works in a specific browser. If you really must use IE-specific CSS, move it to a separate file and use conditional comments, or some other means, to make sure only IE sees the invalid rules.
- Why? Inaccessible and bad for search engine rankings.
- Flash dependency
- Assuming everybody has Flash installed. Not everybody has. And most search engine robots do not (Google has reportedly started experimenting with indexing of Flash files, but they still recommend that you make sure all your text content and navigation is available in HTML files), so if your whole site, or your site navigation, depends on Flash being available, you’re not going to score high with search engines.
- Why? Inaccessible and bad for search engine rankings. I’m not saying you shouldn’t use Flash at all, just that you should use it sensibly.
- Text as image
- Making images of text, and not providing a more accessible alternative. Not only does it take longer for visitors to download images instead of text, you also make it impossible for all visitors to copy the text, and for most visitors to enlarge it.
- Why? Inaccessible, increases load time, bad for search engine rankings.
- Bad forms
- Inaccessible, hard-to-use forms. Learn to use the
<legend>elements, and do not use a “Reset” button.
- Why? Inaccessible, decreased usability. Read Creating Accessible Forms, Better Accessible Forms, and Reset and Cancel Buttons to learn more about creating accessible and usable forms.
- Old skool HTML
- Multiple nested tables, spacer GIFs,
<font>elements, presentational markup. So common I don’t really have to mention it here.
- Why? Increased complexity, bloated pages, slow, inaccessible, bad for search engine rankings.
- Being IE-centric
- Coding for IE/Win first, then adjusting for others, if there is time.
- Why? Takes more time, encourages bad coding practices. IE/Win is notorious for accepting sloppy, invalid HTML, which breaks in many other browsers. IE also accepts well-formed, valid HTML, which works in all browsers, so by using valid HTML you make all browsers happy, and it doesn’t take more time or cost more. Also see The IE Factor.
- Invalid HTML attributes
- Using deprecated or browser specific attributes like
- Why? Invalid and unnecessary. Use CSS instead. For
- Unencoded ampersands
- Many URIs contain long query strings with unencoded ampersands (&). This is invalid, and may cause problems. Ampersands must be written as
- Why? An explanation as well as an example of what can go wrong can be found in Ampersands and validation.
- Using frames to split the browser viewport into several independent documents.
- Why? First of all, let me say that frames may be useful, if used in the right way, in intranets and certain web applications. For a public website, however, frames have too many accessibility and usability problems. Bookmarking problems, printing difficulties, trouble with deep linking, and having to do search engine workarounds are a few of the drawbacks to using frames.
- Inaccessible data tables
- Tables containing tabular data, but marked up as if they were layout tables, not using any of the many elements and attributes that are available for making tables structured and accessible.
- Why? Screen readers and other assistive technologies have no way to make sense of a data table unless it is marked up correctly. A whole bunch of links to articles describing how to mark up data tables can be found in A table, s’il vous plaît, at the Web Standards Project.
- Divitis and classitis
- Related to <span> mania. Adding unnecessary div elements and class attributes.
- Why? See “<span> mania” and “lack of semantics”.
- Too wide fixed width
- If you use a fixed width design, don’t make it too wide. Note: I’m not getting into the whole debate on fixed vs fluid width here.
- Why? If your specified width is wider than your visitors can fit on their monitor, you force them to scroll horizontally, which is really bad for usability.
- Vague and/or presentational class and id names
- Naming a
idbased on how it looks rather than on what it does.
- Why? Doing this is asking for confusion when you redesign. A class named
largebluemay end up making text small and red. An id named
leftcolmay be displayed to the right.
- No background colour
- Failure to declare a background colour for the body element.
- Why? Many users do not have their browser set to display the same default background colour as you do.
- Non well-formed XHTML
- Using XHTML that is not well-formed.
- Why? If XHTML is served as “application/xhtml+xml”, which it should be, strictly compliant browsers, like those based on Mozilla, will not render non well-formed XHTML. Note that this site currently does not serve all documents as “application/xhtml+xml”, for certain reasons explained in my post on Content negotiation.
- Incomplete colours for text input fields
- Specifying only background or text colour for form fields, especially single and multi-line text inputs (
Why? Some people set their browser or operating system to use inverted colours. The default for a text input would then be white text on a black background, instead of black on white.
If you set the text colour for text inputs to dark grey, and don’t specify a background colour, people with inverted colours would get dark grey text on a black background, which is next to impossible to read. The opposite will also cause problems – specifying a light grey background without specifying the text colour would lead to white text on a light grey background.
Always specify either both text and background colours, or none at all, for text input fields.
That’s a pretty long list of things to watch out for. Avoid them all and you’re doing very well. If you’re currently making some of these mistakes, well, if it’s any consolation, I’ve been guilty of making a lot of them at some point. Hopefully this list will help you make fewer mistakes in the future.