Check out Atomic Chess, our featured variant for November, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

Asylum Chess. 3 new unique pieces: fire-through rooks, double-capture knights, leaping bishops. (10x10, Cells: 100) [All Comments] [Add Comment or Rating]
🕸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.