If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!

A web standards checklist

The term web standards can mean different things to different people. For some, it is ‘table-free sites’, for others it is ‘using valid code’. However, web standards are much broader than that. A site built to web standards should adhere to standards (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) and pursue best practices (valid code, accessible code, semantically correct code, user-friendly URLs etc).

In other words, a site built to web standards should ideally be lean, clean, CSS-based, accessible, usable and search engine friendly.

About the checklist

This is not an uber-checklist. There are probably many items that could be added. More importantly, it should not be seen as a list of items that must be addressed on every site that you develop. It is simply a guide that can be used:

- to show the breadth of web standards
- as a handy tool for developers during the production phase of websites
- as an aid for developers who are interested in moving towards web standards

The checklist

1.Quality of code
a. Does the site use a correct Doctype?
b. Does the site use a Character set?
c. Does the site use Valid (X)HTML?
d. Does the site use Valid CSS?
e. Does the site use any CSS hacks?
f. Does the site use unnecessary classes or ids?
g. Is the code well structured?
h. Does the site have any broken links?
i. How does the site perform in terms of speed/page size?
j. Does the site have JavaScript errors?

2. Degree of separation between content and presentation
a. Does the site use CSS for all presentation aspects (fonts, colour, padding, borders etc)?
b. Are all decorative images in the CSS, or do they appear in the (X)HTML?

3. Accessibility for users
a. Are “alt” attributes used for all descriptive images?
b. Does the site use relative units rather than absolute units for text size?
c. Do any aspects of the layout break if font size is increased?
d. Does the site use visible skip menus?
e. Does the site use accessible forms?
f. Does the site use accessible tables?
g. Is there sufficient colour brightness/contrasts?
h. Is colour alone used for critical information?
i. Is there delayed responsiveness for dropdown menus (for users with reduced motor skills)?
j. Are all links descriptive (for blind users)?

4. Accessibility for devices
a. Does the site work acceptably across modern and older browsers?
b. Is the content accessible with CSS switched off or not supported?
c. Is the content accessible with images switched off or not supported?
d. Does the site work in text browsers such as Lynx?
e. Does the site work well when printed?
f. Does the site work well in Hand Held devices?
g. Does the site include detailed metadata?
h. Does the site work well in a range of browser window sizes?

5. Basic Usability
a. Is there a clear visual hierarchy?
b. Are heading levels easy to distinguish?
c. Does the site have easy to understand navigation?
d. Does the site use consistent navigation?
e. Are links underlined?
f. Does the site use consistent and appropriate language?
g. Do you have a sitemap page and contact page? Are they easy to find?
h. For large sites, is there a search tool?
i. Is there a link to the home page on every page in the site?
j. Are visited links clearly defined with a unique colour?

6. Site management
a. Does the site have a meaningful and helpful 404 error page that works from any depth in the site?
b. Does the site use friendly URLs?
c. Do your URLs work without “www”?
d. Does the site have a favicon?

1. Quality of code

1.1 Does the site use a correct Doctype?
A doctype (short for ‘document type declaration’) informs the validator which version of (X)HTML you’re using, and must appear at the very top of every web page. Doctypes are a key component of compliant web pages: your markup and CSS won’t validate without them.

http://www.alistapart.com/articles/doctype/

More:

http://www.w3.org/QA/2002/04/valid-dtd-list.html

http://css.maxdesign.com.au/listamatic/about-boxmodel.htm

http://gutfeldt.ch/matthias/articles/doctypeswitch.html

1.2 Does the site use a Character set?
If a user agent (eg. a browser) is unable to detect the character encoding used in a Web document, the user may be presented with unreadable text. This information is particularly important for those maintaining and extending a multilingual site, but declaring the character encoding of the document is important for anyone producing XHTML/HTML or CSS.

http://www.w3.org/International/tutorials/tutorial-char-enc/

More:

http://www.w3.org/International/O-charset.html

1.3 Does the site use Valid (X)HTML?
Valid code will render faster than code with errors. Valid code will render better than invalid code. Browsers are becoming more standards compliant, and it is becoming increasingly necessary to write valid and standards compliant HTML.

http://www.maxdesign.com.au/presentation/sit2003/06.htm

More:

http://validator.w3.org/

1.4 Does the site use Valid CSS?
You need to make sure that there aren’t any errors in either your HTML or your CSS, since mistakes in either place can result in botched document appearance.

http://www.meyerweb.com/eric/articles/webrev/199904.html

More:

http://jigsaw.w3.org/css-validator/

1.5 Does the site use any CSS hacks?
Basically, hacks come down to personal choice, the amount of knowledge you have of workarounds, the specific design you are trying to achieve.

http://www.mail-archive.com/wsg@webstandardsgroup.org/msg05823.html

More:

http://css-discuss.incutio.com/?page=CssHack

http://css-discuss.incutio.com/?page=ToHackOrNotToHack

http://centricle.com/ref/css/filters/

1.6 Does the site use unnecessary classes or ids?
I’ve noticed that developers learning new skills often end up with good CSS but poor XHTML. Specifically, the HTML code tends to be full of unnecessary divs and ids. This results in fairly meaningless HTML and bloated style sheets.

http://www.clagnut.com/blog/228/

1.7 Is the code well structured?
Semantically correct markup uses html elements for their given purpose. Well structured HTML has semantic meaning for a wide range of user agents (browsers without style sheets, text browsers, PDAs, search engines etc.)

http://www.maxdesign.com.au/presentation/benefits/index04.htm

More:

http://www.w3.org/2003/12/semantic-extractor.html

1.8 Does the site have any broken links?
Broken links can frustrate users and potentially drive customers away. Broken links can also keep search engines from properly indexing your site.

More:

http://validator.w3.org/checklink

1.9 How does the site perform in terms of speed/page size?
Don’t make me wait… That’s the message users give us in survey after survey. Even broadband users can suffer the slow-loading blues.

http://www.websiteoptimization.com/speed/

1.10 Does the site have JavaScript errors?
Internet Explore for Windows allows you to turn on a debugger that will pop up a new window and let you know there are javascript errors on your site. This is available under ‘Internet Options’ on the Advanced tab. Uncheck ‘Disable script debugging’.

2. Degree of separation between content and presentation

2.1 Does the site use CSS for all presentation aspects (fonts, colour, padding, borders etc)?
Use style sheets to control layout and presentation.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-style-sheets

2.2 Are all decorative images in the CSS, or do they appear in the (X)HTML?
The aim for web developers is to remove all presentation from the html code, leaving it clean and semantically correct.

http://www.maxdesign.com.au/presentation/benefits/index07.htm

3. Accessibility for users

3.1 Are “alt” attributes used for all descriptive images?
Provide a text equivalent for every non-text element

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-text-equivalent

3.2 Does the site use relative units rather than absolute units for text size?
Use relative rather than absolute units in markup language attribute values and style sheet property values’.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-relative-units

More:

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-relative-units

http://www.clagnut.com/blog/348/

3.3 Do any aspects of the layout break if font size is increased?
Try this simple test. Look at your website in a browser that supports easy incrementation of font size. Now increase your browser’s font size. And again. And again… Look at your site. Does the page layout still hold together? It is dangerous for developers to assume that everyone browses using default font sizes.

3.4 Does the site use visible skip menus?

A method shall be provided that permits users to skip repetitive navigation links.

http://www.section508.gov/index.cfm?FuseAction=Content&ID=12

Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.

http://www.w3.org/TR/WCAG10-TECHS/#tech-group-links

