The utm_medium is pretty straightforward in that the medium would be values like email, web, twitter, rss, and so on.

But, what’s the difference between utm_source and utm_campaign?

Google’s documentation on these variables is helpful in general, but is not all that clear on the difference between these two variables.

So, here’s how I think of those variables. The utm_source is like a noun, and utm_campaign is like an adjective. The utm_source will be more consistent from one edition to another, while the utm_campaign will change.

Let’s look at an example. Let’s say I send an e-mail newsletter called Brilliant Widgets every season (Spring, Summer, Fall, and Winter), and I want to track how many links back to my website each edition generates. Here are the utm_* values I would use.

utm_* values for the Winter edition of Brilliant Widgets

So, the href value of the link back to my website would look like this: http://blog.davingranroth.com/?utm_source=Brilliant_Widgets&utm_campaign=Winter_2011&utm_medium=email

Now, assuming I use those parameters on the links back to my website and that my website activity is being tracked with Google Analytics, I’ll be able use Google Analytics to identify website visits that came from that e-mail newsletter. Then for the next edition, I would keep utm_source and utm_medium the same, but update to utm_campaign=Spring_2012.

With this thinking, you could define a set of values for all the e-mails you send out, and create a system that would help you know what those values should be when you introduce new online publications.

I’m sure that other people and companies have come up with their own approaches to using these utm_* values.

I’m curious, does anyone else have different ideas or examples to share?

Let’s say you had an abbreviation, like CSS, that you wanted to put into small-caps, say with a little extra tracking. You might think you could use the CSS property font-variant: small-caps, and you’d be good to go. Not so.

Here’s why. Because for small-caps to work, you need to start with lowercase letters.

However, when you’re simply typing your thoughts out before you’ve decided on small-caps for abbreviations, acronyms, etc., you probably typed those abbreviations in uppercase.

So, when you tried small-caps, it simply didn’t work. For example, see this web page from 2005 that Joe Clark wrote to test small-caps. Note how the small-caps versions are more like regular capital letters. Not cool. It makes the hack look good, which is bad.

So, here’s what you can do (and what I think browsers ought to be doing automatically anyway):

1. First apply text-transform: lowercase
2. Then apply font-variant: small-caps

That ought to do it.

Here’s a more specific example of the CSS.

abbr, acronym {
text-transform: lowercase;
font-variant: small-caps;
letter-spacing: 1px;
}

We all know the <br /> tag is used to insert a line break in HTML. But what we’ve been missing is that we were too often after something else. Let me explain.

Common reasons to use line breaks

Why would a web writer interrupt a passage of text with a forced line break? Here are a few possibilities.

• Trying to avoid an orphan
• Inserting a line break before a 2-word proper noun, like “American Airlines,” so the noun isn’t split
• Formatting content like a mailing address

The problem with line breaks (<br /> tags)

Forcing a line to break in a document that will be printed is a no-brainer. But web writing has different constraints that we shouldn’t ignore.

Copy on the web has the luxury and burden of being portable. That text can show up anywhere:

• in an e-mail message
• on some other web page
• in an RSS reader
• copied and pasted into a Tweet
• in a web browser on a mobile phone

This means that the line length you wrote your text for is simply not reliable. You need to consider how that text will show up in other places too, at unknown line lengths.

A line break may look fine on your screen, but it might look really awkward when that text appears somewhere else beyond your control.

Instead of splitting text, stick text together

Orphans

Avoid orphans especially where the text is most likely to appear, but relax. You can’t prevent them altogether.

Instead of inserting a line break, opt to rephrase the text to change the length and prevent the orphan. But realize that when that text appears elsewhere, it might just have an orphan.

You also have the option of a special white-space character called a non-breaking space. In HTML, it looks like this:  . When you put a non-breaking space between two words, those two words will always be on the same line of text.

2+ word proper nouns

If you want to be sure that “American Airlines” remains on the same line in body text, employ a sprinkle of CSS magic. In the markup, a corporate name should be contained within a span element, like this:

<span class="brand_name">American Airlines</span>

And then to make sure that those two words stay on the same line, add a line like this to your CSS file.

.brand_name {white-space: nowrap;}

That will prevent the brand name text from being split at the end of a line. Instead, both words will flip to the next line if there is not enough room for them on the current line of text.

Formatting content like mailing addresses

In this case, I’m actually okay with using <br /> tags. But, left to my own devices, I might use some different markup and some CSS instead.

