Re: A problem w/PRE element

On Sun, 21 Sep 1997, Jordan Reiter wrote:

> I was validating a page using the Kindler, Gentler Validator (DOCTYPE HTML
> 4.0) and was told that my use of the PRE element was incorrect because
>    : document type does not allow element "PRE" here; missing one of
>    : "OBJECT", "IFRAME", "BUTTON" start-tag
- -
> foo
>    foo
>       foo
> </PRE></SMALL></P>

The message from KGV looks misleading, but the key point there is
correct: a PRE element appears in an illegal context. The reason is
that it is within a SMALL element, which is text-level element
(in HTML 3.2 terminology; HTML 4.0 uses somewhat different words,
but its DTD does not allow PRE within SMALL either).

As regards to whether such restrictions are harmful to HTML authoring
(and whether they should be relaxed), a few notes:

In general, restricting elements like EM to text-level markup is somewhat
harmful (see for
details). Whether SMALL is comparable to EM in this respect is debatable;
it is classified as font markup in the HTML 4.0 draft, but people may view
it as semi-logical markup with a meaning opposite to that of EM. Anyway,
if anyone sees justification for using SMALL, the justification would
probably apply to e.g. several consecutive paragraphs as well as to
text fragments within paragraphs. In a sense, it might apply _better_
to the former, since a paragraph with normal text and smaller text
interspersed does not look good, usually.

In your particular case, I suspect the reason for using SMALL was to
deal with preformatted text which would be too wide on "normal" browsers
assuming "normal" font size and "normal" window width. Normality varies,
but in practice preformatted text looks is pretty often displayed oddly if
it has lines longer than 80 characters.

HTML has had the WIDTH attribute for PRE since HTML 2.0 specification,
but browsers generally fail to implement it. Moreover, even if that
attribute worked, it would be a very clumsy way of dealing with problems.
The _author_ would have to count the length of the longest line.
(This resembles computer programs which require as first input the number
of input items.) Of course, the natural solution would be to require that
browsers select the presentation according to the actual width of the
text. (I know that WIDTH was included for performance reasons, to avoid
the necessity of reading the entire PRE block before starting to display
it. I wonder if all features introduced for performance reasons all
perform as excellently as WIDTH for PRE. :-)

Now back to SMALL within PRE... As I explain in
you cannot (according to HTML specs) nest them _either way_ but there _is_
a hack which often works and which does not violate the DTD:
use BASEFONT SIZE=... before the PRE element, then use it again
(to reset size to normal) after the PRE element. No need to
tell _me_ it's ugly. :-)

To conclude, it _is_ harmful that preformatted text with long lines often
causes troubles, and there is no good way to solve such problems in
HTML 3.2 or in the proposed HTML 4.0, but these problems really
_shouldn't_ be solved at the HTML level but by improving browsers.


Received on Monday, 22 September 1997 02:41:52 UTC