…blind visitors are not the only ones inconvenienced by too many links in a navigation area. Recall that a mobility-impaired person with poor adaptive technology might be stuck tabbing through that morass.

http://joeclark.org/book/sashay/serialization/Chapter08.html#h4-2020

More:

http://www.niehs.nih.gov/websmith/508/o.htm

3.5 Does the site use accessible forms?
Forms aren’t the easiest of things to use for people with disabilities. Navigating around a page with written content is one thing, hopping between form fields and inputting information is another.

http://www.htmldog.com/guides/htmladvanced/forms/

More:

http://www.webstandards.org/learn/tutorials/accessible-forms/01-accessible-forms.html

http://www.accessify.com/tools-and-wizards/accessible-form-builder.asp

http://accessify.com/tutorials/better-accessible-forms.asp

3.6 Does the site use accessible tables?
For data tables, identify row and column headers… For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-table-headers

More:

http://www.bcc.ctc.edu/webpublishing/ada/resources/tables.asp

http://www.accessify.com/tools-and-wizards/accessible-table-builder_step1.asp

http://www.webaim.org/techniques/tables/

3.7 Is there sufficient colour brightness/contrasts?
Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-colour-contrast

More:

http://www.juicystudio.com/services/colourcontrast.asp

3.8 Is colour alone used for critical information?
Ensure that all information conveyed with colour is also available without colour, for example from context or markup.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-colour-convey

There are basically three types of colour deficiency; Deuteranope (a form of red/green colour deficit), Protanope (another form of red/green colour deficit) and Tritanope (a blue/yellow deficit- very rare).

More:

http://colourfilter.wickline.org/

http://www.toledo-bend.com/colourblind/Ishihara.html

http://www.vischeck.com/vischeck/vischeckURL.php

3.9 Is there delayed responsiveness for dropdown menus?
Users with reduced motor skills may find dropdown menus hard to use if responsiveness is set too fast.

3.10 Are all links descriptive?
Link text should be meaningful enough to make sense when read out of context – either on its own or as part of a sequence of links. Link text should also be terse.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links

4. Accessibility for devices.

4.1 Does the site work acceptably across modern and older browsers?

Before starting to build a CSS-based layout, you should decide which browsers to support and to what level you intend to support them.

http://www.maxdesign.com.au/presentation/process/index_step01.cfm

4.2 Is the content accessible with CSS switched off or not supported?
Some people may visit your site with either a browser that does not support CSS or a browser with CSS switched off. In content is structured well, this will not be an issue.

4.3 Is the content accessible with images switched off or not supported?
Some people browse websites with images switched off – especially people on very slow connections. Content should still be accessible for these people.

4.4 Does the site work in text browsers such as Lynx?
This is like a combination of images and CSS switched off. A text-based browser will rely on well structured content to provide meaning.

More:

http://www.delorie.com/web/lynxview

4.5 Does the site work well when printed?
You can take any (X)HTML document and simply style it for print, without having to touch the markup.

http://www.alistapart.com/articles/goingtoprint/

More:

http://www.d.umn.edu/itss/support/Training/Online/webdesign/css.html#print

4.6 Does the site work well in Hand Held devices?
This is a hard one to deal with until hand held devices consistently support their correct media type. However, some layouts work better in current hand-held devices. The importance of supporting hand held devices will depend on target audiences.

4.7 Does the site include detailed metadata?
Metadata is machine understandable information for the web

http://www.w3.org/Metadata/

Metadata is structured information that is created specifically to describe another resource. In other words, metadata is ‘data about data’.

4.8 Does the site work well in a range of browser window sizes?
It is a common assumption amongst developers that average screen sizes are increasing. Some developers assume that the average screen size is now 1024px wide. But what about users with smaller screens and users with hand held devices? Are they part of your target audience and are they being disadvantaged?

5. Basic Usability
5.1 Is there a clear visual hierarchy?
Organise and prioritise the contents of a page by using size, prominence and content relationships.

http://www.great-web-design-tips.com/web-site-design/165.html

5.2 Are heading levels easy to distinguish?
Use header elements to convey document structure and use them according to specification.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-logical-headings

5.3 Is the site’s navigation easy to understand?
Your navigation system should give your visitor a clue as to what page of the site they are currently on and where they can go next.

http://www.1stsitefree.com/design_nav.htm

5.4 Is the site’s navigation consistent?
If each page on your site has a consistent style of presentation, visitors will find it easier to navigate between pages and find information

http://www.juicystudio.com/tutorial/accessibility/navigation.asp

5.5 Does the site use consistent and appropriate language?
The use of clear and simple language promotes effective communication. Trying to come across as articulate can be as difficult to read as poorly written grammar, especially if the language used isn’t the visitor’s primary language.

http://www.juicystudio.com/tutorial/accessibility/clear.asp

5.6 Does the site have a sitemap page and contact page? Are they easy to find?
Most site maps fail to convey multiple levels of the site’s information architecture. In usability tests, users often overlook site maps or can’t find them. Complexity is also a problem: a map should be a map, not a navigational challenge of its own.

http://www.useit.com/alertbox/20020106.html

5.7 For large sites, is there a search tool?
While search tools are not needed on smaller sites, and some people will not ever use them, site-specific search tools allow users a choice of navigation options.

5.8 Is there a link to the home page on every page in the site?
Some users like to go back to a site’s home page after navigating to content within a site. The home page becomes a base camp for these users, allowing them to regroup before exploring new content.

5.9 Are links underlined?
To maximise the perceived affordance of clickability, colour and underline the link text. Users shouldn’t have to guess or scrub the page to find out where they can click.

http://www.useit.com/alertbox/20040510.html

5.10 Are visited links clearly defined?
Most important, knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again.

http://www.useit.com/alertbox/20040503.html

6. Site management

6.1 Does the site have a meaningful and helpful 404 error page that works from any depth in the site?
You’ve requested a page – either by typing a URL directly into the address bar or clicking on an out-of-date link and you’ve found yourself in the middle of cyberspace nowhere. A user-friendly website will give you a helping hand while many others will simply do nothing, relying on the browser’s built-in ability to explain what the problem is.

http://www.alistapart.com/articles/perfect404/

6.2 Does the site use friendly URLs?
Most search engines (with a few exceptions – namely Google) will not index any pages that have a question mark or other character (like an ampersand or equals sign) in the URL… what good is a site if no one can find it?

http://www.sitepoint.com/article/search-engine-friendly-urls

One of the worst elements of the web from a user interface standpoint is the URL. However, if they’re short, logical, and self-correcting, URLs can be acceptably usable

http://www.merges.net/theory/20010305.html

More:

http://www.sitepoint.com/article/search-engine-friendly-urls

http://www.websitegoodies.com/article/32

http://www.merges.net/theory/20010305.html

6.3 Does the site’s URL work without “www”?
While this is not critical, and in some cases is not even possible, it is always good to give people the choice of both options. If a user types your domain name without the www and gets no site, this could disadvantage both the user and you.

6.4 Does the site have a favicon?

A Favicon is a multi-resolution image included on nearly all professionally developed sites. The Favicon allows the webmaster to further promote their site, and to create a more customized appearance within a visitor’s browser.

http://www.favicon.com/

Favicons are definitely not critical. However, if they are not present, they can cause 404 errors in your logs (site statistics). Browsers like IE will request them from the server when a site is bookmarked. If a favicon isn’t available, a 404 error may be generated. Therefore, having a favicon could cut down on favicon specific 404 errors. The same is true of a ‘robots.txt’ file.

