[rfc-i] <tt> vs HTML5

To be honest, I prefer <kbd>, <code>, ... over <b>, <i>, ... Maybe it is my
LaTeX background, but I like the idea of logical (say, semantic) markuo,
where you declare what that piece of text represents and leave unspecified
the way it is rendered.  Yes, it is a little bit (how much?) to write, but
the flexibility you gain is immense.  You can decide later if you want to
represent the code with simple monospace font or maybe a bold one.  Maybe
you could want to use monos?ace fonts both for <code> and <samp>, but maybe
with different colors or using italic shape for <samp>... It is also much
easier to keep the same typographical convention over the whole document,
instead of checking of having used the same family, weight, size, ... for
every piece of code, variable, ...

Yes, when I write <code> I do not know how the text will be rendered to the
final user -- maybe because each user will have its preferences -- and,
personally, I do not care, I am happy to concentrate my efforts in writing
a good text, leaving all the aesthetic  decision to style files and user
preferences.

Riccardo

On Sat, Feb 20, 2016 at 2:27 PM, Carsten Bormann <cabo at tzi.org> wrote:

> 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
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20160220/a026a031/attachment.html>