Re: <HR> in <PRE>

In <200201310233.PAA271991@atlas.otago.ac.nz>, "Richard A. O'Keefe" <ok@atlas.otago.ac.nz> writes:
> But there is NO SUCH ANIMAL as "current processing".
> 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.

> 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.

> Note that converting <HR> to &lt;HR&gt; inside <PRE> sections would
> definitely be wrong.

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.


>         Another item for discussion, since other block level elements,
>         and IMG, OBJECT, BIG, SMALL, SUB and SUP are not allowed in PRE
>         context either, should these get moved outside of the
>         PREformatted section as well?
> 
> 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.

-- 
Klaus Johannes Rusch
KlausRusch@atmedia.net
http://www.atmedia.net/KlausRusch/

Received on Thursday, 31 January 2002 15:44:29 UTC