• 0 Comments

Is it disturbing to you when every other Web page you visit has a different font size?. One web page’s font is too small, and another web page’s fonts are too big… Well here’s a way to fix that and set each web page’s fonts to just the size you want.

In Internet Explorer, select: Tools-Internet Options, choose the General tab, click the Accessibility button, and check Ignore font sizes specified on Web pages (the wording varies depending on your IE version).

In Netscape 6 and 7, choose Edit-Preferences, select Fonts (double-click Appearance if you don’t see ‘Fonts’ listed), and then either check Use my default fonts or uncheck Allow documents to use other fonts, depending on your version (the wording of these choices also varies).

Now all Web page fonts should be of uniform size on all pages.

• 0 Comments

In no particular order 55 reasons for me to do “tableless” websites using valid XHTML for markup, CSS for layout and Flash sparingly, only as an ingredient. By tableless I mean avoiding tables (or a tagsoup of unnecessary divs substituting table trs and tds) for layout purposes and aiming towards as semantic markup as possible. Some of the reasons are “over HTML”, some “over Flash full monty” and some over both.

I know this topic has been discussed a plenty, I just needed to reaffirm myself :)

Here we go:

1. You can get free links from showcase sites like zengarden, stylegala, cssimport or cssbeauty
2. You don’t have to spend extra thought and time deciding on styling the mark up of your document (upper- or lowercase, quotes or no quotes on attributes)
3. You don’t need to spend extra thought on which tags should be closed and which can (or should) be left open
4. You “help” the search engines to deliver more relevant content using semantic markup
5. You can save in bandwidth costs and visitors will see them faster by making slimmer pages
6. It’s going to be easier for you to switch to XHTML 2.0 which will give you more semantic tools
7. Once you’ve practised enough, coding pages becomes a whole lot simpler and faster than any table/tr/td tagsoup
8. When the coding is faster you can spend more time on thinking about the user experience
9. Thinking about semantics of a document helps you to make design and information architecture decisions
10. You can quickly make a dummy site to test your sites information architecture and append a look and feel later with only minor code changes
11. You can do the design after most of the backend is done which will help your client (or boss) to think realistically about how much work is still needed
12. It’s possible to link directly to your content pages (compared to Flash)
13. browser controls like text-size and back and forward buttons work (compared to Flash)
14. Redesigns and realigns over the whole site are simpler
15. it’s simpler to make small last minute changes to your designs
16. Clean markup makes it easier or even unnecessary to build a CMS
17. Clean markup makes it easier for another developer to jump on board
18. You can make the backend almost totally independently from the frontend design, by completely different person
19. You have plenty of ways to play with the markup trying to optimize for search engines, without affecting visible layout
20. You have total control on print layouts of your pages
21. Your sites are automatically accessible to all kinds of browsers
22. Promoting web standards will help your work in the future, not having to code differently to each browser
23. With all elemets closed you mark up look cleaner
24. Well-formed code ensures your site works in more browsers
25. Well-formed code would help browser coders to spend more time on useful features than rendering engines that try to understand borken code
26. Your website will work in future browsers
27. Your website works in mobile (and other new) devices
28. You learn the basics of XML which has many other uses
29. CSS files are saved in browser cache for fast retrieval and less bandwidth use
30. Your documents are easy to convert back and forth another format using XSLT
31. Thinking semantics makes you think more about the content
32. Learning semantics makes you appreciate organization and write your other documents (even emails) in more organized way
33. You can write new technologies in your CV or portfolio
34. Modern browsers render a valid document faster
35. You feel better about yourself when you are making sites “the right way”
36. They are doing it: Dan Cederholm, Jeffrey Zeldman, Jason Santa Maria, Shaun Inman, Cameron Moll, Douglas Bowman, Dave Shea…
37. You will belong in a “movement”, make good contacts etc.
38. You learn to appreciate newer browsers which makes for more competition and later for better browsers
39. Blink tag is gone
40. Strict coding makes you learn to see mistakes quicker
41. You can aim to making some money writing a book about it
42. There are more job opportunities if you know these new ways
43. You learn better to understand how a browser works
44. You can use hacks and techniques with cool names like “be nice to Opera”
45. you start to care more about metadata, document and character types
46. With more people making slimmer pages, the amount of data moving in the whole web will be smaller and all connections faster
47. XHTML has a cooler name than HTML
48. There are more people thinking about the advantages and disadvantages and coding tricks of XHTML which makes for a bigger learning forum
49. You can use basically same markup template for many different websites
50. Learning to read and write it fast makes it possible to use cheaper tools (notepad)
51. Google knows this:
    • 4,380,000 xhtml better than html > 4,370,000 html better than xhtml
    • 206 “xhtml is better than html” > 87 “html is better than xhtml”
    • 2,130,000 xhtml sucks < 10,300,000 html sucks
52. When all browsers start to understand the correct MIME-type (xml), you don’t have to convert all your websites from html, just to switch to correct MIME
53. By more people using xhtml you ensure that in the future IE will need to understand the correct MIME-type
54. Accessibility is enforced with requiring Alt attribute for images
55. There just aren’t this many reasons to use HTML or entirely Flash instead

• 56 Comments

Ten CSS Tricks You May Not Know has proven to be such a success that we decided it was time to offer you ten more CSS tricks that you may not know.

1. Block vs. inline level elements

Nearly all HTML elements are either block or inline elements. The characteristics of block elements include:

• Always begin on a new line
• Height, line-height and top and bottom margins can be manipulated
• Width defaults to 100% of their containing element, unless a width is specified

Examples of block elements include <div>, <p>, <h1>, <form>, <ul> and <li>. Inline elements on the other hand have the opposite characteristics:

• Begin on the same line
• Height, line-height and top and bottom margins can’t be changed
• Width is as long as the text/image and can’t be manipulated

Examples of inline elements include <span>, <a>, <label>, <input>, <img>, <strong> and <em>.

To change an element’s status you can use display: inline or display: block. But what’s the point of changing an element from being block to inline, or vice-versa? Well, at first it may seem like you might hardly ever use this, but in actual fact this is a very powerful technique, which you can use any time you want to:

• Have an inline element start on a new line
• Have a block element start on the same line
• Control the width of an inline element (particularly useful for navigation links)
• Manipulate the height of an inline element
• Set a background colour as wide as the text for block elements, without having to specify a width

2. Another box model hack alternative

The box model hack is used to fix a rendering problem in pre-IE 6 browsers on PC, where by the border and padding are included in the width of an element, as opposed to added on. A number of CSS-based solutions have been put forward to remedy this, so here’s another one which we really like:

padding: 2em;
border: 1em solid green;
width: 20em;
width/**/:/**/ 14em;

The first width command is read by all browsers; the second by all browsers except IE5.x on PC. Because the second command comes second it takes precedence over the first – any command that comes second will always override a preceding command. So, how does all this work?

By placing empty comment tags (/**/) before the colons, IE5.0 will ignore the command. Likewise, by placing these empty comment tags after the colon, IE5.5 will ignore the command. By using these two rules in conjunction with each other, we can hide the command from all of IE5.x.

3. Minimum width for a page

A very handy CSS command that exists is the min-width command, whereby you can specify a minimum width for any element. This can be particularly useful for specifying a minimum width for a page.

Unfortunately, IE doesn’t understand this command, so we’ll need to come up with a new way of making this work in this browser. First, we’ll insert a <div> under the <body> tag, as we can’t assign a minimum width to the <body>:

