Intention of verbatim text?

Intention of verbatim text?

[c.buhtz]

Hi,

in org you can have inline verbatim and code text elements like this.

    Example with =verbatim= and ~code~.

I would like to understand what "verbatim" really means. What is the
semantic behind it? What content should go in there?


I'm aware of the separation of content and its presentation.
I'm also aware of the different renderings in my Emacs. Booth are
monotype but with different colors.

The org html export to create both with <code> tag. So in HTML output
there is no difference between verbatim and code anymore.

I also read a lot about the HTML tags code, pre, kbd and samp.

I wonder that maybe I totally misunderstand the intention of
"verbatim"?

The background of my question is that I have my own
org-to-html-converter [1] and try to decide how to treat =verbatim=.
Which HTML tag should I use.

Thanks
Christian

[1] -- <https://codeberg.org/buhtz/hyperorg>

Re: Intention of verbatim text?

[Daniel Fleischer]

c.buhtz@posteo.jp [2023-01-03 Tue 13:20] wrote:

> in org you can have inline verbatim and code text elements like this.
>
>     Example with =verbatim= and ~code~.
>
> The org html export to create both with <code> tag. So in HTML output
> there is no difference between verbatim and code anymore.
>
> I also read a lot about the HTML tags code, pre, kbd and samp.
>
> The background of my question is that I have my own
> org-to-html-converter [1] and try to decide how to treat =verbatim=.

According to https://stackoverflow.com/questions/32284477 they have
different semantics but are rendered the same (by default); they could
be rendered differently, depending on a website's CSS. Maybe use the
semantics for your own org-html converter.

-- 
Daniel Fleischer

Re: Intention of verbatim text?

[Tim Cross]

<c.buhtz@posteo.jp> writes:

> Hi,
>
> in org you can have inline verbatim and code text elements like this.
>
>     Example with =verbatim= and ~code~.
>
> I would like to understand what "verbatim" really means. What is the
> semantic behind it? What content should go in there?
>
>
> I'm aware of the separation of content and its presentation.
> I'm also aware of the different renderings in my Emacs. Booth are
> monotype but with different colors.
>
> The org html export to create both with <code> tag. So in HTML output
> there is no difference between verbatim and code anymore.
>
> I also read a lot about the HTML tags code, pre, kbd and samp.
>
> I wonder that maybe I totally misunderstand the intention of
> "verbatim"?
>
> The background of my question is that I have my own
> org-to-html-converter [1] and try to decide how to treat =verbatim=.
> Which HTML tag should I use.
>
> Thanks
> Christian
>
> [1] -- <https://codeberg.org/buhtz/hyperorg>

IMO (and it is just my opinion, not that of the org developers), the
main use of verbatim (i.e. =text=) is to escape any further
interpolation as org markup. It basically says, when exporting, export
'as is' with no further processing.

Consider a situation where you want to write A_B, but don't want it to
be interpreted as A with a subscript B. There are a number of ways to
handle this. One is to set the #+OPTION to ^:nil and turn off the
behaviour for the whole file or you can use =A_B= to just turn it off
for that use (though this does have other possibly unintended
side-effects, such as a font change, but I'm really just trying to
illustrate the point here).

I would have to look more closely at the output of the HTML export to
verify your assertion that both verbatim and code are rendered the
same. With respect to 'phrases', I guess there is no real difference in
outcome. However, the standard HTML code tag does not preserve line
breaks. Traditionally, for blocks of code, the code tag would also be
wrapped in the pre tag. However, things have evolved and now it is much
more common to see just the code tag with an additional CSS class which
is used to manage the preservation of line breaks and whitespace. From a
purely tecnical 'correctness' standpoint, I would argue that =text=
should be rendered as <pre>text</pre> and not <code>text</code>. When
exporting data, we don't have any semantic markers/information for
=textg=, so wrapping it in a semantic tag like <code> is IMO incorrect
as we are imposing a semantic interpretation without justification. .

Re: Intention of verbatim text?

[c.buhtz]

Thanks for all your feedback.

On 2023-01-04 05:58 Tim Cross <theophilusx@gmail.com> wrote:
> argue that =text= should be rendered as <pre>text</pre>

I did this before but then got them as paragraphs. Not sure how the
correct term of this is in HTML. pre is not inline but handled as an
own paragraph so that you have an extra line in the rendered HTML
output.

> markers/information for =textg=, so wrapping it in a semantic tag
> like <code> is IMO incorrect as we are imposing a semantic
> interpretation without justification.

I also agree that the current org html export is not specific enough
here.

My current solution is to convert ~code~ to <code>code</code> and
=verbatim= to <code class="verbatim">verbatim</code>.

In that case the user can decide himself how to render them. In my
default CSS I would render the ~code~ in monospace with a light gray
background (different from the whole page background) and =verbatim=
with monospace only but without extra background color.

Kind
Christian

Re: Intention of verbatim text?

[Tim Cross]

<c.buhtz@posteo.jp> writes:

> My current solution is to convert ~code~ to <code>code</code> and
> =verbatim= to <code class="verbatim">verbatim</code>.
>
> In that case the user can decide himself how to render them. In my
> default CSS I would render the ~code~ in monospace with a light gray
> background (different from the whole page background) and =verbatim=
> with monospace only but without extra background color.
>

I think I would agree in an approach which leverages the power of CSS is
the best approach. My own personal preference would be to have as much
of the rendering/formatting of various elements managed by CSS classes
as possible as this would make it much easier for users to change how
things are rendered by modifying the CSS classes. Frameworks like Bulma
(https://bulma.io) show how powerful just using CSS can be. Much easier
to modify a CSS class than change a tag.