Check out Janggi (Korean Chess), our featured variant for November, 2024.

Enter Your Reply

The Comment You're Replying To
🕸Fergus Duniho wrote on Sat, Nov 26, 2022 04:22 PM UTC in reply to H. G. Muller from 08:43 AM:

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.


Edit Form

Comment on the page Asylum Chess

Conduct Guidelines
This is a Chess variants website, not a general forum.
Please limit your comments to Chess variants or the operation of this site.
Keep this website a safe space for Chess variant hobbyists of all stripes.
Because we want people to feel comfortable here no matter what their political or religious beliefs might be, we ask you to avoid discussing politics, religion, or other controversial subjects here. No matter how passionately you feel about any of these subjects, just take it someplace else.
Avoid Inflammatory Comments
If you are feeling anger, keep it to yourself until you calm down. Avoid insulting, blaming, or attacking someone you are angry with. Focus criticisms on ideas rather than people, and understand that criticisms of your ideas are not personal attacks and do not justify an inflammatory response.
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.