CSS from the Ground Up - Steps 12 through 15

by Joe Gillespie — Jan 1, 2004

Step 12 – Styling Tables

Although tables have been used for page layout since the dark ages of the Web, I think I've shown in this series that CSS layouts offer much more scope and versatility. Tables are meant for displaying tabular data, the kind of thing you would usually do in a spreadsheet where you need to line-up rows and columns of figures or words.

In earlier times, (and older browsers), you could change the look of table and their cells using the various table properties - background colours, background images, etc. A lot of these features have now been deprecated and are no longer valid – even though they might still work, you can no longer count on them. In fact, you never could. If you tried to use a table background image in Netscape 4 and earlier, it would be repeated in each and every cell, like looking through some multiple image lens, making the whole exercise frustratingly useless.

It used to be okay to specify a table height in pixels or as a percentage of the window height but now you can't. Tables make their own height depending on the content.

Styling tables with CSS can be a bit tricky and not all that predictable. You can build your own table structure with CSS using display:table; and display:table-cell; where each cell is a separate div, but for most purposes, just providing style definitions for HTML table elements – table, tr, td, th, etc – is the easier way.

tr is a table row, a horizontal row of cells. td is a table row division. You might think of it as a column but it doesn't behave like a column and you can't set a column background colour or type style.

Tables inherit some styles from the divs they are within, but not all. If the body of your page has a font-family: verdana, arial, sans-serif style and a color: #009, the table will inherit those but not the font-size or text alignment. Also, there is a hierarchy of importance. Any specification for a td will overrule the style for the tr, which overrules any general style set for table. You can use this to advantage. If you set the table background-color to black and the td background-color to white and give the table a cellspacing="2", you get a table with white cells with 2 pixel black borders around them.

1 2 3 4
1 2 3 4
1 2 3 4

Table 1. This more subtle table has the table background set to transparent and a light tint of the background colour appled to the tds.

Of course, you also have access to all the CSS border styles too so you are not lumbered with the nasty, default HTML table borders. You can also play with the border colours and patterns to give you only vertical lines or horizontal lines that can be solid, dotted, dashed or whatever.

1 2 3 4
1 2 3 4
1 2 3 4

Table 2. Depending on the data you might want to give more emphasis to the horizontal rows or vertical columns like this.

Heading 1 Heading 2 Heading 3 Heading 4
1 2 3 4
1 2 3 4

Table 3. Here, a raised 3D effect is produced by altering the border colours. The table header th is given a darker background colour.

Another trick you might like to try is to give the trs gradating background images.

If you make a small image file of sufficient height to fill the cell and make it very narrow, say 8 pixels, it can be made to repeat horizontally with background-repeat: repeat-x – more subtle and stylish than borders.

table background This tiny image (227 bytes) can be repeated horizontally...

Row 1 2 3 4
Row 1 2 3 4
Row 1 2 3 4
Row 1 2 3 4

Table 4. I've used a slightly darker gradient for the row headers and introduced a pale grey left border to separate the columns.

If you want to style individual cells differently from the overall table, you can do that using inline style definitions attached to the appropriate <td> tags.

<td style="background-color: #f00">cell 1</td>
1 2 3 4
2 3 4
1 2 3
1 2 3 4

Table 5. Okay, so I'm a Mondrian fan but I'm just making the point that you can style individual cells if you really want to!

Using this approach does have the disadvantage that you can't do it from an external style sheet, it is effectively hard-coded into the page but it's okay for one-offs. A better way to style rows or columns is to put them inside their own divs and refer to them as...

#col1 td { ... }
#col2 td { ... }

That way, you can have a fair amount of control without getting down to building your tables from individual divs – which is the ultimate solution if you have the time and patience.

I haven't put all the style declarations on the page; there are too many of them, but if you view the page source, you will see what's going on.

There are lots of possibilities that will occur to you when you start styling tables. Who said that tables have to be boring?

     

Step 13 – Styling Forms

