Pro tip: communicate to the client that shadows are a bonus feature. Your designers may disagree, but the site will not suffer considerably when special effects like box shadows, text shadows, or rounded corners are regarded as enhancements for decent browsers. However, your client’s budget will suffer when they are determined to provide the same visual effects on outdated browsers such as IE6. That said, here is the well-known method in CSS3:

1. .wrapper {
2. background-color: #fff;
3. border: 1px solid #d30d01;
4. box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
5. float: left;
6. height: 75px;
7. margin: 15px;
8. padding: 10px;
9. width: 75px;
10. -moz-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
11. -o-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
12. -webkit-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
13. }

1. <div class="wrapper">
2. <p>CSS box-shadow</p>
3. </div>

At the same time when we rolled out the website, Robert Nyman came to the conclusion that the proprietary Microsoft filter for Shadow looks much prettier than DropShadow, so I forgot about blogging myself as his solution doesn’t rely on unsemantic markup and is more elegant:

1. .wrapper {
2. /* For IE 8 */
3. -ms-filter: progid:DXImageTransform.Microsoft.Shadow( Strength=5, Direction=135, Color='#999999' );
4. /* For IE 5.5 – 7 */
5. filter: progid:DXImageTransform.Microsoft.Shadow( Strength=5, Direction=135, Color='#999999' );
6. }

Note that you get slightly better effects when you choose a dark gray instead of black as shadow color. If you can live with the rendering of the third box below, don’t read any further.

However, applying the filter had the side effect that text inside the box wasn’t anti-aliased in IE 6-8 anymore, and the shadow still didn’t look decent enough. So we added an extra span and applied the blur filter on it.

That led to a more complex code as we needed an inner wrapper where the border and background is applied to, while the outer wrapper merely acted as a … wrapper, where the styles were reset to defaults. HTML first:

1. <div class="wrapper ms-box-shadow">
2. <div class="inner">
3. <p>Internet Explorer with blur filter</p>
4. </div>
5. <span class="shadow"></span>
6. </div>

And here’s the CSS that’s added with Conditional Comments for IE 6-8 only (as IE9 supports native CSS box-shadow, more or less). The shadow element is absolutely positioned, set behind the inner content and blown up to 100%. Not original, but it works:

1. .wrapper, .inner {
2. background-color: #fff;
3. border: 1px solid #d30d01;
4. height: 75px;
5. padding: 10px;
6. position: relative;
7. width: 75px;
8. }
9. .wrapper {
10. float: left;
11. margin: 15px;
12. }
13. /* reset wrapper styles to defaults; work-around for screwed box-model */
14. .ms-box-shadow {
15. background-color: transparent;
16. border: 0 none;
17. height: 95px;
18. padding: 0;
19. width: 95px;
20. }
21. /* Move the inner wrapper to the foreground */
22. .inner {
23. z-index: 50;
24. }
25. /* The shadow element */
26. .shadow {
27. background-color: #000;
28. display: block;
29. filter: progid:DXImageTransform.Microsoft.Blur( makeShadow='true', pixelRadius=4, shadowOpacity=0.30 );
30. height: 100%;
31. left: 0;
32. position: absolute;
33. top: 0;
34. width: 100%;
35. z-index: 0;
36. }

For some reason I got a more similar result with the shadowOpacity set to 30% instead of 20%.

Where’s the crux?

If we are willing to ignore lots of bloated CSS: IE6 only blows the shadow up to 100% when the wrapper has a fixed height. This sucks, but unless you want to add more bloated code in JavaScript I don’t know of any solution for this problem. Still IE 7-8 handle a value of 100% right, and there are many cases where the height is known. Take for example photos where you’d like to apply shadows, some buttons, or horizontal shades lying above images, like the shadow of the second level navigation on this site. Beautiful, isn’t it?

I was responsible for most of the programming beneath the navigation bar on the home page, and every time when I book a ticket there’s a small feature I enjoy so much I want to tell you about it: the buttons on the date selector are really, really tiny (16 × 8px). As you know thanks to Fitt‘s Law, there are even formulas to calculate how much better big buttons can be hit.

So I just added some padding. And that makes a huge difference: try to click on the same buttons later on in the booking process where the padding is missing.

