Why I quit helping with 100% height questions

I just want to say why I'll never help with "100% height" (usually "height at least as tall viewport and/or content") questions any longer.

First, if you know why you're asking for it, the solution is very simple. "100% height" almost never means what people asking about it want it to mean. If they thought harder, the solution is simple. Also, the questions arise because they haven't realized all the possible usable HTML elements.

Second, the few times it's actually "useful" break other expected web behaviors. For example, the "footer always at the bottom of viewport/content" is probably a usability hazard. Among other things, it breaks up the content. Potentially removing the footer by a significant amount of the screen. It also has different behavior for long content versus short content (as compared to position:fixed type behavior). In addition, most uses probably break other good design practices (too much emptiness).

Third, it teaches bad habits. The "100% height" technique is a carry-over request from table hacks. It does not require the questioner to think about their site as simple blocks (ie. rectangles) defined by content. Most requests are answered simply by looking at the blocks at hand (html, body, etc).

Fourth, people spend a significant amount of time worrying about a special case. I usually ponder, when looking at the questioners site, is it really worth worrying about? How about simply making your content better? How about a "better design" for the web?

Finally, "100% height" is usually NOT a design requirement. Web developers often get "fixed" designs from designers and assume that the best translation is "100% height". This is a mistake. Indeed, it reflects a genuine misunderstanding of the process of creating web designs. It's true, of course, that simply leaving the space blank is not the answer either. However, turning a fixed layout into a web layout usually means some compromising and some planning. Usually, the needs are simply a "faux column" derivative.

On width

Width causes two problems. First, people can't figure why an element won't accept width. Second, people can't figure out why their poor "boxes" are bigger than they expect.

Inline elements

The first problem is usually because the developer is trying to apply width to something that can't take it. For example, adding the "width" property to a span, without something more, will do nothing. Span is an inline element--or it is at least treated as such. Since inline elements don't understand width (it really doesn't make much sense), the property gets ignored. The fix is simple: make it not an inline element.

There are two ways to easy ways to make something not an inline element. The first is to change the display property (eg. display: block; or display: inline-block; the latter of which doesn't work in many browsers). The second way is to float an element. By adding float: left;, an inline element is now a box. Problem solved.

The meaning of width...

The second problem is something a bit "trickier". The typical situation looks like this:

div#something {
    width: 100px;
    padding: 5px;
    border: 1px solid #000;
    background-image: url(perfectly-100px-image.gif);
}

They are then shocked to find that their painstakingly precise 100 pixel image doesn't fit perfectly in their box. They then complain that CSS sucks.

Well, the problem is simple. The calculation for "box width" is done by adding the values for 1) width, 2) horizontal padding, and 3) horizontal borders. The problem is most certainly because most people would want to understand "width" to be "box width" and not "content width".

You see, the actual meaning of the "width" property is "content width". It sets the space that a block may use to show its content (inline or otherwise). In the code above, the content contained by #something will have a width of no more than 100px, without doing something else. The overall box, however, will be 100px (content width) + 10px (left & right padding) + 2px (left & right borders), for a total of 112px.

So, to get the "appropriate" behavior, and assuming that the borders are supposed to be on the outside of the image, the following code would work:

div#something {
    width: 90px;
    padding: 5px;
    border: 1px solid #000;
    background-image: url(perfectly-100px-image.gif);
}

10 CSS tips for the new

This is my attempt to save you some time

1. Do not worry about height: 100%

   There are plenty of ways to get this to work, but this is not something that you should concern yourself at first. Trust me, it's simple, but it's not "easy". It's not "easy" because it involves aspects of an HTML document that I'm sure you're not prepared for.

2. You don't need to position everything

   Sounds like common sense to those of us that have done CSS development for a number of years, but it's easily missed for the new. The feeling is usually because the first CSS examples you'll find use crazy things like position:absolute; and float: left;. The truth of the matter is that those techniques are used in the minority of design elements. More frequently than not, you can just leave your poor element alone. If you learn nothing else from this: try nothing first.

3. Make sure that you're not fighting browser defaults

   Some browsers have funky browser defaults for properties likes margins, paddings, line-heights, font-sizes, and font-weights. When in doubt, try things like zeroing out the margins and paddings. Frequently, people will suggest the selector: * { margin: 0; padding: 0; }. It's true, this will clear all those defaults. I suggest that you use it for debugging and be more specific about your killing of properties, like: h1, h2, h3, h4, h5, h6, form { margin: 0; padding: 0; }

4. Validation doesn't mean correct

   The fact that your page validates does not mean that it is correct for the purpose you intend. This is just like how "Stop!" is a valid sentence, but it doesn't mean that the message will convey "proceed in an orderly fashion in the following direction" (it, in fact, would mean just the opposite).

5. There is such a thing as too many divs

   Divs are simply another html element. Doing one-to-one replacement of table elements for divs is probably pointless. There is a whole world of html elements that you should become familiar with. Use them. They're your friends. Divs are just one choice that people often use to divide up their content into smaller pieces.

