 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / August 2003<pre> and proportional vs fixed width fonts
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  SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm > 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. SignatureChris > 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. SignatureKris kristiaan@xs4all.netherlands (nl) "We called him Tortoise because he taught us" said the Mock Turtle. > > pre { font-family: inherit; } > > [quoted text clipped - 7 lines] > missing something, that seems to me the same as 'inherit' and it is > supported fine. font-size != font-family and there do seem to be differences in the implementation. SignatureChris In article <7rjrkvkjk4kk1ftgcvhhh15akk1j1qhsbn@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. SignatureStan 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/ >>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 SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm > >>I've marked up song lyrics with the <pre> tag because it seems the most > >>appropriate type of markup for the type of data. [quoted text clipped - 4 lines] > 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>. To force line breaks inside a paragraph you can use <br>. SignatureMarkus >> >>I've marked up song lyrics with the <pre> tag because it seems the most >> >>appropriate type of markup for the type of data. [quoted text clipped - 8 lines] >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 SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm >>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. SignatureMike Kozlowski http://www.klio.org/mlk/ >>>To force line >>>breaks inside a paragraph you can use <br>. [quoted text clipped - 3 lines] >You're over-reacting to the abuse of <br>; that's a perfectly >legitimate use. I'm not so sure. To me a <br> has no semantic meaning. 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. Imo a song lyric or poem should be read out with a longer pause between the sentences. Headless SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm > 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. SignatureYucca, http://www.cs.tut.fi/~jkorpela/ In article <cicskv07vdmolnlclt665a5orsodcsmcqe@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. >>>I've marked up song lyrics with the <pre> tag because it seems the most >>>appropriate type of markup for the type of data. [quoted text clipped - 4 lines] >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>. SignatureStan 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/ > 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. >>No, I did not write the first quoted bit below. Please do not >>attribute your words to me, especially since I obviously disagree [quoted text clipped - 6 lines] > > 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 >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 SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm In article <nmpskvs3cao6ce6gjatvnqogu7mc2iit84@4ax.com> in comp.infosystems.www.authoring.stylesheets, Headless <me@privacy.net> 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? SignatureStan 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/ >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. Headless SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm In article <g93ukvcvl3g85e99cviq0oojkm4cs5sibf@4ax.com> in comp.infosystems.www.authoring.stylesheets, Headless <me@privacy.net> 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? SignatureStan 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/ >>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 SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm In article <280820031953416265%nhtcapri@rrzn-user.uni-hannover.de> in comp.infosystems.www.authoring.stylesheets, Andreas Prilop <nhtcapri@rrzn-user.uni-hannover.de> 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. SignatureStan 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/ > 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. >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 trim "X wrote ..." lines assuming that people know how to distinguish between ">" and ">>" type quotes. >>>>I've marked up song lyrics with the <pre> tag because it seems the most >>>>appropriate type of markup for the type of data. [quoted text clipped - 19 lines] >Since your song lyrics are _not_ completely preformatted, it is hard >to see any reason for using <pre>. It doesn't say "completely pre formatted" anywhere in the spec, you've made that up. Headless SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm In article <4apskvga83mbf2svlpq4nhgu43jsm5a26m@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 [quoted text clipped - 17 lines] >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. SignatureStan 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/ > 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. SignatureYucca, http://www.cs.tut.fi/~jkorpela/ >> I've marked up song lyrics with the <pre> tag because it seems the >> most appropriate type of markup for the type of data. [quoted text clipped - 5 lines] >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 [quoted text clipped - 4 lines] > >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 SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm >>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. SignatureYucca, http://www.cs.tut.fi/~jkorpela/ >>>2. Put each line inside <div>, and use outer <div> for grouping lines >>>if desired. [quoted text clipped - 3 lines] >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>. > [quoted text clipped - 3 lines] >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 SignatureEmail and usenet filter list: http://www.headless.dna.ie/usenet.htm > 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 . > - - 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>. SignatureYucca, http://www.cs.tut.fi/~jkorpela/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.