If I could make one improvement I would add keyboard functionality to those buttons. Alas as the datepicker itself came from a third party, the assembled code was beyond my control. But I know that the Deutsche Bahn is listening to the needs of people with disabilities and their disability advisory board members are highly competent, so I trust these and other issues will be fixed soon …

1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?

What are the alternatives? Using background-images with off-screen text? Bad code:

1. <a href="foo" class="button">
2. <span>Alternative Text</span>
3. </a>

1. a.button, button {
2. background: url(foo.gif) 0 −26px no-repeat;
3. display: block;
4. height: 52px;
5. overflow: hidden;
6. position: relative;
7. width: 150px;
8. }
9. span {
10. left: −9999px;
11. position: absolute;
12. top: auto;
13. }

That’s a bad idea with accessibility issues. Screen readers will be able to read the text, but if somebody with low vision has high-contrast custom stylesheets, it is likely that the background-image won’t be displayed. Still the alternative text will be invisible off-screen, so the link or button becomes unusable.

A better solution

Now Google’s accessibility specialist T.V. Raman explained their idea for replacing images with sprites. Here are screenshots of Google search results with images, and with background images disabled:

Google puts the alternative text behind the background image simply by attaching it on the span element, not the anchor. So when CSS or background images are turned off, the text just reappears.

1. <a id="logo" title="Go to Google Home" href="http://www.google.com/">
2. Google
3. <span></span>
4. </a>

1. #logo {
2. display: block;
3. height: 52px;
4. overflow: hidden;
5. position: relative;
6. width: 150px;
7. }
8. #logo span {
9. background: url(foo.gif) 0 −26px no-repeat;
10. height: 100%;
11. left: 0;
12. position: absolute;
13. top: 0;
14. width: 100%;
15. }

There’s only an issue if you have a lot of alternative text, perhaps combined with text zoom, so that it doesn’t fit in the reserved space. But I can live with that.

Congratulations to Google for this ellegant solution, and it’s so simple! Why didn’t I think of it?

I started my conference program with a case study by the BBC. They did a redesign and managed to squeeze formerly 60 images into 3 sliding doors and sprites. Their home page is now under 300K and 30 HTTP requests. Nice to see Yahoo’s Exceptional Performance guidelines go mainstream. About 5% of their users access the site without JavaScript. They don’t get identical features, but they get identical care. For them accessibility isn’t a buzzword, it’s become a natural part of their daily work. So they were able to find out that blur() is not a friend with JAWS. Also the BBC plays well with the other kids: they joined the OpenID foundation, and with BBC backstage they open their content through an API. Another charming idea is their public beta where people can testdrive new features. About 60% have personalized their home page, although one of the speakers described the personalization features with “my mom’s head exploded.” They used agile development with 2 week sprints, run the website in 12 languages, but don’t have a CDN yet because of the license fees.

Another case study about the LOHAS community Edenbee wasn’t that exiting, mostly because I knew the platform since beta and didn’t get quite why I should speak with other people about changing their lightbulbs. But it’s nice to keep track of your carbon footprint, a feature that uses the AMEE open API.

I was curious about HTML 5, so I went to the presentation of Lachlan Hunt and James Graham. Still I don’t see any advantage of having a bunch of new elements that are incompatible with older browsers when I can achieve the same with ARIA attributes. But I understand the rationale behind some of their decisions, although that doesn’t mean I come to the same conclusions.

For example people use a lot of “nav” and “menu” classes. To make their live easier, the WHATWG came up with the idea to create a nav element. A block level element, so you wouldn’t have to use those <div class="nav"> any more. But every time I use something like class="navigation" it will be an unordered list! I don’t need another div, I’m perfectly happy with my ul and role="navigation". It’s truly backward compatible, it’s semantic, I can use it today, and there isn’t a steep learning curve.

Then I went to two design talks by Andy Clarke and Dan Rubin, and though their designs were beautiful, the code examples were not. Imagine the flexibility of a newspaper article and compare that with the inflexibility of absolutely positioned paragraphs with fixed heights. Exactly. Apart from that Andy’s main inspiration came from comic books. It never hurts to throw in some colorful images.

Like in comic books, usability is not about getting from A to B, it’s about the experience of getting from A to B. In comic books the size of a panel and the amount of text strongly influences the reading speed. So you can emphasize content and add dynamics in your web design. That doesn’t mean necessarily that everything has to be in boxes. Emphasis can also be added by removing the boxes.

