Ratings & Comments

As an example of how Markdown can be used to touch up pages originally done in plain text, I have revised this page in Markdown. The text was already doing bulleted lists in the same way as Markdown does, and I just left that alone. I initially marked off the diagrams as preformatted text, and then I replaced one with a diagram from the diagram designer. It was helpful that the author already included the FEN code, though I had to fix it up a bit, because he used different letters for the same pieces. I'll touch it up more later. For now, what I've done is a trial run for using Markdown to fix up plain text pages without manually adding in HTML code.

These changes affect pages, not presets. This has nothing to do with Game Courier presets except that there are pages referring people to them.

I have no problem with using 'unmoved', but do you have a short alternative for 'virginity' used further down in the legend?

Here is your text:

Click on piece to toggle virginity on/off

English does not have a single word noun for what you mean. I would suggest "moved status" or "unmoved status" if you want a noun, or you could rewrite it to say "Click on piece to toggle whether it has moved."

Hope I'm not concerned. I don't understand anything, this is for experts. Are these changes affecting the Game Courier presets made so far?

Well, the inventor of the 10x8 chessvariant that could not be mentioned here even objected to the use of 'fairy' for the same reason, and insisted that Fairy-Max would participate in his championship under another name. :-)

I have no problem with using 'unmoved', but do you have a short alternative for 'virginity' used further down in the legend?

I modified the scripts for submitting or editing member-submitted pages to use the format attribute instead of the useshtml attribute. While the latter was binary, the former has four values. The format may now be set to HTML, Markdown, Text, or WYSIWYG. HTML and WYSIWYG both get saved to the database as HTML, though they differ in which mode CkEditor is used with them. Markdown and Text are both saved as plain text in the database, and neither uses CkEditor. They differ in how they are displayed. Markdown is a simpler markup language than HTML, and it gets converted to HTML before being displayed. Text just gets surrounded by PRE tags with no additional conversion.

So far, I have added Format to the database without removing UsesHTML. I will remove it later. In the meantime, please check how well the scripts are working and leave any comments on them here.

H.G., I think by virgin you mean unmoved. The latter word is preferable, because its meaning is precise and literal, whereas the former could be used only metaphorically, and it comes with the baggage of sexual and human sacrifice connotations.

Since these are both HTML pages, they are unaffected by how member-submitted pages are saved to the database. In general, I would like to encourage people to replace ASCII diagrams with images and PRE formatted text with HTML formatted text.

However, I have just made the use of CkEditor, htmlspecialchars, htmlspecialchars_decode, and my trim_lines function dependent on $useshtml being true. This should make it easier to edit pages originally done entirely as PRE text.

Please give me links to specific logs.

Fergus asked some time ago whether a piece covering the same squares as a zB but alternating between the move's arms (for which he suggested the name ‘Helical Bishop’ on account of the path's resemblance to a DNA‐style Double Helix) had already been invented. It seems we can now answer that in the affirmative: it's mentioned twice on this page, as the Zigzag Bishop. Betza also posits what Gilman would go on to call a Bruegel (t[Wzt[FAA]]; for which I initially mistook Fergus' description), as well as a piece (the t[FzDD]) ‘dual’ (in the Gilman sense) to the Harvestman of Seenschach which seems to go curiously unnamed in M&B.

PRE tags are typically used for no other reason than to preserve indentations

But is that an appropriate use for them? Please point me to a page that does this, so that I have a better idea of what you are talking about.

And what about JavaScript embedded in the page? The CkEditor doesn't add any whitespace there; it is smart enough to only do that in HTML code where it knows the whitespace will be ignored.

It hasn't harmed your interactive diagram on this page. It does not remove all whitespace. It removes whitespace only from the beginning and the end of each line, and then it adds a newline character at the end so that lines do not run into each other. Losing whitespace at the beginning and ends of lines should not change how any JavaScript works. I guess the issue here is that CkEditor might not reformat the JavaScript when someone is editing it. I ran a test on this, and CkEditor properly formatted the JavaScript even though whitespace had been removed from the lines in the database. So, this doesn't seem to be a real concern.

