W3C home > Mailing lists > Public > html-tidy@w3.org > January to March 2002

Re: <HR> in <PRE>

From: Richard A. O'Keefe <ok@atlas.otago.ac.nz>
Date: Fri, 1 Feb 2002 13:48:51 +1300 (NZDT)
Message-Id: <200202010048.NAA287720@atlas.otago.ac.nz>
To: KlausRusch@atmedia.net, ok@atlas.otago.ac.nz
Cc: html-tidy@w3.org
Sigh.  One more time.
	> But there is NO SUCH ANIMAL as "current processing".
	[of <HR> inside <PRE> by HTML browsers.]
	> Different Web browsers do it DIFFERENTLY, as I explicitly pointed out.
	> There is no one consistent cross-browser behaviour here.
	
	There is "current processing" in tidy, and tidy users may have
	used this tidy feature to generate valid markup from an input
	source with misplaced tags in <pre> sections.
	
Ahem.  The whole point of this thread is that someone was using a program
that generated <HR> inside <PRE> and it was *killing* Tidy; so nobody
could possibly have been relying on it to do anything in particular.

	> If anyone wants to write *ML code samples, XHTML <![CDATA[...]]>
	> sections are the way to do that.  In HTML, the only way is to stuff
	> them through your own entity-fying filter.
	
	... which is basically what tidy has been doing.
	
Well, no, it hasn't.

In fact, when it wasn't being killed, Tidy has been doing exactly what
I want:

    <HTML><HEAD><TITLE>BUG</TITLE></HEAD><BODY>
    <PRE>before<HR>after</PRE></BODY></HTML>

turned into

    <!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html>
    <head>
    <meta name="generator" content="HTML Tidy, see www.w3.org">
    <title>BUG</title>
    </head>
    <body>
    <pre>
    before
    </pre>

    <hr>
    <pre>
    after
    </pre>
    </body>
    </html>

So I end up looking silly, because it wasn't <HR>-inside-<PRE> *as such*
that was killing Tidy, but some particular detail (NOSHADE, maybe? I've
lost the data and can't check this any more),

and Klaus Johannes Rusch ends up looking silly for claiming that modifying
Tidy to work the way it DOES work would break things.

Now I'm left wondering what the real cause of the original problem was,
and how come moving the <HR> elements AWKwardly worked around it.

	There is formal specification for how tidy reads and process a
	page so it cannot be wrong.  In fact a specification could say
	that any tags between <pre> and </pre> are converted by tidy,
	providing the filter you mentioned above.
	
(a) I was previously unware of any formal specification for any part of
    Tidy, and thought I'd seen all the documentation.  I am pleased to
    hear that I was wrong about that, and would very much like a reference
    so that I can read the specification myself.

(b) Of course a specification can be wrong.  Due to inconsistency, it mail
    fail to specify anything.  It might be untestable.  It might have every
    virtue except specifying what anyone actually wants.  The list is well
    nigh endless.
	
	> You have missed a very important distinction.  The element types you
	> have mentioned are *inline*, but <HR> is a *block*-level element type.
	> <PRE> is allowed to contain any inline content (stuff that would be
	> legal in a <P>) except specifically
	>     IMG|OBJECT|APPLET|BIG|SMALL|SUB|SUP|FONT|BASEFONT
	
	Um, not according to the HTML standard, which allows inline
	elements minus the elements I listed.
	
That's precisely what I said.  <PRE> can contain any inline elements
except the elements I listed.  That list was actually pasted from the
HTML 4 Transitional DTD.

(When you say "HTML standard", do you mean a W3C spec., or the ISO one?)
Received on Thursday, 31 January 2002 19:49:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 April 2012 06:13:51 GMT