Let’s say we have an address like this fictional one.

You could just put that text in an address element and use line breaks.

Or you could mark it up in the hcard microformat, and then think about styling it based on that markup. So, it might instead be coded like this.

<address class="vcard">
<span class="fn">Samuel Clemens</span>
<span class="street-address">1835 Huckleberry Row</span>
<span class="locality">Hannibal</span>,
<abbr title="Missouri" class="region">MO</abbr>
<span class="postal-code">63401</span>
</address>

And then a little bit of CSS like this would take care of the line breaks.

.vcard .fn,
.vcard .street-address{
display: block;
}

The point: we overuse line breaks because they don’t require any extra thought

Instead, let’s consider why we actually want a line break the next time we go to use one. There’s probably a better option once you realize that you don’t actually want to break a line of text, you really just want some of the text to stick together.

So after I upgraded this blog to WordPress 3.01′s Twenty Ten theme, I was mildly irritated to find that I had a few validation errors. I viewed the source code to investigate the offending lines of code, and noted that the code the validator cited was not in the source.

This phantom code led me to suspect that DOM scripting from a plugin caused the errors by inserting more code into the markup. That was it, and this evening I finally took the time to track it down. Here’s the scoop.

First, the phantom code that broke validation

The error indicates an empty target attribute. It turned out, this code was inserted by a plugin.

Honestly, the first time I saw this error message, I didn’t notice the error text that pointed to the target attribute. No, I was first startled by a pattern that looked to me like the tail-end of Javascript code used in an anchor’s href or onclick attribute. I was startled because, having already looked through the code, I thought I would’ve noticed that pattern, since it is one that I avoid.

Where was this code? Well, all 9 errors were in the same area of code: links to other websites (blogroll) in the sidebar. I wanted to see it for myself, so I opened the page and viewed the source code. I used the Find command and pasted in some of the code from the validator error message, but the Find came up empty-handed.

While the offending code was not in the served markup, the validator was certainly picking it up, so I went back to the validator to examine that code in more detail.

Code with an onclick Javascript snippet inserted for Google Analytics tracking. Note the target attribute.

The value of the onclick attribute was the immediate tell for where this code came from. It was the Google Analytics plugin I’m using.

Investigating the plugin that caused the validation error

Google Analytics for WordPress is a fantastic plugin. It makes integrating Google Analytics easy, and it has some excellent advanced settings.

One setting is to track outbound clicks and downloads as events so they are are viewable in Google Analytics.

Checkbox to track outbound links in WordPress.

To test the theory, I unchecked that box, saved the settings, and revalidated the web page.

It passed with flying colors.

Validation error identified, but I’m actually curious about tracking downloads

For the time being, I’m okay with leaving that feature turned off. I’ll let the plugin author know about it and hope the problem will be resolved soon.

Yes, I lose a feature to get back to valid code. Perhaps there is a support group for this kind of behavior.

But in my defense, this is just a personal site. I don’t make any money on it, and my interest in tracking downloads is just curiosity. I only have a few downloads or outbound links I’m interested in, and I have nothing riding on that knowledge beyond satisfied curiosity.

Still, the entirety of this problem can be laid to rest on a simple, meddlesome, and empty target="" attribute. That’s irritating.

I found out that they were a little shorthanded on specialized web help, so I  volunteered to assist. Pabini Gabriel-Petit, the publisher and editor-in-chief, graciously accepted my offer.

Creating print CSS is usually simpler than web page layouts, because the goal is typically to have the content of the page print out well on standard size paper. Multiple columns and site navigation are usually uncalled for.

My first try was to revise the existing print CSS file. After half an hour at that, I decided it would be simpler to start from scratch. The original print CSS was quite complex, and it seemed I was searching for one issue: why did the pages stop printing after page 1?

So I rewrote the CSS, simplifying the CSS code greatly. I had the layout in good shape, but oddly still had the 1 page issue.

I went back to the main screen CSS file and begin sifting through it, looking for clues. Then on a hunch, I found the issue.

The global CSS file is thick. There’s a ton going on there to defend against various cross browser issues. One particular rule I saw repeatedly was the use of overflow: hidden. That rule is used for a few reasons, but one of them is to force a floated box (div or what have you) to expand when it wants to collapse, vertically. This allows things like backgrounds to show through properly.

