I have a 15-inch MacBook Pro from 2017. It’s in perfect working order, except the battery was past its best. ‘Service recommended,’ it always said when I checked. But it was fine, I could get a couple of hours out of it, and I rarely use the computer away from somewhere I can plug in. Especially this last couple of years. {.has-dropcap}

But the screen had developed a problem. There were marks on it that I couldn’t remove. They were kind of hard to photograph, but you can see them here:

I discovered there was a known defect in models of that era called ‘screen delamination.’ The top layer of the screen’s coating was becoming detached from the underlying one.

People had solutions, which involved careful cleaning with various solvents or mild abrasives: isopropyl alcohol, or, I don’t know, toothpaste, maybe.¹

Inevitably, the whole affair has a ‘gate’ name: Staingate. Perhaps less inevitably, but unsurprisingly since it’s a manufacturing defect, Apple have long since acknowledged the problem and offered a free repair programme. As long as your machine was no more than four years old.

I discovered these facts back in the summer. Dug out my receipt. I bought the laptop four years and four days ago. Damn!

At the time I was deep in working towards my dissertation, so I wasn’t going to spend any more time on it. In September, though, I thought it would be worth contacting Apple support and seeing what could be done. I couldn’t get a Genius Bar appointment, but I could take it to an Apple Authorised Service Provider called MR in Shoreditch. They had a look at it and said, yes it’s the delamination thing, you’re outside the free programme, we can fix it: 800 quid. {.has-dropcap}

Too much. But! they also said that it would be worth taking it in to Apple. They might, depending on who you saw, do it for free anyway.

I was slightly sceptical, and we were getting ready for a trip to Scotland at the time, so I left it. Eventually, though, I booked it into the Genius Bar.

You’re outside the programme, they said. But we’ll fix it under consumer law. No charge.

The Sale of Goods Act (or its successors) for the win again: a laptop screen should last longer than four years.

During the tests they run, the guy noticed that the battery was poorly, and offered a replacement. £199 seems steep, so I said no thanks.

Yesterday I got an email to say it was ready to pick up, so I toddled off to Westfield. The staff member who brought it out to me asked me to wait while she checked something. Came back and said, ‘You know how you rejected the battery replacement? Well it seems they did it anyway. We won’t charge you.’ {.has-dropcap}

So that was weird. The work note that came with it said ‘Battery won’t charge at all,’ which was not true when I took it in. But here I am with a good-as-new battery. Well, actually new.

All of this required what they call a ‘Top case replacement.’ ‘Top case with battery,’ in fact, which suggests the battery is in the screen part of the laptop, not the keyboard part, which seems weird.

The big downside – but one that had been prepared for – is that I lost all my stickers. I had heard of this kind of thing happening, so I took photographs.

The questions now are how and whether to replace them.

Dave Winer may be a very smart guy, who effectively invented blogging, RSS, and podcasts, but he’s lost his mind in this post:

We are now all complete newbies when it comes to understanding how networks can be used to spread misinformation. We might look back in a few years and realize that our first line of defense was Facebook, Inc. Maybe tearing them down is like the press tearing down HRC in 2016. I don’t trust their judgement on this stuff, do you?

– Dave Winer, Untitled Scripting News post

The first sentence is fair enough, but the second? Facebook is the first line of attack, rather, on our democratic freedoms. See Cambridge Analytica stories, passim. Or if not the first, then the most powerful tool in the armoury of the anti-democratic forces that plague us.

The ‘them’ he refers to is, I think, journalists. Or ‘journalism,’ as a collective entity:

I judge journalism in the aggregate.

In other words, I say “journalism” did this or that.

– Dave Winer, Journalism in the aggregate

One of the main things he does these days is to rail against journalism.

Just last month I wrote Single Points, about the Fastly CDN outage. This morning many, many sites were down or inaccessible because of an outage at Akamai. A content delivery network again, though they’re saying the outage is caused by ‘edge DNS.’ I’m familiar with DNS, but not the ‘edge’ variant. In fact, I realise it’s capitalised and is the name of an Akamai product or service.

