By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,154 Members | 1,050 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,154 IT Pros & Developers. It's quick & easy.

<pre> and proportional vs fixed width fonts

P: n/a
I've marked up song lyrics with the <pre> tag because it seems the most
appropriate type of markup for the type of data. This results in
inefficient use of horizontal space due to UA's default rendering of
<pre> in a fixed width font.

To change that I'd have to specify a proportional font family, thereby
falling into the size pitfall that is associated with any sort of author
specified font family:

a) If I specify a sans serif font then the font size is going to be to
large for people who have serif as their default font.
b) If I specify a serif font then the font size is going to be to small
for people who have sans-serif as their default font.

What I'd like to do is specify that the UA's/user's preferred
proportional font should be used, but of course this isn't possible.

Am I correct that this is an un resolvable dilemma?
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #1
Share this Question
Share on Google+
21 Replies


P: n/a
Headless <me@privacy.net> writes:
I've marked up song lyrics with the <pre> tag because it seems the most

a) If I specify a sans serif font then the font size is going to be to
large for people who have serif as their default font.
b) If I specify a serif font then the font size is going to be to small
for people who have sans-serif as their default font.
Specify sans-serif and assume people will complain less about too big
than too small?
What I'd like to do is specify that the UA's/user's preferred
proportional font should be used, but of course this isn't possible.

Am I correct that this is an un resolvable dilemma?


pre { font-family: inherit; }

Works in Gecko-based browsers, not in Opera 7 or IE6, though. From my
reading of the spec I think it *should* work in a general bug-free
browser.

--
Chris
Jul 20 '05 #2

P: n/a
In article <7r********************************@4ax.com> in
comp.infosystems.www.authoring.stylesheets, Headless
<me@privacy.net> wrote:
I've marked up song lyrics with the <pre> tag because it seems the most
appropriate type of markup for the type of data.


As you observe below, it's not really the most appropriate because
it forces a monospace font.

Rather than redefine <pre> in styles, why not just create styles to
do what you want? Something like this (untested, but similar to my
own "hanging" class) should suffice:

p.lyric { margin-left: 5em; text-indent: -4em }

This creates a hanging indent. If the window width is such that
every verse fits in one line, visually it will look like the lyrics
all have a 1 em left margin. But if any verse runs to more than one
line, the extra lines will be indented by 4 ems.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #3

P: n/a
In article <87************@dinopsis.dur.ac.uk>,
Chris Morris <c.********@durham.ac.uk> wrote:
pre { font-family: inherit; }

Works in Gecko-based browsers, not in Opera 7 or IE6, though. From my
reading of the spec I think it *should* work in a general bug-free
browser.


pre { font-size: 100%; }

Makes it 100 % of the font-size of the parent element. If I am not
missing something, that seems to me the same as 'inherit' and it is
supported fine.

--
Kris
kr*******@xs4all.netherlands (nl)
"We called him Tortoise because he taught us" said the Mock Turtle.
Jul 20 '05 #4

P: n/a
Stan Brown wrote:
I've marked up song lyrics with the <pre> tag because it seems the most
appropriate type of markup for the type of data.


As you observe below, it's not really the most appropriate because
it forces a monospace font.


That is a presentational consideration that should be irrelevant to the
markup used.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #5

P: n/a
In article <ci********************************@4ax.com> in
comp.infosystems.www.authoring.stylesheets, Headless
<me@privacy.net> wrote:
Stan Brown wrote:
No, I did not write the first quoted bit below. Please do not
attribute your words to me, especially since I obviously disagree
with them.
I've marked up song lyrics with the <pre> tag because it seems the most
appropriate type of markup for the type of data.


As you observe below, it's not really the most appropriate because
it forces a monospace font.


That is a presentational consideration that should be irrelevant to the
markup used.


Make up your mind! Earlier you said:
This results in
inefficient use of horizontal space due to UA's default rendering of
<pre> in a fixed width font.


Now here is what the spec says:

"The PRE element tells visual user agents that the enclosed text is
'preformatted'." -- a direct quote from
<http://www.w3.org/TR/html401/struct/text.html#edef-PRE>

Since your song lyrics are _not_ completely preformatted, it is hard
to see any reason for using <pre>.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #6

P: n/a
Andreas Prilop wrote:
Stan Brown <th************@fastmail.fm> wrote:
No, I did not write the first quoted bit below. Please do not
attribute your words to me, especially since I obviously disagree
with them.


That's why God created quote marks (>). You didn't write it but
you quoted it. Some newsreaders and Google
http://groups.google.com/groups?th=a8acc0ab27afdf2e
even display different quoting levels in different colours.

I thought you know about the basic facts of Usenet quoting.


