This is as days pass by, by Stuart Langridge

Other people

Ed, in the spirit of Thanksgiving, lists some great sites that have shown up in his referrer logs; it would appear that he and I have a rough agreement on what a great site is, since I read a fair propertion of both those in that list and those on his blogroll :) Sadly, he's not on mine because he doesn't ping blo.gs or weblogs.com :( -----

Technorati cosmos

Technorati, who bill themselves as "Web Services for bloggers", have a rather neat feature that they call "Link Cosmos" -- it's essentially another "who's linkng to you" search, but it seems to find results that others don't. I put kryogenix in and it came up with a few places that are linking to me that I didn't know about, and I've added a couple (Blog-Fu and Reflective Surface) to my blogroll because they're good. Always nice to discover interesting new writing. -----

What's the point in XHTML?

So, why do people use XHTML?

Mark talks about the XHTML vs. RSS debate, in somewhat disparaging terms, stating that "Syndication is not Publication".

The entire success of RSS is predicated on the principle that "you can keep doing whatever messed up stuff you've always done on your web pages... oh, and do this other thing too. Look, it's simple, you can code it up in an hour with a few print statements and an escape function." By contrast, this latest XHTML-as-syndication movement seems to be based on the principle that "syndication is so incredibly important that you must immediately stop whatever you're doing with your web pages, upgrade to XHTML, validate your markup, restructure your home page to include all and only the content you're willing to syndicate, and by the way, would you please unlearn that ugly nasty presentational page layout language you've been using for years and learn this wonderful happy structured semantic markup language instead?"
It should be obvious to any rational observer that this will go nowhere fast. A syndication format that requires valid semantic XHTML markup? Spare me. 9 out of 10 bloggers can't even spell XHTML.

One of the issues here is that 9 out of 10 bloggers can't spell RSS either. In fact, a reasonable propertion of bloggers don't even know what RSS is, or that their weblogging tool generates it for them. That so many pages are invalid is not the fault of these 9 out of 10 bloggers, it's the fault of their tool of choice. Imagine if a weblogging tool checked your built pages for XML well-formedness. (Obviously this only works for baked systems, rather than fried.) Not validation against a DTD or anything, just well-formedness. It's not going to solve all problems overnight, I admit, but being able to use XHTML in pursuit of one of its major wins -- that it's XML as well, and therefore can be parsed by the vast suite of XML tools which insist on a minimum level of compliance (by which I mean well-formedness) and then derive power from that (or are there, say, XPath tools for HTML 4.01 that I don't know about? -- would make life a lot easier. If your intention, O XHTML user, is to have your pages marked up in XHTML in pursuit of this goal, then why do you need RSS or similar formats? If your aim is not to use XHTML for this purpose, what is your purpose? Mark's "It's like...semantic and stuff" remark isn't a flappy-handed meaningless contention on the part of XHTML pushers, it's the point of the whole exercise.

He does make a good point about bandwidth, I freely admit. That, however, reduces RSS from being the Right Thing to being an optimisation away from correctness in order to live in the real world. RSS makes your bandwidth bill cheaper; true. And that's quite possibly a major motivating factor for almost everyone, because real world issues come above principles to some extent. It doesn't make RSS right, though.

Moreover, the further points about corner cases such as Dorothea's Latin dates are entirely valid. That backs up the core contention that publication and syndication are not the same thing, assuming that you actually need an accurate date on a post for anything. Those of you who use RSS newsreaders, do you tend to look at "all the latest posts from all my feeds" (in which case a date is obviously vital) or "all feeds with new content" and then read that feed in isolation (in which case you don't need a date at all, although the newsreader does need to cache what it last saw to check for updates rather than caching the last time you read a feed to see whether there are posts since -- an MD5 hash of the feed contents is not much larger than a stored date). Quoting Dean Allen's use of hand-crafted descriptions in RSS misses the point; I fail to see how any hand-crafted description could be a better description of the post than the post itself is! I'm open to correction on this point; Mark quotes Shelley's desire to not have her whole feed in RSS to avoid republication -- I can't see how those who would want to republish her content couldn't just rip it off her website, so I'm unclear on the point of this.

