white-space: pre (well supported?)

[Jerry Sievers]

tried to avoid using PRE in the page markup and instead used DIV
CLASS=foo and assigned the white-space pre property to it.

have some reports already that text is not showing as preformatted.

looks ok with mozilla 1.4 though.

http://www.jerrysievers.com/Projects...&file=Makefile

comments please.

TIA

--
-------------------------------------------------------------------------------
Jerry Sievers 305 854-3001 (home) Unix Administrator/Consultant
305 321-1144 (mobile http://www.JerrySievers.com/

[Jukka K. Korpela]

Jerry Sievers <je***@jerrysie vers.com> wrote:

tried to avoid using PRE in the page markup and instead used DIV
CLASS=foo and assigned the white-space pre property to it.
Why? If the preformatted form of some text, i.e. the division into lines and
the use of spaces, is essential, why would you rely on CSS instead of
markup? And if it is not, why not let browsers reformat the text as they see
fit? There _are_ in-between cases, but I don't see much point in moving from
PRE to DIV, which _reduces_ the (quasi)semantic information involved.
have some reports already that text is not showing as preformatted.
Well, it surely isn't on any browser with CSS support disabled. The document
http://www.blooberry.com/indexdot/cs...whitespace.htm
says that white-space: pre is supported by IE 5.5+ and Netscape 4+ and
Opera 4+, which means rather widespread support - but not universal (I'm
afraid IE 5.0 is still not dead).

Also note: "Conforming user agents may ignore the 'white-space' property in
author and user style sheets but must specify a value for it in the default
style sheet." http://www.w3.org/TR/REC-CSS2/text.h...ef-white-space
(The statement is obscure, and the sample style sheet in CSS2 spec does
_not_ specify a value. The statement has been removed in the CSS 2.1 draft.)
http://www.jerrysievers.com/Projects...&file=Makefile

You seem to have some TAB (HT) characters there. Although HTML
specifications defines their meaning in PRE context, they also warn about
inconsistent implementations .

In CSS, the situation is even more obscure. The TAB character is defined as
a whitespace character, but its effect on rendering is not defined. (The
CSS 2.1 draft contains an attempt at a definition, which is basically the
same as in HTML.)

To conclude, I would suggest replacing TABs by spaces and using the PRE
markup, instead of CSS.

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

[Jerry Sievers]

i appreciate this info.

"Jukka K. Korpela" <jk******@cs.tu t.fi> writes:

Jerry Sievers <je***@jerrysie vers.com> wrote:

tried to avoid using PRE in the page markup and instead used DIV
CLASS=foo and assigned the white-space pre property to it.
Why? If the preformatted form of some text, i.e. the division into lines and
the use of spaces, is essential, why would you rely on CSS instead of
markup? And if it is not, why not let browsers reformat the text as they see
fit? There _are_ in-between cases, but I don't see much point in moving from

i think this is an in between case.

will fix the coding or files as needed to avoid the problem.

this is a basic content mgmt system in the works. the default file
type that is painted into the content part of the page is plain text
(historical reasons only).

seemed prudent to wrap the content window in <div class=pre> and then
jhust read the data in with php.

the minority of files are html with the header part cut away and body
tags replaced with a <div class=html>. was trying to avoid having php
need to determine the file type at run time. also didn't want to have
to edit the plain text files and put <code> or anything else in them.

highly dynamic system with static parts having all common layout
defined in a single set of m4 macro files.

<div class=pre>
php outputs file here...
</div>

so if file happense to have;

<div class=html>
doc body part here...
</div>

this new div just goes back into normal mode. only side effect is a
couple hard line breaks caused by the brief influence of the div with
pre property.
PRE to DIV, which _reduces_ the (quasi)semantic information involved.

have some reports already that text is not showing as preformatted.

Well, it surely isn't on any browser with CSS support disabled. The document

yeah! anyway; bottom line is that this approach that i tried isn't
reliable enough for general use (clever though as i might have thought
it was).
thanks for the response.

bye.
--
-------------------------------------------------------------------------------
Jerry Sievers 305 854-3001 (home) Unix Administrator/Consultant
305 321-1144 (mobile http://www.JerrySievers.com/