Pre

[Neal]

A few questions about pre...

When presenting preformatted text using the white-space: pre;
property/value, Opera renders long lines at small viewport widths as
exiting the borders of the element, IE6 extends the element to contain the
line. Both necessitate horizontal scrolling.

1) Is one considered incorrect, or are both fair interpretations of the
recommendation?

2) It would seem the IE performance has the advantage of retaining
intended contrast between text color and background color. Are there
differing opinions you can share?

3) Obviously, unless one is presenting ASCII art or other width-dependent
content, the line length must be considered to prevent unnecessary
horizontal scrolling. Lines of programming code, for example, can be
legally broken at certain places, and should be to prevent such overflow.
If no collapsing of whitespace is desired the pre value must be in force,
but this prevents the UA from creating new line breaks as well. What would
be the most user-respecting solution to this line-length dilemma, within
the constraints of valid HTML and "valid" CSS?

[Jukka K. Korpela]

Neal <ne*****@spamrc n.com> wrote:

When presenting preformatted text using the white-space: pre;
property/value, Opera renders long lines at small viewport widths
as exiting the borders of the element, IE6 extends the element to
contain the line. Both necessitate horizontal scrolling.
Have you set the width and border? How? URL?
1) Is one considered incorrect, or are both fair interpretations of
the recommendation?
If an explicit width has been set, it shall be honored. Content may
overflow, and normally will by default.
2) It would seem the IE performance has the advantage of retaining
intended contrast between text color and background color.
Such issues should not arise. Why would you set the width narrower than
needed.
3) Obviously, unless one is presenting ASCII art or other
width-dependent content, the line length must be considered to
prevent unnecessary horizontal scrolling.
Sorry, I understand all the words but not the idea in the statement.
Lines of programming
code, for example, can be legally broken at certain places, and
should be to prevent such overflow.
No, if you say white-space: pre, you are saying that lines should never
be broken except as you have broken them in the HTML source.
If no collapsing of whitespace
is desired the pre value must be in force,
Sounds like you're looking for white-space: pre-wrap, but it's in the
CSS 2.1 draft (not in CSS 2.0) and it's poorly supported.
What would be the most
user-respecting solution to this line-length dilemma, within the
constraints of valid HTML and "valid" CSS?

You could use no-break spaces in HTML to prevent whitespace collapse
(this is not _guaranteed_ to work, but it mostly does), and not use CSS
at all. Lines would get broken normally then. However, "normal" is
often absurd in current browsers, since they take liberties in breaking
strings (e.g., breaking "-b" into "-" and "b"), see
http://www.cs.tut.fi/~jkorpela/html/nobr.html

But perhaps most importantly, how should lines be broken if they are
indented? If you have an indented line that gets broken, you probably
want the continuation line have at least the same indentation - but
this won't happen normally. In that case you might consider writing a
program that generates markup where each line is inside a <div>
element, either with class attributes or <div> nesting reflecting the
structure so that you can use CSS to set a suitable margin-left. What I
mean is that if you have, say,

if(foo()) {
for(;;) {
bar(); }}

then this would become e.g.

<div class="code">
if(foo()) {
<div> for(;;) {
<div> bar(); }}</div></div>
</div>

(where the leading whitespace in <div> elements is insignificant, by
HTML rules)
and then you could have

div.code div { margin-left: 1em; }

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Neal]

On Mon, 9 Feb 2004 00:50:47 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tu t.fi> wrote:

Neal <ne*****@spamrc n.com> wrote:

When presenting preformatted text using the white-space: pre;
property/value, Opera renders long lines at small viewport widths
as exiting the borders of the element, IE6 extends the element to
contain the line. Both necessitate horizontal scrolling.
Have you set the width and border? How? URL?

You can observe the behavior and get an idea of what confused you in the
third paragraph at http://users.rcn.com/neal413/test2.html

1) Is one considered incorrect, or are both fair interpretations of
the recommendation?

If an explicit width has been set, it shall be honored. Content may
overflow, and normally will by default.

But notice the difference in behavior between Opera 7.23 and IE6. IE
stretches the element's boundaries to fit. O allows the text to spill
beyond.