One of the selectors that this rule was used on was actually a wrapper for much of the page content. It made sense to me, in a way, that this could confound a browser into hiding paged content that went beyond a page.

So the real key to the much simpler CSS file was to add in an overflow: visible to a large set of selectors to override that overflow: hidden for printed pages.

I sent Pabini the new code, and over the following weeks she tested it and added some details I had missed. About a month ago she deployed the new print CSS code  to the website.

This little evening project was a fun puzzle, and I’m glad I was able to help make such great content on the UXmatters website print out better for more people.

(Back in 2002 or 2003, I forget when, I wrote an article on print styling for web pages.)

Home page of Newsweek.com, May 31, 2010

I don’t know when it happened, exactly, but Newseek.com was recently redesigned. There is so much to say about it, and it is mostly good.

I’ll start with the most obvious: the design.

In short, the home page is easy to scan. There is a clear visual hierarchy. The lead photos and articles have been spot-on for Memorial Day news items, and the clarity of the layout made certain I couldn’t miss them.

The article pages are easy to read and keep enough of the patterns, like the byline and publication date, that it’s easy to figure out what’s what.

My biggest complaint is one that they no doubt haven’t figured out how to get rid of yet: the banner ads.

There’s more talk about the visuals for the new newsweek.com at nymag.com. I won’t go on about that, myself, other than to say, gee, it looks like a professional blog. Oddly, that’s a compliment.

Now let’s look at the markup.

Newsweek.com's namespaces point to interesting uses of meta data.

I’ve had a penchant for information architecture since the late 1990s, and about the first thing I noticed when glancing at the markup for the home page is the references to the Dublin Core meta data definitions and other meta data sets.

I was suddenly intrigued. Good use of meta data is sadly absent in many large-scale websites, and it’s really great to see an effort to play the game for real.

So, at a quick glance through the markup you’ll notice some unusual pieces, first this:
data-track="{'title':'stories being discussed'}", which is an attribute with a value that looks a bit like JSON.

I admit to being behind the times with studying HTML 5, but that attribute spurred my suspicion that this page was using HTML 5. I stopped wondering a few lines later when I spotted an article element, followed soon thereafter by a header element, and a nav element sporting an attribute of role="navigation". Whoa. Newsweek jumped right in.

So what about the meta data? Well, I can’t really know what they’re actually doing, but here is an observation. In a sidebar, they have a list of quotes. Each quote is marked up as a blockquote with an id attribute. Following each quote is a span with attributes like property="dc:creator" and about="#q1". The about attribute refers to the id of the blockquote in question. The content of that span itself is the name of the quoted person, plus which publication the quote came from.

Pretty cool idea: internal markup references like this can build relationships into the content. It could provide some interesting opportunities for parsing later on. Yeah, that’s right, the semantic web.

The problem with this all is…it’s half-baked!

Newsweek.com used "http-equiv" when they needed "name". Oops.

That list of quotes with the ID attributes? All that meta data is duplicated and thereby meaningless! Further, why use a span element when they could have used a cite element? More semantic and those attributes would’ve played as well. Gah!

And back at the top of the markup by those meta data namespace references there is another set of meta tag elements which are sadly marked up incorrectly.

There is a stack of 5 meta elements that use the http-equiv attribute when they should have used the name attribute. I’ll bet whoever coded that knows the difference, but I wonder if they were rushed to get this version out. It feels like a beta.

They are so close to providing some really great examples of meta data use in HTML 5! I hope they release another version soon that gets more precise and cleans up some of this code.

The basic functionality is to provide a checkbox on web forms to reveal the password text, so people can choose to view the password they are entering as they enter it.

Well, this morning I was looking through some old files and found a text document I wanted to print that I had done using Pages. Unfortunately, I had removed iWork from my Mac, so I no longer had the software to open the Pages document.

After a cursory search on the Internet for a program that would let me open Pages docs without having the program itself, I came up empty-handed.

So, I inspected the Pages document and realized it was a package. (Right click on the document icon and Show Package Contents.) The package contained an index.xml.gz file, which I unzipped and found within the body of my document amidst a whole bunch of XML code.

I momentarily considered reconstructing the text in TextWrangler, but thought it might be fun to write an XSLT file to do the work.

Please note that this is a 1st draft meant to retrieve the text from my document. It will not handle anything fancy, just text. Plus, it will only try to make each chunk of text into a plain-text paragraph in HTML, suitable for copying and pasting out of a browser window. Use at your own risk.

