I just realized how multisensory the traditional Unix text mode interface was. You would never check your mail every five minutes, because sysline would tell you when to check mail. And every half hour the beep tells you 30 minutes have passed—if you follow the 30/30/30 rule (rather than the 20/20/20 rule favoured by Canadian optometrists) you know it’s time to walk around or at least look outside the window.

If you don’t know what I’m talking about, I’ve just made somewhat of an adequate simulation, at least for sysline’s half-hour beeps. Leave it open in your browser for at least an hour.

Just a few minutes ago I came to the conclusion that the q tag must not be rendered with quotation marks, and was surprised to find Stacey Cordoni’s article “Long Live the Q Tag” which came to the exact same conclusion, albeit for a different reason.

Anyway, I was editing my previous post and was looking at this:

…or he wouldn’t have suggested that I “get ready to feel unbored.”

The period being inside the quotation mark is an artefact of North American typographic rules. It’s purely visual (something I have been trying to emphasize every time this “rule” is mentioned in editorial circles), and you could argue it’s a case of kerning taken to the extreme. But logically it doesn’t make sense because what the person actually said was

Then get ready to feel unbored!

So the period doesn’t really belong. How do we mark up this fact? Of course we have the q tag, so imagine

…or he wouldn’t have suggested that I “<q>get ready to feel unbored</q>.”

which would have made perfect logical sense, and would mean “the quote doesn’t actually contain a period, but for presentation purposes the period is inside the quotes,” except it doesn’t work, because Chrome actually renders this as

…or he wouldn’t have suggested that I ““get ready to feel unbored”.”

Confused, I looked up the specification of the q tag and found that indeed, the q tag is “supposed” to be rendered with quote marks. Bummer…

Since I thought there was another tag that acts like q but rendered without quote marks, I tried to look for it, but came up empty-handed. Instead, I ran into Stacey Cordoni’s article.

The only logical way to solve the q tag problem is to make it, through CSS, render without quotation marks. But of course, if current versions of lynx really are rendering the quote marks, then this workaround doesn’t even work.

In retrospect, I realize I had come to the same conclusion years ago. The q tag is just badly designed: Being incompatible with typographic conventions aside (and useless as a workaround for illogical typographic conventions), if browsers implemented it to spec, then it’s not possible to add tags to an existing text and not mess up the punctuation.

I have no idea why the W3C designed the q tag the way it is. Didn’t they have any North American typographers—or even copy editors—on their committees?… Maybe everyone was European. Sigh.

A few random things I learnt while I pretty much gutted the entire CSS file and redid this blog’s layout from scratch:

• Drupal supports subthemes and I have absolutely no idea how to use them.
• The html.tpl.php file controls how HTML is emitted.
• If you centre an element using margin-left: auto and margin-right: auto, adding padding will not produce any effect.
• It is supposedly possible to insert Javascript by modifying the .info file in the theme directory, but this does not seem to work.
• The .focusin, .focusout, and .on methods did not exist in very old versions of jQuery.
• If you want to hide a menu at the bottom of the screen, make sure to test whether the hiding and unhiding work with keyboard navigation (plain tabbing and shift-tabbing). There are a number of unexpected points to note in order for unhiding to work correctly:
  • Nothing will trigger the hover event when using keyboard navigation, so don’t put, for example, important things like the menu’s background colour into the hover trigger.
  • Contrary to what you might expect, keyboard navigation will not trigger a CSS focus event. So putting :focus rules into your CSS won’t do a thing.
  • Hiding through absolute positioning is better than setting display to none. Otherwise, when the focusin handler fires, unhiding might not work correctly.
  • Inserting a dummy A element (e.g., with a URL of javascript:true) is better than just setting tabindex to 0 on an ordinarily inert element.

  When this isn’t done right very weird things can happen. For example, you can end up with menus that never unhide when you use keyboard navigation, or you can end up with menus that will pop up but with live links in the menu that the tab key will just skip right over.