in reply to Re: Add < /br> to Approved tags?
in thread Add < /br> to Approved tags?

Correct as to the legality, TTBOMK, and I'm failing to find an example, now that I've opened my yap...
... err, I mean, "committed my remark to a node." However, I remain persuaded, however wrongly, that I have seen it turn up in nodes here.

Your post displays with a linebreak after "HTML," but what you used appears to be <br />, which is a different color of cat.

That said, I believe blessing at least the </br> would be desireable.

Replies are listed 'Best First'.
Re^3: Add < /br> to Approved tags?
by jhourcle (Prior) on Jun 20, 2007 at 17:02 UTC

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

    <br /> is valid XHTML, but perlmonks serves its files as HTML, not XHTML:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

    And in HTML, there are no closing tags for empty elements (<img>, <br>, <input>, etc.).

[reply]
[d/l]
[select]
      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...

[reply]
[d/l]
[select]
        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.

[reply]
[d/l]
[select]
      Respectfully, I believe another point could be addressed more profitably.

      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.

[reply]

        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        

[reply]
[d/l]
[select]

In Section Perl Monks Discussion