<body>
<div id="container">

Next we create our CSS commands, so as to create a minimum width of 600px:

#container
{
min-width: 600px;
width:expression(document.body.clientWidth < 600? "600px": "auto" );
}

The first command is the regular minimum width command; the second is a short JavaScript command that only IE understands. Do note though, this command will cause your CSS document to invalidate so you may prefer to insert it into the head of each HTML document to get round this.

You might also want to combine this minimum width with a maximum width:

#container
{
min-width: 600px;
max-width: 1200px;
width:expression(document.body.clientWidth < 600? "600px" : document.body.clientWidth > 1200? "1200px" : "auto");
}

4. IE and width & height issues

IE has a rather strange way of doing things. It doesn’t understand the min-width and min-height commands, but instead interprets width and height as min-width and min-height – go figure!

This can cause problems, because we may need boxes to be resizable should more text need to go in them or should the user resize text. If we only use the width and height commands on a box then non-IE browsers won’t allow the box to resize. If we only use the min-width and min-height commands though then we can’t control the width or height in IE!

This can be especially problematic when using background images. If you’re using a background image that’s 80px wide and 35px high, then you’ll want to make sure that the default size for a box using this image is exactly 80 x 35px. However, if users resize the text then the box size will need to expand gracefully.

To resolve this problem, you can use the following code for a box with class="box":

.box
{
width: 80px;
height: 35px;
}

html>body .box
{
width: auto;
height: auto;
min-width: 80px;
min-height: 35px;
}

All browsers will read through the first CSS rule but IE will ignore the second rule because it makes use of the child selector command. Non-IE browsers will read through the second one and will override the values from the first rule because this CSS rule is more specific, and CSS rules that are more specific always override those that are less specific.

5. Text-transform command

One of the lesser known, but really useful CSS commands is the text-transform command. Three of the more common values for this rule are: text-transform: uppercase, text-transform: lowercase and text-transform: capitalize. The first rule turns all characters into capital letters, the second turns them all into small letters, and the third makes the first letter of each word capitals.

This command is incredibly useful to help ensure consistency in style across an entire website, particularly if there a number of content editors. Say for example your style guide dictates that words in headings must always begin with capital letters. To ensure that this is always the case, use text-transform: capitalize. Even if site editors forget about the capitalisation, their mistake won’t show up on the website.

It’s also preferable to use text-transform: uppercase to capitalise words, as screen readers may pronounce shorter words in capital letters as acronyms. A great example of this is ‘CONTACT US’, which is pronounced as ‘contact U S’ by some screen readers.

6. Disappearing text or images in IE?

IE has a very strange bug where text or background images sometimes disappears from sight. These items are still actually there, and if you highlight everything on screen or hit refresh they’ll often re-appear. Kind of strange, huh?

This problem mostly occurs on background images and on text next to a floated element. To remedy the problem, simply insert position: relative into the CSS command for the disappearing element, and for some bizarre reason that’ll usually fix the problem. If this doesn’t work (it sometimes doesn’t), assign a width to the offending element in the CSS and that should fix the problem.

7. Invisible text

Sometime you may actually want to make text invisible. Invisible text can be especially useful for screen reader users, perhaps to assign a label to a form item or insert a heading ahead of a section. Don’t want to change the visual appearance by inserting these? Make them invisible and no one using a visual browser knows that they’re there.

You may also want to make text invisible if using a print or handheld CSS file, as some information may not need to be displayed on either of these mediums (see below for more on this).

To make text invisible you can use display: none – easy! This works fine for hiding text from handhelds (if CSS is supported) and printed web pages, but isn’t so great for many screen readers. Screen readers are now becoming too clever for their own good, and some will actually ignore the any text that has the rule display: none assigned to it.

For screen readers users therefore, a new approach is needed: position: absolute; left: -9000px. This basically takes the text and positions it 9000px to the left of the left edge of the screen, essentially making it invisible.

8. CSS document for handhelds

A separate CSS document can be created for PDAs and mobile phones, and only activated when one of these devices is being used to access your site. More and more websites are creating separate CSS documents for printing, so web pages automatically become print-friendly when users choose to print them. You can also do the same for handheld devices.

The following command is used to call up the CSS document for handhelds:

<link type="text/css" rel="stylesheet" href="handheldstyle.css" media="handheld" />

CSS commands in the handheld CSS file override any equivalent commands in the main CSS document. So, what commands should you place in this file?

Ideally, you want handheld web users to avoid having to scroll across. To test this, open up your website in a regular browser window and resize it to 150px in width. Then, open up your main CSS file and insert some new commands at the very bottom of the document. The commands you place here should adjust the layout of the website so that it doesn’t require horizontal scrolling at a 150px width. Then, open up a new document, cut and paste these new commands over, and save it as handheldstyle.css (or whatever name you want to give it).

What your website offers to handheld web users should be quite different to what it offers on traditional web browsers, as the user experience is quite different. For further information, a book such as Handheld Usability is a great read.

9. 3-d push button effect

Back in the early days of the web, 3-d buttons that appeared to become pushed in when moused over were all the rage. At that time, this could only be achieved through images and JavaScript, but now with the advent of CSS we can go all retro and re-create the desired effect:

The main CSS commands you’ll need are:

a {
display: block;
border: 1px solid;
border-color: #aaa #000 #000 #aaa;
width: 8em;
background: #fc0;
}

a:hover
{
position: relative;
top: 1px;
left: 1px;
border-color: #000 #aaa #aaa #000;
}

Aside from these commands, you can insert any other commands to achieve the desired presentation effect – the only limit is your imagination!

10. Same navigation code on every page

Most websites highlight the navigation item of the user’s location in the website, to help users orientate themselves. This is a fundamental requirement for basic usability, but can be a pain as you’ll need to tweak the HTML code behind the navigation for each and every page. So can we have the best of both worlds? Is it possible to have the navigation highlighted on every page, without having to tweak the HTML code on each and every page? Of course it is…

First of all, you’ll need to assign a class to each navigation item:

<ul>
<li><a href="#" class="home">Home</a></li>
<li><a href="#" class="about">About us</a></li>
<li><a href="#" class="contact">Contact us</a></li>
</ul>


You’ll then need to insert an id into the <body> tag. The id should be representative of where users are in the site and should change when users move to a different site section. When in ‘Home’ it should read <body id="home">, in ‘About Us’ it should be <body id="about"> and in ‘Contact Us’ <body id="contact">.

Next, you create a new CSS rule:

#home .home, #about .about, #contact .contact
{
commands for highlighted navigation go here
}

This basically creates a rule that only takes effect when class="home" is contained within id="home", and when class="about" is in id="about" and class="contact" is in id="contact". These situations will only occur when the user is in the appropriate site section, seamlessly creating our highlighted navigation item.

• 0 Comments

Trying to get CSS-based websites to look the same across all browsers can often be difficult. Many of the problems however lie with Internet Explorer implementing CSS commands differently to other, more standards compliant browsers. All is not lost, however, as many of the differences you see across browsers are caused by the same Internet Explorer CSS issues…

1. Page elements are narrower in Internet Explorer

Perhaps the most famous IE and CSS problem is Internet Explorer’s misinterpretation of the CSS box model, which can cause page elements to be narrower in IE. Every HTML element is essentially a box, the width of which is the total of its margin, border, padding and content area. Imagine the following CSS rule:

div {
margin: 5em;
padding: 4em;
border: 1em solid green;
width: 30em
}