More evidence that the increasing centralisation of internet services is a problem. On the plus side, it was resolved quickly. When a service provider has the kind of major clients we’re talking about here, then that company is going to have to be able to respond quickly and get things back up. If a random small or midlevel company ran all its own server hardware and software, an outage would only inconvenience that company’s customers. But the company would need to have the staff available to sort the problems out. That would be a large and arguably unnecessary overhead.

So I understand the desire to offload responsibilities to a service provider, and the economies of scale that a company specialising in running network services can bring. But I fear it’s only a matter of time before one of these events results in serious damage or even loss of life.

Not that I’m claiming to know what the answer is.

I noticed that GitHub was down this morning – or not down, exactly, but its web pages were profoundly broken. I tried different browsers, then jumped on Twitter to see if it was widely reported.

It was. People were saying the problem was Fastly, a content delivery network (CDN). Also that it was affecting other sites. I don’t know when CDNs started being a thing. I think they might have been recommended by some when I was still using WordPress. The idea being that a CDN can host your site’s static assets – images, mainly – while WordPress carries on with the dynamic bits, generating HTML pages on the fly, as it does. The CDN’s scale will mean it can serve those files faster than your little server.

I didn’t bother with them, not having that much traffic. But in the back of my mind there was always the thought, ‘What if the CDN goes down?’ The idea, of course, was that the CDN would be big, multiply-redundant, reliable: it’s not going to go down!

Here’s a CNN report about the outage. It affected a lot more than GitHub, it seems.

So, are CDNs single points of failure? Obviously there’s more than one CDN, but if the failure of any one can disable large chunks of the web, do they put us in a better position?

News comes out that Stack Overflow is being bought by something called Prosus. I’ve never heard of them, but they’re ‘a global consumer internet group and one of the largest technology investors in the world,’ to quote their own site.

This doesn’t bode well. Stack Overflow is without doubt the most useful site in the world, at least as far as programming and other technical matters goes. And its sub-sites cover a vast range of interests beyond the technical: use of English for both beginners and experienced people, for example; or science fiction; parenting, martial arts, the great outdoors, and a hundred more.

When a big company buys up a small one, it rarely ends well for the users of the small company’s products or services, or so it seems to me. Yahoo bought Flickr and let it largely wither on the vine.¹ Similarly with Del.icio.us. Google has bought numerous properties and either rolled them into its own products, or abandoned them.

In this case the purchaser is not a technology company itself, but just a holding company. Those ones tend to result in the bought company coming under pressure to make more money. The buyer wants to recover its investment. That tends to end up with the the bought company either selling intrusive advertising space, or selling its customers' data.

It doesn’t have to go that way. Maybe this Prosus will be different. But I can’t help thinking it’s a sad day for mutual help on the web.

I just got an invite/reminder email about a service called OnMail. I must have signed up to be notified when it became available. Could have been months ago: they apologise for it taking so long.

They should apologise for being bad for the email infrastructure that binds the world together.

I’m exaggerating, but only a bit. Email remains the most important thing on the internet aside from the web. Whenever you sign up for a service, or order something online, you expect to get an email confirmation.¹

Without reliable email, a lot of things would fall apart.

A while back I wrote about Hey, the new email service from Basecamp. There, I was bothered by it not being based on the standard, open protocols that underlie email, at least to the extent that you can’t get your Hey email using a third-party, standard client.

OnMail seems both visually and functionally similar to Hey, and it’s got exactly the same problem.

This trend is bad for email, bad for people who use email. It should be possible to give us the kind of powerful, automated controls over our inboxes that these services offer, without stopping us from using the apps we prefer. It is possible to do that, as companies like SaneBox show.

I do not like this trend.

I was opening a ticket with Fastmail (not a problem, just a query), and when I hit ‘Submit,’ the confirmatory email was in my inbox before the next web page finished loading.

It’s a really good service which I highly recommend, and if you were to sign up using the above link, you’d get 10% off your first year. I would get a small kickback too.

Break away from big email!

Dave Winer has ideas:

ideas for rethinking blogs and feeds. I found, as others have, that I need another kind of document to include in my personal CMS other than a story that’s part of the blog. Everything about blogs are set up to be written, then lightly edited, and never touched again. It’s temporal writing. But there are other things that I want to develop over time, keep coming back to, revising. A few years back I started this.how to hold those docs.

– Dave Winer, Tuesday, October 20, 2020 at 16:05

He’s talking about what I like to call ‘web pages,’ surely? You don’t need any fancy CMS for those, as Dave of all people should know. And if you want to use such a thing, well, even WordPress has its Posts/Pages distinction.

This has been sitting around in my drafts folder for about a month, so it’s long past time to get it out there.

HEY (they always capitalise it, which I don’t care for) is a new email service from Basecamp, makers of fine (I’m told) collaboration software for teams. The video walkthrough lasts about half an hour, but/and gives you a good overview of what it’s like.

Hey was also in the news recently over the way Apple was treating it regarding App Store rules. Apple were clearly in the wrong, and things have been sorted out now.

But that’s all another story. I want to talk about Hey, and why I think it is bad for users. Even at the same time that it’s probably good for users. A company, a service, can — like a person — contain multitudes.

The Good

If you watch that video you’ll see that Hey looks like an unusually interesting and capable email client: good for organising mail, getting the unimportant stuff out of your way until you want to look at it, and making the important things highly visible. It’s both powerful at automatically helping the user, and attractive to look at.

The Bad

But it’s built on a proprietary platform. Email’s biggest strength since its invention has been that it was built on open standards. Whether you were using a Unix command-line client at a university in the early days, or Gmail, Outlook, or another IMAP provider today — none of that matters. If you know someone’s email address, you can contact them, and they you. And more importantly for this discussion: if you want to use different email client software, you can.

That’s because email is built on open protocols: SMTP, POP, and IMAP. Not that you have to understand those – or even know about them – to use email, any more than you have to understand an internal combustion engine to drive a car.

More importantly, if you want to change from one email provider to another, you can do so. This is harder than it should be because the culture of people having their own domain never really caught on. All those josmith1989@gmail.com and hazy_harriet@hotmail.com type of addresses could, instead, have been jo@josmith1989.net and harri@hazyharriet.org.

They still could be, in fact. And when they are, then you can change the underlying email provider without anyone other than yourself having to know or care. To take a not-made-up example, martin@devilgate.org used to go by a complex combination of Gmail (for the spam filtering and search) and 5quidhost.co.uk and its eventual purchaser, TSOHost, because that’s what I used for web hosting, as much as anything else. But a few years ago I switched it to Fastmail. No-one I correspond with had to know anything about the change.

But Hey’s email service does not use the open protocols — principally IMAP — that makes all that possible. Instead they have their own proprietary system. If you move your email into Hey’s service, you might not find it too easy to move it out again.

Secondly, right now they don’t support custom domains, so your correspondents will certainly have to know. While josmith@hey.com might be available right now, if they have any success we’ll soon be back to appending birth years or random numbers to the end of common names, just like on Gmail, Hotmail, etc. Though they have said they intend to support custom domains, so there’s scope for a better solution there.

The Alternatives

Andrew Canion had the same thought I did when I watched the video: you can do most of this in MailMate.¹ At least the viewing, the ‘The Feed’ kind of thing. Though he had the added experience of using SaneBox to automatically file and sort your emails.

Andrew also went further than I did: instead of just thinking, ‘I could do that with MailMate,’ he went ahead and did it, and documented the process (with a tiny bit of help from yours truly).

I had heard of SaneBox through its sponsoring of various podcasts, so I was familiar with the idea, but I hadn’t tried it. I’m now trying it out, along with some of Andrew’s suggestions, and it’s altogether a pretty good setup. Now, all that comes into my main inbox — the only things that appear on unread counts, and hence activate icon badges — are actual emails that I want to see. All the newsletters, receipts, confirmations, and other stuff that isn’t spam but that I don’t want appearing in my inbox, and especially in my unread count — those are all there, but tidily away in other mailboxes, where I can deal with them at my leisure.