I think Stan does and as you can see above its quite easy to quote
things while properly designating who the quote came from.

Headless either clipped the reference to what he wrote or his mail
client did it in the reply - either way Stan is correct in his remark
IMO. I imagine Headless didn't do this on purpose of course....

--Nikolaos
Jul 20 '05 #7

P: n/a
Headless <me@privacy.net> wrote:
I've marked up song lyrics with the <pre> tag because it seems the
most appropriate type of markup for the type of data.
If it's modern lyric, where the amount of indentation is part of the
content, then <pre> might be the best surrogate for adequate markup.

If it's just text divided into lines, then there are two feasible
options:
1. Use <p> markup and <br> inside it.
2. Put each line inside <div>, and use outer <div> for grouping lines
if desired.
In either case, you might wish to suggest that lines not be broken, using
white-space: nowrap, or maybe white-space: pre. But typically verses are
so short that this is not an issue.
This results in
inefficient use of horizontal space due to UA's default rendering of
<pre> in a fixed width font.


I don't thin inefficiency is the most relevant thing here. Rather, the
esthetic appearance of monospace text.

But you _asked_ for monospace font, didn't you? The HTML specifications
even say that you should not use style sheets to change that. That's a
bit exaggerated of course. But usually there are better options.

You could simply use white-space: pre for any block of text. It does not
imply anything regarding fonts. But in non-CSS presentation, this would
make the lines run together. So it's better to indicate the structure in
markup, as much as you can.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #8

P: n/a
Markus Ernst wrote:
>>I've marked up song lyrics with the <pre> tag because it seems the most
>>appropriate type of markup for the type of data.
>
>As you observe below, it's not really the most appropriate because
>it forces a monospace font.
That is a presentational consideration that should be irrelevant to the
markup used.


Well your question was about presentation... Why do you mean <pre> is the
appropriate markup type for lyric data? Lyrics as poems consist of text
paragraphs and the appropriate markup for paragraphs is <p>.


I disagree, a paragraph is a collection of sentences, with unity of
content or purpose. A paragraph isn't affected by random line breaks.

Not so with a song lyric or a poem, there line breaks are *pre*defined
and not to be altered by a UA.
To force line
breaks inside a paragraph you can use <br>.


Ugh, that's very ugly markup imo.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #9

P: n/a
Nikolaos Giannopoulos wrote:
Headless either clipped the reference to what he wrote or his mail
client did it in the reply - either way Stan is correct in his remark
IMO. I imagine Headless didn't do this on purpose of course....


I did do it on purpose. I dislike seeing multiple "X wrote ..." lines
scattered throughout quoted text, thus I trim them out.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #10

P: n/a
Jukka K. Korpela wrote:
I've marked up song lyrics with the <pre> tag because it seems the
most appropriate type of markup for the type of data.
If it's modern lyric, where the amount of indentation is part of the
content, then <pre> might be the best surrogate for adequate markup.

If it's just text divided into lines, then there are two feasible
options:
1. Use <p> markup and <br> inside it.


Ugly.
2. Put each line inside <div>, and use outer <div> for grouping lines
if desired.
Even uglier.
In either case, you might wish to suggest that lines not be broken, using
white-space: nowrap, or maybe white-space: pre. But typically verses are
so short that this is not an issue.
It is an issue, these lines should never be broken, CSS or no CSS, ergo:
<pre>.
This results in
inefficient use of horizontal space due to UA's default rendering of
<pre> in a fixed width font.


I don't thin inefficiency is the most relevant thing here. Rather, the
esthetic appearance of monospace text.

But you _asked_ for monospace font, didn't you?


Nope, that's just what most UA's default to.
The HTML specifications
even say that you should not use style sheets to change that.
Ah, but the reason they give for not doing that: "and is intended to
preserve constant line spacing and column alignment for text rendered in
a fixed pitch font.", which doesn't apply in my case (all text enclosed
in the <pre> tags is the same height, and there are no columns).
You could simply use white-space: pre for any block of text. It does not
imply anything regarding fonts. But in non-CSS presentation, this would
make the lines run together. So it's better to indicate the structure in
markup, as much as you can.


Precisely, ergo: <pre>.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #11

P: n/a
Headless <me@privacy.net> wrote:
If it's just text divided into lines, then there are two feasible
options: 1. Use <p> markup and <br> inside it.
Ugly.


Nobody really cares whether an author enjoys the markup or not.
2. Put each line inside <div>, and use outer <div> for grouping lines
if desired.


Even uglier.


If you are looking for beauty, maybe you should look at something else
than HTML markup.

