[rfc-i] <tt> vs HTML5

cabo at tzi.org (Carsten Bormann) Sat, 20 February 2016 13:27 UTC

From: cabo at tzi.org (Carsten Bormann)
Date: Sat, 20 Feb 2016 14:27:42 +0100
Subject: [rfc-i] <tt> vs HTML5
In-Reply-To: <56C84484.2000902@gmx.de>
References: <56C84484.2000902@gmx.de>
Message-ID: <56C869CE.20602@tzi.org>

Julian Reschke cited HTML5:
>     Where the tt element would have been used for marking up keyboard
> input, consider the kbd element; for variables, consider the var
> element; for computer code, consider the code element; and for computer
> output, consider the samp element.

Indeed, `tt` is as "wrong" as `b`, `i` etc.

I would prefer if the most common span-level elements we have can
generally be generated from readable, common markdown syntax.

There is markdown syntax for `code` elements (which I'm using in this
paragraph).  Now, `kbd` and `samp` elements would need to be written as

~~~
This is <kbd>typed input</kbd> and its <samp>computer output</samp> in a
markdown document.
~~~

which is very precise, but also less readable for the author.
(Which may be OK in the RFC context, as keyboarding and listing of
computer output should be rare in RFCs.)

There is also no good way*) in a code block like the above to point out
that it really is a block of computer output.
Of course, syntax can be invented, but new syntax means making less use
of the tools already in the markdown ecosystem.

Making life good for the authors of course is just one of many
objectives going into the design, but readability of manuscripts does
help with minimizing errors and maximizing quality of the end result.

Gr??e, Carsten

*) not counting hacks such as defining an artwork type of `samp` as
"good" here