I mean, I've set explicit excerpts on posts just for my RSS feed. But not because I think that this is a great way to summarise my message. Because I want to use entities like — in my HTML, and it doesn't work in RSS. I have to remember to use " instead of " in all my posts to avoid breaking my RSS feed. This is a hindrance, not the easy path to syndication.

This is in danger of descending into the age old argument between attempting to change the world to make the Right Thing the thing that works, and stepping away from the Right Thing so that your implementation works in the world. Pushing the former too far leads to zealotry. Pushing the latter too far leads to Internet Explorer v 4. The real truth is somewhere in the middle, and once again some people are trying to decide where that line which they won't step over actually lies.

More on XHTML vs. RSS

Tantek has commented further on my earlier notes about XHTML vs. CSS, in which he takes me to task about assumptions like the lowest level header on a page being a blog posting title. True enough; it was an off-the-top-of-my-head example, rather than anything constructive. And, although I still don't think it's unreasonable to assume that a link with a text node containing a single hash is a permalink, that's certainly no way to catch all (or even most) weblogs' permalinks — the hash is a convention that isn't all that closely stuck to. Nonetheless, this doesn't obscure my main point, and Tantek agrees; that optimising everything for machine readability at the expense of humanity is a bad plan. Having a machine-readable format (RSS) and a human-readable format (HTML) is one possible solution, but it comes at the expense of extra work (even given that most weblogging systems will "automatically" create the RSS for you), but it not being the best possible solution was the point of Anil's original assertion. Tantek also notes that hyperlinks that are permalinks should possibly explicity specify a rel attribute of "bookmark", which I didn't know at all. That's a reasonable use of pre-existing XHTML semantics, rather than overloading a class name. Both Rick over at techno weenie and Simon Willison thought of embedding elements from other namespaces into your XHTML (so you add <rss:title> tags around your post titles), but, as Rick points out, " that might get a bit messy". He's not wrong, and it's horrifically confusing for the average punter, which means that we're optimising for machines again. If the rel="bookmark" thing takes off then you could reverse a post title back from that, I suppose, since every post has only one permalink and every post has one or no titles; in essence, you'd find a header level that matched a permalink and assume that that was the post title. It's a possibility, anyway. This needs more thought, but with all those big brains out there working on it I'm sure someone will come up with something revolutionary eventually... -----

Visions of the future

Paul talks about the state of computing, past, present, and future, in The Ghosts of Online Travel Information, a glorious essay. I skip-read it at first and thought that the "future" section was actually what he was doing at the moment and was deeply envious. The wireless LAN thing and having a blog post automatically happen is entirely possible, and just as soon as I get the money to go wireless and get a new Zaurus (still waiting on the insurance company) I could be doing that. The freely-available wireless travel service at railway stations, however, isn't quite there yet, but it'd be nice if it were, wouldn't it? Why can't I live in a world like this describes, eh? -----

Minor layout change

Those of you who read all this through the web rather than an aggregator, spot the change. Give up? My name's now at the top. No-one other than people I know anyway knows what to call me, so I thought I'd make it a little easier. :) -----

Entities and whatnot in RSS

How should I be creating my RSS for my weblog if I use entities and quotes and whatnot in my HTML? I'm finding that when I use entities (such as &mdash; for a — or a double quote mark (") without escaping it as &quot;), my RSS feed breaks, presumably because these entities are not defined in the RSS XML DTD or something. Are there MT fixes for this sort of thing? This is just One More Reason not to use RSS, innit? -----

EUCD victory

