The site has moved to a new server, and there are now some issues to fix. Please report anything needing fixing with a comment to the homepage.

The Chess Variant Pages

Enter Your Reply

The Comment You're Replying To
H. G. Muller wrote on 2022-11-30 UTC

I also use WYSIWYG mode for submitting comments. My only reason for using HTML is when I want to embed active elements (like Interactive Diagrams) in the submission. Links, images, pre-formatted text and such are all supported in WYSIWIG mode.

In general I find the indentation enforced by the CkEditor in HTML mode helpful. Apart from HTML it also appears to understand embedded JavaScript, and the nice layout prevents errors. I thought that ending 'solo tages" like IMG or BR with /> was actually the HTML 5 standard, so you can hardly blame the editor that it enforces that.

Only very rarely the mangling of whitespace by the Ck Editor backfires. One case was for posting Interactive Diagrams: the definition of those must be given as text within a HTML tag pair (like DIV or TD) which normally ignore leading whitespace in their content. So the Editor indented the definition line, while the original Diagram script expected the definition lines to be left-adjusted. So I had delete all leading whitespace from the Diagram definition before saving each time I edited a submission containing a Diagram. I quickly got tired of that, so I just had the routine in the Diagram script that parses the game definition strip the leading whitespce. (As well as trailing BR tags, which tend to appear there when you copy-paste from HTML Page Source.)

I think the only reason we are discussing this issue is that we now have identified a second (quite rare) case where the adding of leading whitespace backfires: text within TEXTAREA tags. Apparently this is a blind spot of the CkEditor: it does recognize PRE tags, and knows it should not mess with the layout there. But it appears to not do the same thing for TEXTAREA, while it should: this is another context where the text between tags should not be messed with.

While I see plenty of reasons why one could want to use pre-formatted text in submissions through PRE tags, I only see very few for TEXTAREA. The Play-Test Applet uses a TEXTAREA for pasting an existing Interactive Diagram into it (so you can convert it to GAME code, or get a table with verbal descriptions of the moves. But it starts out empty. But it appears that invoking Game Courier as a game viewer would be another application, and the first and only article I so far encountered that did this was Asylum Chess.

Logical solution would be: (1) Make Game Courier strip the leading whitespace the CkEditor added, so that it no longer matters (like I did for the Diagram). (2) Fix the Ck Editor so it treats TEXTAREA the same as PRE (not adding any whitespace). (3) Let the submission script delete leading whitespace only between TEXTAREA tags. This cannot be too hard. (4) Let the submission form test whether the page being edited contains TEXTAREA tags by itself, and only in that case suppress the use of the CkEditor. The text input fields of the form have the standard editing capabilities (which you have to rely on when JavaScript is switched off, as the CkEditor is a JavaScript program).

Edit Form

Comment on the page How to Design and Post Your Own Game

Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

Top level header: <H1>

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: <H2>

  • Unordered list item
  • Second unordered list item
  • New unordered list
    • Nested list item

Third Level header <H3>

  1. An ordered list item.
  2. A second ordered list item with the same number.
  3. A third ordered list item.
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

Alt text for a graphic image

A definition list
A list of terms, each with one or more definitions following it.
An HTML construct using the tags <DL>, <DT> and <DD>.
A term
Its definition after a colon.
A second definition.
A third definition.
Another term following a blank line
The definition of that term.