2) It would seem the IE performance has the advantage of retaining
intended contrast between text color and background color.

Such issues should not arise. Why would you set the width narrower than
needed.

I'm not sure what you're saying here. I've set no width for pre or its
container.

3) Obviously, unless one is presenting ASCII art or other
width-dependent content, the line length must be considered to
prevent unnecessary horizontal scrolling.

Sorry, I understand all the words but not the idea in the statement.

The example cited above should make this clear.

Lines of programming
code, for example, can be legally broken at certain places, and
should be to prevent such overflow.

No, if you say white-space: pre, you are saying that lines should never
be broken except as you have broken them in the HTML source.

Exactly. One can enter line breaks intentionally to prevent the horizontal
scrolling. But with a fluid design, at what point do we say enough is
enough?

If no collapsing of whitespace
is desired the pre value must be in force,

Sounds like you're looking for white-space: pre-wrap, but it's in the
CSS 2.1 draft (not in CSS 2.0) and it's poorly supported.

Aha. Perhaps.
...In that case you might consider writing a
program that generates markup where each line is inside a <div>
element...

My head aches just thinking about that...

[Jukka K. Korpela]

Neal <ne*****@spamrc n.com> wrote:

You can observe the behavior and get an idea of what confused you
in the third paragraph at http://users.rcn.com/neal413/test2.html

Oh, I see. It happens in the simplest case too: create a pre element
with long lines and with a visible border set, and Opera will make the
borders correspond to a block that is 100% of the available width
(which is by default somewhat narrower than the window width, due to
body margin and/or padding) whereas the content overflows.

The same happens with a p element (though it takes more work to force
long lines there, but &nbsp; will do the job fine).

1) Is one considered incorrect, or are both fair interpretations
of the recommendation?

If an explicit width has been set, it shall be honored. Content
may overflow, and normally will by default.

But notice the difference in behavior between Opera 7.23 and IE6.
IE stretches the element's boundaries to fit. O allows the text to
spill beyond.

The width defaults to auto, and as far as I can see, the Opera behavior
is then the correct one. The usual quick way to check that Opera is
right and IE is wrong (as usual) is to view the page on Mozilla. Of
course this is not a quite 100% sure way.

2) It would seem the IE performance has the advantage of
retaining intended contrast between text color and background
color.

Such issues should not arise. Why would you set the width narrower
than needed.

I'm not sure what you're saying here. I've set no width for pre or
its container.

Fair point, I had guessed that you had set a width, and I didn't
realize the impact of the default width.

It seems that adding
pre { display: table-cell; }
fixes this, since it makes the width "as wide as needed". IE does not
understand it, so you get the original incorrect behavior, which is
close to what was wanted here. :-)

3) Obviously, unless one is presenting ASCII art or other
width-dependent content, the line length must be considered to
prevent unnecessary horizontal scrolling.

Sorry, I understand all the words but not the idea in the
statement.

The example cited above should make this clear.

Not quite. Your example has some XML markup (specifically, fragment of
XHTML 1.0 markup) there. Since in XML, whitespace is generally not
honored the way it is inside <pre> elements, you don't need <pre> here
(the same way you would, more or less, need <pre> for presenting
FORTRAN or Python code). You might still use <pre> as a practical
solution. Besides, we have the nasty problem that doctype sniffers are
known to violate specifications by regarding white space as significant
between the quoted strings in a doctype declaration, if memory serves
me right.

Anyway, for XML, HTML, etc. markup I would normally use
<div><code class="...">... </code></div>
unless I wish to preformat it for explanatory purposes. But then one
needs to be cautious with strings that must not be broken, which in
practice implies need for nonstandard <nobr> markup. So in the end,
<pre> might be the least of evils.

...In that case you might consider writing a
program that generates markup where each line is inside a <div>
element...

My head aches just thinking about that...

Oh, that shouldn't be two difficult. The real question is whether you
should write it as a Perl one-liner or a Perl two-liner. :-) Seriously,
writing such markup by hand would be very awkward, but when generated
programmaticall y, you would basically need to just look at leading
whitespace on each line.

--
Yucca, http://www.cs.tut.fi/~jkorpela/