Dan Rubin used a lot of effects on his designs, like a noise filter to add texture on monochrome surfaces. Nice idea, though that implies the designer explaining the rationale of such a feature to the front-end engineers. They would either ignore it because they overlooked the subtle texture or because they assumed it would be just noise. Some less intrusive hint I will readily adopt was using a letter-spacing of −1 on headlines to prevent tiny rivers between letters.

What slightly worries me is that Dan talked about re-using patterns for some effects in Photoshop. Re-using patterns is the same in CSS, but re-usable effects in Photoshop can mean an unusable amount of work in CSS and lots of pictures making the website slow. What I miss so far is a common understanding of effects and patterns that are both easy to work with in Photoshop and in frontend programming.

The next day started with Nate Koechley’s keynote about professional frontend engineering. He chose the topic because he thinks this is critical to the advancement of the Internet, and I couldn’t agree more. As Frontend Engineers we write software with XHTML, CSS, JavaScript, and quite some amount of PHP. Douglas Crockford calls this “the most hostile software development environment imaginable,” and if you take a look at this graphic from Nate’s slides you will understand why. There are a number of knowledge areas that can be applied in a number of ways on three operating systems and half a dozen browsers in two rendering modes. If you ever wondered why you sometimes see little clouds of smoke coming out of your frontend engineering heads, that’s why.

There are four guiding principles:

1. Availability and accessibility for all users worldwide
2. Openness: share, learn, support, advocate
3. Richness: provide, but not too much
4. Stability

Then there are three core techniques: Graded Browser Support, Progressive Enhancement, and Unobtrusive JavaScript.If you haven’t heard about those concepts, please read about them now.

At that point the presentation turned into giving advice for quite a number of best practices and tips, like using JSLint, YUI Unit Testing, or YUI Profiler to enhance the quality of your code. Or serving cacheable assets from cookie-free domains. Or anticipated preloads: sneak in your new JavaScript and CSS files a week before the relaunch. Or did you know that the iPhone 2G can keep only 19 assets in cache, and that it doesn’t cache anything larger than 25K? Uncompressed 25K? Needless to say, Nate’s presentation was one of the conference highlights.

Later I heard a few things about building applications with existing frameworks and APIs, a timely comparison between JavaScript libraries held by no other than jQuery’s John Resig, some tips on internationalization by Richard Ishida, and a panel about accessibility. The one sentence that stuck most in that panel was: “Don’t be the guy with the problems, be the guy with the solutions.” In fact it’s very hard to be passionate about your job while being pragmatic and providing solutions instead of just saying “no.” Something Richard Schwerdtfeger wrote about in a different context:

Working in the accessibility field is extremely difficult. It requires very specialized skills — including incredible persistence. Accessibility is often viewed as additional work that is not always planned for. It requires a person who is tough, committed, patient, and caring to deliver an accessible solution that is usable to our customers. To do this you must have tremendous passion for your job as there is always someone or something to trip you up.

Combining passion and diplomacy is a goal many web evangelists still have to work on… In the meantime remember that accessibility is most likely to have a sustainable impact when it is supported by senior management, when there is an accessibility policy for a company, and when smart companies realize that there is money to be made by maximizing the target audience.

Most rollovers have become obsolete because they can be performed on background images with CSS sprites. If there are hover effects today, they usually come as text on a button background image, or as a text link with an icon next to it.

However, there are those rare cases when there is just an icon without text, like a “play” or “pause” button, or a magnification glass on an image to signal it can be enlarged. If you want to swap images when the element receives focus or on mouseover, traditionally you are stuck with two options:

1. JavaScript to change the image source, or
2. CSS sprites to change the position of a background image behind a transparent gif image.

I like neither. Using JavaScript and two images with pre-loading seems like a waste of resources when it can be done with CSS and one image only. Transparent gifs are so 1998, besides the background usually doesn’t get printed. So what we need on these occasions are CSS sprites for foreground images.

Until recently I thought that can’t be done, but then I stumbled upon some code for checkbox widgets in Dojo. Naturally they use a lot of JavaScript for the task. Anyway I like my default checkboxes and don’t have any urge to make them prettier (I have no doubt our design overlords would enforce aqua icons everywhere), but that made me think. Here’s a suggestion:

First a simple sprite which is 50px wide:

The HTML code uses the dimensions of a single icon for width and height to allow fast page rendering without reflow:

1. <a href="/big/" class="icon">
2. <img src="/img/icon-enlarge.gif" id="magnifier" width="19" height="15" alt="enlarge image" />
3. </a>

The corresponding CSS sets the link to display: block, uses the single icon dimensions for the container, prevents overflow, and resets the image dimensions to auto to prevent distortion. The actual image swapping is achieved by a negative left margin on hover.

1. a.icon {
2. display: block;
3. width: 19px;
4. height: 15px;
5. overflow: hidden;
6. }
7. a.icon img {
8. width: auto;
9. height: auto;
10. border: none;
11. }
12. a.icon:hover img, a.icon:focus img, a.icon img.hover {
13. margin-left: −31px;
14. }

For the sake of simplicity I ignored how the link would be floated or positioned. Also borders, a background color, or padding to increase the clickable area can be added to the parent element.

For simplicity I chose a link in the example, but the same can be done with a div surrounding an <input type="image" />. Then of course you need to define cursor: pointer, and for anything below IE7 bind the DOM event to the hovering element (get the source):

1. <!--[if lt IE 7]>
2. <script type="text/javascript">
3. oIcon = {
4. setHoverClass : function() {
5. this.className = 'hover';
6. },
7. resetHoverClass : function() {
8. this.className = '';
9. }
10. };
11. var elm = document.getElementById('magnifier');
12. if (elm) {
13. elm.onmouseover = elm.onfocus = oIcon.setHoverClass;
14. elm.onmouseout = elm.onblur = oIcon.resetHoverClass;
15. }
16. </script>
17. <![endif]-->

Here is a working example. You know how to adjust the code if you need more than one class on the image.

That was nice and easy. It’s tested in Firefox 2, Opera 9, Internet Explorer 5+, and Safari 2. Screen readers should be okay with the alt text.

Discussion

The trouble begins when people start turning off browser features.

People with disabled images won’t be able to read the alternative text because the visible area is limited by the parent container. That can be detected by comparing the known sprite size with the alt text size. Then the class is set to anything but icon so that the parent container expands.

More severe is when people disable style sheets because then they will see a squeezed image with multiple icons. If you are hyper-correct, you could replace the crushed multi-icon image with the correct single icon (you could use the class or rel attribute to define the icon type), but nobody wants to slice images. As a compromise I would suggest to replace the icon with its alt text.

See the script to detect disabled images or CSS. (Note: it isn’t implemented here because I couldn’t test it properly on IE6 with stuff turned off.)

If JavaScript is unavailable, the user is stranded with what we gave him. Also icons without text are inherently evil because they can’t be enlarged by zoom readers. Did I forget any politically correct disclaimer for obscure use scenarios?

So we ended up with a CSS only version, but still some JavaScript is needed for the extra effort to provide the same experience to users of IE 5-6, and some more for certain user scenarios. Wouldn’t it be easier to slice and swap foreground images the old way? But then again slicing is a pain, and people already start using background images. Do people actually turn off CSS and images? Or is that another remnant of WCAG 1.0 from 1999?

The traditional focus of performance optimization has been on the backend, i.e. system efficiency. But comparing a number of high profile websites, the Yahoo! team found that frontend performance is responsible for 80-98% of the perceived response time. Therefore doubling the frontend performance gains more than doubling the backend performance. In case studies Yahoo! Search became 40-50% faster, the Yahoo! Mail web application gained 70-100%. Of course there are ways to increase backend performance without throwing in more hardware, but better frontend performance reduces traffic and saves resources.

Saving resources on the client side, particularly CPU usage, also pays off in speed. Event delegation is faster than a large number of event handlers. Likewise we know that reducing the number of HTTP requests through techniques like CSS sprites, sliding doors, or file aggregation increases speed. The reason is the limit of two parallel requests per host imposed by HTTP 1.1. That results in a download queue of two requests at a time, increasing the perceived response time of a page. By configuring additional host aliases for your server you can increase the number of parallel requests — but more than 2-4 also increase DNS lookups resulting in higher CPU usage and slower response times.

