That's when I reach for my revolver
Still a great song, 20-odd years after it was first released.
« July 2007 | Main | September 2007 »
Still a great song, 20-odd years after it was first released.
He never talked about it.
A couple of people have asked about the CSS magnifier that I wrote for the National Maritime Museum web site, so this is a test to see if I can easily embed a magnified image in a blog post.
There are a couple of small bugs that need fixing: the positioning is slightly off, and the styles for notes are being overriden by the local CSS. Otherwise, it seems to work without any modification of the original code.
To add the magnifier to an existing image, you'll need a copy of the CSS file, youngpup's DOM-Drag script (for the drag and drop functionality) and the magnifier javascript. Save these to your web server, and link them to the page that you want to use them on. Now, you'll need to change the markup around your image. The markup I'm using is the following:
<p>
<a href="http://www.flickr.com/photos/eatyourgreens/323377296/"
title="See the original photo on flickr">Parc Guell</a>
<a id="ZTbutton" href="javascript: void(0);">Zoom on/off</a>
</p>
<p id="ZTthumbnail">
<img id="zoomImage" src="http://farm1.static.flickr.com/82/323377296_fdf9f077e8.jpg"
width="500" height="375" alt="Parc Guell" />
</p>
Finally, you'll need to add some JavaScript to add the magnifier to your photo:
<script type="text/javascript">
addEvent(window, 'load',
function() {
HotSpotController.init("zoomImage",150,
'http://farm1.static.flickr.com/82/323377296_fdf9f077e8_o.jpg','ZTbutton');
});
function addEvent(obj, evType, fn) {
if (obj.addEventListener) {
obj.addEventListener(evType, fn, false);
return true;
} else if (obj.attachEvent) {
var r = obj.attachEvent("on" + evType, fn);
return r;
} else {
return false;
}
}
</script>
The arguments to HotSpotController.init() are: the id of the image that you want to magnify; the size of the magnifier in pixels (adjust as necessary); the URL of a large image to use as the magnified view; the id of the link to use as the on/off button.
This particular code gives us the image shown below. Turn the magnifier on and off with the ‘on/off’ link. Move it around by either dragging with the mouse, clicking on the photo to select a particular point or use the cursor keys when the on/off link has focus (shifted cursor keys to scan quickly around the photo.)
Bruce Lawson takes time out from exploring the sultry ladyboys ancient Bhuddist temples of southeast Asia to write about the landmine problem in Cambodia. Two people a day are blown up by Cambodian mines, on average.
Unrelated to that, I spent some birthday money (thanks Matt!) on new music this week and I wanted to say that Built to Spill's ‘Goin' against your mind' is one of the best songs I've heard in ages. You can listen to it free on builttospill.com.
I love Sally Timms' voice on this one. Spent the afternoon copying a bunch of Mekons/Jon Langford stuff to iTunes.
We've launched an astronomy blog at work. Astronomy news posted by yours truly, among others. Hopefully it will grow into an interesting and informative read.
Continuing my love-hate relationship with microformats, the tags in the blog are marked up using the rel-tag microformat. This means software, such as Operator for Firefox, can recognise the tags and offer links to similarly tagged content on delicious and flickr. Kind of cool in the case of the Perseids, as you can link immediately to photos of the meteors.
Rel-tag, rather bizarrely, uses the linked URL, rather than the linked text, to identify the tag. Movable Type, by default, publishes tag links as links to the MT search script with a rel="tag" attribute: <a rel="tag" href="http://mydomain/mt/mt-search.cgi?tag=something&blogID=1">something</a>. The upshot of this is that MT, by default, tags your blog posts with the tag mt-search.cgi, according to the rel-tag spec. For the microformat to work, your links have to be something along the lines of http://mydomain/tags/something. For instance, the tag links in our blog are now rewritten as http://www.nmm.ac.uk/rog/tag/perseids.
Rewriting the links requires editting the MT blog templates, and reconfiguring your web server to map the new URLs to the URL of the MT search script. Have a look at cleaning up your tag links for details.
I do wonder, though, how many people will want to use the microformat if it requires rewriting the URLs on your web site? It seems contrary to the principle that microformats are simple and easy to use.
Having posted previously that all the excitement in the microformats world seems to be around publishing them, it was exciting to read that getsatisfaction.com uses microformats on its registration page. Pick a service that you've previously registered for, and the magic of microformats will copy your personal details across for you. So I wandered over to try it out.
“Rather than creating yet another profile, why not start with one you already have?” Okey doke - I'm registered with last.fm and flickr, so why not give those a whirl? First, last.fm - “Add your last.fm username” says the (very swish) form. I obediently type ‘pekingspring’. “This profile does not support hCard” says the form. Doh! No worries, I'll try my flickr username - ‘eat your greens’ This gives me the following message “I'm sorry, but an unexpected error occured: URI::InvalidURIError”. Furthermore, it's in a big red box. Not a good thing, I'm guessing. Silly me for having spaces in my username.
But wait, I forgot that I had an upcoming.org account. I'll give that a whirl. “Sweet! We found it!” says the form (woo hoo!) but my personal details remain blank on the registration form (doh!). I wander off to write a blog post about my exciting microformats experience…
Just watched the Pixies at Newport DVD, courtesy of Amazon DVD rental. A mellow, acoustic gig from an American folk festival. It's good, although odd to hear subdued versions of River Euphrates and I Bleed. Reminds me of listening to Greg play Gouge Away on his acoustic guitar, back when he was living in a cabin in the woods in upstate New York.
I couldn't seem to find this in the Movable Type manual, but here's the code that produces a Recent Comments list in the blog sidebar:
<div class="module">
<h2 class="module-header">Recent Comments</h2>
<div class="module-content">
<ul class="module-list">
<MTComments lastn="6" sort_order="descend">
<MTCommentEntry>
<li>
<a href="<MTEntryPermalink>#c<$MTCommentID
pad="1"$>"><$MTCommentAuthor$></a>
said “<$MTCommentBody remove_html="1"
trim_to="100"$>…”
</li>
</MTCommentEntry>
</MTComments>
</ul>
</div>
</div>

