|
in reply to Re^13: Making Perl Monks a better place for newbies (and others)
in thread Making Perl Monks a better place for newbies (and others)
I completely agree. I just would not like to see PerlMonks with all it's history flushed.
Other than some navigation issues, that take some getting used to, the main ongoing, constant, and IMO completely unnecessary and easily solvable annoyance is my posts are altered in a way that does not reflect my intent.
By hitting the return key on the keyboard twice, the intent is to start a new paragraph. I know for a fact that these newline characters are sent to and received by PerlMonks (the program) but are being stripped.
Instead of hitting the return key once, I have to manually type multiple brackets and backslash, PerlMonks is not content with p but also requires slash p surrounding each paragraph. This all becomes rediculous when posting from a mobile device, where these characters are unavailable.
Sometimes I miss one or the other p and the whole post has to be fixed in preview. The implementation does not seem consistent, so I use br.
The program replaces URL encoded space (+) with space. That was the intent. Why should my (or anyone's) intent to start a paragraph be replaced with a space?
It makes no sense, is annoying and time consuming and completely unnecessary.
To strip the newline character, rather than replace it with an html equivalent is obviously intentional, due to sheer laziness perhaps. My only question is why? It should be an easy fix.
Tom |
Re^15: Making Perl Monks a better place for newbies (and others)
by pryrt (Abbot) on Feb 05, 2020 at 18:19 UTC
|
I know for a fact that these newline characters ... are being stripped.
No you don't. You just don't understand HTML.
This paragraph has ten newlines between the parentheses: (
). But it doesn't render that way. It looks like a single space between the parentheses, like ( ).
HTML is newline agnostic -- or rather, it collapses 1 or more newlines into a single space when rendered. It's not perlmonks that strips the newlines; it's the rendering engine of your browser, in accordance with HTML specifications. If you disbelieve me, view source on my reply, which shows the newlines still exist in the raw HTML. (edit: Perlmonks doesn't strip them out; it send them to your browser, and your browser's rendering engine does the whitespace collapsing./edit) The same works on every HTML page on the internet; it's something I've known since I started hand-coding HTML in college in 1993. It's not something new.
PerlMonks is not content with p but also requires slash p surrounding each paragraph. This all becomes rediculous when posting from a mobile device, where these characters are unavailable. ... Sometimes I miss one or the other p and the whole post has to be fixed in preview. The implementation does not seem consistent, so I use br.
Yes, the HTML spec requires both opening and closing tags for the paragraph, as in <p>...</p>. And the perlmonks preview highlights when you miss one of them. But if you create the post with the missing </p> anyway, it will still render reasonably. For example, I will intentionally forget the closing p in this paragraph...
This paragraph starts with a new <p>, even though the previous paragraph didn't properly close with </p>. And it still renders. Perlmonks was just doing you the favor of showing your malformed HTML before you post; it's up to you whether to listen or not.
I agree that it would be nice if Perlmonks didn't require entry in HTML. (I tried the wikisyntax thingy some time ago, but I am a lot more used to markdown than wiki nowadays, and I'd really prefer if the input engine were Markdown-that-accepts-raw-html-when-I-want-control; but I don't have the skillset to make either a free nodelet hack, or join pmdev and dig into the source code and implement it, so I choose not to complain -- in open source, if I'm not willing or able to do it myself, I don't feel justified in complaining loudly.)
| [reply]
[d/l]
[select] |
|
|
"If you disbelieve me, view source on my reply, which shows the newlines still exist in the raw HTML."
I've been posting from a tablet or phone, most days, which don't have "view source", but, on my computer now, I see, you are absolutely right!
I certainly understand html ignores "return" or newline and other white space, I just never in a million years would have suspected that PerlMonks lets that pass through. I've never before encountered any forum software that did not do SOMETHING with the newline, either strip, or replace.
But I would think that would make fixing the problem that much easier.
Or not much more, if any more, difficult.
Tom
| [reply] |
|
|
| [reply] |
|
|
A reply falls below the community's threshold of quality. You may see it by logging in.
| |
|
|
|
| [reply] |
|
|
|
|
|
|
| A reply falls below the community's threshold of quality. You may see it by logging in. |
Re^15: Making Perl Monks a better place for newbies (and others)
by Your Mother (Archbishop) on Feb 05, 2020 at 18:59 UTC
|
I just would not like to see PerlMonks with all it's history flushed.
You have persistently misunderstood my points. I adore this site. It’s the code that I think is a problem blocking modernization, new features, patches, bugfixes, and easy contribution. I would change nothing about the history or the ethos of the place at all. It is, to me, an ideal forum.
| [reply] |
|
|
I do understand your point(s), and as I said, I completely agree.
Your original post though, mentioned flushing, but nothing about preserving.
I also doubt it would be possible to port PerlMonks to a new platform.
At best, the old forum could be archived.
Tom
| [reply] |
|
|
It is absolutely possible to port it. Huge swaths of it are trivial. It’s just a serious commitment and only senior level webdevs—and it’s time to put a finer point on that point, that Venn does not include anyone who thinks this is a fix for anything: s/\n/<br>/g—and especially ETL pros are qualified to try.
| [reply]
[d/l] |
|
|
|
|
| |
|
|
|
| A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