This means that each div is 50em wide in total. This amount is made up of a 30em wide content area, and a 4em padding, 1em border and 5em (invisible) margin on both the left and right sides.

In IE however, the border and padding are included in the width of the content, as opposed to added on. In IE therefore, the width of the content is only 20em (30em less 5em padding and border on either side), and the total width of the div is just 40em.
This CSS box model problem occurs in IE5.x, and can occur in IE6, depending on how you declare the ISO value in the HTML code. There are two ways of doing this:

• <?xml version="1.0" encoding="iso-8859-1"?>
• <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

The first command is placed on the very first line of the HTML document and the second can be placed anywhere within the <head>. In order for XHTML pages to validate it’s compulsory to use one of these commands. The W3C recommends using the first command as the second will be phased out in the future.

By using the first command however, Internet Explorer 6 will render the CSS box model incorrectly, just like in version 5 browsers. To fix the box model problem, you’ll need to insert a CSS hack to send different width values to different browsers. The CSS hack you use will depend on which ISO value you use, and therefore which versions of IE are rendering the box model incorrectly.

To fix up only IE5.x, use the following CSS commands:

div {
margin: 5em;
padding: 4em;
border: 1em solid green;
width/**/:/**/ 40em;
width: 30em
}

To fix up all versions of IE, use these CSS commands:

div {
margin: 5em;
padding: 4em;
border: 1em solid green;
width: 40em
}
html>body div {
width: 30em
}

(See the article, CSS hacks & browser detection for more on these hacks.)

2. Text spilling out of its container in non-IE browsers

Internet Explorer, unlike other browsers, will expand borders and background colours so text doesn’t spill out of its containing element.

If you’re going to view this in Internet Explorer, the box should look fine. In all other browsers the text is spilling out of the right-hand side of the box. The box has been assigned class="box" and has the following CSS commands assigned to it: .box {
width: 40px;
border: 2px solid #781351;
padding: 3px;
background: #d7b9c9;
white-space: nowrap
}

Non-IE browsers will adhere to the width: 40px CSS command, which is why the box doesn’t expand in these browsers. IE instead interprets width as min-width, and therefore expands the box to fit the text (the same applies with height and min-height).

To ensure the text doesn’t spill out of the box in all browsers, you’ll need to use the following CSS rule, in addition to the first one:

html>body .box
{
width: auto;
min-width: 40px
}

IE will ignore this CSS command, as the command has html>body at the front of it (see the article, CSS hacks & browser detection for more on this). As such, this CSS command is only for non-IE browsers. The first CSS rule, width: auto, cancels out the original width rule. The second command, min-width: 40px then assigns a minimum width to the box, so the box will always expand to fit the text.

Check out the box again (you won’t see any difference in Internet Explorer, so open this up in another browser to see the change); Much better!

3. Disappearing background images

IE has a very freaky bug where it likes to make background images (and sometimes even text – particularly if there are floated elements around) disappear. This often happens when you scroll up and down on a web page and you can usually make the background re-appear by refreshing the page.

Obviously you won’t want your site visitors to have to refresh a page to see a background image in full! A freaky solution to this freaky problem is to insert the CSS command, position: relative into the CSS rule containing the background image:

.foo {
background: url(filename.jpg);
position: relative
}

Occasionally this won’t work, so another solution is to assign a width or a height to the element with the background image. You may not want to assign a height or width, so a solution is to assign a height of 1% for Internet Explorer. Because IE interprets height as min-height (see point 2 above) this CSS rule won’t affect the appearance:

.foo {
background: url(filename.jpg);
height: 1%
}
html>body .foo {
height: auto
}

The height: 1% CSS command is cancelled out by the height: auto CSS command. Internet Explorer doesn’t understand html>body, so by inserting this in front of the second CSS rule this whole CSS rule is ignored by IE.

4. Widths only working on IE

Every HTML element is either a block or an inline element. Examples of block elements include <div>, <p>, <h1>, <form> and <li>. Example of inline elements include <span>, <a>, <label>, <strong> and <em>.

One of the characteristics of inline elements is that you can’t change the width of an inline element. The following CSS rule shouldn’t, in theory, work:

span {
width: 100px
}

This CSS rule won’t work, except in Internet Explorer where each span will now have a width of 100px. In every other browser however, the width of the span will simply be the width of the number of characters contained in the element. The solution? Make the span a block level element:

span {
width: 100px;
display: block
}

(Turning the span into a block element will make the width command work in every browser, but it will also make the span begin on a new line. To combat this, you could assign float: left to the span.)

5. Unstyled version of web page appearing in IE

When your website loads up in Internet Explorer, does an unstyled version of the page appear for a second or two, before the styled version kicks in this? If so, your website may be suffering from what’s known as the Flash Of Unstyled Content (or FOUC).

If you’re using the @import directive (e.g. <style type="text/css">@import "styles.css";</style>) to call up your CSS file then this phenomenon may be happening on your website in IE. It’s weird, there’s no logical explanation for it, but this problem obviously needs to be fixed.

The simple solution to this illogical problem is an equally illogical solution – insert either a link or a script element into the header:

• <script type="text/javascript" src="scripts.js"></script>
• <link rel="stylesheet" href="styles.css" type="text/css" media="print" />

It doesn’t matter which one you insert (or even if you insert both). If you provide a print stylesheet, using the link element to reference it (as indicated in the example above), then you’ll never see the FOUC phenomenon.

6. Fixed width web page not sitting in centre of window

Got a fixed width website and can’t get it to centrally align in the window in Internet Explorer? Or you can get it to centrally align in IE but not in any other browser? Fear not, it’s not your fault! Unfortunately, the correct way of centrally aligning content through CSS doesn’t actually work in IE:

#container {
width: 770px;
margin: 0 auto
}

The second command, margin: 0 auto, basically gives our containing element an automatic margin on the left and right, thereby positioning the containing element in the centre of the browser window.

IE however, will need slightly different commands to make this work:

body {
text-align: center
}
#container {
width: 770px;
margin: 0 auto;
text-align: left
}

This will then centrally align the container in IE too. To prevent the text from centrally aligning too, we insert text-align: left into the container div.

—

This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone. He knows an awful lot about the Disability Discrimination Act and spends much of his time working on the world’s most accessible CMS.

• 0 Comments

One of the main advantages of using CSS is the large reduction in web page download time. To style text, you used to have to use the <font> tag over and over again. You probably also laid out your site with tables, nested tables and spacer gifs. Now all that presentational information can be placed in one CSS document, with each command listed just once.

But why stop there? By using CSS shorthand properties you can reduce the size of your CSS document even more.

Font

Use:

font: 1em/1.5em bold italic serif

…instead of

font-size: 1em;
line-height: 1.5em;
font-weight: bold;
font-style: italic;
font-family: serif

This CSS shorthand property will only work if you’re specifying both the font-size and the font-family – omit either and the CSS rule will be completely ignored. Also, if you don’t specify the font-weight, font-style, or font-varient then these values will automatically default to a value of normal, so do bear this in mind too.

Background

Use:

background: #fff url(image.gif) no-repeat top left

…instead of

background-color: #fff;
background-image: url(image.gif);
background-repeat: no-repeat;
background-position: top left;

Omit any of these commands from the background CSS shorthand property, and the browser will use the default values. If you leave out the background-position command then any background image will be place in the top-left of the container and then repeated both horizontally and vertically.

Lists

Use:

list-style: disc outside url(image.gif)