6. Tables are not evil

   Tables are only evil for layout. Tables have their place among all the other HTML elements. You probably have a good use for a table if you can figure out where to place the following table elements: caption, thead, tbody, tfoot, and th. Also, there is the "summary" table attribute that you should be able to use. A good rule of thumb is that if you have something that would be appropriate in MS Excel, it's probably ok for a table (I realize that people abuse Excel, but that's another issue).

7. Work smarter, not harder with CSS

   Under this rule, there are a number of subrules: if there isn't a point to adding a CSS property, don't add it; if you're not sure why you're adding a CSS property, don't add; and if you feel like you've added the same property in lots of places, figure out how to add it in only one place (ie. this happens for font, color, background-color, font-size, and width properties all the time).

8. After you have a design, start with a blank page of content

   Start with an unstyled, vanilla page of representative content first. It is sort of the inverse of table development. After you've designed your site in a graphics program, create a vanilla page of content. Include your headers, your navigation, a sample of the content, and your footer. Then start adding your html markup. Then start adding your CSS. It works out much better. You can, of course, always go back and tweak your HTML with additional elements, as needed, but you just find that you end up with fewer.

9. Start your CSS by working from the top down

   Creating your CSS in an orderly fashion will help you get started. I find that the top down works the best. By top down, I mean the literal top of your HTML source, which should somewhat correspond to the top of your page's design anyway. Generally, your header is probably at the top of your design and the top of your source.

