- From: Jukka Korpela <jkorpela@cc.hut.fi>
- Date: Mon, 22 Sep 1997 09:41:44 +0300 (EET DST)
- To: www-html@w3.org
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 - - > <P ALIGN=CENTER><SMALL><PRE> > 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 http://www.hut.fi/home/jkorpela/HTML4.0/comments.html 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 http://www.hut.fi/home/jkorpela/HTML3.2/5.44.html 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. Yucca, http://www.hut.fi/home/jkorpela/
Received on Monday, 22 September 1997 02:41:52 UTC