…instead of

list-style: #fff;
list-style-type: disc;
list-style-position: outside;
list-style-image: url(image.gif)

Leave out any of these CSS commands from the shorthand rule, and the browser will use the default values for each, namely disc, outside and none (i.e. no images) respectively.

Margin & padding

There are a number of different CSS shorthand commands for margin and padding, depending on how many of the sides of the containing element have the same margin or padding values:

Four different values

Use:

margin: 2px 1px 3px 4px (top, right, bottom, left)

…instead of

margin-top: 2px;
margin-right: 1px;
margin-bottom: 3px;
margin-left: 4px

Three different values

Use:

margin: 5em 1em 3em (top, right and left, bottom)

…instead of

margin-top: 5em;
margin-right: 1em;
margin-bottom: 3em;
margin-left: 1em

Two different values

Use:

margin: 5% 1% (top and bottom, right and left)

…instead of

margin-top: 5%;
margin-right: 1%;
margin-bottom: 5%;
margin-left: 1%

One different value

Use:

margin: 0 (top, bottom, right and left)

…instead of

margin-top: 0;
margin-right: 0;
margin-bottom: 0;
margin-left: 0

The above rules also apply to padding and border (see below for more on border).

Border

Use:

border: 1px black solid

…instead of

border-width: 1px;
border-color: black;
border-style: solid

Use:

border-right: 1px black solid

…instead of

border-right-width: 1px;
border-right-color: black;
border-right-style: solid

(You can substitute right with top, bottom or left.)

The above CSS shorthand rules can be conveniently combined with the shorthand rules used by margin and padding. Take a look at the following box:

These borders can be achieved with the following CSS command:

border: 8px solid #336;
border-left: 10px solid #ccf;
border-top: 10px solid #ccf

You can achieve exactly the same effect by using:

border: 8px solid #336;
border-width: 10px 8px 8px 10px
border-color: #ccf #336 #336 #ccf

Conclusion

CSS shorthand properties are great! They’re a great way to reduce the amount of code contained in a CSS document, allowing for faster download times and easier editing. Now who can argue with that?

—

This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone. He knows an awful lot about the Disability Discrimination Act and spends much of his time working on the world’s most accessible CMS.

• 0 Comments

1. CSS font shorthand rule

When styling fonts with CSS you may be doing this:

font-weight: bold;
font-style: italic;
font-variant: small-caps;
font-size: 1em;
line-height: 1.5em;
font-family: verdana,sans-serif

There’s no need though as you can use this CSS shorthand property:

font: bold italic small-caps 1em/1.5em verdana,sans-serif

Much better! Just a few of words of warning: This CSS shorthand version will only work if you’re specifying both the font-size and the font-family. The font-family command must always be at the very end of this shorthand command, and font-size must come directly before this. Also, if you don’t specify the font-weight, font-style, or font-variant then these values will automatically default to a value of normal, so do bear this in mind too.

2. Two classes together

Usually attributes are assigned just one class, but this doesn’t mean that that’s all you’re allowed. In reality, you can assign as many classes as you like! For example:

<p class="text side">...</p>

Using these two classes together (separated by a space, not with a comma) means that the paragraph calls up the rules assigned to both text and side. If any rules overlap between the two classes then the class which is below the other in the CSS document will take precedence.

3. CSS border default value

When writing a border rule you’ll usually specify the colour, width and style (in any order). For example, border: 3px solid #000 will give you a black solid border, 3px thick. However the only required value here is the border style.

If you were to write just border: solid then the defaults for that border will be used. But what defaults? Well, the default width for a border is medium (equivalent to about 3 to 4px) and the default colour is that of the text colour within that border. If either of these are what you want for the border then you can leave them out of the CSS rule!

4. CSS document for printing

Lots of web pages have a link to a print-friendly version. What many of them don’t realise is that there’s no need because you can set up a second CSS document to be called up when a user prints the page.

So, your page header should contains links to two CSS documents, one for the screen, and one for printing:

<link type="text/css" rel="stylesheet" href="stylesheet.css" media="screen" />
<link type="text/css" rel="stylesheet" href="printstyle.css" media="print" />

The first line of code calls up the CSS for the screen (notice the inclusion of media="screen") and the second line calls up the CSS for the printable version (using media="print").

So, what commands should you put in this second CSS document? To work it out, open a blank document and save it as printstyle.css. Next, point the screen CSS command to this document so that the command reads: <link type="text/css" rel="stylesheet" href="printstyle.css" media="screen" />.

Now just keep entering CSS commands until the display on the screen matches how you want the printed version to look. You’ll certainly want to make use of the display: none command for navigation, decorative images and non-essential items. For more advice on this, read Print Different, which also mentions the other media for which you can specify CSS files.

5. Image replacement technique

It’s always advisable to use regular HTML markup to display text, as opposed to an image. Doing so allows for a faster download speed and has accessibility benefits. However, if you’ve absolutely got your heart set on using a certain font and your site visitors are unlikely to have that font on their computers, then really you’ve got no choice but to use an image.

Say for example, you wanted the top heading of each page to be ‘Buy widgets’, as you’re a widget seller and you’d like to be found for this phrase in the search engines. You’re pretty set on it being an obscure font so you need to use an image:

<h1><img src="widget-image.gif" alt="Buy widgets" /></h1>

This is OK but there’s strong evidence to suggest that search engines don’t assign as much importance to alt text as they do real text (because so many webmasters use the alt text to cram in keywords). So, an alternative would be:

<h1>Buy widgets</h1>

Now, this obviously won’t use your obscure font. To fix this problem place these commands in your CSS document:

h1
{
background: url(widget-image.gif) no-repeat;
height: image height
text-indent: -2000px
}

Be sure to change “image height” to whatever the height of the image is (e.g. 85px)! The image, with your fancy font, will now display and the regular text will be safely out of the way, positioned 2000px to the left of the screen thanks to our CSS rule. Please note, this can cause accessibility issues as any user with images turned off won’t be able to see the text.

6. CSS box model hack alternative

The box model hack is used to fix a rendering problem in pre-IE 6 browsers on PC, where by the border and padding are included in the width of an element, as opposed to added on. For example, when specifying the dimensions of a container you might use the following CSS rule:

#box
{
width: 100px;
border: 5px;
padding: 20px
}

This CSS rule would be applied to:

<div id="box">...</div>

This means that the total width of the box is 150px (100px width + two 5px borders + two 20px paddings) in all browsers except pre-IE 6 versions on PC. In these browsers the total width would be just 100px, with the padding and border widths being incorporated into this width. The box model hack can be used to fix this, but this can get really messy.

A simple alternative is to use this CSS:

#box
{
width: 150px
}

#box div
{
border: 5px;
padding: 20px
}

And the new HTML would be:

<div id="box"><div>...</div></div>

Perfect! Now the box width will always be 150px, regardless of the browser!

7. Centre aligning a block element

Say you wanted to have a fixed width layout website, and the content floated in the middle of the screen. You can use the following CSS command:

#content
{
width: 700px;
margin: 0 auto
}

You would then enclose <div id="content"> around every item in the body of the HTML document and it’ll be given an automatic margin on both its left and right, ensuring that it’s always placed in the centre of the screen. Simple… well not quite – we’ve still got the pre-IE 6 versions on PC to worry about, as these browsers won’t centre align the element with this CSS command. You’ll have to change the CSS rules:

body
{
text-align: center
}

#content
{
text-align: left;
width: 700px;
margin: 0 auto
}