NTK reports that the UK government havepostponed the EUCD after many comments on the Patent Office's consultation document. If you commented on the document, or made your MP aware of the issues, or did anything to stand in the way, then take a brief moment to feel proud. If you didn't because you didn't know about it, take a moment to read up and know why people were complaining. If you didn't but you meant to, then remember next time that you can't always rely on someone else taking up the torch on your behalf... -----

XHTML instead of RSS

Lots of people — Anil, Scott Andrew LePera, and Tantek among them, luminaries all — are talking about using structured XHTML to format weblogs in place of a separate syndication format such as RSS. My opinion is that they're going about it the wrong way. Bear in mind here that kryogenix.org is HTML 4.01 Transitional, and doesn't always quite manage to validate as that, so I probably don't know what I'm talking about. Anil's suggestion is that we mark up posts using particular tag and class combinations for a particular set part of a weblog post (so, a post title would be <h3 class="title">, for example). Scott complains that that's overloading the class attribute with semantic meaning, which you're not supposed to do. Tantek thinks that we shouldn't try and specify a format explicitly, but have everyone make one up and see which wins; market forces in action. My problem with all of these options is that they all assume that aggregators and other RSS readers are forced to be stupid, that an aggregator should have handed to it, on a plate, what everything means. What's wrong with having our aggregator's parser show a bit of intelligence when parsing? For example, people are complaining that mandating <h3> for a post title renders a page semantically meaningless if there are no <h1> or <h2> tags, which is true. Moreover, suggesting that <h3 class="title"> means "title of a weblog posting" is attempting to layer semantic meaning over and above that which XHTML gives to the tag, which you shouldn't really do, and that's what I think that Scott was complaining about. I see no problem with a custom XML format where you define the semantic meaning of each tag — a <blogposttitle> tag, for example — and then either syndicate from this and display in the browser with XML stylesheets (as Mozquito XForms does, superbly), or instead just XSLT it into HTML and RSS. But, failing all that, we could have the aggregator parser show intelligence when parsing — is it unreasonable to assume, for instance, that the "lowest level" header is one for blog titles? So a page with h1, h2, and h3 headers uses h3 as the post title? A hyperlink preceded by "Posted by" is an author link? A hyperlink containing a text node containing only a # symbol is a permalink? These aren't the only possibilities, and they're not necessarily true in all cases. But you could come up with a set of reasonable heuristics for this sort of thing that wouldn't dictate a(nother) custom XML format or a hackish overloading of XHTML semantics. The issue here is that we're either contorting our HTML or providing an extra syndication format file — both of which are, as Scott points out, "compromises on the part of the author" — in order to make life easier for machines. Nuh-uh. Machines are meant to make life easier for us. Look at, for example, Mark Pilgrim's ultra-liberal RSS parser, which tries all kinds of ways of parsing (not finding; sorry, Mark) your RSS file — the machine works hard so you don't have to. That's the way it's supposed to be. If we're working hard to make the machine's life easier, then we're doing something wrong. -----

All CSS hacks, all the time

Over at Centricle there's a list of all the CSS hacks as of now (via Simon). Straight into my bookmarks file. I'd love to see a page which attempts to display which browser you're using by only using CSS hacks...a project for someone with a lot of spare time, that one. :)

Mozilla largeness

A new job for mpt, in the same industry; internet cafes. He's noting licensing issues with their current Windows desktops, and thinking of moving to Linux. However, he's rejecting Mozilla and Phoenix as browsers; Mozilla because of his list of things wrong with it, and Phoenix because there's too much browser chrome for their standard 800x600 desktop. Can I suggest a different Phoenix theme? LittlePhoenix looks pretty minimal, which maximises screen real-estate usage (one user says in comments that "the inability to get the chrome compact enough was actually one of the last things holding me back from switching back to Netscape/Mozilla."). -----

Little things for big minds

