Verbatim or the like

Discussion in 'HTML' started by Dieter Britz, Sep 21, 2009.

  1. Dieter Britz

    Dieter Britz Guest

    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.
    --
    Dieter Britz (dieterbritz<at>yahoo.com)
     
    Dieter Britz, Sep 21, 2009
    #1
    1. Advertising

  2. Ben C wrote:
    > On 2009-09-21, Dieter Britz <> wrote:


    >> 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.

    >
    > PRE (stands for "preformatted" which is a euphemism for "not
    > formatted").


    To OP a handy reference for you:

    http:://www.w3.org/TR/html4/index/elements.html

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Sep 21, 2009
    #2
    1. Advertising

  3. Ben C wrote:

    >> 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.

    >
    > 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...

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Sep 21, 2009
    #3
  4. Ben C wrote:
    [...]
    > I wouldn't use PRE except for code listings.

    [...]

    You wouldn't use <code> then?

    Cheers,
    Nige

    --
    Nigel Moss
    http://www.nigenet.org.uk
    Replace "spamfree" in email address with "nigel" to reply
    "Your mother ate my dog!", "Not all of him"
     
    nice.guy.nige, Sep 21, 2009
    #4
  5. Dieter Britz

    William Gill Guest

    William Gill, Sep 21, 2009
    #5
  6. Dieter Britz

    dorayme Guest

    In article <>,
    Ben C <> wrote:

    > On 2009-09-21, Dieter Britz <> wrote:
    > > 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.

    >
    > 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;

    --
    dorayme
     
    dorayme, Sep 21, 2009
    #6
  7. Dieter Britz

    dorayme Guest

    In article <pRNtm.18910$>,
    "Jukka K. Korpela" <> wrote:

    > Ben C wrote:
    >
    > >> 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.

    > >


    >
    > 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.

    --
    dorayme
     
    dorayme, Sep 21, 2009
    #7
  8. William Gill wrote:
    > Jonathan N. Little wrote:
    >
    >> To OP a handy reference for you:
    >>
    >> http:://www.w3.org/TR/html4/index/elements.html
    >>

    > 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! ;-)

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Sep 22, 2009
    #8
  9. Dieter Britz

    William Gill Guest

    Jonathan N. Little wrote:
    > William Gill wrote:
    >> Jonathan N. Little wrote:
    >>
    >>> To OP a handy reference for you:
    >>>
    >>> http:://www.w3.org/TR/html4/index/elements.html
    >>>

    >> 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! ;-)
    >

    I think that was a brain tremor. Sorry.

    --
    Bill
     
    William Gill, Sep 22, 2009
    #9
  10. Ben C wrote:

    > On 2009-09-21, nice.guy.nige <> wrote:
    >> 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.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Sep 22, 2009
    #10
  11. Dieter Britz

    dorayme Guest

    In article <2d8um.19278$>,
    "Jukka K. Korpela" <> wrote:

    > ... 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?

    --
    dorayme
     
    dorayme, Sep 23, 2009
    #11
  12. Dieter Britz

    Nik Coughlin Guest

    "dorayme" <> wrote in message
    news:...
    > In article <2d8um.19278$>,
    > "Jukka K. Korpela" <> wrote:
    >
    >> ... 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?


    Au contraire :)

    Markup is declarative code.
     
    Nik Coughlin, Sep 23, 2009
    #12
  13. Dieter Britz

    dorayme Guest

    In article <h9cc62$ro9$-september.org>,
    "Nik Coughlin" <> wrote:

    > "dorayme" <> wrote in message
    > news:...
    > > In article <2d8um.19278$>,
    > > "Jukka K. Korpela" <> wrote:
    > >
    > >> ... 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?

    >
    > 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)

    --
    dorayme
     
    dorayme, Sep 23, 2009
    #13
  14. dorayme wrote:

    > 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.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Sep 23, 2009
    #14
  15. Dieter Britz

    dorayme Guest

    In article <Hfsum.19662$>,
    "Jukka K. Korpela" <> wrote:

    > dorayme wrote:
    >
    > > 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".
    >

    ....
    >
    > 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.


    > 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.


    --
    dorayme
     
    dorayme, Sep 23, 2009
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Patrick Kowalzick
    Replies:
    5
    Views:
    500
    Patrick Kowalzick
    Mar 14, 2006
  2. Replies:
    1
    Views:
    412
    Jim Langston
    May 29, 2006
  3. Guest
    Replies:
    6
    Views:
    1,775
    Guest
    Apr 25, 2010
  4. Cortes
    Replies:
    1
    Views:
    94
    Lasse Reichstein Nielsen
    Jun 2, 2004
  5. Replies:
    1
    Views:
    153
    Dr John Stockton
    Mar 23, 2006
Loading...

Share This Page