rowid,title,contents,year,author,author_slug,published,url,topic
98,Absolute Columns,"CSS layouts have come quite a long way since the dark ages of web publishing, with all sorts of creative applications of floats, negative margins, and even background images employed in order to give us that most basic building block, the column. As the title implies, we are indeed going to be discussing columns today—more to the point, a handy little application of absolute positioning that may be exactly what you’ve been looking for…

Care for a nightcap?

If you’ve been developing for the web for long enough, you may be familiar with this little children’s fable, passed down from wizened Shaolin monks sitting atop the great Mt. Geocities: “Once upon a time, multiple columns of the same height could be easily created using TABLES.” Now, though we’re all comfortably seated on the standards train (and let’s be honest: even if you like to think you’ve fallen off, if you’ve given up using tables for layout, rest assured your sleeper car is still reserved), this particular—and as page layout goes, quite basic—trick is still a thorn in our CSSides compared to the ease of achieving the same effect using said Tables of Evil™.

See, the orange juice masks the flavor…

Creative solutions such as Dan Cederholm’s  Faux Columns do a good job of making it appear as though adjacent columns maintain equal height as content expands, using a background image to fill the space that the columns cannot.

Now, the Holy Grail of CSS columns behaving exactly how they would as table cells—or more to the point, as columns—still eludes us (cough CSS3 Multi-column layout module cough), but sometimes you just need, for example, a secondary column (say, a sidebar) to match the height of a primary column, without involving the creation of images. This is where a little absolute positioning can save you time, while possibly giving your layout a little more flexibility.

Shaken, not stirred

You’re probably familiar by now with the concept of Making the Absolute, Relative as set forth long ago by Doug Bowman, but let’s quickly review just in case: an element set to position:absolute will position itself relative to its nearest ancestor set to position:relative, rather than the browser window (see Figure 1).

 Figure 1.

However, what you may not know is that we can anchor more than two sides of an absolutely positioned element. Yes, that’s right, all four sides (top, right, bottom, left) can be set, though in this example we’re only going to require the services of three sides (see Figure 2 for the end result).

 Figure 2.

Trust me, this will make you feel better

Our requirements are essentially the same as the standard “absolute-relative” trick—a container <div> set to position:relative, and our sidebar <div> set to position:absolute — plus another <div> that will serve as our main content column. We’ll also add a few other common layout elements (wrapper, header, and footer) so our example markup looks more like a real layout and less like a test case:

<div id=""wrapper"">
	<div id=""header"">
		<h2>#header</h2>
	</div>
	<div id=""container"">
		<div id=""column-left"">
			<h2>#left</h2>
			<p>Lorem ipsum dolor sit amet…</p>
		</div>
		<div id=""column-right"">
			<h2>#right</h2>
		</div>
	</div>
	<div id=""footer"">
		<h2>#footer</h2>
	</div>
</div>

In this example, our main column (#column-left) is only being given a width to fit within the context of the layout, and is otherwise untouched (though we’re using pixels here, this trick will of course work with fluid layouts as well), and our right keeping our styles nice and minimal:

#container {
	position: relative;
}
#column-left {
	width: 480px;
}
#column-right {
	position: absolute;
	top: 10px;
	right: 10px;
	bottom: 10px;
	width: 250px;
}

The trick is a simple one: the #container <div> will expand vertically to fit the content within #column-left. By telling our sidebar <div> (#column-right) to attach itself not only to the top and right edges of #container, but also to the bottom, it too will expand and contract to match the height of the left column (duplicate the “lorem ipsum” paragraph a few times to see it in action).

 Figure 3.

On the rocks

“But wait!” I hear you exclaim, “when the right column has more content than the left column, it doesn’t expand! My text runneth over!” Sure enough, that’s exactly what happens, and what’s more, it’s supposed to: Absolutely positioned elements do exactly what you tell them to do, and unfortunately aren’t very good at thinking outside the box (get it? sigh…). 

However, this needn’t get your spirits down, because there’s an easy way to address the issue: by adding overflow:auto to #column-right, a scrollbar will automatically appear if and when needed:

#column-right {
	position: absolute;
	top: 10px;
	right: 10px;
	bottom: 10px;
	width: 250px;
	overflow: auto;
}

While this may limit the trick’s usefulness to situations where the primary column will almost always have more content than the secondary column—or where the secondary column’s content can scroll with wild abandon—a little prior planning will make it easy to incorporate into your designs.

Driving us to drink

It just wouldn’t be right to have a friendly, festive holiday tutorial without inviting IE6, though in this particular instance there will be no shaming that old browser into admitting it has a problem, nor an intervention and subsequent 12-step program. That’s right my friends, this tutorial has abstained from IE6-abuse now for 30 days, thanks to the wizard Dean Edwards and his amazingly talented IE7 Javascript library.

Simply drop the Conditional Comment and <script> element into the <head> of your document, along with one tiny CSS hack that only IE6 (and below) will ever see, and that browser will be back on the straight and narrow:

<!--[if lt IE 7]>
<script src=""http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE7.js"" type=""text/javascript""></script>
<style type=""text/css"" media=""screen"">
	#container {
		zoom:1; /* helps fix IE6 by initiating hasLayout */
	}
</style>
<![endif]-->

Eggnog is supposed to be spiked, right?

Of course, this is one simple example of what can be a much more powerful technique, depending on your needs and creativity. Just don’t go coding up your wildest fantasies until you’ve had a chance to sleep off the Christmas turkey and whatever tasty liquids you happen to imbibe along the way…",2008,Dan Rubin,danrubin,2008-12-22T00:00:00+00:00,https://24ways.org/2008/absolute-columns/,code
99,A Christmas hCard From Me To You,"So apparently Christmas is coming. And what is Christmas all about? Well, cleaning out your address book, of course! What better time to go through your contacts, making sure everyone’s details are up date and that you’ve deleted all those nasty clients who never paid on time?

It’s also a good time to make sure your current clients and colleagues have your most up-to-date details, so instead of filling up their inboxes with e-cards, why not send them something useful? Something like a… vCard! (See what I did there?)

Just in case you’ve been working in a magical toy factory in the upper reaches of Scandinavia for the last few years, I’m going to tell you that now would also be the perfect time to get into microformats. Using the hCard format, we’ll build a very simple web page and markup our contact details in such a way that they’ll be understood by microformats plugins, like Operator or Tails for Firefox, or the cross-browser Microformats Bookmarklet.

Oh, and because Christmas is all about dressing up and being silly, we’ll make the whole thing look nice and have a bit of fun with some CSS3 progressive enhancement. 

If you can’t wait to see what we end up with, you can preview it here.



Step 1: Contact Details

First, let’s decide what details we want to put on the page. I’d put my full name, my email address, my phone number, and my postal address, but I’d rather not get surprise visits from strangers when I’m fannying about with my baubles, so I’m going to use Father Christmas instead (that’s Santa to you Yanks).

Father Christmas
fatherchristmas@elliotjaystocks.com
25 Laughingallthe Way
Snow Falls
Lapland
Finland
010 60 58 000

Step 2: hCard Creator

Now I’m not sure about you, but I rather like getting the magical robot pixies to do the work for me, so head on over to the hCard Creator and put those pixies to work! Pop in your details and they’ll give you some nice microformatted HTML in turn.



<div id=""hcard-Father-Christmas"" class=""vcard"">
	<a class=""url fn"" href=""http://elliotjaystocks.com/fatherchristmas"">Father Christmas</a>
	<a class=""email"" href=""mailto:fatherchristmas@elliotjaystocks.com""> fatherchristmas@elliotjaystocks.com</a>
	<div class=""adr"">
	<div class=""street-address"">25 Laughingallthe Way</div>
	<span class=""locality"">Snow Falls</span>
	, 
	<span class=""region"">Lapland</span>
	, 
	<span class=""postal-code"">FI-00101</span>
	<span class=""country-name"">Finland</span>
</div>
<div class=""tel"">010 60 58 000</div>
	<p style=""font-size:smaller;"">This <a href=""http://microformats.org/wiki/hcard"">hCard</a> created with the <a href=""http://microformats.org/code/hcard/creator"">hCard creator</a>.</p>
</div>

Step 3: Editing The Code

One of the great things about microformats is that you can use pretty much whichever HTML tags you want, so just because the hCard Creator Fairies say something should be wrapped in a <span> doesn’t mean you can’t change it to a <blink>. Actually, no, don’t do that. That’s not even excusable at Christmas.

I personally have a penchant for marking up each line of an address inside a <li> tag, where the parent url retains the class of adr. As long as you keep the class names the same, you’ll be fine.