I just listed the two logical, or least illogical, options.
It is an issue, these lines should never be broken, CSS or no CSS,
ergo: <pre>.
Even at the cost of causing horizontal scrolling? OK, then you can
replace all spaces by no-break spaces, or use the nonstandard <nobr>
markup.
But you _asked_ for monospace font, didn't you?


Nope, that's just what most UA's default to.


Since <pre> by definition means preformatted, it would be highly
illogical not to use monospace font whenever possible.

Besides, if you want to be picky, note that user agents are not required
to avoid breaking the lines; they just "may disable automatic word wrap".
ergo: <pre>.


So you are back to the starting point. I gave you two ways to avoid the
problem you're creating, and you rejected them on grounds of markup
esthetics. So now you are still left with the original, and currently
unsolvabled, problem of telling browsers not to use monospace font, after
your explicitly asking them to do so.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #12

P: n/a
Jukka K. Korpela wrote:
2. Put each line inside <div>, and use outer <div> for grouping lines
if desired.
Even uglier.


If you are looking for beauty, maybe you should look at something else
than HTML markup.


I don't dispute that markup should not be judged on how it "looks" at
source level, but I can't help but cringe when I see <br>'s. Wrapping
each line in a div is to much for me to put up with, call it an author
quirk.
It is an issue, these lines should never be broken, CSS or no CSS,
ergo: <pre>.


Even at the cost of causing horizontal scrolling?


In this case yes.
OK, then you can replace all spaces by no-break spaces
My author quirk is causing involuntary muscle spasms at the mere
thought.
But you _asked_ for monospace font, didn't you?


Nope, that's just what most UA's default to.


Since <pre> by definition means preformatted, it would be highly
illogical not to use monospace font whenever possible.


Absolutely, monospace is the logical default for <pre>, but that does
not exclude situations where the use of <pre> with a proportional font
makes sense.
Besides, if you want to be picky, note that user agents are not required
to avoid breaking the lines; they just "may disable automatic word wrap".


Certainly (same goes for other typical UA behaviour such as using
monospace fonts btw), but practically speaking <pre> is a safe bet if
that's the desired behaviour.
ergo: <pre>.


So you are back to the starting point. I gave you two ways to avoid the
problem you're creating, and you rejected them on grounds of markup
esthetics. So now you are still left with the original, and currently
unsolvabled, problem of telling browsers not to use monospace font, after
your explicitly asking them to do so.


No I didn't, and the problem is very easy to solve by simply specifying
a proportional font family. I wanted to be sure that there was no way to
avoid the font size quirk without compromising the markup.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #13

P: n/a
In article <28*************************@rrzn-user.uni-hannover.de>
in comp.infosystems.www.authoring.stylesheets, Andreas Prilop
<nh******@rrzn-user.uni-hannover.de> wrote:
Stan Brown <th************@fastmail.fm> wrote:
No, I did not write the first quoted bit below. Please do not
attribute your words to me, especially since I obviously disagree
with them.


That's why God created quote marks (>). You didn't write it but
you quoted it.


So you would be happy, when you quote something to refute it, to
have your name attached to the bit you disagreed with, and to have
an article posted that says you wrote it.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #14

P: n/a
In article <nm********************************@4ax.com> in
comp.infosystems.www.authoring.stylesheets, Headless
<me@privacy.net> wrote:
Nikolaos Giannopoulos wrote:
Headless either clipped the reference to what he wrote or his mail
client did it in the reply - either way Stan is correct in his remark
IMO. I imagine Headless didn't do this on purpose of course....


I did do it on purpose. I dislike seeing multiple "X wrote ..." lines
scattered throughout quoted text, thus I trim them out.


If you are going to clip out "X wrote" attributions, then please
also clip out the lines that X wrote. This is just basic good
manners, and has been since at least 1989, when I was first on
Usenet IIRC.

http://www.xs4all.nl/%7ewijnands/nnq/nquote.html#Q6

Remember teh Golden Rule: How would you feel to have statements
attributed to you that you did not write and in fact disagree with?

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #15

P: n/a
In article <4a********************************@4ax.com> in
comp.infosystems.www.authoring.stylesheets, Headless
<me@privacy.net> wrote:
No, I did not write the first quoted bit below. Please do not
attribute your words to me, especially since I obviously disagree
with them.

As you observe below, it's not really the most appropriate because
it forces a monospace font.


Make up your mind! Earlier you said:
This results in
inefficient use of horizontal space due to UA's default rendering of
<pre> in a fixed width font.


Now here is what the spec says:

"The PRE element tells visual user agents that the enclosed text is
'preformatted'." -- a direct quote from
<http://www.w3.org/TR/html401/struct/text.html#edef-PRE>


It doesn't say "completely pre formatted" anywhere in the spec, you've
made that up.