Styling Web page forms is not a great priority for many designers. The forms are usually left 'as is' – and for several good reasons.
  1. The conventions used for forms by default work pretty well as they are.
  2. If a form doesn't look as expected, readers could be confused.
  3. Form styling support in the various browsers isn't all that good.

Let's examine these statements a bit more closely.

 

'The conventions used for forms by default work pretty well as they are.'

 Maybe. Yet there are still a lot of badly designed forms out there, both in print and on the web.
        Basically, I detest form filling and I'm know that others feel the same way.
        But forms are a useful way of collecting information and do so in a way that makes compilation of that information relatively easy. So where do the form 'designers' go wrong?

The first big turn off is when a form 'looks' complicated. This intimidates the user and immediately puts them into 'defensive mode’.
        Then they ask questions that seem irrelevant or intrusive. Why do they need to know my date of birth?

Looking complicated is a matter of layout. You can make a form look simple by presenting it in a clean and orderly way. Letting text sizes go uncontrolled and breaking the layout is probably the first thing to watch for.
        The size and position of any captions or explanatory text also needs to be considered. It is best to put these above or below the input boxes, or to the right. If you do want to put captions on the left, use align: right; to avoid huge gaps that visually disconnect the caption from the box and increase the visual complexity of the layout. Also, try not to have too many different sizes of input boxes and don't fill spaces just for the sake of it. If a zip code box is shorter than the other address boxes, that's okay but don't put other different size boxes on the same horizontal line just to save space.
        On a Web page, you don't need to save space. Rationalise input box sizes. Line them up vertically. Keep them tidy and uncluttered.
 

 complex form

This form looks complicated. It has two vertical axes and eye movement is disrupted by having to jump vertically and horizontally to find the next box.

 simple form

A simpler design has just one vertical axis, right down the middle so eye movement is unimpeded.

Unlike a printed form, thankfully, a Web form masks what is not immediately visible in the browser window so it doesn't overwhelm the viewer. Yet, a very long form on one page that requires lots of scrolling can be even worse. It is better to break long forms across a multiplicity of pages - as long as you make provisions for people to go back if they need to change something.

 

'If a form doesn't look as expected, readers could be confused.'

Yes, you can't 'blow your mind' with form design. A text input box does have to communicate its function, as does a pop-up or submit button. That is not to say that it absolutely has to be a black text on a white, indented background – except that some browsers won't allow anything else!
        It would be a bad idea to confuse an input box with ordinary text, it has to be differentiated and still communicate its purpose.

The elements that you can style are input, textarea and select but you have to be aware that styling the input element affects not only the input text field but also the other input devices like radio boxes, check boxes and the 'Submit' and 'Clear' buttons.
        It’s reasonably safe to style the font-family and font-size. The text-color can be different if you like. The background-color is a little more contentious. Making it a paler tint of the page colour is acceptable and can make the form look less aggressive.

Changing the border of a text input box also changes the border on the submit button so it could look like just another text box if you are not careful. To get round this, you have to 'wrap' the text box in a div of its own and style just #typein input like this...

#typein { }
#typein input
       {
       color: #633;
       font-size: 10px;
       background-color: #ebebd9;
       padding: 3px;
       border: double 3px orange
       }

If you want to make a textarea look like a text input box, then you can do this...

#typein input, #typein textarea
       {
       color: #633;
       font-size: 10px;
       background-color: #ebebd9;
       padding: 3px;
       border: double 3px orange
       }

Select (popups) change in look from one browser and platform to another. Setting a font-family and size is about all that is worth doing. How they look when actually clicked is usually beyond your control anyway.

 

'Form styling support in the various browsers isn't all that good.'

This is best demonstrated with some screenshots.
        The same styles rendered in Explorer (Win), Mozilla, Safari (Mac) and Opera show the variance you can get. More about browser rendering differences coming up.

The crucial point is that we are not trying to 'pretty-up' the forms. We are trying to make them easier to use and less intimidating with thoughtful visual presentation.

Improving the user-experience even further with helpful form validation scripts is another story completely and I won't go into those just now.

Step 14 – Browsers