<div id=""hcard-Father-Christmas"" class=""vcard"">
	<h1><a class=""url fn"" href=""http://elliotjaystocks.com/fatherchristmas"">Father Christmas </a></h1>
	<a class=""email"" href=""mailto:fatherchristmas@elliotjaystocks.com?subject=Here, have some Christmas cheer!"">fatherchristmas@elliotjaystocks.com</a>
	<ul class=""adr"">
		<li class=""street-address"">25 Laughingallthe Way</li>
		<li class=""locality"">Snow Falls</li>
		<li class=""region"">Lapland</li>
		<li class=""postal-code"">FI-00101</li>
		<li class=""country-name"">Finland</li>
	</ul>
	<span class=""tel"">010 60 58 000</span>
</div>

Step 4: Testing The Microformats

With our microformats in place, now would be a good time to test that they’re working before we start making things look pretty. If you’re on Firefox, you can install the Operator or Tails extensions, but if you’re on another browser, just add the Microformats Bookmarklet. Regardless of your choice, the results is the same: if you’ve code microformatted content on a web page, one of these bad boys should pick it up for you and allow you to export the contact info. Give it a try and you should see father Christmas appearing in your address book of choice. Now you’ll never forget where to send those Christmas lists!



Step 5: Some Extra Markup

One of the first things we’re going to do is put a photo of Father Christmas on the hCard. We’ll be using CSS to apply a background image to a div, so we’ll be needing an extra div with a class name of “photo”. In turn, we’ll wrap the text-based elements of our hCard inside a div cunningly called “text”. Unfortunately, because of the float technique we’ll be using, we’ll have to use one of those nasty float-clearing techniques. I shall call this “christmas-cheer”, since that is what its presence will inevitably bring, of course.

Oh, and let’s add a bit of text to give the page context, too:

<p>Send your Christmas lists my way...</p>
<div id=""hcard-Father-Christmas"" class=""vcard"">
	<div class=""text"">
		<h1><a class=""url fn"" href=""http://elliotjaystocks.com/fatherchristmas"">Father Christmas </a></h1>
		<a class=""email"" href=""mailto:fatherchristmas@elliotjaystocks.com?subject=Here, have some Christmas cheer!"">fatherchristmas@elliotjaystocks.com</a>
		<ul class=""adr"">
			<li class=""street-address"">25 Laughingallthe Way</li>
			<li class=""locality"">Snow Falls</li>
			<li class=""region"">Lapland</li>
			<li class=""postal-code"">FI-00101</li>
			<li class=""country-name"">Finland</li>
		</ul>
		<span class=""tel"">010 60 58 000</span>
	</div>
	<div class=""photo""></div>
	<br class=""christmas-cheer"" />
</div>
<div class=""credits"">
	<p>A tutorial by <a href=""http://elliotjaystocks.com"">Elliot Jay Stocks</a> for <a href=""http://24ways.org/"">24 Ways</a></p>
	<p>Background: <a href=""http://sxc.hu/photo/1108741"">stock.xchng</a> | Father Christmas: <a href=""http://istockphoto.com/file_closeup/people/4575943-active-santa.php?id=4575943"">iStockPhoto</a></p>
</div>

Step 6: Some Christmas Sparkle

So far, our hCard-housing web page is slightly less than inspiring, isn’t it? It’s time to add a bit of CSS. There’s nothing particularly radical going on here; just a simple layout, some basic typographic treatment, and the placement of the Father Christmas photo. I’d usually use a more thorough CSS reset like the one found in the YUI or Eric Meyer’s, but for this basic page, the simple * solution will do.

Check out the step 6 demo to see our basic styles in place.

From this…



… to this:



Step 7: Fun With imagery

Now it’s time to introduce a repeating background image to the <body> element. This will seamlessly repeat for as wide as the browser window becomes.

But that’s fairly straightforward. How about having some fun with the Father Christmas image? If you look at the image file itself, you’ll see that it’s twice as wide as the area we can see and contains a ‘hidden’ photo of our rather camp St. Nick.



As a light-hearted visual… er… ‘treat’ for users who move their mouse over the image, we move the position of the background image on the “photo” div. Check out the step 7 demo to see it working.

Step 8: Progressive Enhancement

Finally, this fun little project is a great opportunity for us to mess around with some advanced CSS features (some from the CSS3 spec) that we rarely get to use on client projects. (Don’t forget: no Christmas pressies for clients who want you to support IE6!)

Here are the rules we’re using to give some browsers a superior viewing experience:


	@font-face allows us to use Jos Buivenga’s free font ‘Fertigo Pro’ on all text;
	text-shadow adds a little emphasis on the opening paragraph;
	body > p:first-child causes only the first paragraph to receive this treatment;
	border-radius created rounded corners on our main div and the links within it;
	and webkit-transition allows us to gently fade in between the default and hover states of those links.


And with that, we’re done! You can see the results here. It’s time to customise the page to your liking, upload it to your site, and send out the URL. And do it quickly, because I’m sure you’ve got some last-minute Christmas shopping to finish off!",2008,Elliot Jay Stocks,elliotjaystocks,2008-12-10T00:00:00+00:00,https://24ways.org/2008/a-christmas-hcard-from-me-to-you/,code
100,Moo'y Christmas,"A note from the editors:  Moo has changed their API since this article was written.
                
                
                      
                As the web matures, it is less and less just about the virtual world. It is becoming entangled with our world and it is harder to tell what is virtual and what is real. There are several companies who are blurring this line and make the virtual just an extension of the physical. Moo is one such company. 

Moo offers simple print on demand services. You can print business cards, moo mini cards, stickers, postcards and more. They give you the ability to upload your images, customize them, then have them sent to your door. Many companies allow this sort of digital to physical interaction, but Moo has taken it one step further and has built an API. 

Printable stocking stuffers 

The Moo API consists of a simple XML file that is sent to their servers. It describes all the information needed to dynamically assemble and print your object. This is very helpful, not just for when you want to print your own stickers, but when you want to offer them to your customers, friends, organization or community with no hassle. Moo handles the check-out and shipping, all you need to do is what you do best, create! 

Now using an API sounds complicated, but it is actually very easy. I am going to walk you through the options so you can easily be printing in no time. 

Before you can begin sending data to the Moo API, you need to register and get an API key. This is important, because it allows Moo to track usage and to credit you. To register, visit http://www.moo.com/api/ and click “Request an API key”. 

In the following examples, I will use {YOUR API KEY HERE} as a place holder, replace that with your API key and everything will work fine. 

First thing you need to do is to create an XML file to describe the check-out basket. Open any text-editor and start with some XML basics. Don’t worry, this is pretty simple and Moo gives you a few tools to check your XML for errors before you order. 

<?xml version=""1.0"" encoding=""UTF-8""?> 
<moo xsi:noNamespaceSchemaLocation=""http://www.moo.com/xsd/api_0.7.xsd"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance""> 
	 <request>
		 <version>0.7</version>
		 <api_key>{YOUR API KEY HERE}</api_key>
		 <call>build</call>
		 <return_to>http://www.example.com/return.html</return_to>
		 <fail_to>http://www.example.com/fail.html</fail_to>
	 </request>
	 <payload>
	 ...
	 </payload>
</moo>

Much like HTML’s <head> and <body>, Moo has created <request> and <payload> elements all wrapped in a <moo> element. 

The <request> element contains a few pieces of information that is the same across all the API calls. The <version> element describes which version of the API is being used. This is more important for Moo than for you, so just stick with “0.7” for now. 

The <api_key> allows Moo to track sales, referrers and credit your account. 

The <call> element can only take “build” so that is pretty straight forward. The <return_to> and <fail_to> elements are URLs. These are optional and are the URLs the customer is redirected to if there is an error, or when the check out process is complete. This allows for some basic branding and a custom “thank you” page which is under your control. That’s it for the <request> element, pretty easy so far! 

Next up is the <payload> element. What goes inside here describes what is to be printed. There are two possible elements, we can put <chooser> or we can put <products> directly inside <payload>. They work in a similar ways, but they drop the customer into different parts of the Moo checkout process. 

If you specify <products> then you send the customer straight to the Moo payment process. If you specify <chooser> then you send the customer one-step earlier where they are allowed to pick and choose some images, remove the ones they don’t like, adjust the crop, etc. The example here will use <chooser> but with a little bit of homework you can easily adjust to <products> if you desire. 

... 
<chooser> 
	 <product_type>sticker</product_type> 
	 <images> 
		 <url>http://example.com/images/christmas1.jpg</url> 
	 </images> 
</chooser> 
...

Inside the <chooser> element, we can see there are two basic piece of information. The type of product we want to print, and the images that are to be printed. The <product_type> element can take one of five options and is required! The possibilities are: minicard, notecard, sticker, postcard or greetingcard. We’ll now look at two of these more closely. 

Moo Stickers 

In the Moo sticker books you get 90 small squarish stickers in a small little booklet. 



The simplest XML you could send would be something like the following payload:

...
<payload>
	<chooser>
		<product_type>sticker</product_type>
		<images>
			<url>http://example.com/image1.jpg</url>
		</images>
		<images>
			<url>http://example.com/image2.jpg</url>
		</images>
		<images>
			<url>http://example.com/image3.jpg</url>
		</images>
	</chooser>
</payload>
...

This creates a sticker book with only 3 unique images, but 30 copies of each image. The Sticker books always print 90 stickers in multiples of the images you uploaded. That example only has 3 <images> elements, but you can easily duplicate the XML and send up to 90. The <url> should be the full path to your image and the image needs to be a minimum of 300 pixels by 300 pixels.

You can add more XML to describe cropping, but the simplest option is to either, let your customers choose or to pre-crop all your images square so there are no issues.

The full XML you would post to the Moo API to print sticker books would look like this:

<?xml version=""1.0"" encoding=""UTF-8""?> 
<moo xsi:noNamespaceSchemaLocation=""http://www.moo.com/xsd/api_0.7.xsd"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance""> 
	<request>
		<version>0.7</version>
		<api_key>{YOUR API KEY HERE}</api_key>
		<call>build</call>
		<return_to>http://www.example.com/return.html</return_to>
		<fail_to>http://www.example.com/fail.html</fail_to>
	</request>
	<payload>
		<chooser>
			<product_type>sticker</product_type>
			<images>
				<url>http://example.com/image1.jpg</url>
			</images>
			<images>
				<url>http://example.com/image2.jpg</url>
			</images>
			<images>
				<url>http://example.com/image3.jpg</url>
			</images>
		</chooser>
	</payload> 
</moo>

Mini-cards 

The mini-cards are the small cute business cards in 14×35 dimensions and come in packs of 100. 



Since the mini-cards are print on demand, this allows you to have 100 unique images on the back of the cards.

Just like the stickers example, we need the same XML setup. The <moo> element and <request> elements will be the same as before. The part you will focus on is the <payload> section. 

Since you are sending along specific information, we can’t use the <chooser> option any more. Switch this to <products> which has a child of <product>, which in turn has a <product_type> and <designs>. This might seem like a lot of work, but once you have it set up you won’t need to change it.

...
<payload>
	<products>
		<product>
			<product_type>minicard</product_type>
			<designs>
				...
			</designs>
		</product>
	</products>
</payload>
...

So now that we have the basic framework, we can talk about the information specific to minicards. Inside the <designs> element, you will have one <design> for each card. Much like before, this contains a way to describe the image. Note that this time the element is called <image>, not images plural. 

Inside the <image> element you have a <url> which points to where the image lives and a <type>. The <type> should just be set to ‘variable’. You can pass crop information here instead, but we’re going to keep it simple for this tutorial. If you are interested in how that works, you should refer to the official API documentation.

...
<design>
	<image>
		<url>http://example.com/image1.jpg</url>
		<type>variable</type>
	</image>
</design>
...

So far, we have managed to build a pack of 100 Moo mini-cards with the same image on the front. If you wanted 100 different images, you just need to replicate this snippit, 99 more times.

That describes the front design, but the flip-side of your mini-cards can contain 6 lines of text, which is customizable in a variety of colors, fonts and styles.

The API allows you to create different text on the back of each mini-card, something the web interface doesn’t implement. To describe the text on the mini-card we need to add a <text_collection> element inside the <design> element. If you skip this element, the back of your mini-card will just be blank, but that’s not very festive!

Inside the <text_collection> element, we need to describe the type of text we want to format, so we add a <minicard> element, which in turn contains all the lines of text. Each of Moo’s printed products take different numbers of lines of text, so if you are not planning on making mini-cards, be sure to consult the documentation.

For mini-cards, we can have 6 distinct lines, each with their own style and layout. Each line is represented by an element <text_line> which has several optional children. The <id> tells which line of the 6 to print the text one. The <string> is the text you want to print and it must be shorter than 38 characters. The <bold> element is false by default, but if you want your text bolded, then add this and set it to true. 

The <align> element is also optional. By default it is set to align left. You can also set this to right or center if you desirer. The <font> element takes one of 3 types, modern, traditional or typewriter. The default is modern. Finally, you can set the <colour>, yes that’s color with a ‘u’, Moo is a British company, so they get to make the rules. When you start a print on demand company, you can spell it however you want. The <colour> element takes a 6 character hex value with a leading #.

<design>
	...
	<text_collection>
		<minicard>
			<text_line>
				<id>(1-6)</id>
				<string>String, I must be less than 38 chars!</string>
				<bold>true</bold>
				<align>left</align>
				<font>modern</font>
				<colour>#ff0000</colour> 
			</text_line>
		</minicard>
	</text_collection>
</design>

If you combine all of this into a mini-card request you’d get this example:

<?xml version=""1.0"" encoding=""UTF-8""?> 
<moo xsi:noNamespaceSchemaLocation=""http://www.moo.com/xsd/api_0.7.xsd"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance""> 
	<request>
		<version>0.7</version>
		<api_key>{YOUR API KEY HERE}</api_key>
		<call>build</call>
		<return_to>http://www.example.com/return.html</return_to>
		<fail_to>http://www.example.com/fail.html</fail_to>
	</request>
	<payload>
		<products>
			<product>
				<product_type>minicard</product_type>
				<designs>
					<design>
						<image>
							<url>http://example.com/image1.jpg</url>
							<type>variable</type>
						</image>
						<text_collection>
							<minicard>
								<text_line>
								<id>1</id>
								<string>String, I must be less than 38 chars!</string>
								<bold>true</bold>
								<align>left</align>
								<font>modern</font>
								<colour>#ff0000</colour> 
								</text_line>
							</minicard>
						</text_collection>
					</design>
				</designs>
			</product>
		</products>
	</payload> 
</moo>

Now you know how to construct the XML that describes what to print. Next, you need to know how to send it to Moo to make it happen!

Posting to the API

So your XML is file ready to go. First thing we need to do is check it to make sure it’s valid. Moo has created a simple validator where you paste in your XML, and it alerts you to problems.

When you have a fully valid XML file, you’ll want to send that to the Moo API. There are a few ways to do this, but the simplest is with an HTML form. 

This is the sample code for an HTML form with a big “Buy My Stickers” button. Once you know that it is working, you can use all your existing HTML knowledge to style it up any way you like.

<form method=""POST"" action=""http://www.moo.com/api/api.php"">
	<input type=""hidden"" name=""xml"" value=""<?xml version=""1.0"" encoding=""UTF-8""?> <moo xsi:noNamespaceSchemaLocation=""http://www.moo.com/xsd/api_0.7.xsd"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance""> <request>....</request> <payload>...</payload> </moo> ""> 
	<input type=""submit"" name=""submit"" value=""Buy My Stickers""/>
</form>

This is just a basic <form> element that submits to the Moo API, http://www.moo.com/api/api.php, when someone clicks the button. There is a hidden input called “xml” which contains the value the XML file we created previously.

For those of you who need to “view source” to fully understand what’s happening can see a working version and peek under the hood.

Using the API has advantages over uploading the images directly yourself. The images and text that you send via the API can be dynamic. Some companies, like Dopplr, have taken user profiles and dynamic data that changes every minute to generate customer stickers of places that you’ve travelled to or mini-cards with a world map of all the cities you have visited. Every single customer has different travel plans and therefore different sets of stickers and mini-card maps. The API allows for the utmost current information to be printed, on demand, in real-time.

Go forth and Moo’ltiply

See, making an API call wasn’t that hard was it? You are now 90% of the way to creating anything with the Moo API. With a bit of reading, you can learn that extra 10% and print any Moo product. Be on the lookout in 2009 for the official release of the 1.0 API with improvements and some extras that were not available when this article was written.

This article is released under the creative-commons attribution share-a-like license. That means you are free to re-distribute it, mash it up, translate it and otherwise re-using it ways the author never considered, in return he only asks you mention his name.


This work by Brian Suda is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.",2008,Brian Suda,briansuda,2008-12-19T00:00:00+00:00,https://24ways.org/2008/mooy-christmas/,code
104,Sitewide Search On A Shoe String,"One of the questions I got a lot when I was building web sites for smaller businesses was if I could create a search engine for their site. Visitors should be able to search only this site and find things without the maintainer having to put “related articles”  or “featured content” links on every page by hand. 

Back when this was all fields this wasn’t easy as you either had to write your own scraping tool, use ht://dig or a paid service from providers like Yahoo, Altavista or later on Google. In the former case you had to swallow the bitter pill of computing and indexing all your content and storing it in a database for quick access and in the latter it hurt your wallet.

Times have moved on and nowadays you can have the same functionality for free using Yahoo’s “Build your own search service” – BOSS. The cool thing about BOSS is that it allows for a massive amount of hits a day and you can mash up the returned data in any format you want. Another good feature of it is that it comes with JSON-P as an output format which makes it possible to use it without any server-side component!