Ok, here’s the textFromPages.xsl file.

Others may take this initial XSL file and do what they will with it. I hope that if you take this and make it better, you’ll comment on this post to let me (and others) know.

To have it be useful to you, you’ll need to know how to apply an XSL transformation to a source XML file (specifically the index.xml from Pages).

Hint: Firefox will do the transformation for you if you include the proper xml-stylesheet directive right after the XML prologue in the source XML file. It looks like this: <?xml-stylesheet href="textFromPages.xsl" type="text/xsl" ?>

At first, this may seem obvious (Well, yeah, you didn’t select them, dummy!), except that it runs counter to every other form field.

If you have a text field named “surname” and you submit the form with no value in “surname”, the submission still includes the variable name “surname” but it has no corresponding value. You have the key with a null value.

It’s the same with textareas, any other type of input element, and select lists (where you are limited to a single selection). Even named buttons submit their values.

So, the stealthy cuplrits:

• input type=”radio”
• input type=”checkbox”
• select multiple=”multiple”

Adam and I learned this in the midst of discussing and testing code this evening.

For many programmers and Web developers, having to write up a regex (regular expression, a pattern matching utility found in many programming languages) involves having to dig out a book or look up a website that has the syntax. And then you need to figure out how to write a regular expression that will test some value to see if matches your expression.

Here’s a fun little example of a regex I found on a listserv archive. This one is supposed to verify a valid URI.


(([a-zA-Z][0-9a-zA-Z+\\-\\.]*:)?/{0,2}[0-9a-zA-Z;/?:@&=+$\\.\\-_!~*'()%]+)?(#[0-9a-zA-Z;/?:@&=+$\\.\\-_!~*'()%]+)?


Nobody wants to write that kind of madness. (Ok, yes, some of you do want to write that stuff. You are crazy. Thank you for being crazy. Just post your mad regexes to your blog so we can find them.)

So, regular expressions are helpful for things like validating input to a system. Any Web programmer realizes what an understatement that was.

The idea behind regexer is provide a website in which you can enter a few examples of the values that you want to test, and the site will suggest a regular expression that will do the trick for you.

Whoa. That’d be nice.

And helpful in a many applications, as regular expressions are used in Javascript, PHP, ASP, Perl, .Net, and so on.

So, this is a work in progress, but Adam does have some of it working. Go ahead and try it out the next time you need a regular expression. And, send him feedback if it works or if doesn’t work. He’ll take that info and it can help him make it better for all of us.

The Javascript I had posted earlier fell short in one important arena: when you submitted the form without entering your own text, the form would send in the instructive text. It should instead have erased that text prior to the form submission.

Further, in retrospect, the code was trying to do too much. It is enough to simply set a class of blurred and then remove it, instead of replacing it with a class of sharpened.

So, with that in mind, here is an updated set of Javascript that can be used to insert instructive or suggested texts into form fields, like text input fields or textareas.

The code

To start with, we need some scripts to add and remove classes values from an element. The one caveat when doing this is to remember that you can have many class names assigned in a single class attribute. So, when adding and removing class names, you have to be sure to leave pre-existing class names alone. Instead of writing these functions, I did a quick Google search for “Javascript addClass” and found these handy Javascript functions, hasClass, addClass, and removeClass, at openjs.com. I’ll let you look there for that code.

With those class manipulation functions in hand, I rewrote the setSuggestedFormText function down to this.


/* setSuggestedFormText takes 2 arguments, mode and field.
/ mode is either set to put in place the suggested text
/ clear is to remove the suggested text
/ the set mode also assigns adds a class of blurred
/ field is the value of the ID attribute of the input or textarea element
/ April 13, 2008, Davin Granroth, granroth@gmail.com.
*/
function setSuggestedFormText(mode, field){
var key = document.getElementById(field);
var defaultText = key.title;
if(mode == 'set'){
if(key.value == '') {
addClass(key, 'blurred');
key.value = defaultText;
}
}
if(mode == 'clear'){
if(key.value == defaultText) {
removeClass(key, 'blurred');
key.value = '';
}
}
}

This function takes two arguments: mode and field. The first, mode can be either of set or clear. The one puts in the suggested text from the title attribute of the element, and the other clears it out. Each checks to see if the value of the field has been edited, in which case it respects the user input.