Great. Where would we be without them? How many times have I heard people say that they wish there was just one. Which one though?

Each browser has its own built-in default style sheet. That's what you get when you don't provide your own. Naturally, the built-in style sheets are all different. They come from different companies and work differently on the various computer platforms.

It's amazing that they are so similar but the differences are not insignificant. If you just assume that other browsers are going to give 'similar' renditions of your carefully crafted Web page, you will quickly find out that 'similar' does not mean 'the same' and can mean 'quite different' in some circumstances - even with the same valid CSS style sheet.

I can't go into an exhaustive cross-browser comparison here and there are plenty of them published elsewhere. I will point out a few of the ones that bother me most. Usually, it's a case of Explorer Vs. The Rest – but not always. A list of links to current browsers is always available on the WPDFD News page. Most of them are free or can be test-driven at no cost.

Microsoft Internet Explorer is the most ubiquitous browser there is. In its various guises, it accounts for something like 85% of all browsers used. Unfortunately, it is a law onto itself and doesn't conform to the same standards as other browsers. It conforms to most of them but it is where this conformity diverges that the problems occur.
 

The CSS Box Model

In all versions of IE, the implementation of padding is different from all other browsers. The effect of this is that if you specify a CSS box width in pixels and it has left or right padding, the box will have a different width in IE and other browsers – and can break a tight layout.

IE assumes that padding is inside the box, thereby reducing the text width – which I must admit, seems reasonable to me. W3C standards call for padding to be added outside the box width keeping the text width consistent. Which is the more logical can be argued ad nauseum but we are still left with this fundamental difference that can catch you out if you don't check your pages.

 

What is 'Relative'

'Relative' placement of CSS boxes seems a fairly simple concept. Each box takes a place relative to the one immediately above it. Watch out! If you move a box out of its 'natural flow' by giving it a top or bottom value, what is supposed to happen is that the box moves but leaves its 'place' vacant – like a car does when it moves out of a car parking space. IE (Mac version) closes up that vacated space thereby shifting everything under it up or down.

On the left is what is supposed to happen when you move a relative CSS box, the vacated space effectively becomes an invisible box. On the right, what IE (Mac) does and can break a layout if you don't expect it.

 

Markup formatting shouldn't affect styling

Now, here's the one that really 'bugs' me because it IS most definitely a bug and not a misinterpretation of standards. Browsers are supposed to totally ignore the formatting of the HTML markup. It shouldn't matter if you type the whole thing in one long horizontal line or put double spacing between each line. A bug in IE (Mac) means that if you float boxes left in a horizontal line and have the corresponding markup on separate lines, it gets totally confused. You have to put the markup on one line to get the results you expect. Now, it would be no big deal to fix this bug, but development of IE (Mac) is effectively dead in the water and there are now so many better browsers to choose from – but like habits, old Macs die hard.

Step 15 – The future

Cascading Style Sheet specifications and abilities are continually being updated and browsers being updated to reflect the new possibilities. It is an ongoing and ever-changing process overseen by the folk at the W3C (World Wide Web Consortium).
        Hopefully, the many differences in implementation that we have at present will be reduced if not eliminated but then there are other factors at play.

The concept of viewing Web pages on a computer screen is going to change. We are already seeing Web pages on devices that are not computers and Web-delivered content that is not viewed in browsers.
        Expect more!

Companies are falling over themselves trying to identify ways to build 'communication hub' functionality into their products –  telephones, televisions, cars, refrigerators, microwave ovens are all prime targets. Ultimately, the Web-enabled brain implant will hook us all together and bring the human race up to the same level of communicative sophistication as ants!

With CSS, it won't matter too much what device is being used to display the content. It can already accommodate a diversity of media types even though we mostly use only two – 'screen' and 'print'.
        The upshot of all this is that you can't rest on your laurels, you have to keep up, or give up.

As I wind up this short Cascading Style Sheets from the Ground Up series, I hope it has whetted your appetite for more – and there’s a lot more, believe me.

Del.icio.us Digg Technorati Blinklist Furl reddit Design Float