CSSing

Why I quit helping with 100% height questions

2006-03-23T13:05:00.000-08:00

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

2006-02-14T13:15:00.000-08:00

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

2006-02-03T12:33:00.000-08:00

This is my attempt to save you some time

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.
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.
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; }
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).
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.
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).
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).
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.
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.
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

2004-09-13T10:42:00.000-07:00

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

2004-09-01T05:39:00.000-07:00

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

2004-08-25T06:34:00.000-07:00

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

2004-08-23T06:40:00.000-07:00

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:

Blocks by default STACK

2004-08-19T07:22:00.000-07:00

I'm not sure why people have such a hard time understanding that blocks by default stack on top of each other. I'm not sure why this is such a difficult concept, it's been happening since day one of your introduction to HTML class.

First this question manifests itself in three situations: How do I get my footer div below everything else?, Why doesn't this block sit along side another block? and How come my outer div's background doesn't cover up the whole area of the two inner divs?. They are several seemingly different questions with usually one root cause: blocks, by default, stack. The questions might never arise, except that someone has done something that changes a block's default behavior.

It's probably a good idea to define a few terms. Stack means that the two elements have a vertical relationship which is often visually represented recognized as a line-break which cause the first element to be directly above another. Block refers to a class of HTML elements which stack as compared to those elements which can be used inline. Finally an element is just a generic term for what is generated by an HTML tag.

As I mentioned earlier, everyone is familiar with the fact that block level elements stacking. For example, the code below uses four block level elements: <h1>, <p>, <h2> and another <p>.:

<h1>Lorem ipsum dolor sit amet</h1>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>

<h2>Vivamus cursus iaculis ante</h2>

<p>Vivamus cursus iaculis ante. In id nisl quis tellus suscipit venenatis. Suspendisse potenti.</p>

In the pre-CSS days, everyone seemed to realize that the h1 would be on top of the p which in turn was on top of the h2 which was on top of the final p. Catch that? The implication might be subtle: no matter what content you put between any of the tags, it pushed the subsequent content down the page. In CSS days, guess what! That same logic holds.

Most people take the above for granted. And, in all the confusion, somehow block level elements like headers, lists and paragraphs are different than the div tag. Not that you'd ever do this, but look at this code:

<div>Lorem ipsum dolor sit amet</div>
<div>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</div>

<div>Vivamus cursus iaculis ante</div>

<div>Vivamus cursus iaculis ante. In id nisl quis tellus suscipit venenatis. Suspendisse potenti.</div>

Executing the above code renders the following:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Vivamus cursus iaculis ante

Vivamus cursus iaculis ante. In id nisl quis tellus suscipit venenatis. Suspendisse potenti.

Magic, isn't it? Need some proof, use the border property. The single greatest CSS development trick is to just start adding borders. If we apply a thin border to each div, we can see how they stack:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Vivamus cursus iaculis ante

Vivamus cursus iaculis ante. In id nisl quis tellus suscipit venenatis. Suspendisse potenti.

As you can see, the borders wrap the content of all the elements. In addition, the borders consume, by default, all the horizontal space. Finally, without any margins, each border touches the subsequent border.

I imagine the first problem of How do I get my block at the bottom occurs for two reasons:

One of the middle elements has been removed from the document flow
The developer is using absolute positioning to try to place things on the page.

In fact, point two is actually a special case of the first. Absolute positioning has it's place, but it, to the extreme, removes an element from the document flow and non-child elements have no way of interacting with it.

Document flow

Document flow is the term used to describe how elements, by default, render to the viewport. The default document flow is what was discussed and illustrated earlier. There are two common properties, however, which trap beginner CSS developers of altering the default document flow: float and position.

Position: absolute; in particular totally removes an element. Using position absolute on the first div above cause the subsequent blocks to ignore it and they begin to overlap.:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Vivamus cursus iaculis ante

Vivamus cursus iaculis ante. In id nisl quis tellus suscipit venenatis. Suspendisse potenti.

When the content of the first div grows and expands, the subsequent divs ignore it and continue to overlap. The only way to avoid overlapping is to start throwing in code that works around it: ie. margins and or pixel offsets. This becomes very messy, very quickly. It is also probably one of the areas of greatest frustration.

More often than not though, developers mess with the document flow by using the float property. The float property alters the default stacking behavior. For example, if you want the first and third (ostensibly our headers from the first example) to be along the left hand side of the paragraphs you might add: float: left;:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Vivamus cursus iaculis ante

Vivamus cursus iaculis ante. In id nisl quis tellus suscipit venenatis. Suspendisse potenti.

You should note a few things. First, float left alone won't do much if you have a great deal of content in your headers. This is because there is nothing telling the blocks to behave other than to attempt to consume all the horizontal space. The float property alters this behavior a little. You'll notice that the borders do not extend all the way, but rather closely surround the content. If we wanted to achieve a column like effect, simply add a width.

The second thing you'll note is that even where the non-floated blocks did align along side, their borders extended behind the floats. This is because they've been removed from the document flow. Floating blocks alter the location of text, but do not interfere with other block level element features including: backgrounds, borders, margins, and padding.

Despite the floated elements, note how the second and fourth blocks still stack on top of each other. However, if the floated blocks had a width and the "column" becomes longer than the content situated next to it, we begin down the journey of unwanted results.

While beginners are quick to pick up the importance of float, they often overlook float's kryptonite: clear. The clear property causes blocks to not sit next to floated blocks. If we apply clear: left; to the second and fourth blocks in the previous example we get the following results:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Vivamus cursus iaculis ante

Vivamus cursus iaculis ante. In id nisl quis tellus suscipit venenatis. Suspendisse potenti.

Notice the nice stacking! The clear canceled the effects of floating.

A containing div

What is not obvious from the previous examples is that since floating blocks and positioning blocks absolutely remove those blocks from the document flow, they do not alter the height of a container. This is probably the source of the third problem. Below is an example of the default behavior of two divs towards a containing div:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

By default the containing green border wraps both of the two inner divs. This is usually what the developer expects to happen. However, like always this changes when the document flow is altered. Consider the two divs with float: left; width: 25%;:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Here, notice that the green border does not wrap the two inner divs (if they do, get a better browser). This is the quintessential Containing Floats problem. One that has a number of solutions, even one that I published here about using :after pseudo-class to clear floats.

Altering width doesn't change block behavior

Finally, as sort of an after-thought, altering the width alone does nothing to change a block's behavior. Above we saw how adding float: left; to a block made subsequent blocks align along side it. One common trap for starting developer's is their belief that simply by making a block's width less than 100%, things should line up next to them.

There is, admittedly, some logic to this thought process. However, notice what happens when the first block is given a width of 25% without a float:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

