Was talking with Chat about whether or not we were maximally using HTML tags that are more semantic in nature in this site’s templates and processing. Given that this is currently a Hugo based site, and its pretty easy to improve HTML usage with automation, I thought it would good to explore this.
Here are some cool (by my estimation) HTML tags that I was not aware of before.
abbr is for acronyms and abbreviations. I find this valuable because while I love to use acronyms for the improved information density, I really don’t like assuming that everyone reading will be aware of what they mean. As a reader/learner I find these types of assumptions very freustrating, especially when they are for terms and abbreviations specific to an industry. Using this tag lets me document what abberviations stand for pretty easily.
Now, I figured it would be really annoying to have to dedicate a cycle to updating every post I write with these tags manually, and using an agent would work but we use code for everything we can. So what I did was use a preprocessor on my articles searching for acronyms, and I started keeping a central list of all the acronyms I want defined. This way I can get the first use per-post to have a tooltip and definition the user can click on.
<abbr title="Model Context Protocol">MCP</abbr>
<abbr title="Command Line Interface">CLI</abbr>
<abbr title="Out Of Memory">OOM</abbr>dfn Is a way to identify a term we want to define. When left alone I tend to settle on my own language for things. Sometimes they are pretty intuitive like the term Gap and sometimes it needs a little explenation like when I say I am talking to Chat (because I guess I’m just a little twitch-rotted). Either way, it’s helpful to have embedded definitions and this lets me also make use of popovers to display the definition on hover.
<dfn>Gap</dfn> is the difference between what I expected and what actually happened.I think it’s pretty neat.
This one may have been obvious to others but I didn’t know about the <q> tag for “inline quote” formatting. I was thinking of making a parser syntax for markdown to support this (compared to > block quotes) but then realized its already so short I should just turn on raw HTML support in my .md -> .html processing and rip the raw <q> tags.
Why would I want to format this differently you say?
<q>Because it looks cooler that way</q> I sayWhy would I want to format this differently you say? Because it looks cooler that way
I say.
samp is for output from a program, tool, model, shell, whatever. In the Reflection post, the commit.md windows are code or prompt text, but the response windows are sample output.
<pre><samp>Update parser
Updated the parser to handle large files better.</samp></pre>I don’t really know how useful this one is but it was new to me so I thought I would mention it.
aside is for “a side” note. This is a semantic way for me to have sub-text in these code block windows. When I tag a codeblock like such
```text { title="commit.md" caption="Green highlight means we net-added this from the previous entry." }
Write a commit message for this diff. ++Include why the change was made, not just what.++
```this ends up being
Write a commit message for this diff. ++Include why the change was made, not just what.++which among other things includes.
<aside class="code-window-note">
Green highlight means we net-added this from the previous entry.
</aside>So if I can hide the HTML through markdown preprocessing or Hugo hooks I’m all for it. In the cases where its simplest just to throw some tags into the markdown directly, I just go with that.