I wonder when Yahoo! will present us another impressive calculation how many gigawatts have been preserved by reducing CPU usage in client PCs and in their data centers, as one participant asked in the Q&A part. Energy efficient servers are the next big thing, but are there any concrete suggestions for greener programming? Is AJAX destroying the ozone layer?

Environmental issues aside, here’s the list of rules. I’ll keep it short where I have written about it in my previous article. See the examples and testcases by Steve Souders.

1. Make fewer HTTP requests: This also affects cookies. Eliminate unnecessary cookies, keep them small, set them at granular domain levels (e.g. finance.yahoo.com instead of .yahoo.com), and set an appropriate Expires date.
2. Use a content distribution network (CDN) like Akamai where your (static) content is served from distributed data centers located nearer to your client. Even if your website is not as big as Google you can profit from faster response times by using the YUI library’s own CDN.
3. Add an Expires header not just for images, but also for JavaScript and stylesheet files.
4. Enable gzip: 90%+ of browsers support compression, and gzip is better supported and compresses more than deflate. Gzip HTML files, CSS, scripts, XML, JSON — no images or PDFs.
5. Put CSS at the top, avoid @import as it loads last, even after the images!
6. Move scripts to the bottom as they block parallel downloads even across hostnames and block rendering of any code below them.
7. Avoid CSS expressions as they execute many times and cost CPU.

8. Use external JavaScript and CSS files. Inline CSS is apparently faster for a user’s start page, but not on subsequent pages. After the page has finished loading, use the time to preload scripts to speed up secondary pages.

   1. window.onload = downloadComponents;
   2. function downloadComponents() {
   3. var elem = document.createElement("script");
   4. elem.src = "http://.../file1.js";
   5. document.body.appendChild(elem);
   6. }
9. Reduce DNS lookups for the reasons stated above. Use 1-4 hosts and the keep alive setting.
10. Minify JavaScript with JSMin — inline scripts, too.
11. Avoid redirects as they are the worst form of blocking. Set Expires headers for redirects to enable caching.
12. Remove duplicate files: this is self-explanatory, but it can happen in large teams with many scripts and stylesheets.

13. Mind the ETag: Now this was something I never paid attention to. ETags are unique identifiers to distinguish files that share a URI. They are transmitted in the HTTP header. The default server setting uses the INode, the bytesize and the modification date of a file to calculate a unique ID. Unless servers in a cluster are identical, ETags differ, therefore the files are not cached. Fortunately ETags can be configured in Apache, so it should be possible to match them across different servers.

    1. FileETag MTime Size

    Note that the ETag is also relevant for RSS feeds. For example, currently the W3C talks feed is more or less unusable: some feed readers and services apparently regard the ETag, the feed is mirrored on many servers, so the same news entry from a different server is shown as new and unread multiple times every day…

14. Make AJAX cacheable and small. Some data like a user’s address book or buddy list change infrequently and should be requested via GET, cached, and set with a Last-modified timestamp and gzipped.

These are a lot of rules, and they will be published in a O’Reilly book by Steve Souders and Tenni Theurer in September 2007. Anyway, don’t be overwhelmed by their mass, instead you can start with the easy things: “harvest the low hanging fruit.” Enable caching with the Expire date setting and reduce the number of HTTP requests. You can deal with the rest later.

Finally Nate Koechley announced a Yahoo! performance tool called YSlow as a plugin for the indespensible Firebug extension. He also recommended the commercial IBM Page Detailer, and LiveHTTPHeaders to visualize what’s happening in your browser.

In this article:

• Case study
• Best practices in HTML
• Best practices in CSS
• Best practices for search engines

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.

Getting into the depths of old-school programming we found proprietary tags like <nobr>, <ilayer>, or <spacer>, misconceptions like valign="center" instead of "middle", forgotten closing tags, or tag soup like the classic form between table rows (to prevent top margins), block level elements inside of inline elements, <p> tags around everything (including tables and headlines!), or script tags before or after <html> </html>. Especially ad servers and site statistics were infamous for their crappy stone-age code.

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

1. The document must validate as HTML or XHTML.
2. The document must have a DTD.
3. The document must have a character encoding, either through a HTTP header or a meta tag.

4. The document should have the language defined in the following ways:

   • <html lang="en">
   • <html xml:lang="en">
   • <meta name="content-language" content="en">
