For years, I’ve been using verbatim emphasis in org-mode to mark files and keyboard strokes, while reserving code emphasis to show function names, variables, and other elements of code.

With the reintroduction of <kbd></kbd> tags to the blog yesterday1, I wanted these tags to follow the same logic derived from my usage in org-mode: if I used verbatim in org-mode to indicate keystrokes and filenames, then I should use <kbd></kbd> tags on the blog to indicate the same thing. I explained in a footnote in the post: “The reason I have it different here is because I often talk about files in my posts without referring to code.” That might have been my preference, but it was wrong. We’ll get back to it in a minute.

I wanted to get my markdown-exported posts to preserve the verbatim emphasis from org-mode. But Markdown doesn’t distinguish between verbatim and code emphasis in org-mode — it treats both as ``, or <code></code> tags in HTML. So I started looking for a way to fix this.

The abridged version (the research took over an hour): I ended up with a wrapper function that would add Markdown raw code injection specifically for that code (I’m still working on it) to work with Pandoc. Why Pandoc and not Emacs’s built-in Markdown exporter? Because Emacs’s built-in exporter outputs certain characters, like my now beloved em-dash again, as character reference numbers, which results in a character reference (&#x2014 specifically) instead of an em-dash. Why’s that? Look, have you eaten breakfast today? Because I haven’t. Let me just tell you, these rabbits dig deep holes.

So now, after I had a working way (more or less) to produce my newly introduced <kbd></kbd> tags, I wanted to start using them for filenames. But I was bothered by the fact that while I can do whatever the hell I want this is not considered standard. And when I say “bothered,” I mean this is the thought I woke up to at around 05:40 this morning, which is what you get from a delirious dork Emacs brain like mine.

I knew HTML has standards, but I didn’t connect the logic behind it to semantic HTML — not until I browsed on my phone, in my bed, for another half an hour of impulsive research. Turns out, this is something that some folks take very seriously. And according to these folks, filenames and paths do not and should not have a dedicated HTML tag (surely not <kbd></kbd>, which is for keystrokes only — actually, it’s for “textual user input” which can include voice, for example). Authority has it that I should be indicating filenames using the <code></code> tags (and code emphasis in org-mode), and there’s a good reason for that. Just take my word for it for now (breakfast, remember?)

Reading through their tomb of standards, I realized I need to correct my headings on the blog too (I jump directly to <h3></h3> tags instead of going by order, because the CSS for these tags looks better — in other words, I’ve been lazy by not fixing this), among potentially many other things. There are over a hundred semantic tags in HTML, and there’s a reason for each one.

Damn those rabbits.

Footnotes


  1. I realize that most of you read this via RSS, which might translate these tags as code anyway, making the entire point moot... if you want to see what I mean, you might have to actually use your browser and visit my page as is, just this once.
    
     ↩︎