Wednesday, August 25, 2004

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.

Monday, August 23, 2004

Of Law and Accessibility

It seems that and, following an investigation, and noticing the potential for lawsuits seeking enforcement of accessibility laws, have both undertaken efforts to make their sites more accessible. and, 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 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:

Thursday, August 19, 2004

Blocks by default STACK

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:

  1. One of the middle elements has been removed from the document flow
  2. 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.

Wednesday, August 18, 2004

Using multiple pseudo-classes in one selector

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

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 <q> tags

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: "'";	}

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


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!

Friday, August 13, 2004

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

So you want to get rid of the sponsored links on the results page of "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

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

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

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

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.

Thursday, August 12, 2004

Including script files from script

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:

  1. We need to create a function
  2. 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
		/* 	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"

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

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>

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

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.

Wednesday, August 11, 2004

Using :after to clear floats

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;
<!-- skip to you body -->
<div class="container">
<div class="left">
This div floats to the left
<div class="right">This is the right floating div</div>
<p>I'm normal content within the container div</p>

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;

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

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:

  1. Wrap the text you want to associate with <label></label>
  2. Add an id attribute to the appropriate form field
  3. Add the for attribute to the label tag with the id of the corresponding input field.
  4. 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" />

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>

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:

  1. Accessibility
  2. Usability
  3. And label creates one more semantic container


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.



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

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

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

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; }	
<form action="#" >
	<label for="first-name" class="required">First name: </label>
	<input type="text" name="firstname" id="first-name" />


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: 
	<input type="text" name="firstname" id="first-name" />

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

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 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:

	<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>

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:

  1. Hmmm... I need a page
  2. I know I want my logo and stuff at the top
  3. I have some copyright information that goes at the bottom
  4. And all my pages will have some content that will be different.
  5. 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 -->

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:

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

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:

  1. We need a container
  2. This is probably unique and we can give it an id
  3. We don't need to worry about the content yet
  4. This is, for now, conceptually, logically, and visually last
  5. 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 -->

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

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

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 -->

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

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

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:

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

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


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.

Monday, August 09, 2004

Making a CSS highlighter

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;

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

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;

Wednesday, August 04, 2004

Single GREATEST quote EVER

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.