Simon notes that Mark's latest tinkerings are similar to the php.net url forwarding, on which Mark consciously based his code. Neat. I've used this sort of technique before, especially on IIS/ASP-based sites where you've not got access to mod_rewrite -- in these sorts of environments, a custom 404 handler can work wonders. It's also how the funky caching concept works. If I were Mark, however, I think I'd have used mod_rewrite for some of the work; it would be rather neat if http://diveintomark/find/search%20terms searched for those terms (as Adrian Holovaty already does, and a mod_rewrite hack is easier there than parsing terms out of the URL in your 404 script. (I'm feeling an attack of "right tool for the right job" here, too, although I'm unclear whether it's justified.) The strength of the php.net implementation is that it searches the online PHP manual, something that's rather a challenge to do using only URL rewriting. I turned up on Mark's recommended reading list, too, so I must be doing something right. All this pales into insignificance, though, behind Mark's comment that "I hope to eventually achieve web design nirvana, a state in which, if anyone can't read my site, it's their own damn fault." This should be every web developer's mantra. I'm thinking of having it hacked into the raw stone above my door, so that I see it and remember it every day. If there's a better summary of how we're supposed to be doing what we do, I haven't seen it. -----

Code and HTML and code, oh my!

Tantek continues his tradition of creating stuff that looks like a hack but is actually completely valid with a way to mingle JavaScript and HTML in the same file. Brr. My head hurts just thinking about this. Clever, but I ain't using it :) -----

Catch-ups

There've been quite a few interesting looking things over the last few days, none of which I've really had a chance to look at properly. Since I haven't got something like Sarabian's list o' links, I'll have to settle for a link barrage here with minor commentary. Make Phoenix Even Faster -- speed up the render time on pages for the Phoenix browser. Nice. data: URLs seem to let you add the whole content of a page to a URL. It's the web with no storage requirements! I can think of a few uses for this; are they even remotely well supported across browsers? Aquarion has trouble with phones. I love the way Perl is interspersed into normal conversation:
Drone: Okay Sir, Could we have @DETAILS?
Me: @DETAILS
-----

Links between other places

Simon is thinking about a way of connecting two links; when you read something on the web and realise that it fits in nicely with something else you've read, and write a note about how the two relate. I'm not convinced that this isn't solved by, say, Pingback, because there isn't necessarily a link between the two without your post explaining and drawing on that link, and therefore the chain that other people should follow isn't First-Post-You-Saw to Second-Post-You-Saw, or the other way around, it's First-Post-You-Saw to Your-Post-Explaining-Why-It's-Similar-To-Some-Other-Post to The-Other-Post-That-It's-Similar-To (or, naturally, vice versa). I remain unconvinced that we need yet another addition to the sprawling world of XML-based formats that are trying to make the semantic web happen. Perhaps this is the market forces argument; create all sorts of formats and see which ones win. However, I believe (and have argued before) that there's a risk that all that method does is dilute your pool of good people, because everyone's working on their own magic format. NIH gone mad, not that I'm in any way immune to this. But I'm not seeing the need for further technology here. -----

Universal search engine

I've been looking lately at a product called Vrisko, a universal search engine. The way it works is that you tell it about data sources and how to search them, and it then provides you with a single search across all of those data sources. Your data sources can be previously existing website search engines (which it handles by submitting a search to that site's search engine and screen-scraping the results), search engines that return XML, SQL databases (you tell it the SQL query to use and what sorts of results it should get back), API calls (tell it the call and the data that should be returned from that call), and so on. What I'd like to know is whether anyone's developing a similar sort of thing under a free software licence? It's not a technically difficult thing to do, and it would be nice to use (and possibly add to) an open-source project rather than forking out loads of money to a corporation and then not being able to contribute to its development. Anyone with any ideas, a comment or an email would be much appreciated. -----

No RAND in W3C standards

