Verbatim or the like

D

Dieter Britz

I use HTML markup directly, to make web pages, not web page tools. Now I
want to reproduce some text as is, i.e. not have it formatted. An example
might be a program, or, say, a poem. In my case, some BibTeX entries.

Is there an HTML markup that prevents formatting, like <NOFORMAT>, or
<LITERAL> or the like? I tried googling, but find only pointers to
buttons to press within web building tools - which I don't use.
 
J

Jukka K. Korpela

Ben said:
PRE (stands for "preformatted" which is a euphemism for "not
formatted").

I would not call it a euphemism. Informally, <pre>...</pre> means: the text
data inside the tags has been formatted in a particular way, as regards to
the use of spaces, newlines, and other whitespace - don't change this the
way you usually (and for good reasons) do with text! Se it's preformatted
and must not be reformatted.

On the other hand, is such formatting essential to poetry? Poetry is
thousands of years older than written language, not to mention spaces and
significant newlines. While a poem can usually be divided into units we
might call "lines", in an abstract structural sense, and this concept can
usually be mapped to the concept of a line of text, I would rather use some
markup for the lines, say

<div class="poem">
<div>...</div>
<div>...</div>
....
<div>...</div>
</div>

The advantages might become obvious if you think how a poem should be
rendered in a small-size device, like a fairly primitive cell phone with a
small line length. Using <pre> you lose data or get a horizontal scroll bar.
Using the approach I suggest, you could use CSS to suggest indentation of
continuation lines in order to make the structure (division into abstract
"lines") understandable.
Still need to escape < and > (use &lt; and &gt;).

No, only "<" and "&" need to be escaped, and in some contexts only. It's a
good idea, though, to escape all of "<", ">", and "&" independently of
context (when they are not used for markup), just for simplicity. And of
these, "&" is probably the one that might appear in poetry...
 
D

dorayme

Ben C said:
PRE (stands for "preformatted" which is a euphemism for "not
formatted").

Still need to escape < and > (use &lt; and &gt;).

If you are in a hurry, select all the stuff in PRE and tell your GREP
enabled editor to replace <([^<>]+)> with \&lt;\1\&gt;
 
D

dorayme

"Jukka K. Korpela said:
On the other hand, is such formatting essential to poetry? Poetry is
thousands of years older than written language, not to mention spaces and
significant newlines.
While a poem can usually be divided into units we
might call "lines", in an abstract structural sense, and this concept can
usually be mapped to the concept of a line of text, I would rather use some
markup for the lines, say

<div class="poem">
<div>...</div>
<div>...</div>
...
<div>...</div>
</div>

The advantages might become obvious if you think how a poem should be
rendered in a small-size device, like a fairly primitive cell phone with a
small line length. Using <pre> you lose data or get a horizontal scroll bar.
Using the approach I suggest, you could use CSS to suggest indentation of
continuation lines in order to make the structure (division into abstract
"lines") understandable.

Some poetry is meant to be seen, something that straddles more
traditional notions (that lend to your mark up above) and visual art
(that do not). There is an argument for desisting from trying to cater
to primitive cell phones for this type of poem. A wrong impressionwill
be created. Better for a *difficulty* to exist than a ruination of a
fine visual poem.
 
J

Jonathan N. Little

William said:
To OP Jonathon's hand must have stuttered a bit. The link is:

Yep, Jonath*a*n's hand has a mind of its own, a common affliction! ;-)
 
J

Jukka K. Korpela

Ben said:
Ben C wrote:
[...]
I wouldn't use PRE except for code listings.
[...]

You wouldn't use <code> then?

I do use that but only for function names or keywords etc. appearing
in the middle of other text.
Odd.

But you make a good point-- why not use it for code listings and make
it display: block?

Because <code> is by definition inline (text-level) in HTML, and it
generally causes confusion and risks to make inline elements display as
blocks or vice versa. It's also pointless. If you don't like to use <pre>
(which I understand), then use <div> for a block. Using <code> inside it is
logical if the content is computer code. But it has nothing to do with the
issue of preserving whitespace.
 
D

dorayme

"Jukka K. Korpela said:
... then use <div> for a block. Using <code> inside it is
logical if the content is computer code...

Ah... I have seen it used - perhaps unwisely - for inline display of
HTML mark-up. Is this taking too much liberty, markup clearly not being
computer code?

Ever seen samp being used?
 
N

Nik Coughlin

dorayme said:
Ah... I have seen it used - perhaps unwisely - for inline display of
HTML mark-up. Is this taking too much liberty, markup clearly not being
computer code?

Au contraire :)

Markup is declarative code.
 
D

dorayme

"Nik Coughlin said:
Au contraire :)

Markup is declarative code.


Sounds loud! <g>

I have felt without having any firm argument that the element code is
rather too narrow as just computer code and just as a bit of revisionism
goes on in the law by less than literalist black-letter judges,
especially at the constitutional level, so too a little bit will be to
the good here...

(That is not my tuppence worth btw, if any one finds it useful or
enlightening, please send *at least* $US5)
 
J

Jukka K. Korpela

dorayme said:
I have felt without having any firm argument that the element code is
rather too narrow as just computer code

Well, that's how it has been defined, anyway. But we can interpret "computer
code" wider than "program code".
and just as a bit of
revisionism goes on in the law by less than literalist black-letter
judges, especially at the constitutional level, so too a little bit
will be to the good here...

You lost me there... sorry I was thinking about other matters... like the
following:

The code element is by default rendered in a monospace font, and this is
usually the only implication of using that markup. However, some automatic
translation programs have been observed to interpret code element content so
that it shall not be translated, i.e. that it shall remain invariant in
translations. For example, <code>print</code> remains unchanged instead of
becoming <code>sortir</code>. This is a good thing of course.

But this also raises the question whether code markup should be defined so
that it indicates its content as being a code expression in some agreed
system of codes, not a natural language expression. For example, if some
text mentions CAT as an airport code, it should be treated as
translation-invariant the same way as, say, the UNIX "cat" command name
should be - quite independently of rendering issues. (Note that this is not
about abbreviations. Abbreviations and codes are different beasts, even
though many codes have been formed as abbreviations.)

If <code> markup were used consistently (you wish!), search engines could do
clever things, letting people interested in, say, "CAT" as a code of some
kind search for its occurrences in such usage, without being thrown at with
all the cats in the world.
 
D

dorayme

"Jukka K. Korpela said:
Well, that's how it has been defined, anyway. But we can interpret "computer
code" wider than "program code".
....

The code element is by default rendered in a monospace font, and this is
usually the only implication of using that markup.

Perhaps there is also the slight practical author advantage in having
GREP patterns to scan documents and replace some characters to render
them harmless to browsers (> to &gt;...) - find and replace but only
within <code></code>. I was also imagining, more to the point, that some
human readers, perhaps blind ones, might have some ways to receive the
information in code elements in a more digestible form, their browsers
doing various helpful things...
However, some automatic
translation programs have been observed to interpret code element content so
that it shall not be translated, i.e. that it shall remain invariant in
translations. For example, <code>print</code> remains unchanged instead of
becoming <code>sortir</code>. This is a good thing of course.

I suppose it is good in many ways. Perhaps it is not as good as it could
be if HTML mark-up is being displayed in the code element in some
situations. But this perhaps touches on your other point about the
possibility of the content being indicated.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top