Best Practices in Web Development
Roger Johansson and Sean Fraser recently reviewed websites which were submitted for the CSS Reboot Spring 2006, and they seemed to be quite shocked when 71.8% failed to validate. While this is sobering and to a degree surprising — one might expect better results from CSS aware developers on a relaunch — it confirmed my own results from reviewing a couple of high profile websites for clients.
In this article:
Case study
Over the years we made several technical analyses for the clients’ own websites and some of their competitors, including major German broadcasting companies, TV program journals, and a couple of large online travel sites.
We were checking for overall performance like file sizes as well as best practices in (X)HTML, CSS, semantics, and some other aspects of friendliness to users and search engines. We mostly skipped accessibility because there were already severe errors in the other areas.
It’s not like these websites were made by some backstreet crack houses agencies. All have a well-known logo stuck to them, most of them get more than a million visits each month, some up to more than a hundred million. Still the reviews felt like a time-travel to 1998. In our elite circles we speak about a “new professionalism,” but HTML in the wild is still a very dark and ugly jungle.
Most common errors were missing alt-attributes and unencoded &-characters in URLs. Also quite common were XML endslashes in HTML documents, or hacks from the nineties: proprietary attributes like background in table data, height in a table row, marginwidth, marginheight, topmargin and leftmargin, or missing type attributes in style and script tags.
Only a few were missing a doctype declaration (DTD) altogether, most ran HTML transitional 4.01 in quirks mode, only one claimed to be XHTML 1.1 (gasp). Seven out of ten had a charset encoding, but only the XHTML website did care to define the site’s language. Almost all had no clue about CSS positioning and used table layout.
Sometimes we encountered code where developers obviously hadn’t understood even the most basic principles of CSS 1. They used either font tags with style attributes, or other tags just like font tags with a lot of repeated inline style. Thus the advantages of CSS through central style sheets with classes and IDs were counteracted.
It didn’t come as a surprise that the few websites using CSS 2 for layout had significant smaller file sizes. Those with CSS 2 had between 15-21 KB of HTML, their competitors with table layout 55-95 KB. Still you got to pay attention to the file size of images and rich media (including banners) as they frequently blow up the total amount. Be aware of DHTML menus, as they have a tendency to get out of control sizewise (40k JavaScript in one case, 85k in another). Less than a total of 100k for the home page should be sufficient, even for sites with rich graphic interfaces.
I don’t want to bore you with further rants about burning bandwidth with 600k large home pages (multiply that by a million), hence we thought positive and made a checklist of best practices. Although the checkpoints appear to be quite obvious and common sense when you read them, you might be surprised that the best website managed to fulfil 22 out of 29 checkpoints, the worst only 8, with an average of 12.
By the way, the HTML and CSS part of the checklist is more or less the same we use for testing the qualifications of job applicants. We associated a severity grade (major, average, minor) with each checkpoint, and for each error in the small task we give them we subtract 3, 2, or 1 point(s) respectively from a maximum of 100. Half the amount is subtracted when a checkpoint is partially fulfilled. We adopted that system from the German accessibility test — it’s fair and a great way to compare test results.
Here’s the short version of our checklist. Feel free to make your own severity rating. Just be consistent in your own tests to get comparable results.
Best practices in HTML
- The document must validate as HTML or XHTML.
- The document must have a DTD.
- The document must have a character encoding, either through a HTTP header or a
metatag. -
The document should have the language defined in the following ways:
<html lang="en"><html xml:lang="en"><meta name="content-language" content="en">
- All attribute values should be quoted. In XHTML, quotes are mandatory.
- Element and attribute names should use a consistent case to enhance readability, preferred is lowercase for XHTML compability.
- Code should be well
<!-- commented -->to help maintaining developers to get a fast grip of the basic structure and key concepts. - Code should be consistently indented, tabs preferred over spaces.
- Images, image maps and scripted content must have an
alt-attribute with an appropriate value. - Images should always specify their
widthandheightto allow browsers to continue rendering while waiting for the image data. - Some special characters like
",<,>, and&(especially within attributes likehreforsrc) must always be replaced by their character entities or numeric character references (NCR). Also characters not included in the character set, like€in ISO 8859-1, must be replaced. The W3C I18N activity group further recommends to replace other special characters like–, but not common characters like “ü” in German texts or “é” in French to maintain code readability. scriptandstyletags must have atypeattribute.-
JavaScript code should be included using external files for caching and better maintenance.
Of course with Yahoo’s performance research about browser cache and HTTP requests you could discuss if external files load faster with several server requests through
script src="foo.js"or just one request and internal HTML code, but either way you should use central, non-redundant files and include them in one way or another.
Best practices in CSS
- CSS must validate.
- Elements should be positioned with CSS 2, not tables.
- All ornamental lines, borders, background colors and -images, underlines and other decorational elements should be rendered with CSS 2.
- Text should be formatted with CSS 1, not with
fonttags. - All style sheets should be included in reusable, centrally maintainable, and cacheable external CSS files, not as redundant code within the HTML files.
- External CSS files should be sent with the correct MIME type (
text/css). - CSS classes and IDs must be valid, i.e. beginning with a letter, not a number or an underscore. IDs must be unique. Their names should be generic, describe functionality rather than appearance.
Best practices for search engines
- Use a descriptive title with the name of the website and consistent separating characters in it.
- Use keywords, keyphrases, and a description reflecting the page’s content.
- The URL should be descriptive, human-readable, easy to remember, to bookmark, and easy to spell on a phone. Don’t bother the user with file extensions, thus you will be future compatible and independent from your current software.
- Use the Robots Exclusion Standard, i.e.
robots.txt. - The content should be as high up in the code as possible as it gets more relevance there.
- Use proper semantic code, like headlines, or list items for anything that resembles a list. Don’t use list items to get bullet points or headlines to set bold text.
- Use
<link>tags to specify relations between pages, likerel="start",chapter,prev, ornext, as search engines might value your start page more, or browsers could preloadnextpages. - Use a favorite icon for bookmarking and to keep your error log clean.
- Use the PICS standard to signal search engines and filter programs that your website is safe for kids.
This entry is filed under web development, web standards. It is licensed under a Creative Commons Attribution-Share Alike 3.0 License.
Nach fast monatelanger Abstinenz lasse ich mich noch einmal in den Foren bei OpenBC.com sehen. Dort stolpere in Webdesign und Usability über einen Beitrag von Martin Kliehm, der auf einen Post im Blog learningtheworld.eu verweist, in dem er erneut das Thema Webstandard aufgreift.
Ausgehend von der beachtlichen Menge nicht-validierender Seiten, die für den CSS Reboot ’06 gemeldet waren, führt er in einer übersichtlichen, aber detaillierten Liste die Maßnahmen an, die bei einem Projekt „Webseite“ Berücksichtigung finden sollten. Klasse Arbeit, Lesepflicht!
[…] Martin Kliehm: Best Practices in Web Development (exzellente Zusammenfassung, daher ergeht Lesebefehl!) […]
[...] CSS classes and IDs must be valid. “I.e. beginning with a letter, not a number or an underscore. IDs must be unique. Their names should be generic, describe functionality rather than appearance.” [CSS Best Practices] [...]
[...] Best Web-Practices [...]
[…] Trecho do artigo traduzido do blog Learning the World. Para acessar o artigo completo em inglês, clique aqui. […]
[…] КлаÑ?Ñ?Ñ‹ и идентификаторы должны быть правильными. Имена клаÑ?Ñ?ов и идентификаторов должны начинатьÑ?Ñ? Ñ? буквы, идентификаторы должны быть уникальными, их имена должны отражать функциональноÑ?Ñ‚ÑŒ Ñ?лемента, а не его оформление. [CSS Best Practices] […]
[…] CSS classes å’Œ IDs å¿…é¡»å?ˆæ³•. “我们在定义这些对象的使用最好用他们的功能, 而ä¸?是他的外观â€? [CSS Best Practices] […]
[…] CSS classes and IDs must be valid. “I.e. beginning with a letter, not a number or an underscore. IDs must be unique. Their names should be generic, describe functionality rather than appearance.” [CSS Best Practices] […]
[…] CSS classes å’Œ IDs å¿…é¡»å?ˆæ³•. “我们在定义这些对象的使用最好用他们的功能, 而ä¸?是他的外观â€? [CSS Best Practices] […]
[…] Классы и идентификаторы должны быть правильными. Имена классов и идентификаторов должны начинаться с буквы, идентификаторы должны быть уникальными, их имена должны отражать функциональность элемента, а не его оформление. [CSS Best Practices] […]
[…] CSS classes and IDs must be valid. “I.e. beginning with a letter, not a number or an underscore. IDs must be unique. Their names should be generic, describe functionality rather than appearance.â€? [CSS Best Practices] […]
[...] Классы и идентификаторы должны быть правильными. Имена классов и идентификаторов должны начинаться с буквы, идентификаторы должны быть уникальными, их имена должны отражать функциональность элемента, а не его оформление. [CSS Best Practices] [...]