Ratings & Comments
I think we should keep the current WYSIWYG editor unless we find a better one. It is what I generally use. For quoting people and typing responses, often with formatting, I think it's the easiest and most intuitive of the methods. Mangling whitespace is a potential issue, but it doesn't seem to manifest much in practice.
This is a nice guide, and will be helpful.
I have one markdown question. Is there a standard way to force a line break? If I just put a single return, it is ignored. If I add two returns, I get a blank line between the two. I suppose I can just use the HTML <BR> tag but is there a markdown-specific way to do this? I do this for things like:
Thanks,
Greg
@Greg, leaving (at least) two spaces at the end of a line before a return renders a newline without a new paragraph.
E.g.,
Ben
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).
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
This is a small sample, if I did everything I'd be spending all day:
https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=dax00-cvgameroom-2020-304-184 https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=per31-cvgameroom-2019-145-205 https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=niccar-krinid-2004-167-366
https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=hambledon-sdc.stats-2008-361-709 https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=tamandua-cvgameroom-2015-24-775 https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=sissa-tamandua-2013-90-201
Help!
I was editing this article, to put an Interactive Diagram in the formerly empty Setup section, and when I saved it all other sections had disappeared. Fortunately I did still have the Introduction on the clipboard, but attempts to paste it back kept failing. I could paste it in the Setup section, and then it showed up. When I finally posted it in the Introduction surrounded by <p></p> tags it did get included in the page after saving.
Is it possible to check an earlier version to see what else was destroyed?
You can recover from this entry on archive.org, there wasn't much ...
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Is it possible to check an earlier version to see what else was destroyed?
Yes, we save all revisions to member-submitted pages. Go toward the bottom of the page where it tells who last revised the page, and click on the word revised, or go to the Edit menu and select the menu item for the revisions.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
You can recover from this entry on archive.org, there wasn't much ...
But what was there was quite essential. Thanks!
I repaired it now, again with some difficulty. There seems to be something terribly wrong with the submission form: it appears to be able to just delete entire sections without warning. We should figure out why that happens.
All I initially did was paste the Diagram I had made in the comment into the Setup textentry of the submission form. This was empty before; the article only consisted of Introduction and Rules. When I then pressed 'Send', the Introduction section was entirely gone (including the header), and the Rules section had only retained its first sentence.
By using the 'back' button of the browser I could back up the the submission form as it looked before I pressed 'send'. As I assumed that I must have accidentally hit some key that led to deletion of the content of the text entries, I thought that resubmitting it while making sure all text was there would solve it, but as a safety measure I copied the text in the Introduction entry to the clipboard. Again the same thing happened: the Introduction section just disappeared.
I noticed that the text in the Introduction text entry was just plain text without any line breaks. So I added <p></p> tags around it after pasting it again from the clipboard, and then it remained. But I had not saved the remainder of the Rules section anywhere.
When I pasted the missing text at the bottom of the Rules text entry in the submission form, it again consistently disappeared on saving the submission. The only content remaining in that section was the first sentence, followed by a line with a <p> tag. Only when I pasted the missing text under that, and added a closing </p> tag behind it, the text remained on submission.
So it seems that text not in HTML tags, or in unbalanced tags, gets deleted on submission. It is risky to assume that none of the articles that I am editing will not contain any such text, and if they do these would be severly dameged on editing; probably withoout noticing it.
I made a quick test submission and can confirm that text outside of paragraph tags disappears somewhere between the submission and the database. What changes happened with the addition of markdown as an option for MS pages, and to what extent does CKEditor interfere with the HTML option?
It has nothing to do with the CkEditor. When I switch JavaScript off, so that this editor cannot be invoked, the text also disappears on submission if there isn't a closing </p> tag.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
25 comments displayed
Permalink to the exact comments currently displayed.
Since this comment is for a page that has not been published yet, you must be signed in to read it.