Perhaps I grow mad. But. The cited page employs the mysterious </BR> tag: <i> MOC2-119 </i><br> Apollinaris Patera</br> April 1999 Enforcer 5.0 and Ancestor 4.5 parse "</BR>" as a valid line-break. Mozilla snorts and ignores it, refusing to issue a newline. Um. I suppose this may be considered a matter of syntactic fascism in the parser. Personally I believe that browsers should reinforce the writing of proper HTML/CSS by stingily withholding the render-magic for malformed script. But make of it what ye will.

Hmm, syntactic fascism? How about just illegal markup. I did notice (thanks to this bug) that while it's illegal markup, Nav tends to treat </br> as a <BR>, so i'll consider doing the same. Just please stop calling my code names. :)

As I've been branded a "facist", I'll only say that I've changed the code to support the ILLEGAL </br> tag.

<Rage> YOU FIEND! Your work is directly contrary to the intent of my submission! Bah... now I will name your algorithms weak, and wet. GCC wouldn't be so forgiving: why, then, should you? I did not name thou or thy code "fascist"! I *expressly* stated that I support the "fascist" stinginess which your code evinced! REVERSE YOUR CHANGE, YOU... YOU... COMMMERCIAL PROGRAMMER! </Rage>

Attempting to steal gem's HTMLParser bugs all at once. Changing QAContact to janc.

As of June 8's Apprunner (Build ID 1999060808), the ******COUNTER-EVOLUTIONARY****** tag is supported... but I'll be watching you, rickg@netscape.com...

py8ieh=bugzilla@bath.ac.uk, do we wish to support illegal tags?

Yes, so long as it is only NavQuirks mode. We do not want Mozilla to break the many invalid pages that are already out there. This particular bug is one that can result in lines of text being merged into each other -- quite a serious problem in some cases.

Ah, but I had understood from beppe@netscape.com's comments in Bug 3268 that Nav Quirks mode would not be, er... enabled in the finished release? I assure you, Mozilla "breaks" many pages presently, with it's strict (and absolutely proper, I wholeheartedly agree!) interpretation of an "empty" <P> tag (http://www.windowmaker.com exhibits what I speak of - no bug filed). "Not our problem", and the like... Mozilla's flame will indeed be a rude awakening to many designers when the time lozenges into existence. If Nav Quirks is not to know encoding beyond Viewer, then the radiation-damaged </BR> tag should not be recognized.

*Sigh* Hands discordant with mind: To say, http://www.windowmaker.org... observe the lack of vertical spacing between the two lists to one's left ("General" and "Utilities").

Several things: 1. NavQuirks _may_ not be enabled. That does not mean that it _won't_ be enabled. See RFC2119 for an exact definition of 'may'. 2. The empty <P> problem is less serious than the </BR> problem, since empty <P>s always cause line breaks, even when being ignored. If the </BR> was ignored, then old pages may have text running into each other. That is bad. 3. The <P>-before-<LI> issue does actually have a bug open on it (I forget the number right now). 4. Eventually NavQuirks will be enabled by recognising old pages based on the <!DOCTYPE> declaration (or, probably, lack thereof...). Hence, old pages will have workarounds enabled, and new ones will not.