This coming weekend sees the peak of the Perseids meteor shower. Annual meteor showers occur when the Earth's orbit around the Sun passes through the orbit of a comet. Dust and debris, which the comet has left along its path, burns up in the Earth's atmosphere. We see the results as shooting stars in the night sky.
Peak activity for this year's Perseid shower is predicted to reach 80-100 shooting stars per hour before dawn (in Europe) on Monday 13th August. Read more about the 2007 Perseids at the European Space Agency.
A while back, Bruce Lawson and James Craig wrote hAccessibility, about the abbr design pattern and potential problems that it raises for people who browse the web with screen readers. Since then, there has been some useful discussion on how to make microformats more friendly to screen readers, which is great.
The core problem is this - certain microformats require machine readable data to be encoded in the HTML of a web page. For example, hCalendar stores a machine readable date which can then be used to export your event data to a calendar. Cool stuff, but the readers of your web page get a bunch of gobbledigook presented to them in a little tooltip. Try hovering your mouse over the following phrase to see what I mean - this Wednesday. A blind reader hears the phrase 'this Wednesday' expanded as bunch of meaningless numbers. Someone looking at the web page (and using a mouse) will see a tooltip with a bunch of meaningless numbers (I'm assuming here that most people don't automatically recognise ISO-formatted dates, which is what 2007-08-08 is).
A solution to this problem would be to fix screen readers so that they read out the string '2007-08-08' as '8th August 2007', or whatever the local equivalent for publishing a date is wherever you happen to be reading this. Effectively, it seems to me, the code above needs to be transformed to - this Wednesday.
I wonder, though, if this transformation isn't better performed by the web browser itself, then sent to the screen reader to be read? The web page that you read is not the original HTML sent from the web server, but the resulting DOM after it has been parsed by your browser's HTML parser and processed by any scripts or browser extensions that happen to be running. The machine-readable date stored in the abbreviation title in the original HTML could be processed by a script, or browser extension, and transformed into a localised, human-readable title, after the HTML is loaded but before it's rendered to the viewer. A javascript to do this shouldn't be hugely difficult.
This approach solves the fundamental problem of misusing abbreviation titles to contain unreadable content - surely a breach of the accessibility and usability guidelines which ask us to write our content in the clearest, simplest language for our users? The title attribute is content, after all.
However, I still have reservations. Firstly, using a script to process a microformatted date might not be readable by JAWS or Window-Eyes. Steve Faulkner recently demo'ed some cases in which the parsed DOM is modified with a script, but screen readers don't pick up the changes. Personally, I think this has to be addressed by the makers of assistive technology. A web browser which can't read out scripted changes to the DOM is pretty much crippled on the modern web. It is a real, practical issue, though - if a solution works for sighted users in IE/Firefox/Safari/Opera etc. but doesn't work in a popular screenreader, such as JAWS, then is it a useful solution? It's certainly not an accessible solution, unfortunately.
Secondly, does the person reading the page need a date expanded as an abbreviation in the first place? Reading the phrase 'this Wednesday' above, did you really need to be told that this refers to '8th August 2007'. The abbr design pattern is a hack, and not a particularly elegant one, to make up for HTML 4 not containing a tag, or attribute, to semantically describe dates and locations. So the microformat is very useful to machines, but I'm not aware of any usability studies which show that it enhances the value of the page for people.
Finally, taking hCalendar as a specific example, there doesn't seem to be a lot of demonstrated value in microformats at the moment. They are nice, really really nice, and some great things could be done with them. But I'm not sure that I can, for example, use hCalendar on the National Maritime Museum's event calendar and have the events automatically recognised by a search engine, or harvested by a service such as Upcoming. So I'm not sure that there's a great incentive to publish microformatted data yet - it still seems to me very much like a geek, niche thing. Lots of people are publishing them, but is anyone doing anything useful when it comes to consuming them? Because if that started to happen on a wider scale, then there would a real, demonstrable value to adding microformats to a web page. At the moment, the lack of this, coupled with accessibility problems makes me nervous about using microformats myself.
Slack motherfucker - superchunk's theme song, I guess. I saw them on the come pick me up tour and jumped around The Garage like a, well like a man who'd drunk too much beer, when they played this at the end. Larry Livermore bought me more beer. What a nice bloke.