Starting with a working HTML form

In order to add a search to your site, you start with a simple HTML form which you can use without JavaScript. Most search engines will allow you to filter results by domain. In this case we will search “bbc.co.uk”. If you use Yahoo as your standard search, this could be: 

<form id=""customsearch"" action=""http://search.yahoo.com/search"">
	<div>
		<label for=""p"">Search this site:</label>
		<input type=""text"" name=""p"" id=""term"">
		<input type=""hidden"" name=""vs"" id=""site"" value=""bbc.co.uk"">
		<input type=""submit"" value=""go"">
	</div>
</form>

The Google equivalent is:

<form id=""customsearch"" action=""http://www.google.co.uk/search"">
	<div>
		<label for=""p"">Search this site:</label>
		<input type=""text"" name=""as_q"" id=""term"">
		<input type=""hidden"" name=""as_sitesearch"" id=""site"" value=""bbc.co.uk"">
		<input type=""submit"" value=""go"">
	</div>
</form>

In any case make sure to use the ID term for the search term and site for the site, as this is what we are going to use for the script. To make things easier, also have an ID called customsearch on the form.

To use BOSS, you should get your own developer API for BOSS and replace the one in the demo code. There is click tracking on the search results to see how successful your app is, so you should make it your own.

Adding the BOSS magic

BOSS is a REST API, meaning you can use it in any HTTP request or in a browser by simply adding the right parameters to a URL. Say for example you want to search “bbc.co.uk” for “christmas” all you need to do is open the following URL:

http://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&format=xml&appid=YOUR-APPLICATION-ID

Try it out and click it to see the results in XML. We don’t want XML though, which is why we get rid of the format=xml parameter which gives us the same information in JSON:

http://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&appid=YOUR-APPLICATION-ID

JSON makes most sense when you can send the output to a function and immediately use it. For this to happen all you need is to add a callback parameter and the JSON will be wrapped in a function call. Say for example we want to call SITESEARCH.found() when the data was retrieved we can do it this way:

http://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&callback=SITESEARCH.found&appid=YOUR-APPLICATION-ID

You can use this immediately in a script node if you want to. The following code would display the total amount of search results for the term christmas on bbc.co.uk as an alert:

<script type=""text/javascript"">
	var SITESEARCH = {};
	SITESEARCH.found = function(o){
		alert(o.ysearchresponse.totalhits);
	}
</script>
<script type=""text/javascript"" src=""http://boss.yahooapis.com/ysearch/web/v1/christmas?sites=bbc.co.uk&callback=SITESEARCH.found&appid=Kzv_lcHV34HIybw0GjVkQNnw4AEXeyJ9Rb1gCZSGxSRNrcif_HdMT9qTE1y9LdI-"">
</script>

However, for our example, we need to be a bit more clever with this.

Enhancing the search form




Here’s the script that enhances a search form to show results below it.

SITESEARCH = function(){
	var config = {
		IDs:{
			searchForm:'customsearch',
			term:'term',
			site:'site'
		},
		loading:'Loading results...',
		noresults:'No results found.',
		appID:'YOUR-APP-ID',
		results:20
	};
	var form;
	var out;
	function init(){
		if(config.appID === 'YOUR-APP-ID'){
			alert('Please get a real application ID!');
		} else {
			form = document.getElementById(config.IDs.searchForm);
			if(form){
				form.onsubmit = function(){
					var site = document.getElementById(config.IDs.site).value;
					var term = document.getElementById(config.IDs.term).value;
					if(typeof site === 'string' && typeof term === 'string'){
						if(typeof out !== 'undefined'){
							out.parentNode.removeChild(out);
						}
						out = document.createElement('p');
						out.appendChild(document.createTextNode(config.loading));
						form.appendChild(out);
						var APIurl = 'http://boss.yahooapis.com/ysearch/web/v1/' + 
													term + '?callback=SITESEARCH.found&sites=' + 
													site + '&count=' + config.results + 
													'&appid=' + config.appID;
						var s = document.createElement('script');
						s.setAttribute('src',APIurl);
						s.setAttribute('type','text/javascript');
						document.getElementsByTagName('head')[0].appendChild(s);
						return false;
					}
				};
			}
		}
	};
	function found(o){
		var list = document.createElement('ul');
		var results = o.ysearchresponse.resultset_web;
		if(results){
			var item,link,description;
			for(var i=0,j=results.length;i<j;i++){
				item = document.createElement('li');
				link = document.createElement('a');
				link.setAttribute('href',results[i].clickurl);
				link.innerHTML = results[i].title;
				item.appendChild(link);
				description = document.createElement('p');
				description.innerHTML = results[i]['abstract'];
				item.appendChild(description);
				list.appendChild(item);
			}
		} else {
			list = document.createElement('p');
			list.appendChild(document.createTextNode(config.noresults));
		}
		form.replaceChild(list,out);
		out = list;
	};
	return{
		config:config,
		init:init,
		found:found
	};
}();

Oooohhhh scary code! Let’s go through this one bit at a time:

We start by creating a module called SITESEARCH and give it an configuration object: 

SITESEARCH = function(){
	var config = {
		IDs:{
			searchForm:'customsearch',
			term:'term',
			site:'site'
		},
		loading:'Loading results...',
		appID:'YOUR-APP-ID',
		results:20
	}

Configuration objects are a great idea to make your code easy to change and also to override. In this case you can define different IDs than the one agreed upon earlier, define a message to show when the results are loading, when there aren’t any results, the application ID and the number of results that should be displayed.

Note: you need to replace “YOUR-APP-ID” with the real ID you retrieved from BOSS, otherwise the script will complain! 

var form;
var out;
function init(){
	if(config.appID === 'YOUR-APP-ID'){
		alert('Please get a real application ID!');
	} else {

We define form and out as variables to make sure that all the methods in the module have access to them. We then check if there was a real application ID defined. If there wasn’t, the script complains and that’s that.      

form = document.getElementById(config.IDs.searchForm);
if(form){
	form.onsubmit = function(){
		var site = document.getElementById(config.IDs.site).value;
		var term = document.getElementById(config.IDs.term).value;
		if(typeof site === 'string' && typeof term === 'string'){      

If the application ID was a winner, we check if the form with the provided ID exists and apply an onsubmit event handler. The first thing we get is the values of the site we want to search in and the term that was entered and check that those are strings.

if(typeof out !== 'undefined'){
	out.parentNode.removeChild(out);
}
out = document.createElement('p');
out.appendChild(document.createTextNode(config.loading));
form.appendChild(out);  

If both are strings we check of out is undefined. We will create a loading message and subsequently the list of search results later on and store them in this variable. So if out is defined, it’ll be an old version of a search (as users will re-submit the form over and over again)  and we need to remove that old version.

We then create a paragraph with the loading message and append it to the form.

var APIurl = 'http://boss.yahooapis.com/ysearch/web/v1/' + 
												term + '?callback=SITESEARCH.found&sites=' + 
												site + '&count=' + config.results + 
												'&appid=' + config.appID;
					var s = document.createElement('script');
					s.setAttribute('src',APIurl);
					s.setAttribute('type','text/javascript');
					document.getElementsByTagName('head')[0].appendChild(s);
					return false;
				}
			};
		}
	}
};

Now it is time to call the BOSS API by assembling a correct REST URL, create a script node and apply it to the head of the document. We return false to ensure the form does not get submitted as we want to stay on the page.

Notice that we are using SITESEARCH.found as the callback method, which means that we need to define this one to deal with the data returned by the API.

function found(o){
	var list = document.createElement('ul');
	var results = o.ysearchresponse.resultset_web;
	if(results){
		var item,link,description;

We create a new list and then get the resultset_web array from the data returned from the API. If there aren’t any results returned, this array will not exist which is why we need to check for it. Once we done that we can define three variables to repeatedly store the item title we want to display, the link to point to and the description of the link.

for(var i=0,j=results.length;i<j;i++){
	item = document.createElement('li');
	link = document.createElement('a');
	link.setAttribute('href',results[i].clickurl);
	link.innerHTML = results[i].title;
	item.appendChild(link);
	description = document.createElement('p');
	description.innerHTML = results[i]['abstract'];
	item.appendChild(description);
	list.appendChild(item);
}

We then loop over the results array and assemble a list of results with the titles in links and paragraphs with the abstract of the site. Notice the bracket notation for abstract as abstract is a reserved word in JavaScript2 :).

} else {
		list = document.createElement('p');
		list.appendChild(document.createTextNode(config.noresults));
	}
	form.replaceChild(list,out);
	out = list;
};      

If there aren’t any results, we define a paragraph with the no results message as list. In any case we replace the old out (the loading message) with the list and re-define out as the list.  