That said, SaneBox is not free (though it’s cheaper than Hey), and I don’t get that much annoying email. So I don’t think I’ll continue with this exact setup when the free trial ends. But it’s worth knowing that there are good ways — and standards-compliant ways — to achieve similar functionality to Hey’s.

We Built This City on IMAP

What this all shows is that there’s nothing in Hey’s service that you couldn’t create by building on top of IMAP, except the user interface – and that doesn’t have to know about the underlying protocols in any case. It’s possible that is exactly what they have done: implemented it on top of IMAP. In fact, doing anything else would mean giving themselves a lot of extra work, as they would have to effectively reinvent IMAP in any case.

If I were going to build a service like Hey, I’d start with an off-the-shelf IMAP service, probably open source, and build the filtering rules and all that around it.

So I hope that’s what they have done, and that at some point in the future they make their service available to ordinary email clients via IMAP.

I don’t know whether people know about this iOS feature. I discovered it by accident a year or two back. Before that I used to snooze my alarms by drowsily scrabbling for my phone, prying my eyes open, then trying to tap the correct onscreen button.

Then one morning the alarm was too loud – or it might have been too quiet, I don’t recall – and I tried to change the volume. When I pressed the volume button, the alarm instantly stopped. I thought I had cancelled it by accident, until it rang again the customary nine minutes later.¹

Since then I’ve always snoozed my alarms that way. But nearly every time I do, I think, “Do people know about this feature?” Because I don’t think I’ve ever seen it written down. And I’m going to post this without DuckDucking first, so that the existence of some article in The Verge or somewhere doesn’t spoil my flow.

I had thought that pressing the power button cancelled the alarm, rather than snoozing it, but I just checked, and it also snoozes it. So if you reach out, eyes closed, and press anything on the side of your iPhone, you’ll get another nine minutes.

In the interest of fully informing you, dear reader, I’ve just checked what the Home button does; and it appears that does cancel the alarm. So keep your presses to the sides.

I should note that I still have an iPhone 7. I’ve no reason to believe the behaviour is significantly different on more recent models, but obviously on the 10-series phones (X, XR, XS and the various 11s) you don’t have the Home button, so something different might happen. Let me know if you find out.

Email apps, especially ones that offer advanced services like “send later,” may be storing our usernames and passwords on their servers.

To be clear what that means: if you use Gmail, for example, you put your Google username and password into the app when you set it up. You expect the app to store them securely on your device. But some apps may also be storing that username and password — your keys to all the Google services in this example — on computers owned by the company that makes the app. Computers over which neither you nor Google has any control.

I’m not suggesting that the company I talk about below, or any other, is doing anything nefarious. They need to be able to log in to your mail server in order to send your mail later. But I hadn’t realised until now what that means, and I’m guessing neither will a lot of people. And to my mind they don’t make what they’re doing clear enough.

Worst of all, having passwords stored on unknown servers — at the very least, that’s worrying.

Background

On episode194 of the Connected podcast, Myke Hurley and Federico Viticci were reviewing the latest version of the iOS (and Mac) app Spark. It’s a fine email app, which I was using on my iPhone and iPad. So I was alarmed when they mentioned in passing that mail handled by the app is routed through Readdle’s servers. That didn’t seem likely at first. Spark is an email client. You tell it what servers handle your mail, and it connects to them to receive and send. The servers belonging to the company that makes the app have no business getting involved in that.

I did some digging. Whether or not Myke was right™ about mail going through their servers, the reality turned out to be much worse.

Digging

I tweeted at the Spark account. Here’s what happened:

@SparkMailApp Hi, I was listening to a podcast today on which it was suggested that if I use Spark, then my email is routed through your servers. Is that true?

— Martin McCallion (@devilgate) May 25, 2018

Which podcast said that?

— Terry Blanchard (@terryblanchard) May 25, 2018

The latest episode of Connected, with Myke Hurley and Federico Viticci.

— Martin McCallion (@devilgate) May 25, 2018