This will then centre align the main content, but it’ll also centre align the text! To offset the second, probably undesired, effect we inserted text-align: left into the content div.

8. Vertically aligning with CSS

Vertically aligning with tables was a doddle. To make cell content line up in the middle of a cell you would use vertical-align: middle. This doesn’t really work with a CSS layout. Say you have a navigation menu item whose height is assigned 2em and you insert this vertical align command into the CSS rule. It basically won’t make a difference and the text will be pushed to the top of the box.

Hmmm… not the desired effect. The solution? Specify the line height to be the same as the height of the box itself in the CSS. In this instance, the box is 2em high, so we would insert line-height: 2em into the CSS rule and the text now floats in the middle of the box – perfect!

9. CSS positioning within a container

One of the best things about CSS is that you can position an object absolutely anywhere you want in the document. It’s also possible (and often desirable) to position objects within a container. It’s simple to do too. Simply assign the following CSS rule to the container:

#container
{
position: relative
}

Now any element within this container will be positioned relative to it. Say you had this HTML structure:

<div id="container"><div id="navigation">...</div></div>

To position the navigation exactly 30px from the left and 5px from the top of the container box, you could use these CSS commands:

#navigation
{
position: absolute;
left: 30px;
top: 5px
}

Perfect! In this particular example, you could of course also use margin: 5px 0 0 30px, but there are some cases where it’s preferable to use positioning.

10. Background colour running to the screen bottom

One of the disadvantages of CSS is its inability to be controlled vertically, causing one particular problem which a table layout doesn’t suffer from. Say you have a column running down the left side of the page, which contains site navigation. The page has a white background, but you want this left column to have a blue background. Simple, you assign it the appropriate CSS rule:

#navigation
{
background: blue;
width: 150px
}

Just one problem though: Because the navigation items don’t continue all the way to the bottom of the screen, neither does the background colour. The blue background colour is being cut off half way down the page, ruining your great design. What can you do!?

Unfortunately one of the only solutions to this is to cheat, and assign the body a background image of exactly the same colour and width as the left column. You would use this CSS command:

body
{
background: url(blue-image.gif) 0 0 repeat-y
}

This image that you place in the background should be exactly 150px wide and the same blue colour as the background of the left column. The disadvantage of using this method is that you can’t express the left column in terms of em, as if the user resizes text and the column expands, it’s background colour won’t.

Using this method the left column will have to be expressed in px if you want it to have a different background colour to the rest of the page.

—

This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone. He knows an awful lot about the Disability Discrimination Act and spends much of his time working on the world’s most accessible CMS.

• 1 Comment

A print stylesheet formats a web page so when printed, it automatically prints in a user-friendly format. Print stylesheets have been around for a number of years and have been written about a lot. Yet so few websites implement them, meaning we’re left with web pages that frustratingly don’t properly print on to paper.

It’s remarkable that so few websites use print stylesheets as:

• Print stylesheets enormously improve usability, especially for pages with a lot of content (such as this one!)
• They’re phenomenally quick and easy to set up

Some websites do offer a link to a print-friendly version of the page, but this of course needs to be set up and maintained. It also requires that users notice this link on the screen, and then use it ahead of the regular way they print pages (e.g. by selecting the print button at the top of the screen). Print-friendly versions are however useful when printing a number of web pages at the same time such as an article that spans on to several web pages.

How to set up your print stylesheet

A print stylesheet works in much the same way as a regular stylesheet, except it only gets called up when the page is printed. To make it work, the following needs to be inserted into the top of every web page:

<link rel="stylesheet" href="print.css" type="text/css" media="print" />

The file, print.css is the print stylesheet, and the media="print" command means that this CSS file only gets called up when web pages are printed. (There are many different media you can use for stylesheets, such as for handheld, TV, projection etc. – see a full list of media types for more.)

What to put in your print stylesheet

The CSS commands in the print stylesheet essentially override the CSS commands in the main stylesheet. As such, the only commands you need to put in the print stylesheet are ones to override the CSS commands in the main stylesheet. This means you don’t need to repeat any colour or branding CSS commands as they’ll already be taken from the main stylesheet.

Generally speaking, you’ll want your print stylesheet to make the following happen when users hit that print button:

Remove unwanted items

Usually it’s just your organisation logo and page content that you’ll want to appear on the printed version of the web page. You’ll normally want to remove the header, left column and right column. You may also want to remove the footer (or some of it) from the printed version, unless it contains your contact details.

There may be certain isolated items you’d prefer weren’t printed so you can simply assign these class="noprint" in the HTML. To get rid of these items, along with the header and navigation (assuming these are assigned <div id="header"> and <div id="nav">) use the display: none command:

#header, #nav, .noprint {display: none;}

You may also want to remove certain images and adverts, especially animated images as these won’t make sense when printed.

Format the page

There’s nothing worse than printing off a web page to find the last few words of each line cut off. It’s also annoying (and a waste of paper) when the left and right columns are left in, leaving a very narrow space for the content so the web page prints on to 15 pieces of paper.

Generally speaking, the three CSS commands you’ll need are:

width: 100%; margin: 0; float: none;

These commands should be applied to any containing elements (<div>s for a CSS layout and <table>s for table layouts) to ensure the content spans the full width of the paper. So, the full CSS command would perhaps be something like:

#container, #container2, #content {width: 100%; margin: 0; float: none;}

Change the font?

Some print stylesheets do change the font size (often to 12pt) but this isn’t generally a very good idea. If users increase text size on the screen then the text will print in this larger font size… unless you specify a fixed font size in the print stylesheet.

Other print stylesheets change the font family to a serif font (such as Times New Roman) as this is slightly easier to read from print. Whether you choose to do this or not is up to you as users may be a bit surprised to see a different font printed out.

Do also bear in mind that background images and colours don’t print out by default. As such, you may wish to change the colour of text in a light colour so it has a reasonable colour contrast without its background.

Links

Print-outs are often in black and white so do make sure that links have a decent colour contrast. If not, assign links a slightly darker colour in the print out. For example:

a:link, a:visited {color: #781351}

For bonus usability you could include a footnote on the page listing all the URLs from that page, with each link referencing its URL underneath with a number. It’s otherwise impossible to know where a link is pointing to when reading a print out from a web page. See this working example and find out how to do this by reading this Improving link display for print article.

Making the print stylesheet

When making the print stylesheet place the print CSS commands into the bottom of your main CSS file. As you keep adding more commands check how your web pages look on the computer screen (don’t do this on a live website!). Keep adding commands until you’re happy with the appearance, then cut these commands out of the main CSS file and paste into the print stylesheet.

To summarise, your print stylesheet may look similar to this:

/* Remove unwanted elements */
#header, #nav, .noprint
{
display: none;
}

/* Ensure the content spans the full width */
#container, #container2, #content
{
width: 100%; margin: 0; float: none;
}

/* Change text colour to black (useful for light text on a dark background) */
.lighttext
{
color: #000
}

/* Improve colour contrast of links */
a:link, a:visited
{
color: #781351
}
You’ve now got a print stylesheet! For something this quick and easy to set up that improves usability as much as it does, you’d be mad not to use one!

—

This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone. He knows an awful lot about the Disability Discrimination Act and spends much of his time working on the world’s most accessible CMS.

• 0 Comments

More and more web developers are ditching tables and coming round to the idea of using CSS to control the layout of their site. With the many benefits of using CSS, such as quicker download time, improved accessibility and easier site management, why not?

The problem with CSS

Historically the main problem with using CSS has been lack of browser support. This is no longer the case as version 5 browsers, which all have good support for CSS, now account for over 99% of browsers in use.

Instead, the problem is that browsers can sometimes interpret CSS commands in different ways, causing developers to throw their arms up in the air and switch back to pixel-perfect table layouts. Fear not though, as you learn more about CSS you’ll gradually start to understand the different browser interpretations and realise that there aren’t really that many.

How browser detection using CSS hacks works

The way browser detection using CSS hacks works is to send one CSS rule to the browser(s) you’re trying to trick, and then send a second CSS rule to the other browsers, overriding this first command. If you have two CSS rules with identical selectors then the second CSS rule will always take precedence.

Say for example you wanted the space between your header area and the content to have a gap of 25px in Internet Explorer, or IE as it’s affectionately known. This gap looks good in IE but in Firefox, Opera and Safari the gap is huge and a 10px gap looks far better. To achieve this perfect look in all these browsers you would need the following two CSS rules:

#header {margin-bottom: 25px;}
#header {margin-bottom: 10px;}

The first command is intended for IE, the second for all other browsers. How does this work? Well, it won’t at the moment because all browsers can understand both CSS rules so will use the second CSS rule because it comes after the first one.

By inserting a CSS hack we can perform our browser detection by hiding the second CSS rule from IE. This means that IE won’t even know it exists and will therefore use the first CSS rule. How do we do this? Read on and find out!

Browser detection for Internet Explorer

To send different CSS rules to IE, we can use the child selector command which IE can’t understand. The child selector command involves two elements, one of which is the child of the other. So, html>body refers to the child, body, contained within the parent, html.

Using the example of the header margin, our CSS command would be:

#header {margin-bottom: 3em;}
html>body #header {margin-bottom: 1em;}

IE can’t understand the second CSS rule due to the html>body CSS command so will ignore it and use the first rule. All other browsers will use the second rule.

Browser detection for Internet Explorer 5

It may seem strange at first to send different CSS rules to different versions of a browser, but in the case of IE5 it’s very necessary. This is due to IE5’s misinterpretation of the box model. When specifying the width of an element in CSS, padding and borders aren’t included in this value. IE5 however, incoporates these values into the width value causing element widths to become smaller in this browser.

The following CSS rule would result in a width of 10em for all browsers, except IE5 which would give it a width of just 5em (IE5 would incorporate two sets of padding and border, on both the left and right, when calculating the width):

#header {padding: 2em; border: 0.5em; width: 10em;}

The solution to this problem? Perform browser detection and send a different CSS rule to IE5:

#header {padding: 2em; border: 0.5em; width: 15em; width/**/:/**/ 10em;}

IE5 will use the first width value of 15em, 5em of which will be taken up by the two sets of padding and border (one each for the left and for the right). This would ultimately give the element a width of 10em in IE5.

The 15em value will then be overridden by the second width value of 10em by all browsers except IE5, which for some reason can’t understand CSS commands with empty comment tags either side of the colons. It doesn’t look pretty but it does work!

Browser detection for Internet Explorer on the Mac

Quite simply, IE on the Mac does strange things with CSS. The browser’s become somewhat obsolete as Microsoft aren’t going to be bringing out an updated version. As such, many web developers code their CSS-driven sites so that the site works in IE/Mac, although it may not offer the same level of advanced functionality or design. Provided IE/Mac users can access all areas of the site this is seen as a suitable way of doing things.

To hide a command using the IE/Mac CSS hack is simple, and involves wrapping a set of dashes and stars around as many CSS rules as you like:

/* Hide from IE-Mac \*/
#header {margin-bottom: 3em;}
#footer {margin-top: 1.5em;}
/* End hide */

IE/Mac will simply ignore all these commands. This CSS hack can actually be quite useful if there’s a certain area of the site not working properly in IE/Mac. If that section isn’t fundamental to being able to use the site, you can simply hide it from IE/Mac like so:

#noiemac {display: none}

/* Hide from IE-Mac \*/
#noiemac {display: block;}
/* End hide */

The first CSS rule hides the entire section assigned the noiemac id (i.e. <div id="noiemac">). The second CSS rule, which IE/Mac can’t see, displays this section.

Browser detection for IE 4 and Netscape 4

Version 4 browsers have limited and somewhat erratic support for CSS. Making a CSS layout in these browsers, whose market share has now slipped well below 1%, can be extremely challenging. It’s become common practice nowadays to completely hide the CSS file from version 4 and earlier browsers. This can be achieved using the @import directive to call up the CSS document:

<style type="text/css">@import "styles.css";</style>

Version 4 (and earlier) browsers will display a non-styled version of the site as they can’t understand this @import directive.

Checking your site in the different browsers

At the time of writing, the major Internet browsers include IE5, IE6, Firefox, Opera and Safari. (Check out TheCounter.com for up-to-date browser statistics.) You can download all these browsers, and a number of more obscure ones, at the Evolt browser archive.

Ideally you should check your site in all these browsers, on both PC and Mac (except IE6 and Safari, which are only available on PC and Mac respectively). If you don’t have access to a Mac you can get a screenshot of your site on Safari by running it through Dan Vine’s iCapture or you can pay to use Browsercam which offers a more extensive screen capturing service.

Conclusion

On the whole, modern browsers have very good support for CSS – certainly good enough for you to be using CSS to control layout and presentation. Sometimes however, certain page elements will appear differently in different browsers. Don’t worry too much if you don’t know the reason why – if you can fix it up with these CSS hacks then your web pages should look great across all browsers!

—

This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone. He knows an awful lot about the Disability Discrimination Act and spends much of his time working on the world’s most accessible CMS.

• 0 Comments

Specs, primers, validators, stuff like that

The CSShark Answers FAQs — Martina Kosloff has compiled a pretty good FAQ on CSS. Worth your time.

css/edge — From the mind of Eric Meyer comes this great little site pushing CSS to the edge. It is, in his words: “intended, first and foremost, to be as relentlessly creative with CSS as we have been practical all these years. It does not exist to present or explain safe cross-browser techniques; in fact, almost the opposite. The goal here is to find ways to make CSS live up to its fullest potential, with only minimal regard to browser limitations.”

websitetips.com CSS section — Literally a ton of links to CSS resources from all over. A better set of links than this one by far.

Style Sheet Reference Guide from webreview.com. — Eric Meyer’s excellent resource, including the justly famous browser compatibility charts. It’s a bit dated (I wish it included Opera 5 and more of CSS2) but still an excellent resource.

CSS School from w3schools.com. — A whole lot of information, references, and examples.

Cascading Style Sheets, level 1 Recommendation from the Web Design Group. — This is the spec (really a rec) folks; can be very helpful if you learn how to read it.

W3C CSS Validation Service — Download a CSS validating app, give it a URL, or cut and paste your CSS here for the ultimate in CSS Validation services.

The Layout Reservoir from BlueRobot. — A resource much like this page with beautiful CSS layouts for you to steal.

Agitprop — Todd Fahrner’s collection of CSS writings, tests, and treatises. Good stuff.

CSS Pointers Group — A great resource full of information and links to other resources on CSS. Some of it is a bit dated (but what isn’t in today’s modern age?), and they are all down on multi column layouts, but still a must visit.

Eric Meyer’s CSS work — The author of the O’Reilly CSS Definitive Guide, Eric has done an amazing amount of writing and work on CSS. One highlight: his frame set views of the W3C’s CSS references.

• 0 Comments