Comments/Ratings for a Single Item

H.G., can you link to such an example?  As far as I can tell, we just apply wordwrapping (to default 75 characters) and put PRE tags around each section.  But this should preserve linebreaks, and seems to e.g. at
http://www.chessvariants.org/index/msdisplay.php?itemid=MS4chessfourdime

Or did you mean in the comments?
Test.
Aha, ordinary linebreaks here don't get processed.  I can probably fix this reasonably quickly.

Fergus, I think one of the text entry systems I mentioned in my last comment would do the first three bullets of what you want.  And I would like to disallow arbitrary use of scripts, instead having the displaying function replace things like [diagram] with the appropriate script (for a short list of approved scripts).

Disallowing arbitrary use of scripts sounds good. But that means I will
have to come up with another way of inserting the JavaScript for diagrams
that show legal moves on mouseclick. And these diagrams would still require
the use of JavaScript snippets in onclick attributes.

Please look into text entry systems. It looks like we want one with the
ability to add shortcodes, that can switch between HTML and WYSIWYG entry,
and maybe can handle file uploads. Based on my experience with WordPress, I
would prefer to have one that uses Page Up and Page Down properly.
Wordpress doesn't handle these properly, and plugins I've tried to
replace its native text entry with on my blog have been buggy.

EDIT: I managed to get linebreaks more faithfully reproduced in non-HTML Comments, but some comments (for reasons I don't fully understand) had linebreaks inserted into them (after being edited?) that made this more faithful reproduction ugly.  Given two evils, I'll stick to the one that's been in practice for a while.

Hopefully we will incorporate a nicer text entry system that will obviate the problem going forward.

> Disallowing arbitrary use of scripts sounds good.

Actually disallowing scripts sounds very bad, in the member-submitted articles. There is no reason why the submitter should not be in full control over how the page looks, and what it does. We have an approval period during which editors review any contribution, so if it turns out that there can be undesirable applications of scripting, the contribution can simply be rejected. It is not like you couldn't do arbitrarily unacceptable things using pure HTML, or even only plain text...

This of course would be different in forum posts, like this comment listing, where the user postings share a page with postings of other users. In theory scripts could be used there to alter the way other people's comments are displayed in the client of anyone that views them.

I can add that several of my member-submitted articles now make essential use of scripting. I have incorporated the interactive diagram in most of those, now, and in most cases (such as Mighty-Lion Chess and Elven Chess) the standard betza.js script for the diagram is all that is needed. But the large Shogi variants (Dai Dai and Maka Dai Dai, and my shrunken versions Cashew and Macadamia Shogi) have unusual and complex promotion rules (pieces promote on capture, and whether such promotion is mandatory or optional, or even what you have to promote to, can depend on what you capture. Werewolf Chess also uses a contageous piece. This exceeds the general treatment of promotion the betza.js script can provide, so the pages need to define their own function to decide what the piece will become after the move.

For the Shogi variants I also provide buttons that switch the diagram between piece representations: mnemonic, western-style pictograms or kanji tiles. The 'onclick' specifier in those buttons does contain JavaScript snippets to alter values of variable used in the betza.js script, making it take the images from an other directory. See for instance the article Macadamia Shogi.

One sticking point remains. Although I managed to separate JavaScript from
HTML, I cannot separate JavaScript from PHP. The JavaScript my diagrams use
includes arrays of spaces and legal moves that are written by PHP because
they are specific to a particular game. So, if we forbade JavaScript on
pages, no one would be able to include the JavaScript that is needed for
showing the legal moves in a diagram. Also, when we let people include
JavaScript files, they still need to run functions in those files. So,
perhaps, we could allow JavaScript on pages, though not in comments, and
just police against any misuse of JavaScript.

> So, perhaps, we could allow JavaScript on pages, though not in comments, and just police against any misuse of JavaScript.

Yes, this was what I was proposing from the start. It seems obvious that if you want to allow people to submit their own contributions, you should allow them all the tools they could get to deliver the best result. I don't know what kind of 'misuse' you are afraid of. It seems they could do little harm other than wrecking their own page. For which they probably would not need JavaScript.

If you want to minimize the work involved in policing, the submission form could get another checkbox "Using JavaScript" similar to the one we have now for "Using HTML tags", so that the editors reviewing the submission are made immediately aware whether they are dealing with a page that is static, or one with one that might contain surprises, and deserves some closer inspection.

I was assuming the worst about possible malicious code; a bit of searching hasn't come up with anything that I am too worried about at this site. (As for editor review, I was worried about modifications to an existing page, which doesn't require an editor's sign-off; or sufficiently subtle scripts that wouldn't be noticed without examining the source.)

I did a little looking for a text entry system and right now I like CKEditor.

I looked at the demo for CKEditor. It seems like a powerful WYSIWYG editor,
including several features we won't ever need, but when I clicked
"Source" to edit the HTML directly, it ghosted out nearly everything. I
would favor something that is more sophisticated on the HTML end and a bit
simpler on the WYSIWYG end.

I see that CKEditor can be extended with various plugins. Maybe there is
one that would make the HTML editor more sophisticated.

I now equiped the article describing the interactive diagrams with a 'Design Wizard'. This will (after the user specified all the parameters and selected available piece images from a list) eventually show the HTML code he will have to paste into his own member submission to get the same diagram there.

In making this I noticed something very sick in the submission script:
Less-than signs are of course interpreted as HTML tags, but the normal way for escaping them (by writing "'ampresand' lt >" does not work: this is apparently already converted to a less-than sign during submission, and then interpreted as HTML tag anyway. It even does that within JavaScript things. The only way to make a less-than sign appear in text generated by the JavaScript is to use a double escape in the JavaScript strings: "'ampersand' amp ; lt ;" or in HTML text that you write yourself. Super-annoying thing is that every time you then edit the article it will have removed all "amp ;" from this, so that you have to substitute them back in by hand everywhere in the article where a less-than sign should occur!

Evidently the problem with special characters is an issue with textarea
elements in general.  From what I can tell, the best solution is to escape
all such characters when pulling the information from the database to
populate the textareas; then the textarea (for whatever reason) will
collapse all of that escaping back into what actually lives inside the
database.

Indeed, it seems important that the retrieval + resubmission (for the purpose of editing) does not alter what was not touched during the edit.

The problem seems to be that the submission somehow processes the submitted text TWICE for escape expansion. If I use a single escape for '<' (the usual &lt;), it has exactly the same effect as when I write a plain '<' (namely mutilate the text because it thinks what follows is a HTML tag). And indeed, after retrieval, it is a '<'. I have to escape it twice, writing &amp;lt;, so that after the first processing a &lt; is left. This is then printed as a '<' in the text rather than mistaken for a HTML tag, but on retrieval will only be singly escaped as &lt;.

This happens also during posting comments; you don't want to know what I had to write to get the above text printing as I wanted it... It doesn't matter whether you tick 'using HTML'.

If I can post this, the problem with posting to "We're Moving to England"
is that it has an apostrophe in the title, not that I made it before the
move.

Ben,

Can you make the comment system responsive rather than just designed for
mobile? The header sets a variable called $mobile, which can be used to
provide different code for mobile and desktop displays. Something like what
we used to have would be more suitable for the desktop.

To editors, FYI

I'm having troubles editing my posts at times, until I make a fresh post.
Then I'm allowed to edit my posts for a little while, only, it seems.
Otherwise, when I've attempted to edit a post of mine what's been happening
is that I'm told I must sign in, even though it seems that I already am (in
fact, I don't think the 'edit' option for my posts would show if I were not
signed in). 

Anyone else having this problem?

There are have been some hiccups while moving to a new webhost. I'll look
into this.

It doesn't really seem so. In fact my member-submitted article on interactive diagrams was totally messed up even without me editing it, and the usual work-arounds for getting the less-tan signs to display in the HTML or escape sequences for them to be present in the embedded JavaScript do not seem to work anymore either, so I could not correct it by editing.

Oh, sorry H.G., I was referring to Kevin Pacey's remark that editing
comments was impossible altogether.

I was delaying adding code to escape html characters because I thought
perhaps a new entry system might take care of it for me.  But now I think
it will take me too long to work out the details of that, so I will try to
add the escaping later today or tomorrow.

Perhaps the problems with your user-submitted page have to do with the
transfer?

...and now I can't edit my comments again.  I checked the script, my change
is still there; so I don't know what the problem is now.

AMPERSAND lt ; shows up as <, and I write a > to make sure it terminates a false tag. AMPERSAND amp ; lt ; shows up as <, and I write a > to make sure it terminates a false tag. AMPERSAND amp; amp; lt ; shows up as &lt;, and I write a > to make sure it terminates a false tag. AMPERSAND amp ; amp ; amp ; lt ; shows up as &amp;lt;, and I write a > to make sure it terminates a false tag.