I'm aware of that, but there were no long lines in that
particular case. Of course, it's a matter of definition what is
"long"... but as a rule of thumb, I'd consider anything less than 72
characters as acceptable (as traditionally being recommended for
mail or news messages, for example).
| [reply] |
No, you can't assume that 72 characters isn't "too wide". My rule of thumb for that is more like 24 characters. Even 24 characters can be "too wide" in cases that I run into, but that is usually only on smaller-than-typical devices so I don't sweat it too much1. With nodelets and thread indenting and other things, it is quite easy for 60 characters to be "too wide" (no, my browser window is rarely maximized).
1 I do prefer that PerlMonks renders reasonably on smaller-than-typical devices and am happy to find that PerlMonks actually does a better job of this than most web sites I run into. I don't mind when the rare <pre> section makes the site a bit too wide for a small-display client. But a 50-character line in a <pre> section can make a thread nearly impossible to read on a smaller device's browser.
It wouldn't be particularly hard to parse <pre> blocks and re-render them as things that use fixed-width fonts and preserve whitespace but also are willing to wrap. That way we'd have something a lot like <code> but that allows HTML inside of it. And we wouldn't have to beat people up to avoid using <pre> tags. Not that this will be implemented this month.
| [reply]
[d/l]
[select] |
Ok, so is 24 the authoritative number? If so, the part of the
footnote 1 on Perl Monks Approved HTML tags which says
"... and please use <code> instead of <pre> unless
the enclosed lines are pretty short."
could be modified to read something like
"... and please use <code> instead of <pre> unless
the enclosed lines are less than 24 characters wide (as they typically
won't be wrapped by browsers). Don't use <pre> at all if the reply level
of the node in question is deeper than 4."
That would be a pretty minor change, and hopefully, clearly telling
people what the rules are will avoid having to "beat" them to it
(though admittedly, that might work only with the more civilised ones). In case 24 isn't ok either, we should probably do away
with <pre> altogether...
It wouldn't be particularly hard to parse <pre> blocks and
re-render them as things that use fixed-width fonts and preserve
whitespace but also are willing to wrap.
Until that is done, would it be ok if I enclose such sections in
<p><tt>...</tt></p>, adding <br /> at the end of
every line, and replacing every other space with in
stretches of consecutive spaces? (<tt> doesn't preserve
whitespace) At least in Firefox that seems to render as intended.
Any better suggestions how to highlight stuff in preformatted sections?
(BTW, it will always be a mystery to me why browsers on
small-screen devices don't allow you to configure something like "forced
wrap" for preformatted sections... But that's another issue.)
| [reply]
[d/l]
[select] |
So you want the janitors less or more zealous with pre edits from now on?
| [reply] |