Say hello to the kbd and samp elements
Ever heard of the <kbd> element? Probably not, neither had I until recently! As you may have guessed already, kbd stands for keyboard, with that information alone you can probably guess what it's used for - but let's look at a quote from the great MDN just to clarify:
The HTML <kbd> Element (or HTML Keyboard Input Element) represents user input and produces an inline element displayed in the browser's default monotype font.
the default styling on a kbd element results in this: esc
Simple enough right? I can see a few situations already where this might be useful, customer documentation comes readily to mind; but developer forums/community websites like Stackoverflow also make good use of this element.
Unfortunately for us, the implementation is a bit more complicated than that, and if you want to fully utilise this element it's also necessary to know about other ambiguos elements too, let's look at a quote from the official HTML5 spec on the matter:
The kbd element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).
When the kbd element is nested inside a samp element, it represents the input as it was echoed by the system.
When the kbd element contains a samp element, it represents input based on system output, for example invoking a menu item.
When the kbd element is nested inside another kbd element, it represents an actual key or other single unit of input as appropriate for the input mechanism.
There's start with the second and third lines of that quote (I think we've pretty much covered the first already).
These lines talk about the samp element, the HTML5 spec describes this element as follows: The samp element represents (sample) output from a program or computing system.
Simple enough right? The following example from the spec should help clear things up a little:
<p>The computer said <samp>Too much cheese in tray two</samp> but I didn't know what that meant.</p> Thankfully the spec doesn't seem to complicate things any further apart from referencing its use with relation to the <kbd> element. I won't elaborate further on those two lines, as I think it would unnecessarily complicate this article (I think the use cases for those two situations are very few indeed).
Now let's focus on the last line of that quote. This line seems to infer that you need two kbd elements to represent an actual key (I had to do a double take here, don't worry this is correct!), and hopefully should you want to use the element in those situations the spec should be helpful enough.
I think it's pretty reasonable to question the sensibility of this, but it does make sense when indicating a key combination, for example:
<p>Highlight some text then press <kbd><kbd>Ctrl</kbd> + <kbd>C</kbd></kbd> to copy it.<p> The spec does however conclude that Such precision isn't necessary
so you can equally just write the above as:
<p>Highlight some text then press <kbd>Ctrl</kbd> + <kbd>C</kbd> to copy it.<p> Am I actually going to end up using this!?
There are only a few fringe cases in which I can see the <kbd> element actually being useful (and even fewer for the <samp> element). To top it all off I can't really see how the kbd elemet can actually be useful for end users (after some research it appears it offers no accessibility benefits) or for developers (other than for a styling hook, but if you live off of oocss like me you should probably be using classes anyway)
Quite why it is included in the spec is a bit of a mystery to me, it sounds mildly useful at first, but when you realise that <kbd>Ctrl</kbd> + <kbd>C</kbd> actually carries no more meaning than <span class="kbd">Ctrl</span> + <span class="kbd">C</span> it becomes quite apparent that using it is probably a waste of both time and effort.
Some poeple out there may well use it on the basis that It's more semantic to do it this way!
but I would disagree, search engines and browsers treat it no differently than a span tag, browsers add default stlying to it, but you'll probably want to overide this anyway so it ultimately ends up being more of a hinderance than help. To top it off users don't gain anything from its usage (and neither do developers from my viewpoint). Unfortunately all of the above seems to hold true for the samp element too.
Here's to hoping the elements I cover in my next post are a bit more useful!