10. Use Google™, first

    You probably won't learn everything without doing a bit of searching. I've found that one of the best search queries is the following: CSS [whatever it is I'm searching for]. (without the []) By that, I mean, if I'm trying to figure out how to remove that damn extra space below my h1 elements, I search for: CSS h1 extra space below. Notice that you'll get results that might not be perfect, but you don't even need to know that the problem is margins. You can also be more specific if your problem is in one browser only by modifying your search to the following: CSS IE [my problem]. (no []). For example, the following: CSS IE extra 3 pixels to the right of a float.

That took awhile to write. I hope that helps. Enjoy!

Quick Centering

There's nothing difficult about centering, what is oft overlooked, however, is that you can apply centering to the body element. This example by Simple Bits: CSS Centering 101 is a classic example of when you don't need more than the body element.

In the example, they're centering a fixed width layout. So they give the container element a width. My question is, why do that?

If we know that the content will ALWAYS be 700px wide, let's give the width to the body element. If we need to give our page a background, we still have the HTML element. Thus our code is further simplified:

<html>
  <!-- skipping head, but that's important too -->
  <body>

  </body>
</html>

In addition, the CSS stays exactly the same, swapping html and body for the body and container:

html { text-align: center; /* IE5 hack */ }
body { text-align: left; /* IE5 hack */
       width: 700px;
       margin: 0 auto;
}

That's all she wrote!

You can do lots of fun things with the html and body elements that should suffice for most designs.

Fluid layouts using percentages is probably a bad idea

In the last post, there was a discussion of "fluid" layouts which only briefly touched on the notion of what a fluid layout actually means. In the transition from a CSSless web development to CSS enhanced web development we gained a bunch of units of measure, which alters the possibilities for fluid layouts.

In the traditional sense, a fluid layout meant largely that you had to use either percentages on all your "columns" or you had a "fixed" navigation column with a unitless content column (often achieved by setting that column's width to 100% and let the browsers break it). While both of these concepts have their place, it remains to be seen that either of them represent the holy grail of fluid layouts.

In the first case, setting percentages for both columns, you have necessarily created a layout without any real attention to the content. The developer makes some necessary assumptions when laying out a page like: 25% of the screen for navigation and 75% for content. The first assumption is that 25% is an appropriate size for the navigation. The second assumption was that the browser will necessarily break the layout and save your design when it was too small.

The second problem relates to how designers used tables as hacks. A table cell, by default, has to contain its contents, there are no exceptions. That means that when the content exceeds the specified width, the width is ignored and the content is contained. So in reality, designers relied on their layouts breaking to save them.

The first problem is a little less obvious. When developers say that navigation should consume 25% of the screen, they make the decision based on what a normal person would see at 25%. However, the size of 25% varies wildly because of things like resolution, window size, etc. 25% of 800px might be what you're after, but 25% of 300px or 1200px might be too small or too big, respectively. The 25% has less to do with the actual content contained within and more about wishful thinking and a naive reliance on the browser gracefully breaking the layout.

Developers and designers recognizing the inherent flaws in setting things like navigation bars to widths using percentages shifted to the slightly more realistic fixed column fluid content block. This eliminated the variation of width problem and still kept the content "fluid". For table-hacks, there is not much of an alternative. Without delving into the complicated world of CSS, the best you could do was width="150".

The obvious problem here is that by setting a particular pixel width, you're just hoping that your content will fit appropriately. Again, it's wishful thinking on the part of the designers because when that troublesome end-user changes their font-size, and you're not using fixed fonts, the navigation bar all of sudden looks too narrow or too wide (depending on if they increased or decreased their font-size). All the time the designer spent with the rules of proportion is thrown out the window.

That is, until one realizes that there are CSS units that go beyond simple % and px.

The em

For example the em. The em is a relative unit of measure. It is roughly equivalent to the size of the capital letter M at the current font-size. This gives designers an extraordinary amount of control over the width of a column as related to the content of the column.

What that means is, say that the longest line of the navigation is the word "navigation", but setting the width of the navigation to 10em, you will necessarily contain the word navigation with room to spare (notice that all the letters are probably smaller than M). Furthermore, a nasty user who changes their font-size will always see the same proportional size of the navigation bar.

By applying em, you can create a hyper-fluid page. The page's content will be fluid to screen size, *cough* and line-length *cough*, and the navigation bar (or any other bar) will be fluid to font-size and have some designer specified relationship to the content the bar contains. The best of all worlds.

Nevertheless, for most developer's the biggest hurdle is becoming proficient in recognizing when to use em and when to use other units of measure. A topic for another time.

Line-length is not different than any other user preference

So there's a long discussion, which bridges two posts about using fixed-width layouts. However, I think that the whole discussion starts off on a totally silly logical footing: that somehow line-length is somehow different than any other property.

Line length, while not explicitly a CSS property is influenced by the horizontal width of a container it's in. We can assume that if a content container is 450px (or 40em for that matter), then the content will be no wider than 450px (there are a few cases where this might not be the case, but we don't really need to worry about them for this discussion). Furthermore, the application of padding and margins to the content and to it's container will further restrict the line-length.

That's obvious. What's not so obvious is we've implicitly assumed something about the user. A principled, conscientious web developer knows that restricting a user's font-size is a big no-no. The reason is simple, not everyone has the eye-sight, or the screen reading ability of the twenty-to-thirty-something creating the page (ok, some developer's might be older, but whatever). They too realize that lots of people use lower font-size settings on lower resolution to get more content "above the fold" (here, I mean before they have to vertically scroll). So the developer consciously chooses to use ems and percentages of the user's default font-size.

So what's the have to do with line-length? Simple: everything. A user using larger fonts whose content area is limited by a 450px container will have a far poorer reading experience than someone using the font-size a developer assumed the majority use. In addition, someone with a smaller font-size will have far longer lines than intended (probably more likely).

This problem is only somewhat solved using a relative unit like em for the width of the container. It's probably fixed for the user with a small font. Obviously, the line-length will be how the developer intended it. In fact, it would most certainly fall within one of the calculations for line-length. This does make, of course, the assumption that your layout can handle the fluidness of the content column (sounds almost like a fluid design to me). What's a little more difficult is what would happen at larger font-sizes. While the calculations referenced before For the larger font-sizes, a relative sized content container introduces the potential for horizontal scroll.

Whenever there is a fixed width layout, you're going to scroll on someone's screen: low resolutions, not maximized windows, etc. When you relatively size your container, you might in fact make this worse. For someone with large fonts, you potentially create a problem where the line-length might require scrolling both directions to read.

Here in lies the dilemma: by fixing your width you assume you're fixing the line-length problem. This is, by and large, probably true. What it does, though, is violate of the implicit principle rule discussed earlier: end users are the best decision-makers about their own readability requirements. We make that assumption about font-size, why would line-length be any different?

Of course, that's the perfect world scenario. People really don't know, or at least, do know that they know. Likewise, users don't often change they're browser window sizes to help them read better (perhaps because they're not used to being able to decide). This doesn't change the fact that some users do know (especially those that need to for good reason).

Finally, the line length discussion is important, and often overlooked in favor of design and structural considerations. It is important to realize that even in flexible designs, some absolute maximums and absolute minimums are ascertainable. Presumably, no one is going to want 2em widths or 1000em widths. I also believe that max-width and min-width properties solve even more of the problems (ie. width: 40em; max-width: 750px; min-width: 200px;). The lack of support by "the most popular" browser shouldn't prevent developers from implementing them.

Of Law and Accessibility

It seems that Priceline.com and Ramada.com, following an investigation, and noticing the potential for lawsuits seeking enforcement of accessibility laws, have both undertaken efforts to make their sites more accessible.

Ramada.com and Priceline.com, which face no charges and make no admissions of guilt, will pay the state $40,000 and $37,500 to cover the investigation's cost. Spitzer said both firms were cooperative.

Let's see... $40k because of their table-laden sites are unnecessarily inaccessible. I'm sure that both companies have their own web development staff, but imagine if they had purchased this from a web design firm.

There's a potential lawsuit waiting to happen.

Update 1: Potential

To two big sites, $74k is "pocket change." The real potential is that future plaintiffs might be able to use the results of the investigation against Priceline or Ramada. There the sums might not be nearly so insignificant.

This might also open the door for potential litigation against other sites by groups with the backing of do-gooder attorneys.

Lastly, I don't know if I can make the point enough, this was $74k simply because they couldn't do things right the first time. I wonder how much their risk assessers would like to hear that.

Update 2: Accessible travel sites

Kapuni.com is a British travel site which is conforms to web standards and is 100% accessible.

For fun, I've linked the accessibility results of several other sites:

• Orbitz.com
• Travelocity.com
• Hotels.com