<sup>ping trouble with a long spoon

I like Rob Goodlatte‘s Flow Theme for WordPress. But it makes me look like a shambling moron in some of my equations, viz.:

What’s ‘d2 v3’ supposed to mean? I certainly didn’t type that.

Digging (not very deeply) into Rob’s CSS, I found this section

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
 margin: 0;
 padding: 0;
 border: 0;
 outline: 0;
 font-size: 100%;
 vertical-align: baseline;
 background: transparent;
}

That forces pretty much all text to be aligned with the baseline, including <sup> and <sub>. While it may be all pretty like, it also destroys the sense of my markup.

Deleting the references to sub and sup in line 5 fixes the problem. Let’s have that equation again:

Laaaahrvely.

embedded Old Man Luedecke

Old Man Luedecke plays The Rear Guard in Toronto a couple of nights ago:

So if that didn’t work, here’s the YouTube video:

I took this with my little PowerShot SD790 balanced on a sugar bowl. Cropped and recoded in Avidemux2, it’s not bad. To get the embedded video above, I used ffmpeg2theora (thanks, Daring Fireball!).

Whatever you do, don’t – on your first try of recording live video – try using a setting you’ve never investigated. For the second set, I used CHDK‘s default video. It looks like an attack of mosaic tiles. Oh well.

implicit markup: easy to read, hard to parse

I don’t usually ponder about other people’s blog postings, but Jeff Atwood’s Responsible Open Source Code Parenting reminded me of some of the old wars that the used to be when I was a markup head. Jeff writes about his frustration that John Gruber’s Markdown text-to-html filter:

  1. hasn’t been updated for some time
  2. doesn’t quite do exactly what Jeff’s users at Stack Overflow want
  3. appears to have any changes in its behaviour from v1.0.1 strenuously vetoed by Gruber himself.

Markdown is nice in that you can write screeds of text, and it does almost exactly what you’d expect. The markup doesn’t get in the way, usually. The difficulty arises when implicit markup (indented lines for quoted text, bulleted lists, highlights) has to give way to explicit (cross-references, code samples). Explicit markup is ugly, but sometimes, you’ve got to do it. Complex intent requires complex modes of communication, and sometimes plain text just hasn’t the bandwidth. [As an aside, there was a hilarious lengthy recurring episode on John Mark Ockerbloom‘s late bookpeople mailing list where a user (mercilessly skewered here)  insisted that they could write a general Gutenberg plain-text converter that would re-create typeset quality in an e-book reader with no explicit markup, and that XML was completely unnecessary and ill-conceived. The un-markup language, called zen markup language (said user had an aversion to the shift key) lives on only in a single website: the home of z.m.l. As for XML, its executive assistant had no comment on the matter.] Looking at Markdown, it looks like Gruber’s moved on from it. He made a 1.0.1 which did what he wanted. The code’s there to change if anyone needs it. I understand his frustration at people wanting to make changes and still call it Markdown; I’d be annoyed if I had text which I thought was in one format suddenly not be accepted, or do something unexpected. Seriously, that’s almost as bad as ‘deprecated‘. [At least Gruber didn’t go on a deletion rampage, like (admittedly smaller-time) erstwhile CHDK stalwart Barney Fife did when he was slighted in a forum. Looks like almost everything he contributed to CHDK has been removed, including some very useful control scripts and explanations.] Personally, when I need to make text to web conversions, I still use txt2html and a bunch of shell and Perl glue to feed to tidy. It’s on its third maintainer, doesn’t do much, but does it simply. And I’m pretty simple that way.

Update: see also On my increasing exasperation with Markdown.

Scripting Radio Buttons

I use Perl’s HTML::Template module a lot. It allows you to write web pages that are dynamically modified by the controlling Perl CGI/mod_perl application.

Most of my applications fill in forms from values in a database. This is easy enough when you are filling text fields, but if you ever use radio buttons, things kind of fall down.

I’ve found a way around this. Let’s say you have a status field that can have three values:

  • active
  • blocked
  • retired

So in Perl I define three constants:

  use constant STATUS_ACTIVE => 'active';
  use constant STATUS_BLOCK => 'block';
  use constant STATUS_RETIRE => 'retire';

Then in the template, I have something like this:

  <input type="radio" name="status"
   <!-- TMPL_IF NAME=STATUS_ACTIVE -->
   checked="checked"
   <!-- /TMPL_IF -->
  value="active" />Active

  <input type="radio" name="status"
   <!-- TMPL_IF NAME=STATUS_BLOCK -->
   checked="checked"
   <!-- /TMPL_IF -->

  value="block" />Blocked

  <input type="radio" name="status"
   <!-- TMPL_IF NAME=STATUS_RETIRE -->
   checked="checked"
   <!-- /TMPL_IF -->
  value="retire" />Retired

If the status variable is $account->status, say, I’d use:

  $template->param(
   STATUS_ACTIVE => ($account->status eq STATUS_ACTIVE),
   STATUS_BLOCK =>  ($account->status eq STATUS_BLOCK),
   STATUS_RETIRE => ($account->status eq STATUS_RETIRE)
  );

and, magically, the template picks up the right value.

If the status variable isn’t set to one of the three predefined values, you get a radio group that none of the values is selected. You might wish to think about how you’d deal with that, perhaps setting a safe default.