The next step is to set up the function which triggers this function at the appropriate events. There are three events at which the function needs to be called: when the page loads, when focus is put on the field, and when focus is removed from the field. Here is the code for setUpSuggestedFormText.


/*
/ field is the id of input or textarea field
/ parent is the id of the containing form element
*/
function setUpSuggestedFormText(field, parent){
if(document.getElementById(field)){
// This will set the text on page load
setSuggestedFormText('set', field);
// These 2 events will toggle between the set and clear modes
document.getElementById(field).onblur = function(){
setSuggestedFormText('set', field);
}
document.getElementById(field).onfocus = function(){
setSuggestedFormText('clear', field);
}
// Clear the text before sumitting the form.
document.getElementById(parent).onsubmit = function(){
setSuggestedFormText('clear', field);
}
}
}

This setUpSuggestedFormText takes two arguments: the id of the field element and the id of its parent form. The id of the parent is used in the trigger for the form submission. I had considered using a parentNode property to find it, but depending on the markup in the form, it may be multiple parentNodes up. So, this is less code. However, if someone wants to write up the function to recursively walk up the parentNode tree to find the parent form’s id, I’d be happy to incorporate it.

The last step is to call the setUpSuggestedFormText once the DOM has loaded in the page. One slightly intrusive means of doing this is to put a Javascript setUp function just before the closing body tag. You can, of course, choose to use something like an addDOMLoadEvent (Google for that) function. Here is what the setUp function looks like in the Javascript.


function setUp(){
setUpSuggestedFormText('to','msgForm');
setUpSuggestedFormText('from','msgForm');
}

You can download sample code which uses an illustration of a message form with from, to, and message fields. The download is a ZIP file which contains an XHTML file, a CSS file, and a Javascript file.

Over the last year or so, I’ve worked on a number of websites where I wanted to add instructive text to form fields, but didn’t want that text to get in the way when a person actually tries to fill out the form. So, behavior-wise, the page would load with instructive (or suggested) text in the fields. It should have a class attribute that can be used to style it so it doesn’t look like a real value (grey and italic, for instance). When someone clicks on the field, the instructive text should go away and the class should go away so the default styling kicks in. When someone clicks off, the suggested text and class should pop back in, so long as the field is empty. The instructive text should come from the title attribute on the field (that made the most sense to me, given all the options).

So, here are a couple Javascript functions to do so.