return{
		config:config,
		init:init,
		found:found
	};
}();

All that is left to do is return the properties and methods we want to make public. In this case found needs to be public as it is accessed by the API return. We return init to make it accessible and config to allow implementers to override any of the properties.

Using the script


In order to use this script, all you need to do is to add it after the form in the document, override the API key with your own and call init():

<form id=""customsearch"" action=""http://search.yahoo.com/search"">
	<div>
		<label for=""p"">Search this site:</label>
		<input type=""text"" name=""p"" id=""term"">
		<input type=""hidden"" name=""vs"" id=""site"" value=""bbc.co.uk"">
		<input type=""submit"" value=""go"">
	</div>
</form>
<script type=""text/javascript"" src=""boss-site-search.js""></script>
<script type=""text/javascript"">
	SITESEARCH.config.appID = 'copy-the-id-you-know-to-get-where';
	SITESEARCH.init();
</script>

Where to go from here

This is just a very simple example of what you can do with BOSS. You can define languages and regions, retrieve and display images and news and mix the results with other data sources before displaying them. One very cool feature is that by adding a view=keyterms parameter to the URL you can get the keywords of each of the results to drill deeper into the search. An example for this written in PHP is available on the YDN blog. For JavaScript solutions there is a handy wrapper called yboss available to help you go nuts.",2008,Christian Heilmann,chrisheilmann,2008-12-04T00:00:00+00:00,https://24ways.org/2008/sitewide-search-on-a-shoestring/,code
109,Geotag Everywhere with Fire Eagle,"A note from the editors:  Since this article was written Yahoo! has retired the Fire Eagle service.
                
                
                      
                Location, they say, is everywhere. Everyone has one, all of the time. But on the web, it’s taken until this year to see the emergence of location in the applications we use and build.

The possibilities are broad. Increasingly, mobile phones provide SDKs to approximate your location wherever you are, browser extensions such as Loki and Mozilla’s Geode provide browser-level APIs to establish your location from the proximity of wireless networks to your laptop. Yahoo’s Brickhouse group launched Fire Eagle, an ambitious location broker enabling people to take their location from any of these devices or sources, and provide it to a plethora of web services. It enables you to take the location information that only your iPhone knows about and use it anywhere on the web.

That said, this is still a time of location as an emerging technology. Fire Eagle stores your location on the web (protected by application-specific access controls), but to try and give an idea of how useful and powerful your location can be — regardless of the services you use now — today’s 24ways is going to build a bookmarklet to call up your location on demand, in any web application.

Location Support on the Web

Over the past year, the number of applications implementing location features has increased dramatically. Plazes and Brightkite are both full featured social networks based around where you are, whilst Pownce rolled in Fire Eagle support to allow geotagging of all the content you post to their microblogging service. Dipity’s beautiful timeline shows for you moving from place to place and Six Apart’s activity stream for Movable Type started exposing your movements.

The number of services that hook into Fire Eagle will increase as location awareness spreads through the developer community, but you can use your location on other sites indirectly too.

Consider Flickr. Now world renowned for their incredible mapping and places features, geotagging on Flickr started out as a grassroots extension of regular tagging. That same technique can be used to start rolling geotagging in any publishing platform you come across, for any kind of content. Machine-tags (geo:lat= and geo:lon=) and the adr and geo microformats can be used to enhance anything you write with location information.

A crash course in avian inflammability

Fire Eagle is a location store. A broker between services and devices which provide location and those which consume it. It’s a switchboard that controls which pieces of your location different applications can see and use, and keeps hidden anything you want kept private. A blog widget that displays your current location in public can be restricted to display just your current city, whilst a service that provides you with a list of the nearest ATMs will operate better with a precise street address. 

Even if your iPhone tells Fire Eagle exactly where you are, consuming applications only see what you want them to see. That’s important for users to realise that they’re in control, but also important for application developers to remember that you cannot rely on having super-accurate information available all the time. You need to build location aware applications which degrade gracefully, because users will provide fuzzier information — either through choice, or through less accurate sources.

Application specific permissions are controlled through an OAuth API. Each application has a unique key, used to request a second, user-specific key that permits access to that user’s information. You store that user key and it remains valid until such a time as the user revokes your application’s access. Unlike with passwords, these keys are unique per application, so revoking the access rights of one application doesn’t break all the others.

Building your first Fire Eagle app; Geomarklet

Fire Eagle’s developer documentation can take you through examples of writing simple applications using server side technologies (PHP, Python). Here, we’re going to write a client-side bookmarklet to make your location available in every site you use. It’s designed to fast-track the experience of  having location available everywhere on web, and show you how that can be really handy. Hopefully, this will set you thinking about how location can enhance the new applications you build in 2009.

An oddity of bookmarklets

Bookmarklets (or ‘favlets’, for those of an MSIE persuasion) are a strange environment to program in. Critically, you have no persistent storage available. As such, using token-auth APIs in a static environment requires you to build you application in a slightly strange way; authing yourself in advance and then hardcoding the keys into your script.

Get started

Before you do anything else, go to http://fireeagle.com and log in, get set up if you need to and by all means take a look around. Take a look at the mobile updaters section of the application gallery and perhaps pick out an app that will update Fire Eagle from your phone or laptop.

Once that’s done, you need to register for an application key in the developer section. Head straight to /developer/create and complete the form. Since you’re building a standalone application, choose ‘Auth for desktop applications’ (rather than web applications), and select that you’ll be ‘accessing location’, not updating.

At the end of this process, you’ll have two application keys, a ‘Consumer Key’ and a ‘Consumer Secret’, which look like these:

 
    Consumer Key
    luKrM9U1pMnu
    Consumer Secret
    ZZl9YXXoJX5KLiKyVrMZffNEaBnxnd6M
 

These keys combined allow your application to make requests to Fire Eagle.

Next up, you need to auth yourself; granting your new application permission to use your location. Because bookmarklets don’t have local storage, you can’t integrate the auth process into the bookmarklet itself — it would have no way of storing the returned key. Instead, I’ve put together a simple web frontend through which you can auth with your application.

Head to Auth me, Amadeus!, enter the application keys you just generated and hit ‘Authorize with Fire Eagle’. You’ll be taken to the Fire Eagle website, just as in regular Fire Eagle applications, and after granting access to your app, be redirected back to Amadeus which will provide you your user tokens. These tokens are used in subsequent requests to read your location.

And, skip to the end…

The process of building the bookmarklet, making requests to Fire Eagle, rendering it to the page and so forth follows, but if you’re the impatient type, you might like to try this out right now. Take your four API keys from above, and drag the following link to your Bookmarks Toolbar; it contains all the code described below. Before you can use it, you need to edit in your own API keys. Open your browser’s bookmark editor and where you find text like ‘YOUR_CONSUMER_KEY_HERE’, swap in the corresponding key you just generated.

Get Location

Bookmarklet Basics

To start on the bookmarklet code, set out a basic JavaScript module-pattern structure:

var Geomarklet = function() {
	return ({
		callback: function(json) {},
		run: function() {}
	});
};
Geomarklet.run();

Next we’ll add the keys obtained in the setup step, and also some basic Fire Eagle support objects:

var Geomarklet = function() {
	var Keys = {
			consumer_key: 'IuKrJUHU1pMnu',
			consumer_secret: 'ZZl9YXXoJX5KLiKyVEERTfNEaBnxnd6M',
			user_token: 'xxxxxxxxxxxx',
			user_secret: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
	};
	var LocationDetail = {
			EXACT: 0,
			POSTAL: 1,
			NEIGHBORHOOD: 2,
			CITY: 3,
			REGION: 4,
			STATE: 5,
			COUNTRY: 6
	};
	var index_offset;
	return ({
		callback: function(json) {},
		run: function() {}
	});
};
Geomarklet.run();

The Location Hierarchy

A successful Fire Eagle query returns an object called the ‘location hierarchy’. Depending on the level of detail shared, the index of a particular piece of information in the array will vary. The LocationDetail object maps the array indices of each level in the hierarchy to something comprehensible, whilst the index_offset variable is an adjustment based on the detail of the result returned.

The location hierarchy object looks like this, providing a granular breakdown of a location, in human consumable and machine-friendly forms.

