This Blog Is Not For Reading

Luddite Memorial, Liversedge

Him: Bob, have a look at this video: LOLcats at work

Me: Did you intend to send a link with that?

Him: Yes, here it is: LOLcats at work

Me: Sorry, still no link. Remember, I don’t receive HTML e-mail…

Him: Wut? I’ve never heard of someone not receiving HTML e-mail!

E-mail was never designed for HTML; it is intended to be a plain-text medium. HTML is merely cobbled on, and mail clients have no standard way to render HTML messages, resulting in different displays on different mail programs. Some mail programs, especially those run from the command line, can’t show HTML rendered messages at all.

Although I use a graphical mail client (Thunderbird), I choose to not display HTML for two reasons:

1) Security: HTML mail can have Javascript code or other objects embedded. That’s a great way to get virus infections on your computer. I don’t want any code running on my computer that I didn’t put there myself.

2) Privacy: HTML mail that links to external images allows the owner of those images to track your mail usage: When you open the mail, how often you open it, the location you open it at, what computer you’re using, and whether you forward it to others (and then, when they open the mail, how often, their location, &c).

Not to mention that HTML messages are far bigger than text messages, especially when the HTML contains embedded images, fonts, and other stuff. Now, that’s not such a big deal with fast connections, unlimited download caps, and cheap disk drives, but it will still make a difference on small-format devices like phones and watches.

That said, if you do send me HTML e-mail, be sure to embed any images or LOLcat videos. That way I can still view them as static attachments, without revealing when, where, and how often I view them.

For more info have a look at the Wikipedia article on HTML e-mail

–Bob.

You can send HTML e-mail to Bob Jonkman at bjonkman@sobac.com

The Luddite Memorial, Liversedge by Tim Green is used under a Creative Commons — Attribution 2.0 Generic — CC BY 2.0 license.

Delete

The rest of us, Prone to Pecadillos, may occasionally write blogposts and then change our minds about the content. When that happens it’s best not to make changes or delete posts without letting your readers know.

Instead of making a wholesale change to a post it’s better to create a new post. Imagine if someone wrote about a similar issue, quoted from your post and provided links to it. Now your post has changed, and the links no longer make sense because the content has changed. Or someone makes a comment on a post, the content of the post is changed, and now the comment has nothing to do with the post.

Instead, create a new post with a new link. It’s a good idea to keep the original post; you could delete it, but then other people’s links would return an error (that’s called “link rot”).

About the only good reason for modifying an existing post is to correct an error. Even then you shouldn’t delete the incorrect material, but indicate it should be deleted by using the <del> tag, and marking the new material with an <ins> tag. For example:

The Javan Rhinoceros <del>has only one survivor </del> <ins> is now extinct</ins> in Vietnam.

This would show with crossed-out text for <del> and highlighted text for <ins>, like this:

The Javan Rhinoceros has only one survivor is now extinct in Vietnam.

(which is a sad development, and may be worthy of a post of its own).

If you really want to delete a post then replace it with text like “This post has been removed by the author”. If you do that then you should delete or hide the comments too.

These are open and transparent ways to indicate deletions. It’s merely an online publishing convention, since there really isn’t a style guide for HTML like Strunk and White’s in the online world. Or, more accurately, there are far too many Strunk and White’s in the online world!

–Bob.

Delete by delete08 is used under a CC-BY-NC license