function setSuggestedFormText(mode, field) {
/*
mode values must be one of: set, clear, or reset
set is to check the value on page load
clear is to clear the default value when someone clicks on the field
reset is to fill in the default value when someone clicks off the field
field is the value of the ID attribute of the input or textarea element
Use .blurred and .sharpened selectors in your CSS file
*/
var key = document.getElementById(field);
var defaultText = key.title;
switch(mode) {
case 'set':
if(key.value == '') {
key.value = defaultText;
key.setAttribute('class', 'blurred');
}
break;

To use these functions, add them to your site’s Javascript library, and then call the following functions when the document is loaded. Google for adddomloadevent or you could probably use jQuery’s document.ready function.

Ok, usage. Let’s say you have an input field for an email address, like so:


<input type="text" name="email"
id="email" title="Your e-mail address" />

You would add the following javascript code to trigger the functions.


// Once the DOM is loaded, call this function
setUpSuggestedFormText('email');

Feel free to use it. If you make an improvement, please let me know.

To see it in use, try the search form on this page. For now, the Javascript source is at http://davingranroth.com/blog/custom.js

Alright, so if you look up “Nephtali” on thinkbabynames.com, you see it listed as a variant of “Naftali.”

The boy’s name Naftali \n(a)-fta-li, naf-tali\ is of Hebrew origin, and its meaning is “struggling”. Biblical: a son of Jacob and one of the ancestors of the 12 tribes of Israel.

“Struggling.” Apt.

How many phone calls from Adam have I received in the last year that began, “With Nephtali, if you were to do [blah blah blah], which of these approaches would you like the best?”

Countless. Every other day is a conservative estimate, considering that many days, there were many phone calls.

The man has been obsessively working on this “Nephtali.” Yesterday, in our ritual Nephtali conversation, he said, “So old man, it’s time to post this to your blog.”

After so many versions and so much work on Adam’s part, it’s time to break the silence.

What is Nephtali?

Well, I’ll give you my take on it, but for the practical details (and a download), go to nephtaliproject.com.

Nephtali is a framework for the development of data-driven websites. It uses PHP 5 and is object-oriented. It’s flexible, extensible, and plays nicely with other frameworks, like the Pear and Zend frameworks. Because of how it handles data, developers will tend to write more secure Web apps. It separates the presentation from the programming logic well, so that it is easy to use a tool such as Dreamweaver without worrying about messing up the behind-the-scenes programming. And, the API was written with a continual drive to make it user-friendly for programmers, while maintaining a value on security.

My experience with Nephtali, thus far

I’ve played with a couple iterations of Nephtali, and once getting oriented, I found I like it. (Granted, I’m biased having had so many discussions with Adam about it.)

Compared to CakePHP, Nephtali is easier to use. For instance, in CakePHP, or other Model-View-Controller frameworks (e.g., Ruby on Rails), database models are abstracted and then calls in the app rely on those abstractions. While there is a great benefit to this, I’ve found the abstractions themselves to be problematic. Nephtali can provide abstraction to fairly simple database actions (standard CRUD operations), but, gosh darn it, I like being able to jump in and write SQL. The reality for me as a developer is that database model abstraction causes me more grief than they are worth. Abstraction can slow me down, especially when the queries and relationships get tricky. Now, one of the big benefits to abstraction is that it can promote the DRY principle. Nephtali provides well for that, through implementing sub-classes, and I still have the direct, easy line to thinking about and working with the data in SQL.

The future of Nephtali

I could go on, but the proof for Nephtali will be in how many sites it is eventually used on, and how many other developers get their heads into it.

So, developers, check out Nephtali. And if you have questions or suggestions, do not hesitate to dialogue with Adam about it. And tell him to post a screen-cast of building a basic app with Nephtali.

For now, I’m going to see if I can get Adam to smash a bottle of champagne over his development box in honor of this release. Congrats, Adam!

In the course of work this week, we discovered that Yahoo! and Google still have record of a section of a website we removed nearly 4 months ago.

Surely the search engine robots had revisited the pages, repeatedly received 404-File Not Found errors, and proceeded to removed those pages from their indexes, right?

Apparently not. Here’s one explanation as to why.

Context: Using robots.txt in the process of removing old pages and posting new ones

I had also recently glanced at the robots.txt file for the domain in question, and noticed that there was a disallow rule applied to the pages that we had removed.

Four months ago, we released a new web service to replace one provided by these old pages. For a period of time, we kept both online with forwarders in place. During this time we added an entry to robots.txt to prevent spiders from indexing the old pages, and we encouraged indexing of the new pages by providing links to them.

Once we removed the old pages, we didn’t think to remove the entry from robots.txt. Afterall, the pages weren’t there, why would it matter?

Well, my revised theory holds that it does matter.

Hypothesis: Excluding the robot with robots.txt stopped it from even checking that the page was there. So, with no confirmation that the page was gone, it didn’t tell the indexer to update the records.

Here’s the scenario, from a search engine spider’s perspective.

(This model probably doesn’t technically match what’s going on in reality, but I hope it’s close enough to get some insight from.)

As a spider, I crawl links to pages, and when I find good pages (HTTP response of 200-OK), I read what textual data I can and send it back to the indexer to update our records.

However, if I try to get to a page, but the server tells me the page isn’t there, I send that as a note back to the indexer, and proceed to try to read the next page.

After receiving a few of these File Not Found messages over time about the same page, the indexer will remove that record from the index, as a matter of housekeeping.

Our problem may have been that we posted a robots.txt file which prevented the spiders from even trying to access these pages, and so when we had the pages removed, the spiders never had a chance to get the 404 error. So, they never communicated back to the indexer that there was a problem with the pages. So, the indexer never triggered its housekeeping activities and has left the pages referenced in its index.

Moral of the story: Don’t screw with spiders.

Had we left robots.txt well enough alone, the spiders would have found the bad links and soon enough the indexes would have been updated. Because we short-circuited their processes, we have preserved index reference to pages that have long since died.

Next, I think, I’ll load this XML file into PHP using the simplexml features which will make it easy to run the data through a PHP-based GeoCoding processor that I’m sure I can dig up. The goal is to transcode the addresses of the ranges into latitude/longitude points, which seem to be required pieces of data for the KML file I’m trying to piece together.

I may at the same time output the whole thing into KML format, since I’ll be in there with the data nodes anyway.