5. All attribute values should be quoted. In XHTML, quotes are mandatory.
6. Element and attribute names should use a consistent case to enhance readability, preferred is lowercase for XHTML compability.
7. Code should be well <!-- commented --> to help maintaining developers to get a fast grip of the basic structure and key concepts.
8. Code should be consistently indented, tabs preferred over spaces.
9. Images, image maps and scripted content must have an alt-attribute with an appropriate value.
10. Images should always specify their width and height to allow browsers to continue rendering while waiting for the image data.
11. Some special characters like ", <, >, and & (especially within attributes like href or src) 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.
12. script and style tags must have a type attribute.

13. 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

1. CSS must validate.
2. Elements should be positioned with CSS 2, not tables.
3. All ornamental lines, borders, background colors and -images, underlines and other decorational elements should be rendered with CSS 2.
4. Text should be formatted with CSS 1, not with font tags.
5. All style sheets should be included in reusable, centrally maintainable, and cacheable external CSS files, not as redundant code within the HTML files.
6. External CSS files should be sent with the correct MIME type (text/css).
7. 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

1. Use a descriptive title with the name of the website and consistent separating characters in it.
2. Use keywords, keyphrases, and a description reflecting the page’s content.
3. 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.
4. Use the Robots Exclusion Standard, i.e. robots.txt.
5. The content should be as high up in the code as possible as it gets more relevance there.
6. 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.
7. Use <link> tags to specify relations between pages, like rel="start", chapter, prev, or next, as search engines might value your start page more, or browsers could preload next pages.
8. Use a favorite icon for bookmarking and to keep your error log clean.
9. Use the PICS standard to signal search engines and filter programs that your website is safe for kids.

In this post:

• Eric Meyer: Keynote
• Jeremy Keith: Using DOM scripting to plug the holes in CSS
• Chris Wilson: IE: 7 and beyond
• The new accessibility guidelines: WCAG 2.0
• Jeffrey Veen: Designing the next generation of web apps

Introducing geeks to a social life

There was some socializing the evening before the conference where I met with a couple of Germans, like Jens Grochtdreis who initiated the German web standardista group “Webkrauts”, Jan Eric Hellbusch whose website I had noticed before for some master theses about accessibility, or Tomas Caspers who is a member of WaSP and the mastermind behind the accessibility portal Einfach für alle. Actually I wasn’t the only one to notice he looks like the lost fifth member of the German punk band “Die Toten Hosen”?… Also that’s where I met Roger Johansson, whose technical blog 456 Berea Street is a must-read for CSS and accessibility aware coders.

So my first day on @media began with a walk through polluted London air along surveillance cameras and anti-tank barriers along the Houses of Parliament over to the queue in front of the Queen Elizabeth II Conference Center (QE2CC) where we got nice bags and name tags. I would suggest shawls with the @media logo for next year to stand a chance against the bloody cold air conditioning while it was 28° C outside.

Eric Meyer: Keynote

The conference started with a keynote by Eric Meyer with his personal impressions of the last ten years of the web. Quite interesting since I’ve been reading his articles on Web Review, where he published among other things the famous CSS browser compatibility chart, a great companion in my struggle with 4th generation browsers.

Looking back, he realized the following truths:

1. Small groups of dedicated experts can change a lot (e.g. the CSS Samurai, or Tantek Çelik who introduced doctype switching).
2. Free information is an essential part of any new web technology’s adoption.
3. You don’t hear much anymore from people or companies who kept information as a “personal advantage.”
4. You might be the first who thought about a certain solution. Savour this moment, and then share it.

Using DOM scripting to plug the holes in CSS

As an example, Jeremy Keith introduced the techniques of Buck Owens, the first musician to “hack” the tinny sound of early radios by replacing the bass with a regular guitar. So his tracks sounded better and got more airtime. Using DOM scripting to work around incomplete CSS implementations or to simulate CSS 3 behavior is basically the same, as long as there aren’t yet browsers with “great bass.”

Okay, most of the stuff in his presentation sounded familiar, and I’d rather set zebra stripes on table row backgrounds server side. Still I got some inspiration how to do some things better. For example it never occurred to me to combine selectors like

1. document.getElementById("id") .getElementsByTagName("p")

