Javascript textile previews

After my original post about it, it’d probably be good to point out that Jeff Minard has taken the idea and run with it, introducing

  • h tag support
  • br tag support
  • proper html syntax (a few tags were being closed incorrectly.)
  • Various small fixes

Of course, have a Blogger-hosted blog I can’t make use of any of these oh-so-clever solutions (because of user recognition I think – otherwise I could just provide my own form), but it’s good to keep up with the wizards.

North-south split ‘getting wider’

At least, so says a study by Sheffield University, which goes on to say that the south “r0xx0r” and “pwnz” the north. Almost

You are NOT from Yorkshire!

You are probably a softie Southerner, or a Northerner who’d like to forget they’d ever encountered a mystery meat pie! Shame on you!

Which comes with this lovely picture of Tim Nice but Dim

Courtesy of the BBC’s “How Yorkshire are you?” quiz.

Mozilla bugs

We recently started using JSPWiki with the clean template at work for our intranet. Sadly there are two major issues all the Firefox and Mozilla users in the office are facing (and there are an awful a lot of them):

  • links to locations and files on the internal network don’t work (i.e. file:/// URLs which work fine in IE)
  • printing inserts random pagebreaks

Of course, this means that every time you want to follow a link to a directory on the network (e.g. a link to “all the necessary docs are in this folder”) or print a page out, we’re having to copy the URL, load up IE, paste the URL in and then do whatever it was (or, ok, in the first instance just right-click the link, “Copy Link Location” and paste it into the URL bar, which, strangely works – it’s just clicking the link which doesn’t). Very frustrating.

I understand the first bug. It’s a security restriction. There’s probably a way around it, but I have absolutely no idea what that solution might be and neither bug 163410 or bug 238093 give any help (possibly because my bug is “Security Error: Content at http://xxx may not load or link to file:////yyy.” which is not the same as either of those bugs). But the second (which may or may not be bug 187486, which was the closest thing I could find) is completely bizarre. I know I should spend some time making up a minimal test case, and I will, but printing always seems to be the one big thing that IE really does do better than the Gecko browsers.

But anyway, these two are pretty much showstoppers as far as getting anyone else in my office to use Firefox goes – one of the first things they’ll try and use will be the intranet, and *bam* it won’t work. If anyone out there has any ideas what I can do about either of these problems, please let me know.

Open source MS Exchange connector

I’m about a month behind the times, but on May 14th 2004 the Novell Connector (which used to be called Evolution Connector) became open source instead of payware. This opens up the field for a whole host of Linux mail, PIM and groupware applications to start supporting MS Exchange servers (apps like Kroupware, Kontact, and loads of Gnome stuff which I don’t know the names of).

As far as desktop and office use of Linux this is a real breakthrough, at my last job I had a dual-booting Linux/Win2000 box, but I could only do productive work under Win2000 because I’d never get mails, calendar notifications, access to the company address book and so on.

For me, the applications are already good enough (reading/writing documents, coding, reading/writing mail, browsing the web and IM sums up about 95% of my computer use and I can do all of these things very happily on a Linux box) but now the ability to run Linux in the workplace where Outlook is king and remain connected is just incredible. Roll on the Linux office. 🙂

Relating Atom entries and feeds

Bill de hÓra recently wrote an interesting article on mapping Atom to RDF, and in the process linking individual entries to the feed which contains them by virtue of a <atom:feed rdf:resource="feed-url"/>. This is a very interesting area to me at the moment, and it seems strange that an explicit child -> parent relationship hasn’t previously been defined in the Atom syntax, only parent -> child by virtue of the document structure.

The main use case I’m interested in, and have been thinking about for the past couple of months, was also posted to the atom-syntax mailing list by Bob Wyman over the weekend, that is, transmitting individual atom:entry elements over XMPP (Jabber) via JEP-0060, which is an incredibly detailed and potentially useful specification which, AFAIK, only actually has two implementations: Mimir and the slightly more well known

we implement a content-based publish/subscribe system that distributes each newly discovered Atom entry (or RSS item) that matches a user’s subscription by publishing a single entry feed as the payload of a JEP-0060 event.

Basically, we’re forced to construct a full feed when all we really want to do is publish a single entry.

I’ve got my own aggregation system which does almost exactly the same thing except that it currently bundles the atom content inside of a normal Jabber chat packet, and this is exactly the problem I’m currently facing. Fortunately there are now a couple of proposals which would seem to cover this case, namely Entry Origin and Link Parent, so I’ll have to see what I can do with those, and spend some time following the mailing list to see what changes and decisions are made.

Bob also made a rather amazing statement which seems to have been rather passed over (there are no follow-ups to his mail on the list):

In the near future, we’ll be making available code modules that will make it very easy for existing aggregator developers to incorporate support for Jabber into their news aggregators. Thus, if you’ve got a news aggregator, you’ll be able to provide support for receiving updates via Jabber without having to become a Jabber/XMPP expert.

As far as I’m concerned, this is really big news. I’ve started to run into problems with JabRSS where things like timely delivery of items is a must, and of course things like search just aren’t anywhere near as good as I’d like (plus the Atom support is very very basic and really only half-works), and so desktop aggregators are starting to have a brighter appeal. Of course, all the free ones are still rubbish, but I’m hoping that I can implement all the stuff I need in FeedThing. Anyway, the point is that the fact that aggregators store all their data locally is killing me – it’s the reason I moved away from them in the first place. Implementing a desktop aggregator which uses JEP-0060 as its backend is the only solution which makes sense to me, and this offer from Bob looks too good to turn down.

CSS Hacks

I’ve noticed that developers have started using different hacks to get around IE box model issues, so was wondering what’s the current preferred method and why?

I was relatively pleased to notice that my own position on the matter is the same as Anne van Kesteren:

IE7 or putting IE6 into quirks mode and using the underscore hack (‘_width:100px’ for example).

Clean and simple. That’s the way I like it.

Slow replies

Over the last few months I’ve had a number of people contact me on various issues, from IM to RDF to syndication and more. To all those people – Sorry for not having got back to you yet! I’ll be trying to clear the backlog this week.

Jabber IRC gateway

About six months ago I spent some time poking around the Internet for an IRC library which could be used over Jabber (maybe providing either a chatroom or a gateway component, whatever), but drew a blank. I looked at Martyr briefly to see if I could write one myself, but in all honesty it sounded like too much hard work for something I wouldn’t really use (I’m very rarely on IRC).

It seems like one of those things you’d have expected to have been around for ages, but as with much of the state of the Jabber world (a post on which I’m saving up), it’s just not there. So hurrah! for yesterdays’ issue of the Jabber Journal which mentions three such projects:

There are now three IRC gateway projects underway: one built on top of the Xmpppy library (running at, another created by Jacek Konieczny (running at, a fine free server in Portugal hosted by 3GNTW), and a third that is native to the ejabberd server (running at Another option is JIG, a server-side component that enables any IRC client to be a Jabber client.

Typical, eh? You wait for one IRC gateway projects, and three turn up at once.

Firefox clone

Un clone de Firefox vient d’apparaître, il s’agit de smartfox. Aucune différence avec Firefox 0.8 à part le changement de nom et un njouveau logo, mais c’est le premier navigateur dérivé de Firefox, l’initiative est intéressante

Wow, incredible! I think what I don’t get is why they’re bundling under a different name instead of lending their time and effort to promoting Firefox. Actually, I do get it – it’s one guy who’s bought a domain and thinks he’s innovative and cool and will gain kudos for releasing his own build of the browser. You know, to do that, he probably should have changed more than the name and shortcut icon.

XHTML – Why?

XHTML – Why? basically says the only reason is so that HTML becomes valid XML.

I understand, of course, that this is an old argument, but in the intervening years all I’ve seen is that people have realised they can now use XPath on their web pages. Well, that’s just great.

This is a big turnaround for me, I was convinced that XHTML was going to help us smooth the transition between making websites completely User-Agent and device agnostic, as well as opening up HTML to manipulation by all the existing XML tools, but you know what? There are already a plethora of existing (and good) HTML parsers out there, so the “well-formed XML” argument falls on my deaf ears, and apart from the comparatively esoteric usage of XPath, no-one’s yet found a good use for these XML tools in manipulating XHTML (not in the least because most XML tools will pretty-print by default, and break your page in IE).

And far from XHTML being the panacea of cross-device websites, developers have discovered that properly separated content and presentation will allow their plain old HTML sites to be rendered just fine on mobile devices (not that most PDA apps, like Plucker don’t just scrape the content into their own format anyway). So where are the XHTML torch-bearers? What do they have to offer me? Why is my HTML site no longer good enough? Where is the next generation of browsers that will be able to make use of all this X-technology? XHTML – Why?