Indiscriminately destroying the existing explicitly requested layout when you happen to load and resubmit an article for making an innocent change elsewhere basically makes the submission form unusable.

One of the problems is that CkEditor does this anyway. Stripping off whitespace undoes some of the damage and keeps things more uniform.

In particular, I could no longer use it to replace a static setup image by an Interactive Diagram without running a large risk to irreversibly damage the page.

I don't know all the details about how interactive diagrams work, but the one on this page seems fine, and it has had whitespace removed from each line. Maybe you could make sure that static setup images do not rely on whitespace at the beginning or end of lines.

It is far easier to delete whitespace you don't want than to add whitespace that got erroneously deleted, as you would not always know exactly how much whitespace there originally was, and where.

You can check an earlier revision to find out exactly how much whitespace needs to be preserved, and you can use NOBR or SPAN tags to preserve it. Also, deleting whitespace is not an easy job when CkEditor keeps indenting the HTML code. So, I'll disagree on what's far easier.

The most important property of an edit function is that when you activate it, alter nothing, and save, that you have not altered anything, and certainly not anything essential.

If I could figure out how to get CkEditor to behave that way, it would help a lot. Since it doesn't behave that way, it helps to rein things back in by trimming off excess whitespace.

I think the best solution to the addition of leading whitespace in textareas that are used as input for Game Courier is to have Game Courier itself strip off such whitespace. Just as I have done for the Interactive Diagram.

As I already described in my prior comment, there was another issue. The TEXTAREAs looked bad due to excess whitespace that was caused by how CkEditor formats the HTML by putting extra whitespace at the beginnings of lines.

Yes, I think it is better. As it is right now, the text allows more moves than the diagram. Of course the diagram is clear in itself but it is never good to have a difference, one might wonder if the diagram is wrong.

I had seen somewhere (maybe in AI AI?) this piece defined as "leaps as a narrow knight then slides outwards vertically or leaps as a wide knight then slides outwards horizontally". But it can be argued that one needs to know what narrow Knight and wide Knight mean.

Whatever, I suggest to add something to remove the wrong interpretation.

That is no good. PRE tags are typically used for no other reason than to preserve indentations. The CkEditor adds such tags in WYSIWYG mode when you select 'formatted text' in the 'layout' pulldown. (I am guessing the English names, as I see them in Dutch; it is the control left of the question mark.) What you have done would cause every existing submission that relies on it to get utterly destroyed upon editing. And what about JavaScript embedded in the page? The CkEditor doesn't add any whitespace there; it is smart enough to only do that in HTML code where it knows the whitespace will be ignored.

Indiscriminately destroying the existing explicitly requested layout when you happen to load and resubmit an article for making an innocent change elsewhere basically makes the submission form unusable. In particular, I could no longer use it to replace a static setup image by an Interactive Diagram without running a large risk to irreversibly damage the page. And this holds for all editing jobs by CVP editors.

Please revert this as quickly as possible. The adding of whitespace can be annoying in exceptional circumstances. (E.g. I had to adapt the parser of the Interactive Diagram to remove the leading whitespace, as the Diagram's definition is within HTML tags.) But it is not nearly as bad as removing whitespace in the far more common case where the user explicitly requested it. It is far easier to delete whitespace you don't want than to add whitespace that got erroneously deleted, as you would not always know exactly how much whitespace there originally was, and where. The most important property of an edit function is that when you activate it, alter nothing, and save, that you have not altered anything, and certainly not anything essential.

I think the best solution to the addition of leading whitespace in textareas that are used as input for Game Courier is to have Game Courier itself strip off such whitespace. Just as I have done for the Interactive Diagram.

You will have to be more specific, as for me this doesn't seem to happen. What exactly is the position in which the castling failed, and how did you reach it?

You can do that by replacing drawdiagram.php with diagram-designer.php while keeping the rest of the URL the same.

Yes, just put them back.

Thanks, Fergus. I've removed "Tournament" from the title.