Larry Rosen writes that the W3C have released their last-call draft of their patent policy. This policy has removed the parts that permitted royalties to be charged to those implementing W3C specifications, and that's a very good thing. Rosen goes on to say
"The community now needs to be heard supporting this policy so that it is not undone during the public input and W3C Advisory Council phase. Address your comments to www-patentpolicy-comment@w3.org."
This is absolutely true; if we show support then the W3C will have it affirmed that there are people out there who care about more than patent royalties. They do a good job; show them you appreciate it. -----

hr.rec.tv.buffy

The hr.rec.tv.buffy FAQ is highly amusing to read; screeds of what I believe is Hungarian, and then every now and again you'll see a bit you recognise.
I on postoji, iako bi većina obozavatelja vjerojatno radije htjela da ne postoji. Joss Whedon autor je scenarija, ali nije imao previse utjecaja na film, pa se konačna verzija razlikuje od njegovog viđenja filma. I glumi Luke Perry, sto je dovoljno zastrasujuće. Film je već nekoliko puta emitirala Hrvatska televizija.
I'm sure I recognise one or two of those names :)

RISC OS revolution

See, this is why I like ROX. It's modelled on RISC OS, about which it says:
RISC OS is very revolutionary. The Desktop is largely unchanged for 14 years because it was designed correctly in the first place!
It is, too. A RISC OS desktop today looks pretty similar to a Windows desktop, or a Mac desktop, or a KDE desktop, or a Gnome desktop. The point is that it looked the same as that when I started using it a decade ago. Well done the RISC OS team. -----

Project Genesis

Internal project correspondence for the Genesis Project. Har! -----

When good interfaces go crufty

When good interfaces go crufty, a superb essay by mpt that discusses why the "Quit" command in your File menu shouldn't be there, why filepickers are bad (except in RISC OS, which is why I use ROX, a RISC OS-a-like window manager, although it doesn't really help because other apps don't use its power), why renaming files breaks the world and shouldn't, and how the Programs menu in Windows, KDE, and Gnome is the ultimate in crufty behaviours. Highly recommended, and if this doesn't fire off thoughts in you about how these things might be improved, then you lose all your accumulated hacker points and go back to the beginning of the level. I hadn't even thought of these things as problems (and I'll bet most other people, including most coders, hadn't either), which shows that either mpt is immensely clear-sighted and can break the paradigm (well, sort of... Thomas Kuhn, stop turning in your grave), or that we've all been successfully brainwashed by people who thought these things up and convinced us of their own beliefs that they were the right thing to do. The Emperor has no clothes, says Matt; are we able to listen? -----

Hiding CSS from NN4

Just because I always need this and can never remember where it is, Caio Chassot documents how a CSS comment like /*/*/ can be used to hide style from NN4. -----

Pay for all your email

Joel Spolsky suggests that, to counter spam, someone sets up a service where sending email costs a penny, and everyone allows all mail that comes from that server through their spam filters, because you know that spammers wouldn't (and couldn't) pay money for the vast volumes of mail they send. In principle, not a bad idea. Sadly, though, Joel then seems to put his corporate head back on and ruins the whole effect:

Eventually, if it caught on, you wouldn't need a spam filter: just put all the free email in a suspect folder, and check it once a week in case some old school holdouts insist on sending you email without paying.
Yeah, that's right. Because then we'll be at a stage where we've managed to make people pay money to use a service that was formerly free, and now you can look down on those people who don't want to pay because they think that it should be free. This I consider to be blind corporate thinking -- it's the reason that Linux is not tried in more businesses. (Note: not the reason it's not used more; I have no problem at all with firms who try it and decide that it's not for them. But failing to investigate an alternative that might be better and might save you money just because you don't like the idea of it, because it's "free" and therefore worthless, is blinkered.)

Funky caching

Phil Ringnalda writes about funky caching, an idea he picked up at PHPCon, where your weblogging system doesn't build pages when you save an entry, a la Movable Type; instead, it builds them on the fly when requested, as does b2 and a host of other systems, and then saves the built page to the filesystem so that the next time it's served, it's static. This is a stunning idea, and it's one I'm going to steal for Vellum, which is now really really close to being stable enough to use here. -----

