This site will work and look better in a browser that supports
web standards, but it should be accessible for any browser or Internet device.
If you're seeing this message, you may have to scroll to the bottom of the page to see the navigation links.
XHTML and CSS
The last few years have introduced a long list of changes. We've come full circle to the foundation of the web: html is for structuring information not presentation. XHTML and CSS are designed to realize those changes. XHTML and CSS are now requirements of many web design positions. The future is no longer about custom extensions by Netscape or Microsoft, it's about web standards.
Another change has been the dot-com crash. In the days of the dot-com, excess was everything and everything was excess. Everything was bandwidth-hogging graphics, flash files and incredibly complicated table layouts. Many people now consider it cool to create sites that download fast, comply with standards and are accessible. In short, it's cool to do what we were supposed to be doing in the first place. This is what impresses web designers now.
This document is a collection of notes on XHTML, CSS and related developments.
Form and Function
The control designers know in the print medium is really a reflection of the limitations of the printed page.
What pages are different. They have to render on everything from standard web browsers like Internet Explorer and Mozilla to text browsers (Lynx) to cell phones. Web pages have to be adaptable. They have to be legible regardless of the screen size and resolution, available colors or whether the browser supports graphics.
Begin by thinking about what your pages do, not what they look like. HTML shouldn't be used for presentation. CSS (style sheets) was designed for that. HTML was designed to structure your information. If HTML provides a structuring element, use it, otherwise use classes through elements like div and span. In short, content is structured by html. The presentation is handled by stylesheets. Modern web standards and now the market are forcing this division of design from data.
Because webpages have to be adaptable, use style sheets to suggest the appearance of the page. You can't rely on any particular element of style sheets to work in order for a page to be accessible. So what do you do? You embrace flexibility. The upside, is that the new standards make redesigning the look of a website a much easier task. You're no longer forced to manually handcraft each page. You modify your stylesheets and go home.
First, don't rely on fixed font sizes. Use relative sizes instead. In designing your style sheets, specify font size as a percentage of the size of a parent unit. It's best to leave the body tag without a text size. Then, make other elements larger or smaller. So h1 tags might be set to say 50% bigger than the body size, h3 30% bigger and so on. Then the viewer can set to the main text size appropriate for their eyes and their computer.
Second, Layout elements should be designed using percentages. If you want items to be sized appropriately for the size of text, you can use the em for elements such as margins, indentation and so on. An em is the height of a capital letter (e.g. 'L') in the font of the element. By specifying layout size relative to font size, the layout will grow and shrink depending on what a user's font size is set to.
Third, you can't rely on color or color combinations by themselves to convey meaning. A significant number of people are color blind. Others use monochrome (one color) browsers (say in an early web-enabled cellphone). A technique in black and white publishing is to use 4 different weights of text on any page to simulate 4 colors. So, you might have Headlines, subtitles, body text and side bars in a text heavier than the body text.
Forth, drop using tables for formatting. Use style sheets. Tables follow the letter of the law, but don't follow the spirit. Them make pages maddeningly hard to maintain. I don't want to think about all the time I've spent tweaking tables on various websites to adjust a look. And tweak and tweak and tweak. Then copy the changes to each page. Then go through and test each page. And fix each page. And, oh my !@#$, a new version of a browser screws it all up. Now, you just modify your style sheet file.
There are a couple of basics you can do to make the initial transition to XHTML:
- Make sure all of your tags are lower case
- All tags have to be closed (e.g. there has to be a </h1> for every <h1>
- If a tag doesn't have a closing tag (e.g. img), add a slash to the end of the tag. So, <img> becomes <img />. The space before the slash is needed so older browsers don't blow up
- Make sure you nest your tags so that it's <p>this<sup>1</sup></p> not <p>this<sup>1</p></sup>
- All attributes have to be quoted. <div align="left&34;> has to be used instead of <div align=left>
For me, the first rule is the hardest. I want to keep the shift key down between < and >.
First, style sheets are all about inheriting things from an item's parent. If the body has a certain font and size, everything inside the body will have the same font and size unless the style sheet modifies the font or the size. By default, the h1 and other headline tags change the font size.
Second, sometimes there's a conflict between elements. The cliche example is the various anchor elements (link, visited, hover, active). In the case of a link you've already visited that the mouse is hovering over, link, visited and hover styles all apply. In general, browsers will start with whatever style information is inherited from the item's parent. They will then go through any styles that apply in the order they exist in the style sheet. In my case, I want hover and active to be the most important styles (e.g. overide the defaults in link and visited), so I put them later in the style sheet: link, visited, hover then active.
In CSS' box model padding and borders are added to the overall size. If the width of a box is 300 pixels wide with 20 pixels of inner padding on each side, the box ends up being 340 pixels wide. This is a little mind twisting, but IE 5/Windows (IE 6 has fixed this) gets it wrong. To make sure all other browsers get it right, make sure your doctype is correct. The Doctype should be the first thing in your document. If you leave out the DOCTYPE or the W3C url, you'll get the quirks mode. You can use any of the following 3 doctypes depending on what you're doing. Most people use the first:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
The float property is a wonderful tool. Float allows you to float the content to the desired width or point. It also, in conjunction with the clear property, can be used to flow text around images.
Similarly, you can use the z-index to place objects above other objects. Layers sound complicated, but there really are no layers. Some objects have a z index, so CSS2 browsers will move them up or down.
Because of the way some browsers work, it's best to just use positioning characteristics with the div tag.
O'Reilly (see below) and others note that even Internet Explorer 6.0 doesn't support position fixed, when early version of Netscape 6.0 and Mozilla before 1.0 supported it. I was creating a layout where I floated the main content right and wanted a 'top' link that stayed in the lower right corner. In that case, you can futz you way around things, by adding a clear left command and making sure that the block in question is after your main content. IE will happily cram it at the right end of a block that's below your main content (oooh, ugly) and everything else will ignore the clear left and keep it in the lower right corner. Joy!
position : fixed;
left : 85%;
top : 93%;
clear : left;
- w3.org's validator will check you xhtml
- this and this are examples of 3 panel layouts (e.g. a top title bar, a content bar and a nav bar)
- A List Apart issue 100 (issue and notes)
- Other approaches are covered by Eric Costello's notes on the best ways to create CSS layouts that handle browser differences and Tantek Çelik's box model hack
- BlueRobot's CSS Layout Reservoir and CSS Centering mini-tutorials #1 and #2
- Glish's CSS Layout Techniques
- Owen Briggs's amazing Little Boxes visual layouts page, and the Box Lesson Problem & Workaround Set, which addresses bugs in various browsers.
- Xhtml tags reference
- O'Reilly CSS Hints for Internet Explorer 5