The second block, no matter what still attempts to consume all the available horizontal space. We can fix that by adding width: 25% to the second block:

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Even though their widths are less than 100% (by alot mind you), they still do not site next to each other. The problem is that we've forgotten a block's default behavior. Since a block's default behavior is to stack we need to alter it. As above, this is most often achieved using the float property.

In conclusion

Remember that blocks stack. You knew it before you read this, and you should definitely understand it now. Getting page elements to flow with changes shouldn't be a problem anymore.

Using multiple pseudo-classes in one selector

2004-08-18T12:33:00.000-07:00

So just for fun, I wanted to see if I could make Table Ruler style effects using only the :hover pseudo-class. Of course, that was pretty simple. I could get most anything I wanted done just using: tr:hover { }.

Quickly I realized that I could have more fun. What if I wanted to differentiate not only the row, but the cell. And this was born:

Hover over these rows and table cells
Column 1	Column 2	Column 3
Lorem ipsum dolor sit amet, consectetuer adipiscing elit	Vivamus cursus iaculis ante.	Etiam mi nulla, porttitor vitae, euismod in, pharetra in
Lorem ipsum dolor sit amet, consectetuer adipiscing elit	Vivamus cursus iaculis ante.	Etiam mi nulla, porttitor vitae, euismod in, pharetra in
Lorem ipsum dolor sit amet, consectetuer adipiscing elit	Vivamus cursus iaculis ante.	Etiam mi nulla, porttitor vitae, euismod in, pharetra in

The CSS, again, is very simple:

<style type="text/css">
	table { border: 1px solid #000; width: 75%; }
	tr td { border: 1px solid #000; padding: .5em; }
	tr:hover { background-color: #eee; }
	tr:hover td { border-color: #900; } 
	tr:hover td:hover { background-color:  #ffcc00; }
</style>

I'm pretty sure that it has been along time since anything I've tried to do in CSS was difficult.

Using single quotes for nested tags

2004-08-18T12:18:00.000-07:00

Here's a short bit of CSS that fixes the double-quoting problem in Mozilla/FireFox when you use a quote tag within another quote tag:

<style type="text/css">
		q q:before { content: "'";	}	
		q q:after {	content: "'";	}
</style>

The above will result in this: There are two quotes, and this one is nested

Update!

It's been pointed out that you can achieve much the same effect using the CSS Quote Property. Now that's one that I haven't used much!

Per-site userContent.css to kill Google's ads!

2004-08-13T13:11:00.000-07:00

So you want to get rid of the sponsored links on the results page of Google.com? "Yes," you say? Well here's the easy way. First, install the URI ID extension for FireFox. Then, use the following line of code in your userContent.css:

/* this kills the top bar
     	 - no "related news" though either */
#www-google-com p.e
     { display: none !important; }

/* kills the right sponsored links */
#www-google-com table[align=right] 
     { display: none !important; }

You should no longer see the ads!

My own FireFox userContent.css tweaks

2004-08-13T10:46:00.000-07:00

Following the lead of Hick's tweaking FireFox, I've added a couple of my own from my userContent.css:

/* just plain annoying things */
marquee { display: none !important; }
blink { text-decoration: none !important; }

/* add an e-mail icon to mailto: links */
a[href^=”mailto:”] { 
      background: url(mail.gif) no-repeat top left !important; 
      padding-left: 20px !important; 
}
/* alternatively, I've used 
   text-decoration: overline; for e-mail */

/* always have an underline */
a:hover { text-decoration: underline !important; }

I also included these in Hick's comments.

More color goodies

2004-08-13T06:41:00.000-07:00

This is just for future reference, but EasyRGB is a very cool color tool to have you your list of must-have bookmarks.

New Lipsum Generator

2004-08-13T06:38:00.000-07:00

This Lipsum generator is very cool, Lorem Ipsum. In addition to standard lipsum, they've included Esperanto and Volapük. Very cool.

Why SEO is pointless

2004-08-13T06:27:00.000-07:00

It never ceases to amaze that people ask about SEO. For some reason, to them, it's a big mystery why their pages don't make the top ten pages for search like: "video games" or "construction" or "hot blonde girl sex". Seriously.

Rather than do my own long, under-researched explanation, I'll point you to Derek K. Miller's, Boosting your search ranking: it's no trick.

The reason other sites might return higher ranks than you are is that they are very popular, and if you have just redesigned your site, it contains much new information that hasn't yet propagated everywhere. In essence, Google is a reputation machine—the rank of a site is determined by how many others link to it, and by how many link to those sites, and so on. When information about you appears on the sites of major newspapers or well-known webloggers, for example, their pages may outrank you until those news items get old, and it's possible that may always be the case.

If you're concerned about your ranking, read the whole thing. Otherwise, do the simple thing: create good content, good enough content that others link to you, and save your money.

Including script files from script

2004-08-12T13:29:00.000-07:00

This short piece of code shows how to use Javascript to properly include javascript source files into code without having to hard code EACH script tag into your HTML. We use this technique rather than trying to do insane things with writeln() which will no doubt cause problems.

The first part is simple, include the base javascript which includes the writes into the head of your document:

<script type="text/javascript" src="js/library.js"></script>

Any files that belong to your JavaScript application should be loaded through this libary.js file.

The library.js file

The library.js file is a bit more complicated. The methods that we use are DOM methods. That means that this technique will not degrade into old browsers. However, if you're writing complicated JavaScript applications, you probably should avoid support for those browsers.

So, the first thing we want to do is make sure that the browser supports DOM methods. So the first line of library.js is a conditional:

if (document.getElementById) {
	// the majority of the libary.js code goes here
} else {
	// add some non-support code if necessary
}

Since the full DOM might not be created yet, we should note that we will need to load these scripts using a function at the body's onload. That entails two things for our code:

We need to create a function
We need to add that function onload

So, the first part is easy, we create a function as the second line of our code:

if (document.getElementById) {
	function loadLibrary(e) {
		// the contents are discussed below
	}
} else {
	// add some non-support code if necessary
}

We can add loadLibrary to the onload in two ways. The simple way is to set window.onload equal to the function. The slightly better method is to use Phrogz's attachEvent() function. Using the simple method has a number of problems, namely that you overwrite any other onload functions in the process. However, for simplicity sake, let's use it:

if (document.getElementById) {
	function loadLibrary(e) {
		// the contents are discussed below
	}
	
	// add the loadLibrary function to the onload
	window.onload = loadLibrary;
	
} else {
	// add some non-support code if necessary
}

Adding <script> elements with DOM

If we left the code as it is now, it would do almost nothing. We still need to add the script elements to the page. To do this, we need to know a couple things. First of all, the code below relies on a <head> element to be present in your document. Since all good code has a head, this should be trivial. Second, we need to know how DOM's create element works.

When using DOM, every document has a method called "createElement" which takes a name. In this case, the name we're using is "script". For every script that our JavaScript application uses, we need a NEW element created.

Also, every script element has two properties we need to set: type and src. These are the same attributes that you need when you hard code the <script> tags into HTML code.

So, with that, the code is simple:

if (document.getElementById) {
	function loadLibrary(e) {
		// these are just shortcut variables:
		var d = document;
		
		// save time by not having to type 'text/javascript' in the loop
		var t = 'text/javascript';
		
		// just so that we don't have to write /javascript/ all over
		var l = '/javascript/';	
		
		/* 	get the head of the document:
			gTBTN returns an array, and we only need
			the first one (and there SHOULD only be one	*/
		head = document.getElementsByTagName('head')[0];
		
		/* 	you can loop over the following section for
			as many scripts as you require: 			*/
		e = d.createElement('script');	// create a script element
		e.type = t;	// set the type of the script
		e.src = l + '1.js';	// point the script tag at your js file
		head.appendChild(e);
		/* 	end creating an element,
			close the loop 			*/
		

	}
	
	// add the loadLibrary function to the onload
	window.onload = loadLibrary;
	
} else {
	// add some non-support code if necessary
}

That's it! No more. Though, one last note, if you document calls javascript functions which are created in the files included by libary.js, you might want to make alternatives for browsers that don't support DOM. If you don't those browsers may throw errors about functions not being defined.

Laughable: "It's a business site, I can't use CSS"

2004-08-12T09:15:00.000-07:00

That was the quote of the day in #css on EFNET. If anything, that is just the opposite of the case. Business, far and away have more reasons to consider CSS than some crappy personal site (not all personal sites are crappy, but most are).

The first concern is almost entirely aesthetic. The comment usually goes, "my client wants it to look the same in all browsers." I'm sorry, but what a load of crap. What your client is trying to say is that, "in browsers that most people use, it should look good." Of course it should look good. As a web designer, if you handed a text-only, unstyled demonstration to your client, they'd walk out the door.

What is less obvious about the client's request is that "all browsers" sure as heck is more encompassing than they realize. Realizing that table designs suck on pdas, cellphones, internet appliance, text browsers, and anything older than 4-5.0 browsers is something they're not accustomed to thinking about. That's your job.

I'll assume for a minute that not everyone is so articulate that they could make the slam-dunk argument from aesthetics alone. There are pocketbook reasons why businesses should care.

First, up front design costs are trivial compared to the ongoing cost of maintaining a good site. Most savvy organizations and businesses know that from experience. Their experience might not come from the web, in particular, but from other software vendors. It's never the initial purchase that hurts, it's the ongoing maintenance costs (in software it's usually about 20% of the initial cost).

Maintaining, upgrading or updating a web site is no trivial task with a table design. The complexity of the code often prevents a client from maintaining their own work, which is really nothing but job security for web developers. Furthermore, upon redesign or upgrade, it often means starting from scratch. This is not 10-50% maintenance cost, it's 100% of the original.

Second, unlike most personal sites, businesses are interested in conveying as much information to as many people, as quickly as possible, and for as little as possible. Let's imagine that about 1/10 people have an impairment that makes using the web very difficult. A table layout is almost inherently inaccessible, or even where the developer has taken care to meet the requirements, the layout may be difficult to navigate without the visual cues. As such, that's potentially 10% of the market the you've foreclosed on simply because.

The accessibility issue plays on the lawsuitaphobia of many organizations and corporations. Fear that someone, somewhere might file a discrimination suit will probably scare the bajeezus out of many bosses. This argument is probably better made in larger corporations with higher exposure.

Third, while the initial design might incorporate the original content, inevitably, the content will grow with time. With each new file, presentation is replicated and pushed back to the server. Over time, this increases the bandwidth requirements and server requirements mulitudes faster than separating the content and presentation initially. Here again, the maintenance issue rears its head too. When the new documents are created, they're often embedded in the templates, extracting that content later is time consuming and costly.

Finally, since corporations and organiations, unlike personal sites, are usually looking to invest into the future and are in the game for the longer haul, higher initial up front costs are quickly out-weighed by the countervailing requirements of the future.

Skip Navigation - Quick Tip to help UCR

2004-08-12T07:36:00.000-07:00

One of the first problems that people discover when viewing their beautiful, well-structured webpage without styles is that the important areas might be buried BELOW other page elements, like navigation.

One frequent solution is called skip navigation. Skip navigation are in page links, or links to fragments, which jump a reader to the content they're searching for. This is usually not so important for styled pages because the eye can quickly find the important sections of well-designed visual sites more quickly than the user can read the words "skip to content".

On the other hand, a page in all text with only font-size variations can take much longer to find the information the user is looking for. Enter, stage right, skip navigation. Most people have probably never seen skip navigation. And even fewer developers have even considered it.

Skip navigation are usually one to three links at the top of code. It's usually placed directly above or below the header and links to: content, page navigation, and some other important element of the page. In code it often looks like this:

<ul id="skip-navigation">
<li><a href="#content">Skip to content</a></li>
<li><a href="#navigation">Skip to navigation</a></li>
</ul>

Since most users don't need nor want to see the skip navigation, we simply add the following to our stylesheet:

#skip-navigation { display: none; }

This, for all intents and purposes, hides the skip navigation to users who are using styles.

To use this trick there are a couple requirements. The first is that you have two structural elements with ids "navigation" and "content". You no longer need to use the <a name="content"> since this is the old, pre-id technique. URI fragments will jump to a page's id. This is another reason to use ids in structural markup instead of classes. This also means that your skip navigation can include other important parts of your page, like "copyright" or "search".

That's all there is to it.

Structuring your pages: Part Ia

2004-08-12T06:58:00.000-07:00

Previously, in Structuring your pages Part I, I took you through the mental processes that go into structuring the underlying markup. What has since been pointed out to me is that I only touched on some of the "other" structural considerations.

The one primarily emphasized in the previous article is probably the most common: tradition structural demands. That is, typically, in print and on the web, there are common structural elements: headers, footers, content blocks, navigation bars or sidebars, etc. These can logically group the content contained within. Moreover, each of these elements have some meaningful and often logical relationship to their placement in code.

There are several other structural considerations, which I merely brushed on:

Design considerations
Search engine optimization
Unstyled content readability
Design flexibility
Sub-structural elements

"Design considerations" might seem an odd one considering since the goal is largely one of separation of content and presentation. However, I think everyone needs to remember that CSS based designs are not 100% separation, it is simply a step in the right direction. Much further, of course, than tabular designs, but still require a great deal of embedded design. The whole idea of embedding structure into you content, in fact, is somewhat a step away from content-presentation separation.

In fact there are two components to structural layout that bare on design elements: amount and placement of elements. It almost goes without saying that with a minimalist structural markup philosophy, you're never going to achieve complex designs. This goes to the "design flexibility" point as well.

If your goal is the epitome of flexible layouts, ultra-skinnability, come CSS Zen Garden, then you're necessarily going to want more structural elements which in turn can be styled to a designer's needs. This flexible layouts also bears on the types of containers a content producer might use in content markup (Part II of this discussion).

"Search engine optimization" was briefly discussed with the placement of the navigation element. While SEO might bear more on content markup, it should also be reflected in your structure as well. Consider the obvious question: "should I place my header at the top or the bottom?" It seems quite silly for a number of reasons, but there are lots of good reasons to place the header at the top. For SEO the most obvious reason is that it probably contains the most important elements of the entire site's importance: your title. Burying your title at the bottom means it's last in terms of the page's importance. That's simple information theory.

Burying your title also bears on the "unstyled content readability." While CSS can place your header visually at the top, if you wanted to, there would be no control of how the page is viewed without styles. Searchbots, those little things that go around an index your sites, view pages without styles. So do many accessible browsers. And so do many people with visual impairements.

UCR also means that if your repetitive navigation appears above the content, someone without styles turned on has to skip over, or read over, all the navigation every time they want to read your content. There are a number of solutions, including skip navigation, but it is something to consider when structuring your page.

Another obvious consideration are sub-structural elements. I have largely outlined structural elements that might be best classified as "super structure" elements. Or, in continuing the skeletal analogy, what might be consider the "skull" and "spinal cord" of the human skeleton. However, even the human skeleton has specialized bones for particular super structures. This might be akin to grouping I discussed at the end of part I in the "more structural elements" section. However, I think you can make the argument that this concept of grouping can be taken one step further.

Imagine that the content section, within the normal content, might have a section dedicated for "news". The news section could contain a header declaring the section name. In addition each news story might have a sub header for the title and by-line, a paragraph long description, and a list which might include publication date and other information. Every story and the declaring header should probably be grouped within a structural element.

What seems very obvious about sub-structural elements is that they need not appear on every page, but it is still a structural consideration.

I am also fairly certain that no discussion could bring together a comprehensive list of every structural consideration. However, you should be able to see that with every splintering, from super-structural to the ones mentioned above, the value of the consideration exponentially decreases.

Using :after to clear floats

2004-08-11T11:33:00.000-07:00

The example block below demonstrates how to use the :after pseudo-class to clear all floating elements in a block. In this example, the middle block (in this case a <p>) has a :after which will create another block and have it clear.

This is the left floating div

This is the right floating div

I'm normal content within the .p div

The code is pretty straight-forward

<style type="text/css">
.container p { margin: 0; border: 1px solid #ffff00; }

/* this is the middle element */
.container p:after {
display: block;
content: "I want this to clear";
	border: 1px solid #900;
	float: left;
	clear: both;
}
.container {
	border: 1px solid #0f0;
	width: 80%;
margin: 0 auto;
}
		
.left {
	float: left; width: 5em;
	border: 1px solid #789;
}
.right {
	float: right; width: 5em;
	border: 1px solid #aca;
}
</style>
<!-- skip to you body -->
<div class="container">
<div class="left">
This div floats to the left
</div>
<div class="right">This is the right floating div</div>
<p>I'm normal content within the container div</p>
</div>

There are a few things to notice, first, the clearing block is applied not to the container, but rather the middle block. The middle block is denoted with a bright yellow border. The reason that this works is because the :after pseudo-class is still contained within the creating block. In the above example, the clearing block is denoted with a red border. Note: In IE you will not see the red bordered element at all.

Since the height of an in-the-flow block is stretched beyond the height of the floating elements, its container will grow as well. The container, in this example, has a green border.

IE does it wrong anyway

IE does this wrong anyway, so there is no containing floats issues with IE. And since IE ignores the :after pseudo-class, nothin is lost!

The only difference IE will show is that the yellow bordered inner-block will not stretch around all elements

The gotcha

In order for this to work in a layout, you need the content to probably be empty. No problem. Use the following CSS instead:

<style type="text/css">
	.container p:after { 
		display: block;
		clear: both;
		content: " ";
		height: 0;
		overflow: hidden;
	}
</style>

Using the above, the results look like this:

This is the floating div This is the floating div This is the floating div This is the floating div

This is the floating div

I'm normal content within the container div

It's magic! No red bordered element, no content, no gaps.

Thanks to Phrogz for the inspiration.

Labels the forgotten HTML Form Tag

2004-08-11T11:24:00.000-07:00

Even on big commercial sites, there's still almost no use of the label tag. I largely attribute this to the fact that most developers don't even think about them, or have never even heard of them. On the other hand, many application developers have certainly thought about how exactly to achieve some of the effects that are implicit with label tags.

As such, I feel it's my duty to get more people to start using them.

Using the <label> tag

The label tag is just another form element. The standard explanation of the label element is that a label associate text to an input field in code and markup, rather than just visually. As awkward and difficult as that might be to understand, it is in fact, a very simple tag to use:

Wrap the text you want to associate with <label></label>
Add an id attribute to the appropriate form field
Add the for attribute to the label tag with the id of the corresponding input field.
File → Save!

Simple enough, here's an example (just a simple one):

<form action="#" >
	<label for="first-name">First name: </label>
	<input type="text" name="firstname" id="first-name" />
</form>

The above code will look like this:

Before moving on, there are a couple things to note. First, by definition, you do not need to be explicit with your label (ie. use the for attribute and the id attribute), if you wrap the input and the text within the label. However, IE doesn't extend all the benefits of using a label if you choose that method.

Second, since the label uniquely identifies a form field and since the value of id must be unique, you may find yourself having problems with radio buttons and checkmarks. However, form get/post operations use the name field and not the id field. As such we can do something like this:

<form action="#" >
	<p><input type="checkbox" name="hobby" id="reading" />
	<label for="reading">reading: </label><p>
	
	<p><input type="checkbox" name="hobby" id="writing" />

	<label for="writing">writing: </label></;/p>
	
	<p><input type="checkbox" name="hobby" id="skiing" />
	<label for="skiing">skiing: </label></p>
</form>

That code will render like this:

Third, some inputs have implied labels. Those fields require no additional information and they include: buttons, submit buttons, and reset buttons. As such, there's no need to do any additional work, unless you want to.

Why, as web developers, we should care about the label tag

The problem as I see it, is that most people don't care about associating the text with the input in code, and would rather save the bytes and keystrokes. In fact, most developers just assume that a visual connection between an input field and describing text is sufficient. In general, that's probably true.

However, There are really three main reasons why we should care:

Accessibility
Usability
And label creates one more semantic container

Accessibility

508 Standards, Section 1194.22 Rule 1.1.2 says that "all input elements are required to contain the alt attribute or use a LABEL".

Simply stated, "you can't just have an input field without more associated information." And since, as lazy developers, we don't want to do more work than we have to, and since we presumably are already typing text to describe the form field visually, why not just use the label tag? How's that for a run-on sentence?

The accessibility requirement, for some, is probably sufficient enough reason, however, that largely doesn't appeal to most people. The next reason might.

Usability

Clickability!

Ever notice how little radio buttons and checkboxes are? Ever get frustrated by the fact that you have to move your mouse into a little 5px by 5px box in order to make it function correctly? Ever want to just wish you could just click the corresponding text? Ever write a Javascript to do that?

Well, one of the nicest things about the <label> tag in modern browsers is that the associated text is connected to the input and by clicking the text you either cause the checkbox/radio button to become marked or the focus is set to the input field.

Scroll back up to the examples. Click the text. In the checkboxes, you'll notice that the checks are set and unset when clicking the text. For the text field focus is set.

Using styles, it's possible to visually clue the user into the clickability:

<style type="text/css">
	label { cursor: pointer; }	
</style>

By doing that, the user will get a hand every time they mouse over the label text. They might be more apt to click the text and thus learn for future use.

Access keys

This is a bit more controversial, read Using Accesskeys, but it's understandable the there may be a good enough reason to use them. Accesskeys are simple key commands, although they vary widely by OS and browser, which allow the end-user to immediately reach a particular area, or in this case, an input.

None of the above examples use the accesskey attribute, however it's as simple as adding: accesskey="f". That will allow the user to do something like: alt-f (notice the possible conflict with the file menu) to reach the associated input field.

Like the label suggestion above, it might be possible to use CSS to set off the accesskey in a couple ways. First, if the first letter of the label is always the accesskey, you could use:

<style type="text/css">
	label:first-letter { color: #900; font-weight: bold; }	
</style>

Or, if you'd prefer, you could use some other tag, like span, to surround the particular character which would act as your accesskey:

<style type="text/css">
	label span{ color: #900; font-weight: bold; }	
</style>

On this point, the decision is left to the developer. For complex forms with more than a few fields, it doesn't make much sense. On the other hand, imagine the possibility for the search field or the login field.

One more container!

Perhaps the single most advantageous reason to use the label tag, as a developer, is that it gives you that illusive, extra, semantic container that there never seem to be enough of. That is, instead of adding spans, divs, tds, or ps, we can instead rely on the label to provide us another element with which to style.

The most obvious example of this is the CSS Side by Side form. Using the label tag, we can create the two column tabular look without tables by making the label float.

We can also use the label to supply help information and necessary context. For example, if we want to designate a particular as required we could do the following, using CSS:

<style type="text/css">
	label.required { color: #900; font-weight: bold; }	
</style>
...
<form action="#" >
	<label for="first-name" class="required">First name: </label>
	<input type="text" name="firstname" id="first-name" />

</form>

More creatively, we can also use the label to provide more insight into an input field, in a tooltip like option. Like any element, the label tag can use the title attribute. Thus, when the user is hovering over the label tag, the little tooltip box shows up. In the Clickability! section, I mentioned that we can make the cursor a hand so that it looks clickable, but what if we expanded that idea. For example, using a bit of javascript to provide more insight:

<form action="#" >
	<!-- the &#10; inserts returns in the javascript too -->

	<label for="first-name" 
		title="This field is required!&#10;
		Your first name is the first part of your given name.&#10;
		For example: John, Laura, or Jane." 
		class="required" onclick="alert(this.title);">
			First name: 
		</label>
	<input type="text" name="firstname" id="first-name" />
</form>

Now, this is not an ideal solution, but you could easily have javascript render a helpful box next to the input box that shows that helpful information. The above example looks and works like this:

It's not a terrible idea, and for some users, it's probably better than nothing.

In conclusion

Even if none of the above makes any sense to you, you should probably still use it. By default, it doesn't have any style characteristics and thus will not change your design. In addition, the time it takes to add a label tag is nominal, and if you use it under the one more container theory, you're probably reducing the amount of meaningless code you have on your page.

Now start coding!

Structuring your pages: Part I

2004-08-11T10:45:00.000-07:00

One of the precursors to any website redesign bent on using Web Standards is asking, then answering, the question: "how should I structure my page?" Structure, in the sense discussed here, is how content is represented in HTML code. This discussion does not include structuring anything outside the body tag, rather it will focus on the structure of a page's content and the page's content containers.

The structure of the code between the body tags is generally represented in code by two concepts: structural markup and content markup.

Structural markup can be thought of as the skeletal framework of any HTML code. It has no real meaning except to divide the page up into logical sections in which content markup can be added. I used the word divide on purpose. Since structural markup is meant to represent essentially meaningless, but organizational, divisions, it is customary to use a <div> tag. We will discuss the considerations of marking up every structural block below.

The second type of markup is content markup. Content markup are the semantic containers in which a page's content resides. As it turns out, most content falls into three categories of elements: headings, lists or paragraphs. These elements are usually represented in code with tags like: ul, ol, li, dl, dt, dd, h1, h2, h3, h4, h5, h6, and p. Unlike the structural markup, these tags have real meaning and their use represents something both in code, to a machine, and to human looking at the code. As a note, just about anything can be content markup. In some sense, even the structural markups are a type of content markup, and there will inevitably be times when generic containers built from div tags would fall under this category.

In each case, there is a mental process and a set of decisions to be made during the process. Some are trivial; others are not. In this section, we will first look at structural markup. In a later post, we will examine content markup.

Structural

Structural markup seems to be the toughest concept for new developers to understand. In part, I blame this on the fact that never before have table-jockeys had to even consider this concept in the abstract. Rather they created a series of table cells and placed their content within the appropriate table cell. Nevertheless, those table cells are probably the primordial ooze from which to begin thinking about how a page is going to be structured.

A general case can be made that most webpages have at a very minimum a header, a content and a footer section. In tables, these might well be three table-rows and three table cells. Conceptually, this would put the header on top, the content in the middle and the footer on the bottom. Indeed, the table structure would also, in most cases, dump to the screen exactly like this. For example:

<table>
	<tr><td>Hi! This is my header</td></tr>
	<tr><td>This is where I'd put all my content!</td></tr>
	<tr><td>I'd probably have a copyright, and footer information down here.</td></tr>
</table>

As always, this type of table-think is dangerous. While in the simple case, this might work, it will nevertheless lock a developer into a particular design concept. What happens when you add navigation? Two navigations? What if you want to switch the order of the navigation and the content? In every case, you begin to complicate what started off as a simple, short table.

The tabular layout is also wasteful. Notice that to simply get the stacking effect we needed a wrapping table tag, three rows, and three cells. It would seem that at least three, if not four, of those elements are unnecessary.

Instead, let's think about what is really being said in when developers layed out that table. The mental process probably went like this:

Hmmm... I need a page
I know I want my logo and stuff at the top
I have some copyright information that goes at the bottom
And all my pages will have some content that will be different.
I'll also want to have some navigation

As I noted above, this discussion is only dealing with the stuff between the body tags. As such, the creation of a body tag gives us the first step: "I need a page." In table-think, it would be the combination of <body> and <table> that would fulfill this first step. We'll see in a bit, that for the sake of "more containers" we may add another element here, but for now, let's not.

Deciphering the mental process

The second step, "I need stuff at the top", begins the more difficult work. "I need stuff at the top" isn't much help, until you translate the "need" into something more elaborate as "I need a special section [division] to add the important branding information at the top of the page." There are three components to this step: the elemental, the division, and the visual/logical placement.

What the mental process in the second step is telling us is that the developer already has is a concept about what he needs (a discussion of elemental markup), where it needs to go (a pseudo-CSS discussion), and that this is somehow distinct from other parts of the page (the structural discussion). In the instant gratification world, most table-thinkers skip right to the elemental and layout discussion. However, this skips perhaps the most important step: the first step in our structural plan.

The header

In the publishing world, this logical division is called masthead or in simple terms the "header". Aside from what the developer thinks is appropriate content for the "header", we need no further information to build our first structural element, we'll call it "header":

<div id="header">
<!-- I will put all the stuff for my header:
	logo, slogan, etc between these tags -->
</div>

There are a couple things happening in this small piece of code. First, the <div> tag becomes a container for anything that the developer feels belongs in the header. We need nothing more than these two itty-bitty tags (one open and one close). Second, we have identified the header using the id attribute.

Using ids vs. classes

Allow me to digress for a moment. A common question is raised about when to use an id and when to use a class. While there is no hard and fast rule because they can function the same way, I tend to think of ids as special cases of classes where I can guarantee the uniqueness. Since High-level structural elements are almost certainly unique and as such they are best described as a class. Since a page probably should not have more than one header, using an id makes some sense. In addition, we can logically directly address ids in both script and CSS with little concern that there will be more than one of them.

What are block level elements?

A <div> tag, by itself does nothing. It is a generic block level element. Block level elements, by default, are elements which force a line break on open and on close. Block level elements, by default, consume the entire available horizontal space. By default, they consume only as much vertical space as necessary. In addition, block level elements stack on top of each other. They can also contain other block level elements and other inline elements. In addition, they are supposed to apply padding, margins and borders according to the traditional box model. All of these are the default behaviors of a <div>. Nonetheless, these behaviors can be altered by CSS.

Knowing this, though, we can now think about where this container (note: I will use block, element and container synonymously) in code. Which leads us to another part of the ideas in the mental process: placement.

Conceptually, logically and perhaps visually the header belongs first. The first two are satisfied simply by placing the code first: ie. right below the <body> tag:

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
</body>

Also, knowing the default behavior of a block level elements, placing the header block first in code will also mean that it will display at the top of the page. Though there are a few things to note. First, the default behavior of the body is to have some margin and padding. If you expect your header to be flush against the viewport (the rendering part of the browser), then you need to turn of the margins and/or padding in the stylesheet: body { margin: 0; padding: 0; }. Second, no matter what you inside the header block, by default, everything subsequent to header will stack. If you start changing the default behavior, ie. using position: absolute; or float: left;, you may change how subsequent elements interact with this block. For example, floating blocks within the header, may cause the header to not contain those elements. All of this discussion are problems innate to CSS, not to the structure, though.

The stacking behavior, though, is the behavior most developers expect, and it is an important default behavior to remember. Knowing this alleviates the "how do I get my header and footer to be on top of and below my content, respectively" questions.

With this in mind, we are finished discussing the header, and will make understanding the footer and content blocks easier. Oops, I've given away parts of the subsequent mental process. You'll find that once you're familiar with structuring one part, each additional part becomes easier.

The third is a common requirement for a more or less static footer, "I have some copyright information that goes at the bottom". This can be translated as, "That legal mumbo-jumbo needs to be below my other stuff." Using the methodology from above we know a few things:

We need a container
This is probably unique and we can give it an id
We don't need to worry about the content yet
This is, for now, conceptually, logically, and visually last
By default, blocks will stack, we don't need anything more

With this in mind, we can make our container. Almost universally, the bottom of a page is called a "footer". As such, we'll name it to match. Again, there are probably not two footers and thus we can use an id.

<div id="footer">
<!-- I will put all the stuff for my footer:
	copyright, contact info, etc -->
</div>

Since we know that the blocks will stack and that this is conceptually last, we can add the block to our code:

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
	<div id="footer">
	<!-- I will put all the stuff for my footer:
		copyright, contact info, etc -->
	</div>
</body>

If we were to fill in some dummy content, for header and footer, we would see that they're exactly how we had imagined them. The divs do not change much about the output. They do, however, in code, logically group the content within the containers. Since they're grouped using ids, we can manipulate individual elements' style in CSS using the following format: #header h1 { ... } and #footer p { } which will apply styling specifically for that container.

We can now add the content block.

The content block

The content block is no different than the header or the footer. The content block, however, is the block that usually contains all the "content" (imagine that) that a end user is looking for. In mental process three, we said, "And all my pages will have some content that will be different." Here there is no explicit reference to a container, but one can be inferred.

In theory, you don't need any containers for anything. You can develop a perfectly legitimate page without ever marking up the structure. However, when it comes for us to code or differentiate parts of content, if we do not have the containers, we fall back on classing every element on a page. For example, if we place a <h1> in our header and our content has an <h1> as well, if we didn't have the containers how could we differentiate the two? You could do <h1 class="header"> and <h1 class="content">, but that's ugly and inefficient. You'd very quickly realize that every element had to have a class.

So as we think about the content section, we can see that two things are possible. First, we could just simply allow the developer to add the new content between the header and footer sections, or, second, we can add another block.

Here in lies one of the more difficult decisions: to block or not to block. The decision is a both a design issue and a practical issue.

Practically speaking, adding more divs increases overhead, a little, and increases the code's complexity, a little. However, it also increases your specificity, provides more elements upon which to apply styles, and may ultimately improve readability and maintenance. On the other hand, embedding too many divs into your code can lead to the polar opposite.

As a compromise, I personally always try to wrap related content, at least one time. In this case, while our content could potentially go without any container doing so might potentially allow hundreds of content elements which should be related to not be. As such, we'll create a block called "content."

<div id="content">
<!-- This is where the content for
	a page will be entered -->
</div>

From our previous rules, we know that this block will be between header and footer.

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
	<div id="content">
	<!-- This is where the content for
		a page will be entered -->
	</div>
	<div id="footer">
	<!-- I will put all the stuff for my footer:
		copyright, contact info, etc -->
	</div>
</body>

With only three tags we have done much the same as the table whilst providing infinitely more specificity and flexibility. However, we haven't yet completed our fifth requirement. As we mentioned before adding navigation to the tabular layout meant knowing something more about the design and would further complicate the simple table. Using the structure we've created, and knowing nothing about the ultimate layout, we can add a container for navigation very quickly. So quickly in fact, that it doesn't get it's own section.

Though, before we add navigation, we need to consider one more thing. Our business rules say nothing about where the navigation should go relative to the content. That is, we know that navigation belongs between header and footer, but beyond that we're offered no additional help. Furthermore, we have not considered any design issues left/right/top/bottom in our structure, so we cannot look to this for guidance. What we do know is that search engines rank content by order in code. The nearer the top the better the content (top-down precedence), or at least so the theory goes. We also know our navigation is probably repetitive, but still necessary. However, it is the "content" on the page that is the most important. As such we probably want the navigation below content. We also know that our footer is last, that was another design requirement.

With that in mind, we can add navigation:

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
	<div id="content">
	<!-- This is where the content for
		a page will be entered -->
	</div>
	<div id="navigation">
	<!-- This is where my navigation links
		will be -->
	</div>
	<div id="footer">
	<!-- I will put all the stuff for my footer:
		copyright, contact info, etc -->
	</div>
</body>

In a typical tabular layout, with navigation on the left and content on the right, the navigation would probably be ahead of the content in code. In addition, a tabular layout requires us to move code around if we were to want to move navigation to the other side.

More structural elements?

Looking at our code above, it is conceivable to find several more logical groupings. The most obvious is a grouping around content and navigation. Why? Simple, header and footer have hard and fast rules about location: top and bottom, respectively. Everything else, in this case content and navigation, is between those two. There seems to be a relationship of "everything else" there. Whether or not this particular grouping is good or not might also affect how flexible a design could or could not be (ie. relatively positioning navigation, etc).

Another possible grouping would be a div containing all the blocks. This would be strictly a shortcut for some design features that reflected how all the containers were handled (ie. max width and horizontally centered blocks).

Conclusion

Structural markup is conceptually very simple. So simple, that once you've found a structure that you like, most subsequent designs will follow almost exactly the same structure. The key to figuring out an appropriate structure is figuring out your page's content needs and asking the sometimes difficult business questions.

Making a CSS highlighter

2004-08-09T07:57:00.000-07:00

In law school I find myself highlighting a great deal in text. Unlike some of my fellow students, I try to only highlight the important stuff. Which got me to thinking, wouldn't it be nice if there were some CSS equivalent to the highlighter?

It doesn't take long to realize that there are two elements that would work well for this purpose: <em> and <strong>. Both are emphasis elements, much like how we assume highlighters work, and both can be easily styled.

So that this isn't entirely obvious, let's make highlighters of three colors: yellow, blue and pink. Each color will represent a different part of the text. For example, the thesis, the conclusion and some vocabulary word.

First, we need to mark up our text appropriately, denoting which areas of content are to be highlighted:


<p><strong>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</strong> Duis sed diam. Vestibulum convallis gravida ante. Integer a nisl. Suspendisse sit amet arcu. Phasellus blandit, elit nec ultrices rhoncus, augue pede facilisis urna, id vulputate neque pede id tortor. <strong>Vivamus at dui:</strong> In id sapien nec augue rutrum elementum. Phasellus eget sapien. Aliquam elementum orci in nisl. Nam imperdiet nulla eget neque. Phasellus nec eros at elit porttitor bibendum. Fusce augue elit, sagittis id, consequat id, tincidunt ut, diam. Nam porttitor. Donec elit. Nullam felis arcu, gravida ut, auctor et, ullamcorper sit amet, urna. <strong>Fusce diam enim, convallis non, molestie in, accumsan sit amet, purus. Vestibulum nunc. Sed dapibus.</strong></p>

In this example the first and last line need are the ones we want highlighted. We'll pretend that these are the thesis and conclusion sentences. In addition, we've highlighted a word that will be vocabulary. All three need seperate styles. So well have a "highlight" class as well as a "thesis", "conclusion" and "vocab" secondary class.

The code is simple:

<style type="text/css">
strong.highlight {
 /* note that this may cause the highlight to overlap */
padding: .1em;

/* overlap is possible with border too */
border: 1px solid #000; 

/* we want to override the default behavior */
font-weight: normal; 

}

strong.thesis {
/* bright yellow */
background-color: #ff0;
}
strong.conclusion {
/* pink */
background-color: #f6c;
}
strong.vocab {
/* blue */
background-color: #6cf;
}
</style>

To make this work, we can take the above code and just apply dual styles:

<p><strong class="highlight thesis">Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</strong> Duis sed diam. Vestibulum convallis gravida ante. Integer a nisl. Suspendisse sit amet arcu. Phasellus blandit, elit nec ultrices rhoncus, augue pede facilisis urna, id vulputate neque pede id tortor. <strong class="highlight vocab">Vivamus at dui:</strong> In id sapien nec augue rutrum elementum. Phasellus eget sapien. Aliquam elementum orci in nisl. Nam imperdiet nulla eget neque. Phasellus nec eros at elit porttitor bibendum. Fusce augue elit, sagittis id, consequat id, tincidunt ut, diam. Nam porttitor. Donec elit. Nullam felis arcu, gravida ut, auctor et, ullamcorper sit amet, urna. <strong class="highlight conclusion">Fusce diam enim, convallis non, molestie in, accumsan sit amet, purus. Vestibulum nunc. Sed dapibus.</strong></p>

The end result looks like this:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Duis sed diam. Vestibulum convallis gravida ante. Integer a nisl. Suspendisse sit amet arcu. Phasellus blandit, elit nec ultrices rhoncus, augue pede facilisis urna, id vulputate neque pede id tortor. Vivamus at dui: In id sapien nec augue rutrum elementum. Phasellus eget sapien. Aliquam elementum orci in nisl. Nam imperdiet nulla eget neque. Phasellus nec eros at elit porttitor bibendum. Fusce augue elit, sagittis id, consequat id, tincidunt ut, diam. Nam porttitor. Donec elit. Nullam felis arcu, gravida ut, auctor et, ullamcorper sit amet, urna. Fusce diam enim, convallis non, molestie in, accumsan sit amet, purus. Vestibulum nunc. Sed dapibus.

Using a repeatable image as a border

2004-08-09T07:45:00.000-07:00

I've done this example for people many times. The trick is simple, apply a repeatable image to a container block and then make the children have a solid background.

The following example uses <blockquote> as the container and <p> as it's children.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus pharetra, wisi fringilla posuere interdum, leo eros pellentesque eros, non venenatis tellus ligula ac neque. Phasellus pede. Nulla facilisi. Integer diam tortor, varius vitae, sodales sit amet, faucibus ut, odio. Curabitur quam sapien, rutrum sit amet, porta vel, dapibus ut, tortor. Phasellus a mi vel ipsum auctor dictum. Integer vel nunc.

Curabitur dolor. Mauris tempus. Ut purus tellus, cursus ac, aliquet at, tempor sed, metus. Vivamus tempus euismod sapien. Maecenas a urna. Morbi pellentesque. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Fusce consectetuer fermentum justo.

Like I said, the trick is very simple:

blockquote.image-border {
	background-image: url(image-border.gif);
	padding: .5em;
	margin: 1em;
}
blockquote.image-border p {
	margin: 0; padding: 0;
	background-color: #fff;
	padding: .25em;
}

Single GREATEST quote EVER

2004-08-04T12:23:00.000-07:00

I was reading Throwing tables out the window when I got to this:

IE interprets CSS more loosely than other browsers that have been iterating versions over the last couple years (Mozilla, Firefox, Safari, Opera…). Starting with IE means fewer problems with development work will be detected early on. Developing for IE initially, then trying to retrofit for other browsers will increase time and cost in the long run. But there’s a better way to approach development that’s faster and less costly.

Doesn't get much clearer than that.

Color picker of choice!

2004-07-28T09:34:00.000-07:00

Found my color picker of choice: Color scheme.

Consensus?

2004-07-28T04:31:00.000-07:00

Is there a consensus among the standards bigwigs? Find out for yourself.

Steal These Buttons

2004-07-28T04:29:00.000-07:00

I always manage to forget where to Steal these buttons.

Now I won't.

Ticked Off? Visited Links How-To

2004-06-01T11:58:00.000-07:00

The idea is simple, use background images of anchor tags to visually indicate the status of the link. This works better for lists of links than for inline links, check out: CollyLogic: Ticked Off

VisiBone Font Survey Results - Browsershare

2004-05-28T11:53:00.000-07:00

Good for future reference: VisiBone Font Survey Results

Multilevel Suckerfish dropdowns

2004-05-25T08:15:00.000-07:00

Just for reference, this page has a nice multi-level version of the suckerfish dropdown: Suckerfish Dropdowns - Perciformes!

Fun with Forms

2004-05-19T14:25:00.000-07:00

This piece has an interesting take on how to do forms: fun with forms.

So pretty!

Must bookmark: Developing With Web Standards

2004-05-19T13:14:00.000-07:00

I stumbled across this site while sitting in #css on EfNet. The page is a good overview of everything related to Developing With Web Standards.

This document explains how and why using web standards will let you build websites in a way that saves time and money for the developer and provides a better experience for the visit

Text sizing in ems

2004-05-19T06:38:00.000-07:00

I've frankly never encountered that many problems using the ems unit. I have people tell me that things were "too small," but that's usually because the user had their font settings set to "small" or "smaller". Silly people.

Regardless, this is one of the best explanations of how relative font-sizing works: How to size text using ems.

If the world were an ideal place, we’d all use pixels. But it’s not, we have the broken browser to contend with. IE/Win will not allow readers to resize text that has been sized in pixels. Like it or not, your readers will want to resize text at some point. Perhaps they are short-sighted, doing a presentation, using a ridiculously high resolution laptop or simply have tired eyes. So unless you know (not think) your audience won’t be using IE/Win or will never wish to resize their text then pixels are not yet a viable solution.

The page goes on to explain how to "start" with a particular fixed unit size (ie. px) by using percentages of the default value.

As a note, I'm not sure that I would ever make the body of a non-personal site start at 62.5% of the user's default.

Suckerfish Dropdowns

2004-05-19T06:24:00.000-07:00

I'm a huge fan of Suckerfish dropdowns. In general, they're very lightweight and easy to implement. So, of course, it didn't take long for there to be the "son of suckerfish".

The original Suckerfish Dropdowns article published in A List Apart proved to be a popular way of implementing lightweight, accessible CSS-based dropdown menus that accommodated Internet Explorer by mimicking the :hover pseudo-class.

Well now they're back and they're more accessible, even lighter in weight (just 12 lines of JavaScript), have greater compatibility (they now work in Opera and Safari without a hack in sight) and can have multiple-levels.

CSSing

Why I quit helping with 100% height questions

On width

Inline elements

The meaning of width...

10 CSS tips for the new

Do not worry about height: 100%

You don't need to position everything

Make sure that you're not fighting browser defaults

Validation doesn't mean correct

There is such a thing as too many divs

Tables are not evil

Work smarter, not harder with CSS

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

Start your CSS by working from the top down

Use Google™, first

Quick Centering

Fluid layouts using percentages is probably a bad idea

The em

Line-length is not different than any other user preference

Of Law and Accessibility

Update 1: Potential

Update 2: Accessible travel sites

Blocks by default STACK

Document flow

A containing div

Altering width doesn't change block behavior

In conclusion

Using multiple pseudo-classes in one selector

Using single quotes for nested tags

Update!

Per-site userContent.css to kill Google's ads!

My own FireFox userContent.css tweaks

More color goodies

New Lipsum Generator

Why SEO is pointless

Including script files from script

The library.js file

Adding <script> elements with DOM

Laughable: "It's a business site, I can't use CSS"

Skip Navigation - Quick Tip to help UCR

Structuring your pages: Part Ia

Using :after to clear floats

IE does it wrong anyway

The gotcha

Labels the forgotten HTML Form Tag

Using the <label> tag

Why, as web developers, we should care about the label tag

Accessibility

Usability

Clickability!

Access keys

One more container!

In conclusion

Structuring your pages: Part I

Structural

Deciphering the mental process

The header

Using ids vs. classes

What are block level elements?

The footer

The content block

More structural elements?

Conclusion

Making a CSS highlighter

Using a repeatable image as a border

Single GREATEST quote EVER

Color picker of choice!

Consensus?

Steal These Buttons

Ticked Off? Visited Links How-To

VisiBone Font Survey Results - Browsershare

Multilevel Suckerfish dropdowns

Fun with Forms

Must bookmark: Developing With Web Standards

Text sizing in ems

Suckerfish Dropdowns