The Day Alertbox Died

The Day Alertbox Died (via mpt), a short survey of long past and recent editions of Jakob Nielsen's Alertbox column on usability, which concludes that it has increasingly become populated by puff pieces for the Nielsen Norman Group, Jakob's company. Certainly I've thought this, which is why I've stopped reading, although I hadn't actually realised that that's why I stopped reading; in the survey, Chris McEvoy notes that one third of the links from the Alertbox are NN Group links. Jakob even manages to get a link to a non-free report into the latest interview for Digital Web. -----

Remember, remember November

It's November again. Seven years ago this month, in November 1995, my friend Anne died while we were all at university, of carbon monoxide poisoning from a faulty boiler. The installer was fined four thousand pounds. Apparently CO is the most common form of accidental poisoning in the US, with eight thousand deaths a year. Now that we're coming into winter, and especially if you're in student housing, go out and buy a carbon monoxide detector. Don't put it off. I still miss my friend. Make sure you don't have to miss yours. -----

Instantaneous web services

Phil Wainewright comments on instantaneous actions in a web services infrastructure (via Sam Ruby). This is why I like this technology. -----

A census of blogspace

Phil Wolff over at a klog apart offers the thought that we need a census of blogspace. He asks a few questions, as well, about the size of the "blogsphere":
Do you have an educated guess?
Not even remotely. No idea. I could pick a figure, but it could be out by two orders of magnitude.
Do you know of any prior work in this area?
Not that I'm aware of, I must admit, although it could well have passed me by.
Can you think of a methodology or two to create useful measures of the number of bloggers and the number of weblogs?
Google. Google is the best way for queries about all of the net, because it indexes all of the net. You could get a rough estimate of the number of webloggers by making a few simplifying assumptions: all webloggers either have their own domain or are using one of a few weblogging hosts (blogspot, Livejournal, etc, it's a fairly short list), getting user counts from each of the major hosts, and then searching Google for the word "permalink" and extracting the number of unique domains. That'll be a low estimate, because there are multiple weblogs on some domains, and because not all weblogs use the word permalink, but it'd be a figure to begin working with.
The other alternative is to assume that all weblogs are interconnected (see the next question), start at one place, and link-crawl yourself, counting as you go. You'd need rules of what constituted a weblog, which is something not well-defined for a person looking at one, never mind an automated process, but hey.
What related questions would you want answered?
How many different "islands" are there in the interconnected map of weblogs? Can you navigate from any given blog to any other blog by merely travelling links between weblogs? What does the map look like? What's the most connected node? Which node is at the centre of the map? Lots of questions about the map of links, really.
How might you use this information?
Blimes, I dunno. It'd be interesting to look at :) I could do a "six steps to as days pass by" thing, or something.
Pitfalls to avoid?
No idea, guv. At this stage, where there's no data at all, any data is better than none, so make assumptions, guess figures, and so on. We can refine the data later.
Would you join a BlogCensus.org to provide and share stats?
Suppose so, but I always find that sort of thing fairly silly, because the audience is self-selecting. The Linux Counter is much the same principle, and it's pretty useless in terms of information.
-----

Drop shadows with CSS

A new little browser experiment: Dropshadows, using techniques from Unobtrusive DHTML to make it easy to use and cross-browser. -----

Fire! Fire! Everybody out!

Sarabian lists things not to do during a firemen's strike, including the classic 'don't set fire to your pants, especially the ones that say "Keep away from naked flame"'. As he says, don't panic. Don't even notice that it's going on is probably closer to the truth. -----

Sibling blogs

According to BlogTree, adpb is a "parent blog" to Gimle. Wow. I didn't realise I was having an influence on people. Thanks, Baldur! -----

100 best sci-fi stories

The 100 science fiction books "you just have to read" list (via Gimlé) disillusions me, because I've only read 15. Much like Baldur, I'd have liked to see Michael Marshall Smith represented in the list; Only Forward isn't that much newer than Neal Stephenson's Snow Crash, both of which are among my very favourite sci-fi books. I'm not convinced about the inclusion of Alice either, because I'd class it as fantasy, and if you're allowed fantasy in the list then I'd include such things as the Dragonlance Chronicles or the Elenium. Still, a list of the 100 top anything is bound to be amazingly subjective. I should still read more of them, though. Best book on that list that you probably haven't read: I Am Legend by Richard Matheson, a superb short-ish story about vampires and the end of the world. Best books on that list that you probably have read: Only Forward, Snow Crash, and The Andromeda Strain. -----

XUL future

Aaron Andersen has written The Future of XUL, describing XRE, the XUL Runtime Environment. XUL is the language, environment, whatever, in which Mozilla's front-end is written, and it's the key part of the development of Moz as an application platform rather than just a web browser. Essentially, you define your interface in XML, and then use JavaScript to actually do the work. Anyway, the XRE is a small runtime environment that you can distribute with your app, which will mean that the end-user won't need all of Mozilla to run a XUL app, much like the Java virtual machine, or the MS Visual Basic runtimes. It's a pretty essential component if Moz-at-dev-platform is ever going to be more than a theoretical idea. It's apparently "six months away", although, as Aaron says, believe it when you see it. -----

Python persistence

IBM developerWorks have a new article about persisting objects in Python. Vellum, the blogging system currently under development by Sarabian and I, uses pickling of objects extensively to persist state, so I read this with interest, particularly the __setstate__ bits (which explain ways to handle the problem you get when you change a class definition and then try and unpickle instances of that class that were pickled under the old definition). I shall certainly be needing those as the Vellum objects' definitions change over time. -----

New Halloween memo

ESR has published a newly leaked internal Microsoft memo as Halloween 7. The memo discusses how MS's anti-Linux anti-GPL marketing drive is backfiring, but highlights some key areas on which the free software community needs to work to ensure that we don't lose to the larger marketing budget, particularly potential patent lawsuits and Linux's genuinely lower total cost of ownership (as admitted by MS themselves!) Noses still to the grindstone, all, but this is promising stuff; we're making a good showing based on technical excellence, and people are realising that... -----

Debian and ALSA

Dan "overridex" McCombs has written a HOWTO on installing ALSA in Debian, which should be very useful to lots of people. I personally run ALSA on my Debian box, but it was a nightmare to get running and I'm still not sure I've done it right. Good show. -----

Zaurus theft

Last night, someone stole my Sharp Zaurus from me. Right out of my hand, while I was standing on the street. I am not at all happy about this. The police give little chance of me ever getting it back, but fortunately it's covered on my house and contents insurance, so I shouldn't be without it for too long. But I was somewhat shell-shocked at the time, and somewhat despondent now. -----

Unobtrusive DHTML

Once again, I've been busy working. However, what I've done this time is pretty much in a releaseable state, I think, so you get to see some new code, all. It's an update to aqTree, but on steroids, and this time it comes with a free essay that you get to read about how DHTML should be. Unobtrusive DHTML, and the power of unordered lists. Let me know whether you like it. -----

Overselling and fireworks

New rant, about overselling products, cold remedies in America, and kneeling in damp grass. -----

Computing business cards

Steve Parkes, who is clearly a very funny chap even though I haven't quite managed to meet him yet, talks about business cards from different tech manufacturers. I'm still laughing at this :-) -----

This website belongs to Stuart Langridge. Contact details are available. Don't eat yellow snow. Valid HTML5, at least in theory, except for the bits that aren't because I'm that futuristic that I'm ahead of the spec, oh yes. HTML5 help from Bruce Lawson, among others. Fonts from the superb FontSquirrel. End.