The only time Spark servers access your email is to create a push notification (to create sender, subject, and message snippet) The content is cached until the notification is sent, but removed after that.

— Terry Blanchard (@terryblanchard) May 25, 2018

OK, seems fair. Thanks. Probably all a misunderstanding, either by them or me. Just out of interest, is the “send later” feature done on the client?

— Martin McCallion (@devilgate) May 25, 2018

Ah, forgot about that one! We will store it on our server until the send later time, then we send it through your email server and it is removed from our server.

— Terry Blanchard (@terryblanchard) May 25, 2018

OK. Isn’t that a problem, in that you must be storing your users’ mail server credentials on your servers? I’m pretty sure it doesn’t say that in your Ts&Cs.

— Martin McCallion (@devilgate) May 25, 2018

It’s the second item that we mention in our privacy policy. https://t.co/WpQSIDGPgx

— Terry Blanchard (@terryblanchard) May 25, 2018

I had already found their privacy policy:

OAuth login or mail server credentials: Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages and other communication. Without such access, our Product won’t be able to provide you with the necessary communication experience. In order for you to take full advantage of additional App and Service features, such as “send later”, “sync between devices” and where allowed by Apple – “push notifications” we use Spark Services. Without using these services, none of the features mentioned above will function.

The wording “Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages” suggests that Spark the app needs to log into your server, which it does. But nothing about that says that your credentials will be stored on their servers.

Further down, in point 4, “How Long Personal Data is Stored For,” in a table that includes “Type of information,” we see (emphasis mine) :

Email address, email content for Spark Services, mail server credentials

So there it is. They do store your username and password on their servers, and they do tell you; though only if you read well into the kind of document that notoriously goes unread.

Final Thoughts

For features like “send later” they need to store the fact that you want to send an email at a specific time, and log in to your server in order to send it. And to be fair, I’m sure they can’t be alone in keeping that kind of data. Lots of clients offer “send later” and similar services, and all of them will have to log in to your mail server to work. So they have to store your credentials on their servers to do it.

And consider, if you use Gmail, that means your username and password not just for Gmail, but for all Google’s services, are now stored on somebody else’s servers. Their security might be great, but how do we know?

The more I think about this, the more concerned I become. Passwords should only be stored in one place: a secure, trusted password manager. But above all, these services need to be much clearer about the fact that they’re storing our passwords.

My iPhone 6 was getting slow, and its battery was poor. I have been thinking of replacing it. But September is approaching, and Apple will announcing new iPhones (three new ones, according to rumours). So I had more or less set my mind on waiting till then.

That would also be consistent with my iPhone buying history: 3G, 4S, 6… the next in the sequence is 7S.

Friday changed my plans. I was standing at a bus stop on Old Street, just replying to a WhatsApp message. Something touched my hand, and for half a second I thought someone was bumping into me. Then there was a firm grip on my phone and it was gone. Pulled right out of my hand and off down the road on a moped — which must have come across the pavement from behind me.

I should have been more aware. I knew this kind of theft was a thing. We’ve been hearing about them for a few months. But you don’t always think about it, and you never think it’s going to happen to you. And, yes, OK, drink had been taken. But not that much.

The bus arrived a few seconds later, so there was nothing I could do but get on and head home. There was another guy at the stop who witnessed it, and he very kindly set up a hotspot on his phone and let me use it from my iPad. The Find My iPhone app didn’t find it, so the thief had probably turned it off right away. But I was able to request a remote wipe in case it’s ever turned back on, and I got an email from Apple saying all the card details had been removed from Apple Pay.

All of which meant I had to make a trip to the Apple Store on Saturday. And to the Three store, where it was alarmingly easy to get a replacement SIM. I just had to tell them my phone number and give them a payment card. No questions asked. Not even my name and address.

So I now have jet black 256 GB iPhone 7. Which is lovely. I’m late to all the new features, obviously, but here’s a quick rundown:

• TouchID: it’s now insanely fast to unlock my phone. Seems like it’s almost before I touch the home button sometimes.
• 3D Touch: people on podcasts seem to be saying they’ve stopped using this, but I’m loving it. Especially the edge-press for activating the app switcher (a feature which seems to be going away in iOS 11, I hear, so I probably shouldn’t get too used to it).
• The haptic feedback generally. Little clicks that tell you when you’ve activated something. Just makes the whole experience much nicer.
• The “taptic” home button. When I’ve tried this in the shop before now I wasn’t too sure about it. But a couple of days using it for real and I think maybe I prefer it to the feel of the old real button.

Plus, it’s black. Really, really black.

Even the box was black.

The cables are still white, of course. Which reminds me, I’ve always disliked Apple’s ear buds, and passed all my past ones on to my kids. But I thought I’d give these a try, not least because I wouldn’t mind trying the AirPods if they’re ever in stock anywhere,¹ and they have the same form factor.

And I don’t hate them. I thought I always had trouble getting them to stay in, but that doesn’t seem to be the case now. The main problem is they don’t give enough sound isolation, so you can hear the traffic and people talking even with music or a podcast playing. I’ve always preferred the kind with rubbery tips, which form a seal. But aside from that, these are better than I expected. Which bodes well for AirPods.

Downside: the battery life doesn’t seem dramatically better than my old one, weirdly. For the first couple of days it was busy downloading updates and restoring things (and getting hot), but that should be over now. I’m assuming that I just have to give it a few full cycles till it beds in and the measurement gets more accurate.

And all the things you have to set up again. That’s not the fault of the phone, though, so much as the way it came to me. If had planned this I would have done an encrypted iTunes backup, which would have meant more things were restored to the new phone.

Anyway, that was a lot of words and no links about not very much.

Our glorious leaders have seen fit to copy Trump and his cronies with banning laptops and tablets on planes — from certain countries. The only possible reason for this madness is to punish people for coming from (or visiting) those countries.

Worse, though: such a ban is only going to:

1. make things even more confusing and complex at airport security, and
2. get extended until it covers all flights, everywhere. You wait and see.

Those times when you’re typing a document at work on a shonky Windows 7 machine, and longing for your Mac, where you’d have professional text-handling tools, like Marked for previewing Markdown.

Not that you can’t preview, as long as you’ve got a decent text editor such as Sublime Text (well, specifically Sublime). But things are just so much easier with Mac tools.

And I speak as one who has never had the opportunity to use the Mac professionally. I’ve used Windows machines at works since about 1993, and before that green-screen 5250 terminals.

One of these days, though.

When the original Unix designers (or, as it turns out, Mike Muuss) chose ping as the name for the command for checking the status of a network host, it was a moment of inspired genius. The word is almost onomatopoeic in its appropriateness.

But nowadays people are pinging each other all over the place: emails, IMs, even phone calls are “pinged” at each other. “I’ll ping you an email,” they say.

The purist in me cringes a little each time I hear it. But it shouldn’t. The word that was so apposite for those early savants is just as suitable today: it communicates a needed concept. And English, of course, is a living, thriving language. So let people get on with it

Just don’t expect me to use it myself.

I’ve tried various email clients on iOS, but for quite a while now my favourite has been Dispatch from Clean Shaven Apps. As well as the many integrations and efficient handling of archiving and deleting emails, I like it because it is one of the only apps that lets you order mail in the One True Way.

Which in case you’re wondering is oldest at the top. Newest at the top is fine for blogs and similar news-based things, but it’s not right for anything else. Call me old-fashioned, but that was the default in Eudora and probably in Mutt and Elm and all those too, and it was and remains the best way.

Even Outlook lets you order it oldest-first. Though disturbingly few people take advantage of it.

Anyway, that’s not the point. The point is that today Dispatch let me down. I was typing a reply on my iPad this morning. The reply composition window looks like this:

I did something — I’m not sure what — that made the composition window slide off to the right. Part of it was still visible, so I tried tapping on it. And it disappeared.

There was no prompt, and nothing in my drafts folder. All that I had typed was gone, like tears in rain.

I’ve just been trying to reproduce it, and I can, up to a point: if you slide the compose window to the right it goes off out of the way, like this:

Which is actually quite useful, because it makes the compose window non-modal and lets you interact with your other messages. But somehow something can go wrong, even though I can’t make it happen now.

Not the end of the world. I retyped the mail. But that’s not good enough, Dispatch. You have to be able to trust your email client.

It ought to be easy to install a software package on Linux. I mean, it usually is. All modern distros ship with package managers, right? So all you should have to do is type (Debian-based example):

sudo apt-get install PACKAGE-NAME

and away you go. Right?

Well, usually. But today, not for me.

I have a NAS box from Western Digital, which is really a little Linux server with a biggish disk drive. Some time ago I replaced the shipped distro with a newer one, but it was so long ago, and it’s been so quiet and reliable that I can’t remember what version, exactly.

So first, there seems to be no way to interrogate it to see what distro it is. I mean, there must be, and this page lists several ways, but none of them work on this box. I mean, uname shows me the kernel version and all that, but not the distro.

Anyway, all that doesn’t really matter. I was only doing it to install Node, and I was only wanting to install Node so that I could run AirSonos. We got a Sonos Play:1 for the kitchen recently, and it’s great, but the one weakness is that it doesn’t support playing from an arbitrary source one your phone, such as, say, your podcast app of choice (Overcast, obvs).

AirSonos is supposed to effectively turn the Sonos into an AirPlay speaker, so you can easily send audio to it from iOS devices. And you want it to be running on a server, so it’s available all the time.

But it turns out that Node does not want to install on my NAS. Either by apt-get, as above, or by downloading the binary and unpacking it. (That installs it, obviously, but it won’t run.)

I’m going to try running SonoAir on my MacBook. That’s a wrapper round AirSonos, and obviously it’ll only work (assuming it does at all) when my MacBook is awake. But life’s too short.

If you’re using the excellent Pandoc to convert between different document formats, and you:

• want your final output to be in HTML;
• want the HTML to be styled with CSS;
• and want the HTML document to be truly standalone;

then read on.

The most common approach with Pandoc is, I think, to write in Markdown, and then convert the output to RTF, PDF or HTML. There are all sorts of more advanced options too; but here we are only concerned with HTML.

The pandoc command has an option which allows you to style the resulting HTML with CSS. Example 3 in the User’s Guide shows how you do this, with the -c option. The example also uses the -s option, which means that we are creating a standalone HTML document, as distinct from a fragment that is to be embedded in another document. The full command is:

pandoc -s -S --toc -c pandoc.css -A footer.html README -o example3.html

If you inspect the generated HTML file after running this, you will see it contains a line like this:

<link rel="stylesheet" href="pandoc.css" type="text/css">

That links to the CSS stylesheet, keeping the formatting information separate from the content. Very good practice if you’re publishing a document on the web.

But what about that “standalone” idea that you expressed with the -s option? What that does is make sure that the HTML is a complete document, beginning with a DOCTYPE tag, an <html> tag, and so on. But if, for example, you have to email the document you just created, or upload it to your company’s document store, then things fall apart. When your reader opens it, they’ll see what you wrote, all right; but it won’t be styled the way you wanted it. Because that pandoc.css file with the styling is back on your machine, in the same directory as the original Markdown file.

What you really want is to use embedded CSS; you want the content of pandoc.css to be included along with the prose you wrote in your HTML file.

Luckily HTML supports that, and Pandoc provides a way to make it all happen: the -H option, or using its long form, –include-in-header=FILE

First you’ll have to make sure that your pandoc.css file¹ starts and ends with HTML <style> tags, so it should look something like this:

<style type="text/css">
body {
    margin: auto;
    padding-right: 1em;
    padding-left: 1em;
    max-width: 44em; 
    border-left: 1px solid black;
    border-right: 1px solid black;
    color: black;
    font-family: Verdana, sans-serif;
    font-size: 100%;
    line-height: 140%;
    color: #333; 
}
</style>

Then run the pandoc command like this:

pandoc -s -S --toc -H pandoc.css -A footer.html README -o example3.html

and you’re done. A fully standalone HTML document.