I think the point is -- there is no valid </br> tag for a reason -- it's not valid.

Also, one thing that no one seems to have mentioned at all in this thread yet, is: why should one use the br element at all, be it in HTML or XHTML or whatever? Granted, even I occasionally do, but that has really to be a rare thing - most often I don't want to barely break lines within paragraphs, but I'm fine with splitting the text across paragraphs, thus using <p> tags. Having a background (although not a terribly vast experience) in TeX/LaTeX, which are all about good typography, I feel compelled to remind that that's the same recommendation that's usually made there, although the markup is completely different. Paragraphs are plainly separated by empty lines (or explicit \par commands, but you generally don't need to) while the breaks must be inserted with \newline or \\: thus in that case perhaps the UI makes it slightly more convenient to shape the text in paragraphs, than to use returns a' la average quadratic dumb wordprocessor luser...

Also, one thing that no one seems to have mentioned at all in this thread yet, is: why should one use the br element at all, be it in HTML or XHTML or whatever?

Postal addresses.

At least, that was the justification for including it in HTML+ (aka HTML2).

Personally, I would've preferred that <address> have been made line return preserving, similar to <pre>, and we never would've run into this issue.

Postal addresses.

Well, I suppose that in principle there are many other reasons for wanting such a beast: also, *ML languages are much more about fancy formatting stuff on a computer screen than about high quality typography than those others I mentioned - and even those let you conjure up ad hoc stuff of all kinds if you really want to.

The commonplace but erroneous usage is -- in the word used to consider some ill-titled nodes -- "haznav." PM corrects those, via moderation (when consensus arises, which -- I acknowledge -- it clearly hasn't here).

But given the nature of moderation, and the workload already facing the janitors, I see little good coming of considering this ill-favored tag, thereby adding to the the list in NTC and the job facing those who do scullery duty.

Hence, it seems to me more zealotry than pragmatism to reject the (amended) suggestion, namely: that we create a mechanism to correct instances where this non-HTML tag is encountered.

But it is not a hazard to navigation.

The real problem I see here is that HTML nesting enforcement is optional. If it were required, then those trying to use </br> would immediately see their mistake and learn something in the process.

I'd appreciate (and certainly try to apply) any patch that unconditionally enables HTML nesting enforcement in preview (with the already-plumbed, I believe, user-selected "error reporting level for preview"), as the easiest short-term fix with the "most bang for the buck".

In seeing how common the </br> mistake is and further that both IE and FireFox silently interpret </br> as <br />, I've been tempted to have PM also make that silent transformation. But I'm not convinced that is the best idea. But it doesn't matter because it won't be any time soon before I could make such a change, anyway.

As for the minor point of those claiming that <br /> is invalid HTML since PerlMonks doesn't tag its output as "XHTML", I'll note that the HTML standard defines lenient treatment of parts not expected and so, last I heard, <br /> in HTML is precisely defined to be treated as <br>. If someone is having some practical problem with the use of <br /> in PerlMonk's output, please be specific. The partial conformance to XHTML can be useful (for those parsing parts of PM output) but tagging the output as XHTML would be bad since the conformance is not complete. So I'm inclined to continue moving toward XHTML while not violating the HTML standard in any practical way.

- tye        

Tye I give this a major ++.

However I am not sure I understand your third paragraph as you intended. My confusion stems from this:

Regxp: signaling when to stop and Re: use lib functionality are the latest among the June-to-date nodes which use "</br>."

In the case of the second (for its brevity), the opening line(s) render this way (color and font excepted), for me, in IE6, FF & Moz:

Hi,</br></br> This Module simplifies the manipulation of @INC at compile time.</br></br> Using

When observed with ViewSource (html validator is on), I see:

<p>
Hi,<font color="#808080" class="htmlignored">&lt;/br></font><font colo
+r="#808080" class="htmlignored">&lt;/br></font>


This ...</p>
[download]

Is this an indication that the </br> tags were processed by an existing "silent (and automated) transformation" or merely an artifact of the browser, ViewSource and the validator?