""user"": {
		""location_hierarchy"": [{
			""level"": 0,
			""level_name"": ""exact"",
			""name"": ""707 19th St, San Francisco, CA"",
			""normal_name"": ""94123"",
			""geometry"": {
					""type"": ""Point"",
					""coordinates"": [ - 0.2347530752, 67.232323]
			},
			""label"": null,
			""best_guess"": true,
			""id"": ,
			""located_at"": ""2008-12-18T00:49:58-08:00"",
			""query"": ""q=707%2019th%20Street,%20Sf""
		},
		{
				""level"": 1,
				""level_name"": ""postal"",
				""name"": ""San Francisco, CA 94114"",
				""normal_name"": ""12345"",
				""woeid"": ,
				""place_id"": """",
				""geometry"": {
						""type"": ""Polygon"",
						""coordinates"": [],
						""bbox"": []
				},
				""label"": null,
				""best_guess"": false,
				""id"": 59358791,
				""located_at"": ""2008-12-18T00:49:58-08:00""
		},
		{
				""level"": 2,
				""level_name"": ""neighborhood"",
				""name"": ""The Mission, San Francisco, CA"",
				""normal_name"": ""The Mission"",
				""woeid"": 23512048,
				""place_id"": ""Y12JWsKbApmnSQpbQg"",
				""geometry"": {
						""type"": ""Polygon"",
						""coordinates"": [],
						""bbox"": []
				},
				""label"": null,
				""best_guess"": false,
				""id"": 59358801,
				""located_at"": ""2008-12-18T00:49:58-08:00""
			},
		}

In this case the first object has a level of 0, so the index_offset is also 0.

Prerequisites

To query Fire Eagle we call in some existing libraries to handle the OAuth layer and the Fire Eagle API call. Your bookmarklet will need to add the following scripts into the page:


	The SHA1 encryption algorithm
	The OAuth wrapper
	An extension for the OAuth wrapper
	The Fire Eagle wrapper itself


When the bookmarklet is first run, we’ll insert these scripts into the document. We’re also inserting a stylesheet to dress up the UI that will be generated.

If you want to follow along any of the more mundane parts of the bookmarklet, you can  download the full source code.

Rendering

This bookmarklet can be extended to support any formatting of your location you like, but for sake of example I’m going to build three common formatters that you’ll find useful for common location scenarios: Sites which already ask for your location; and in publishing systems that accept tags or HTML mark-up.

All the rendering functions are items in a renderers object, so they can be iterated through easily, making it trivial to add new formatting functions as your find new use cases (just add another function to the object).

var renderers = {
geotag: function(user) {
	if(LocationDetail.EXACT !== index_offset) {
			return false;
	}
	else {
		var coords =
			user.location_hierarchy[LocationDetail.EXACT].geometry.coordinates;
		return ""geo:lat="" + coords[0] + "", geo:lon="" + coords[1];
	}
},
city: function(user) {
	if(LocationDetail.CITY < index_offset) {
		return false;
	}
	else {
		return user.location_hierarchy[LocationDetail.CITY - index_offset].name; 
	}						 
}

You should always fail gracefully, and in line with catering to users who choose not to share their location precisely, always check that the location has been returned at the level you require. Geotags are expected to be precise, so if an exact location is unavailable, returning false will tell the rendering aspect of the bookmarklet to ignore the function altogether.

These first two are quite simple, geotag returns geo:lat=-0.2347530752, geo:lon=67.232323 and city returns San Francisco, CA.

This final renderer creates a chunk of HTML using the adr and geo microformats, using all available aspects of the location hierarchy, and can be used to geotag any content you write on your blog or in comments:

html: function(user) {
	var geostring = '';
	var adrstring = '';
	var adr = [];		 
	adr.push('<p class=""adr"">');
	// city
	if(LocationDetail.CITY >= index_offset) {
		adr.push(
			'\n		 <span class=""locality"">'
		+ user.location_hierarchy[LocationDetail.CITY-index_offset].normal_name
		+ '</span>,'
		);
	}
	// county
	if(LocationDetail.REGION >= index_offset) {
		adr.push(
			'\n		 <span class=""region"">' 
		+ user.location_hierarchy[LocationDetail.REGION-index_offset].normal_name
		+ '</span>,'
			);
	}
	// locality
	if(LocationDetail.STATE >= index_offset) {
		adr.push(
			'\n		 <span class=""region"">'
		+ user.location_hierarchy[LocationDetail.STATE-index_offset].normal_name
		+ '</span>,'
		);
	}
	// country
	if(LocationDetail.COUNTRY >= index_offset) {
		adr.push(
			'\n		 <span class=""country-name"">'
		+ user.location_hierarchy[LocationDetail.COUNTRY-index_offset].normal_name
		+ '</span>'
		);
	}
	// postal
	if(LocationDetail.POSTAL >= index_offset) {
		adr.push(
			'\n		 <span class=""postal-code"">'
		+ user.location_hierarchy[LocationDetail.POSTAL-index_offset].normal_name
		+ '</span>,'
		);
	}
	adr.push('\n</p>\n');
	adrstring = adr.join('');
	if(LocationDetail.EXACT === index_offset) {
		var coords = 
			user.location_hierarchy[LocationDetail.EXACT].geometry.coordinates;
		geostring = '<p class=""geo"">'
			+'\n		<span class=""latitude"">'
			+ coords[0]
			+ '</span>;'
			+ '\n		 <span class=""longitude"">'
			+ coords[1]
			+ '</span>\n</p>\n';
	}
	return (adrstring + geostring);
}

Here we check the availability of every level of location and build it into the adr and geo patterns as appropriate. Just as for the geotag function, if there’s no exact location the geo markup won’t be returned.

Finally, there’s a rendering method which creates a container for all this data, renders all the applicable location formats and then displays them in the page for a user to copy and paste. You can throw this together with DOM methods and some simple styling, or roll in some components from YUI or JQuery to handle drawing full featured overlays.

You can see this simple implementation for rendering in the full source code.

Make the call

With a framework in place to render Fire Eagle’s location hierarchy, the only thing that remains is to actually request your location. Having already authed through Amadeus earlier, that’s as simple as instantiating the Fire Eagle JavaScript wrapper and making a single function call. It’s a big deal that whilst a lot of new technologies like OAuth add some complexity and require new knowledge to work with, APIs like Fire Eagle are really very simple indeed.

return {
	run: function() {
		insert_prerequisites();
		setTimeout(
			function() {
				var fe = new FireEagle(
					Keys.consumer_key,
					Keys.consumer_secret,
					Keys.user_token,
					Keys.user_secret
				);
				var script = document.createElement('script');
				script.type = 'text/javascript';
				script.src = fe.getUserUrl(
					FireEagle.RESPONSE_FORMAT.json,
					'Geomarklet.callback'
				);
				document.body.appendChild(script);
			},
			2000
		);
	},
	callback: function(json) {
		if(json.rsp && 'fail' == json.rsp.stat) {
			alert('Error ' + json.rsp.code + "": "" + json.rsp.message);
		}
		else {
			index_offset = json.user.location_hierarchy[0].level;						 
			draw_selector(json);
		}
	}
};

We first insert the prerequisite scripts required for the Fire Eagle request to function, and to prevent trying to instantiate the FireEagle object before it’s been loaded over the wire, the remaining instantiation and request is wrapped inside a setTimeout delay.

We then create the request URL, referencing the Geomarklet.callback callback function and then append the script to the document body — allowing a cross-domain request.

The callback itself is quite simple. Check for the presence and value of rsp.status to test for errors, and display them as required. If the request is successful set the index_offset — to adjust for the granularity of the location hierarchy — and then pass the object to the renderer.

The result? When Geomarklet.run() is called, your location from Fire Eagle is read, and each renderer displayed on the page in an easily copy and pasteable form, ready to be used however you need.

Deploy

The final step is to convert this code into a long string for use as a bookmarklet. Easiest for Mac users is the JavaScript bundle in TextMate — choose Bundles: JavaScript: Copy as Bookmarklet to Clipboard. Then create a new ‘Get Location’ bookmark in your browser of choice and paste in.

Those without TextMate can shrink their code down into a single line by first running their code through the JSLint tool (to ensure the code is free from errors and has all the required semi-colons) and then use a find-and-replace tool to remove line breaks from your code (or even run your code through JSMin to shrink it down).

With the bookmarklet created and added to your bookmarks bar, you can now call up your location on any page at all. Get a feel for a web where your location is just another reliable part of the browsing experience.

Where next?

So, the Geomarklet you’ve been guided through is a pretty simple premise and pretty simple output. But from this base you can start to extend: Add code that will insert each of the location renderings directly into form fields, perhaps, or how about site-specific handlers to add your location tags into the correct form field in Wordpress or Tumblr? Paste in your current location to Google Maps? Or Flickr?

Geomarklet gives you a base to start experimenting with location on your own pages and the sites you browse daily.

The introduction of consumer accessible geo to the web is an adventure of discovery; not so much discovering new locations, but discovering location itself.",2008,Ben Ward,benward,2008-12-21T00:00:00+00:00,https://24ways.org/2008/geotag-everywhere-with-fire-eagle/,code
110,Shiny Happy Buttons,"Since Mac OS X burst onto our screens, glossy, glassy, shiny buttons have been almost de rigeur, and have essentially, along with reflections and rounded corners, become a cliché of Web 2.0 “design”. But if you can’t beat ‘em you’d better join ‘em. So, in this little contribution to our advent calendar, we’re going to take a plain old boring HTML button, and 2.0 it up the wazoo. 

But, here’s the catch. We’ll use no images, either in our HTML or our CSS. No sliding doors, no image replacement techniques. Just straight up, CSS, CSS3 and a bit of experimental CSS. And, it will be compatible with pretty much any browser (though with some progressive enhancement for those who keep up with the latest browsers).

The HTML

We’ll start with our HTML.

<button type=""submit"">This is a shiny button</button>

OK, so it’s not shiny yet – but boy will it ever be.

Before styling, that’s going to look like this.

Ironically, depending on the operating system and browser you are using, it may well be a shiny button already, but that’s not the point. We want to make it shiny 2.0. Our mission is to make it look something like this



If you want to follow along at home keep in mind that depending on which browser you are using you may see fewer of the CSS effects we’ve added to create the button. As of writing, only in Safari are all the effects we’ll apply supported.

Taking a look at our finished product, here’s what we’ve done to it:


	We’ve given the button some padding and a width.
	We’ve changed the text color, and given the text a drop shadow.
	We’ve given the button a border.
	We’ve given the button some rounded corners.
	We’ve given the button a drop shadow.
	We’ve given the button a gradient background.


and remember, all without using any images.

Styling the button

So, let’s get to work.

First, we’ll add given the element some padding and a width:

button {
	padding: .5em;
	width: 15em;
}

Next, we’ll add the text color, and the drop shadow:

color: #ffffff;
text-shadow: 1px 1px 1px #000;

A note on text-shadow

If you’ve not seen text-shadows before well, here’s the quick back-story. Text shadow was introduced in CSS2, but only supported in Safari (version 1!) some years later. It was removed from CSS2.1, but returned in CSS3 (in the text module). It’s now supported in Safari, Opera and Firefox (3.1). Internet Explorer has a shadow filter, but the syntax is completely different.

So, how do text-shadows work? The three length values specify respectively a horizontal offset, a vertical offset and a blur (the greater the number the more blurred the shadow will be), and finally a color value for the shadow.

Rounding the corners

Now we’ll add a border, and round the corners of the element:

border: solid thin #882d13;
-webkit-border-radius: .7em;
-moz-border-radius: .7em;
border-radius: .7em;

Here, we’ve used the same property in three slightly different forms. We add the browser specific prefix for Webkit and Mozilla browsers, because right now, both of these browsers only support border radius as an experimental property. We also add the standard property name, for browsers that do support the property fully in the future. 

The benefit of the browser specific prefix is that if a browser only partly supports a given property, we can easily avoid using the property with that browser simply by not adding the browser specific prefix. At present, as you might guess, border-radius is supported in Safari and Firefox, but in each the relevant prefix is required.

border-radius takes a length value, such as pixels. (It can also take two length values, but that’s for another Christmas.) In this case, as with padding, I’ve used ems, which means that as the user scales the size of text up and down, the radius will scale as well. You can test the difference by making the radius have a value of say 5px, and then zooming up and down the text size. 

We’re well and truly on the way now. All we need to do is add a shadow to the button, and then a gradient background.

In CSS3 there’s the box-shadow property, currently only supported in Safari 3. It’s very similar to text-shadow – you specify a horizontal and vertical offset, a blur value and a color.

-webkit-box-shadow: 2px 2px 3px #999; 
box-shadow: 2px 2px 2px #bbb;

Once more, we require the “experimental” -webkit- prefix, as Safari’s support for this property is still considered by its developers to be less than perfect.

Gradient Background

So, all we have left now is to add our shiny gradient effect. Now of course, people have been doing this kind of thing with images for a long time. But if we can avoid them all the better. Smaller pages, faster downloads, and more scalable designs that adapt better to the user’s font size preference. But how can we add a gradient background without an image?

Here we’ll look at the only property that is not as yet part of the CSS standard – Apple’s gradient function for use anywhere you can use images with CSS (in this case backgrounds). In essence, this takes SVG gradients, and makes them available via CSS syntax.

Here’s what the property and its value looks like:

background-image: -webkit-gradient(linear, left top, left bottom, from(#e9ede8), to(#ce401c),color-stop(0.4, #8c1b0b));

Zooming in on the gradient function, it has this basic form:

-webkit-gradient(type, point, point, from(color), to(color),color-stop(where, color));

Which might look complicated, but is less so than at first glance.

The name of the function is gradient (and in this case, because it is an experimental property, we use the -webkit- prefix).

You might not have seen CSS functions before, but there are others, including the attr() function, used with generated content. A function returns a value that can be used as a property value – here we are using it as a background image.

Next we specify the type of the gradient. Here we have a linear gradient, and there are also radial gradients. 

After that, we specify the start and end points of the gradient – in our case the top and bottom of the element, in a vertical line. 

We then specify the start and end colors – and finally one stop color, located at 40% of the way down the element. Together, this creates a gradient that smoothly transitions from the start color in the top, vertically to the stop color, then smoothly transitions to the end color.

There’s one last thing. What color will the background of our button be if the browser doesn’t support gradients? It will be white (or possibly some default color for buttons). Which may make the text difficult or impossible to read. So, we’ll add a background color as well (see why the validator is always warning you when a color but not a background color is specified for an element?).

If we put it all together, here’s what we have:

button {
	width: 15em;
	padding: .5em;
	color: #ffffff;
	text-shadow: 1px 1px 1px #000;
	border: solid thin #882d13;
	-webkit-border-radius: .7em;
	-moz-border-radius: .7em;
	border-radius: .7em;
	-webkit-box-shadow: 2px 2px 3px #999; 
	box-shadow: 2px 2px 2px #bbb;
	background-color: #ce401c;
	background-image: -webkit-gradient(linear, left top, left bottom, from(#e9ede8), to(#ce401c),color-stop(0.4, #8c1b0b));
}

Which looks like this in various browsers:

In Safari (3)



In Firefox 3.1 (3.0 supports border-radius but not text-shadow)



In Opera 10



and of course in Internet Explorer (version 8 shown here)



But it looks different in different browsers

Yes, it does look different in different browsers, but we all know the answer to the question “do web sites need to look the same in every browser?“.

Even if you really think sites should look the same in every browser, hopefully this little tutorial has whet your appetite for what CSS3 and experimental CSS that’s already supported in widely used browsers (and we haven’t even touched on animations and similar effects!).

I hope you’ve enjoyed out little CSSMas present, and look forward to seeing your shiny buttons everywhere on the web.

Oh, and there’s just a bit of homework – your job is to use the :hover selector, and make a gradient in the hover state.",2008,John Allsopp,johnallsopp,2008-12-18T00:00:00+00:00,https://24ways.org/2008/shiny-happy-buttons/,code
116,The IE6 Equation,"It is the destiny of one browser to serve as the nemesis of web developers everywhere. At the birth of the Web Standards movement, that role was played by Netscape Navigator 4; an outdated browser that refused to die. Its tenacious existence hampered the adoption of modern standards. Today that role is played by Internet Explorer 6.

There’s a sensation that I’m sure you’re familiar with. It’s a horrible mixture of dread and nervousness. It’s the feeling you get when—after working on a design for a while in a standards-compliant browser like Firefox, Safari or Opera—you decide that you can no longer put off the inevitable moment when you must check the site in IE6. Fingers are crossed, prayers are muttered, but alas, to no avail. The nemesis browser invariably screws something up.

What do you do next? If the differences in IE6 are minor, you could just leave it be. After all, websites don’t need to look exactly the same in all browsers. But if there are major layout issues and a significant portion of your audience is still using IE6, you’ll probably need to roll up your sleeves and start fixing the problems.

A common approach is to quarantine IE6-specific CSS in a separate stylesheet. This stylesheet can then be referenced from the HTML document using conditional comments like this:

<!--[if lt IE 7]>
<link rel=""stylesheet"" href=""ie6.css"" type=""text/css"" media=""screen"" />
<![endif]-->

That stylesheet will only be served up to Internet Explorer where the version number is less than 7.

You can put anything inside a conditional comment. You could put a script element in there. So as well as serving up browser-specific CSS, it’s possible to serve up browser-specific JavaScript.

A few years back, before Microsoft released Internet Explorer 7, JavaScript genius Dean Edwards wrote a script called IE7. This amazing piece of code uses JavaScript to make Internet Explorer 5 and 6 behave like a standards-compliant browser. Dean used JavaScript to bootstrap IE’s CSS support.

Because the script is specifically targeted at Internet Explorer, there’s no point in serving it up to other browsers. Conditional comments to the rescue:

<!--[if lt IE 7]>
<script src=""http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE7.js"" type=""text/javascript""></script>
<![endif]-->

Standards-compliant browsers won’t fetch the script. Users of IE6, on the hand, will pay a kind of bad browser tax by having to download the JavaScript file.

So when should you develop an IE6-specific stylesheet and when should you just use Dean’s JavaScript code? This is the question that myself and my co-worker Natalie Downe set out to answer one morning at Clearleft. We realised that in order to answer that question you need to first answer two other questions, how much time does it take to develop for IE6? and how much of your audience is using IE6?

Let’s say that t represents the total development time. Let t6 represent the portion of that time you spend developing for IE6. If your total audience is a, then a6 is the portion of your audience using IE6. With some algebraic help from our mathematically minded co-worker Cennydd Bowles, Natalie and I came up with the following equation to calculate the percentage likelihood that you should be using Dean’s IE7 script:



p = 50 [ log ( at6 / ta6 ) + 1 ]

Try plugging in your own numbers. If you spend a lot of time developing for IE6 and only a small portion of your audience is using that browser, you’ll get a very high number out of the equation; you should probably use the IE7 script. But if you only spend a little time developing for IE6 and a significant portion of you audience are still using that browser, you’ll get a very small value for p; you might as well write an IE6-specific stylesheet.

Of course this equation is somewhat disingenuous. While it’s entirely possible to research the percentage of your audience still using IE6, it’s not so easy to figure out how much of your development time will be spent developing for that one browser. You can’t really know until you’ve already done the development, by which time the equation is irrelevant.

Instead of using the equation, you could try imposing a limit on how long you will spend developing for IE6. Get your site working in standards-compliant browsers first, then give yourself a time limit to get it working in IE6. If you can’t solve all the issues in that time limit, switch over to using Dean’s script. You could even make the time limit directly proportional to the percentage of your audience using IE6. If 20% of your audience is still using IE6 and you’ve just spent five days getting the site working in standards-compliant browsers, give yourself one day to get it working in IE6. But if 50% of your audience is still using IE6, be prepared to spend 2.5 days wrestling with your nemesis.

All of these different methods for dealing with IE6 demonstrate that there’s no one single answer that works for everyone. They also highlight a problem with the current debate around dealing with IE6. There’s no shortage of blog posts, articles and even entire websites discussing when to drop support for IE6. But very few of them take the time to define what they mean by “support.” This isn’t a binary issue. There is no Boolean answer. Instead, there’s a sliding scale of support:


	Block IE6 users from your site.
	Develop with web standards and don’t spend any development time testing in IE6.
	Use the Dean Edwards IE7 script to bootstrap CSS support in IE6.
	Write an IE6 stylesheet to address layout issues.
	Make your site look exactly the same in IE6 as in any other browser.


Each end of that scale is extreme. I don’t think that anybody should be actively blocking any browser but neither do I think that users of an outdated browser should get exactly the same experience as users of a more modern browser. The real meanings of “supporting” or “not supporting” IE6 lie somewhere in-between those extremes.

Just as I think that semantics are important in markup, they are equally important in our discussion of web development. So let’s try to come up with some better terms than using the catch-all verb “support.” If you say in your client contract that you “support” IE6, define exactly what that means. If you find yourself in a discussion about “dropping support” for IE6, take the time to explain what you think that entails.

The web developers at Yahoo! are on the right track with their concept of graded browser support. I’m interested in hearing more ideas of how to frame this discussion. If we can all agree to use clear and precise language, we stand a better chance of defeating our nemesis.",2008,Jeremy Keith,jeremykeith,2008-12-08T00:00:00+00:00,https://24ways.org/2008/the-ie6-equation/,code
117,The First Tool You Reach For,"Microsoft recently announced that Internet Explorer 8 will be released in the first half of 2009. Compared to the standards support of other major browsers, IE8 will not be especially great, but it will finally catch up with the state of the art in one specific area: support for CSS tables. This milestone has the potential to trigger an important change in the way you approach web design.

To show you just how big a difference CSS tables can make, think about how you might code a fluid, three-column layout from scratch. Just to make your life more difficult, give it one fixed-width column, with a background colour that differs from the rest of the page. Ready? Go!

Okay, since you’re the sort of discerning web designer who reads 24ways, I’m going to assume you at least considered doing this without using HTML tables for the layout. If you’re especially hardcore, I imagine you began thinking of CSS floats, negative margins, and faux columns. If you did, colour me impressed!

Now admit it: you probably also gave an inward sigh about the time it would take to figure out the math on the negative margin overlaps, check for dropped floats in Internet Explorer and generally wrestle each of the major browsers into giving you what you want. If after all that you simply gave up and used HTML tables, I can’t say I blame you.

There are plenty of professional web designers out there who still choose to use HTML tables as their main layout tool. Sure, they may know that users with screen readers get confused by inappropriate use of tables, but they have a job to do, and they want tools that will make that job easy, not difficult.

Now let me show you how to do it with CSS tables. First, we have a div element for each of our columns, and we wrap them all in another two divs:

<div class=""container"">
	<div>
		<div id=""menu"">
		⋮
		</div>
		<div id=""content"">
		⋮
		</div>
		<div id=""sidebar"">
		⋮
		</div>
	</div>
</div>

Don’t sweat the “div clutter” in this code. Unlike tables, divs have no semantic meaning, and can therefore be used liberally (within reason) to provide hooks for the styles you want to apply to your page.

Using CSS, we can set the outer div to display as a table with collapsed borders (i.e. adjacent cells share a border) and a fixed layout (i.e. cell widths unaffected by their contents):

.container {
	display: table;
	border-collapse: collapse;
	table-layout: fixed;
}

With another two rules, we set the middle div to display as a table row, and each of the inner divs to display as table cells:

.container > div {
	display: table-row;
}
.container > div > div {
	display: table-cell;
}

Finally, we can set the widths of the cells (and of the table itself) directly:

.container {
	width: 100%;
}
#menu {
	width: 200px;
}
#content {
	width: auto;
}
#sidebar {
	width: 25%;
}

And, just like that, we have a rock solid three-column layout, ready to be styled to your own taste, like in this example:



This example will render perfectly in reasonably up-to-date versions of Firefox, Safari and Opera, as well as the current beta release of Internet Explorer 8.

CSS tables aren’t only useful for multi-column page layout; they can come in handy in most any situation that calls for elements to be displayed side-by-side on the page. Consider this simple login form layout:



The incantation required to achieve this layout using CSS floats may be old hat to you by now, but try to teach it to a beginner, and watch his eyes widen in horror at the hoops you have to jump through (not to mention the assumptions you have to build into your design about the length of the form labels).

Here’s how to do it with CSS tables:

<form action=""/login"" method=""post"">
	<div>
		<div>
			<label for=""username"">Username:</label>
			<span class=""input""><input type=""text"" name=""username"" id=""username""/></span>
		</div>
		<div>
			<label for=""userpass"">Password:</label>
			<span class=""input""><input type=""password"" name=""userpass"" id=""userpass""/></span>
		</div>
		<div class=""submit"">
			<label for=""login""></label>
			<span class=""input""><input type=""submit"" name=""login"" id=""login"" value=""Login""/></span>
		</div>
	</div>
</form>

This time, we’re using a mixture of divs and spans as semantically transparent styling hooks. Let’s look at the CSS code.

First, we set up the outer div to display as a table, the inner divs to display as table rows, and the labels and spans as table cells (with right-aligned text):

form > div {
	display: table;
}
form > div > div {
	display: table-row;
}
form label,
form span {
	display: table-cell;
	text-align: right;
}

We want the first column of the table to be wide enough to accommodate our labels, but no wider. With CSS float techniques, we had to guess at what that width was likely to be, and adjust it whenever we changed our form labels. With CSS tables, we can simply set the width of the first column to something very small (1em), and then use the white-space property to force the column to the required width:

form label {
	white-space: nowrap;
	width: 1em;
}

To polish off the layout, we’ll make our text and password fields occupy the full width of the table cells that contain them:

input[type=text],
input[type=password] {
	width: 100%;
}

The rest is margins, padding and borders to get the desired look. Check out the finished example.

As the first tool you reach for when approaching any layout task, CSS tables make a lot more sense to your average designer than the cryptic incantations called for by CSS floats. When IE8 is released and all major browsers support CSS tables, we can begin to gradually deploy CSS table-based layouts on sites that are more and more mainstream.

In our new book, Everything You Know About CSS Is Wrong!, Rachel Andrew and I explore in much greater detail how CSS tables work as a page layout tool in the real world. CSS tables have their quirks just like floats do, but they don’t tend to affect common layout tasks, and the workarounds tend to be less fiddly too. Check it out, and get ready for the next big step forward in web design with CSS.",2008,Kevin Yank,kevinyank,2008-12-13T00:00:00+00:00,https://24ways.org/2008/the-first-tool-you-reach-for/,code