Or I never thought of using a universal selector in JavaScript:

document.getElementsByTagName("*")

Also the next time I’m manipulating an object’s class, I promise to do it by writing some reusable functions like

1. document.getElementByClassName()
2. function addClass(element, className)

And after I createElement I should set more attributes by setting a className instead of adding each attribute separately.

When he mentioned CSS 3, I learned that Safari is already capable of handling multiple background images. And I liked his introduction of the geeky Star Trek term of a “Kobayashi Maru scenario” for a no-win situation, or his translation of object detection

1. if (document.getElementById) { }

with “you must be this high to ride.” Rather cool, and a very entertaining presentation.

IE: 7 and beyond

Chris Wilson worked on the Mosaic browser (that’s, like, Netscape 1 — scary, isn’t it?) and on IE ever since version 2. Praise him for first implementing CSS in IE3, blame him for some nasty bugs he’s personally responsible for in IE6. Also he’s the one who wrote he will quit (and probably become a professional surfer) the day he loses his passion or IE gets mothballed again.

After some blatant promotion for all the outstanding new features and fixes in IE7, things you can read about in the IEBlog if you haven’t yet, he came to the interesting facts:

First of all, they are planning the next two releases now, and it won’t take another five years until IE8 will emerge. Also IE7+ for Windows Vista is only marketing speak, what counts is that it has the same features as IE7 for Windows XP, except for some vista-only security and parental control. IE7 will ship in “second half 2006.” More precisely, the Malaysian Vista developer Jabez Gan disclosed earlier that December 6 will be the release date.

Because of the deep interaction with the operating system they can’t push it as a critical Windows update, but they will “strongly encourage people to update.” The new fonts won’t be deployed with the update, more likely in a separate package, simply because with Unicode support some are too large.

On a technical side they are aware of developer’s problems to test on multiple versions of IE. Though it is technically hard to have a friendly co-existence of multiple IEs because they provide the operating system, it should be possible to create side-by-side versions of the browser only. Yay, that’s what we want!

Also they would like to support the XHTML MIME type, but want to do it right, later. Same is true for advanced DOM support, or passing the Acid2 test. What’s next for the web? Mashups, RSS, microformats, and XMLHttpRequest (did you know there’s a W3C working draft?). XForms is on their radar, but they need to coordinate efforts with other browser vendors.

Besides Chris recommended some tools like an expression finder to spot CSS hacks, or an application compatibility toolkit, stuff you can download as part of the Internet Explorer 7 Readiness Toolkit from Microsoft with a genuine copy or from someplace else without.

The new accessibility guidelines: WCAG 2.0

I had hoped that by visiting the panel about WCAG ['wu:kæg] I could avoid having to read the unreadable myself, but I was disappointed. You will read in another post about it. Not much else to tell about that panel, except WCAG 2.0 is probably not as bad as we have thought. There are notes and the slides available on accessify.com.

Designing the next generation of web apps

Jeffrey Veen is the partner of Jesse James Garrett who gets all the attention for coining the term “Ajax.” Anyway, Ajax is so going to change our world. Like the automobile, or the Great Depression. Some will get more mobile, some will get greatly depressed when the web becomes inaccessible.

In another panel the speakers agreed that Ajax can make live easier as an enhancement (Jeremy Keith calls it “Hijax”), but shouldn’t be a world of pain for the others. Actually I can see some of Jeff’s examples (use Stuart Colville’s notes to understand the slides) as an enhancement. Like giving immediate feedback when input fields in a form validate, while degrading gracefully by giving feedback after a regular submit.

You can enhance understanding by coloring and visualizing rainfall values in a nicely designed table, or you can further enhance it by making it interactive with a fader to choose cities on a map. But I can’t imagine how to have both.

In another example he showed a mashup of Google Maps with a Chicago crime database. Nice, but how can that be made accessible? So that people without JavaScript, or screen reader and braille display users with JavaScript can access the raw data table that lies under the visualization?

There was a lot of talk how today’s websites will be tomorrow’s web applications, but like Nate Koechley put it: You can’t just copy one aspect of desktop applications while ignoring the accessible alternatives. Desktop applications are accessible with multiple input devices, like a mouse or a keyboard. Screen readers can get the content. Don’t you forget it when developing the “next generation off apps.” There’s more than just good looks.