Silly me -- all this time I thought "preformatted" meant
"preformatted".

Please note: I have removed the attributions to make a point.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #16

P: n/a
Headless <me@privacy.net> wrote:
Wrapping
each line in a div is to much for me to put up with, call it an
author quirk.
As you wish. It is, however, the closest you can get in HTML in order to
indicate, in descriptive markup, a piece of text as a line. Of course
<div> does not mean 'line'; it does not mean anything - except a block
level container, with implied line breaks before and after, and this is
what I mean by "the closest you can get". The XHTML 2.0 draft proposes a
step forward, namely specific markup for lines.

The CSS side of the matter, in present-day authoring, is that using a
container, <div>, rather than separator, <br>, gives you an element to
play with - something to assign properties to, if desired.
OK, then you can replace all spaces by no-break spaces


My author quirk is causing involuntary muscle spasms at the mere
thought.


The no-break space is the character-level method of keeping words
together. Nothing to frown upon, really. Too bad most editors don't let
us type them directly and see them as "different spaces" in a convenient
way. But it _is_ possible to enter no-break spaces directly, not just as
clumsy entity references &nbsp;.
- - the problem is very easy to solve by simply
specifying a proportional font family.


Well, that was your solution, and the obvious one, but the problem with
it, as you initially wrote, is that you cannot effectively tell the
browser to use its default font, once you've said <pre>.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #17

P: n/a
In article <g9********************************@4ax.com> in
comp.infosystems.www.authoring.stylesheets, Headless
<me@privacy.net> wrote:
Stan Brown wrote:
Remember teh Golden Rule: How would you feel to have statements
attributed to you that you did not write and in fact disagree with?


I'm interested in what is being said, not who says it.


That's nice, but doesn't actually answer my question. Think about
it: how will _you_ feel when someone misrepresents what _you_ said?

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #18

P: n/a
Stan Brown <th************@fastmail.fm> wrote:
So you would be happy, when you quote something to refute it, to
have your name attached to the bit you disagreed with, and to have
an article posted that says you wrote it.


As long as the quote marks are correct - yes.

Example:

Andreas Prilop wrote:
bullshit bullshit bullshit bullshit

I strongly disagree with this bullshit.


blah blah blah blah blah

where the last line (and only the last line) is written by you,
for example.
Jul 20 '05 #19

P: n/a
In article <cr********************************@4ax.com>,
Headless <me@privacy.net> wrote:
Markus Ernst wrote:

To force line
breaks inside a paragraph you can use <br>.


Ugh, that's very ugly markup imo.


You're over-reacting to the abuse of <br>; that's a perfectly
legitimate use. Look at it this way: Either you need to break the
lines with <br> or with a literal line-break character. Which of
those feels like better markup to you?

If we already had XHTML 2.0's <line> element, that'd be the obvious
choice, but in the world we live in, <br> is as good as you're going
to get.

--
Mike Kozlowski
http://www.klio.org/mlk/

Jul 20 '05 #20

P: n/a
Stan Brown wrote:
I'm interested in what is being said, not who says it.


That's nice, but doesn't actually answer my question. Think about
it: how will _you_ feel when someone misrepresents what _you_ said?


Not interested in attributions = not bothered by mis attributions.
Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm
Jul 20 '05 #21

P: n/a
Headless <me@privacy.net> wrote:
To me a <br> has no semantic meaning.
That's debatable. Does a space have a semantic meaning? A line break in
plain text? And your alternative is using <pre>, where line breaks are by
definition significant. What is the semantics of <pre>?
That means
that a speaking browser should read out a song lyric or poem marked
up with <br>'s in the same manner as it would read out a paragraph.
Maybe, maybe not. It depends on the browser. A screen reader probably
does not know the difference between "casual" line break (as resulting
from normal formatting of text by a browser) and "essential" line break
as resulting from <br> - or from a source line break in <pre> context!
But a speech browser that uses an HTML document as primary input _can_
tell the difference.
Imo a song lyric or poem should be read out with a longer pause
between the sentences.


Certainly, and with intonation that reflects the verse structure.
But with <pre> you cannot even in principle say anything about this in
current CSS. When <br> is used, you might do something, though it's a bit
illogical to style breaks. When <div> is used (around each verse line),
the basic situation is much better (in principle, that is).

In fact, using <div> you could even permit line breaks if needed due to
narrow canvas - if it acceptable to have a presentation like

verse line 1 here
verse line 2 here
verse line 3 that is so
long that it is split
verse line 4

And I guess most readers would figure out what this means. You could
achieve this easily, if you use <div> markup, since you can just set a
suitable margin and a suitable first-line indent.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #22

This discussion thread is closed

Replies have been disabled for this discussion.