Comments/Ratings for a Single Item

getElementById('board' + active).style.backgroundImage=...

That appears to fix this problem, but a new problem has come up. None of my buttons will work until I click on one of the automatically generated buttons.

The problem appears to be interference from the other diagram on the page that is in a comment, as my buttons are working fine in the diagram in the comment when viewed by itself, and they are working fine on the iPad, and after getting them to work, they stop working if I click on a button for the other diagram.

Indeed, multiple Diagrams on one page can be problematic; the script wasn't really designed for that. Especially if a Diagram needs to be interfaced with some external element, such as custom JavaScript embedded in the page, piece lists or tables embedded in the text, or buttons to change Diagram parameters, there can easily be confusion about which Diagram these belong to. What makes it worse is that each Diagram usually cames with its own link to a betza.js script, and if they use different versions it will be the last link on the page that will prevail. Which could be an obsolete version not implementing what an earlier Diagram relies on.

To make life easier I now made all the betza.js scripts save the Diagram numbers in the global array sats[], which can be indexed by the satellite value of the sought Diagram. Buttons could use that info to make sure they will always act on the right Diagram; they should call TwitchDiag(sats['satelliteValue']) before they start changing any parameters.

they should call TwitchDiag(sats['satelliteValue']) before they start changing any parameters.

I just tried that, and none of my buttons worked even after using the automatically generated buttons. Shortly after I did this, I reloaded the page again, and the Interactive Diagram would not work at all, just showing code where the diagram should be. This is a problem on both this page and in the comment I made with the diagram, and it is a problem with both Firefox and Edge. So it's not on my end.

Sorry, I bungled this big time. I just slipped in a simple line of code in all 3 betza.js scripts before switching off the PC and going to bed. That will teach me to never, never make a change without testing. The almost infallible rule is that when I paste in a line of code in multiple places it ALWAYS contains a bug or typo.

In this case I had written "if(sats === undefined)", and it turns out this causes a run-time error when sats is undefined. It had to be "if(typeof(sats) == 'undefined')".

I fixed that now, and to test whether it worked as expected I scrolled down through the Comments list until I encountered a page with three Diagrams. The first of that was apparently the Comment you are using for experimenting with the background buttons. The second Diagram, which was my recent, modernized copy of the old Xiangqi Diagram, refused to be parsed unless I viewed it is isolation.

In figuring that out, and to explain the unexpected Diagram numbering the sats[] array showed of the other two Diagrams (the one appearing first had the highest number!), I discovered the following problems:

1) The two Xiangqi Diagrams used the same value for satellite=xiang. This thwarts the purpose of allowing external elements to recognize which Diagram they belong to by discriminating them by satellite.

2) Your Diagram was cloned from mine, which was again cloned from the very old Xiangqi Diagram. In that thime Diagrams were recognized by the betza.js script by having id="diagram". Both clones still had that. But in HTML the ids are supposed to be unique, and with getElementById() it would only find the first one. This is why my Diagram was ignored. For allowing multiple Diagrams on one page I later switched to recognizing Diagrams by class="idiagram"; with geteElementsByClassName() you can then get an array of all Diagrams on the page. For backward compatibility it still also looks for an id="diagram", and if it finds one it adds that to the array as last element. This explained why the first Diagram got the highest index in the array.

I now corrected both issues by having my Xiangqi diagram use satellite=xiang2, and making all Diagrams flagging their presence through class, rather than id. This should cause the page to behave less erattically. In the console log the script now prints

Object { piece: 2, xiang2: 1, xiang: 0 }

for the sats[] array after the last Diagram has been parsed. ('piece' is the default value for satellite, and represents HaruN Y's Diagram on that page).

BTW, I noticed you were using very many buttons for different styles. I don't know what your objections were to the layout of the auto-generated buttons, but it is possible to control that layout somewhat: If a set name starts with an asterisk, like set=*Oriental, the asterisk would be stripped off the name, and the button would be placed on a new line. That way you can prevent uncontrolled wrapping in a large row of buttons.

If you don't want to use auto-generated buttons, you can still divide up the Diagram definition in sets, by using numeric values for the set indicators; this suppresses creation of buttons. You can then make your own buttons select a set by having them call TwitchDiag(diagNr, setNr). The diagNr you could get in a reliable way as sats[satelliteValue]. But for the main Diagram on an article page, where no one can pre-empt you with other Diagrams, it would always be 0. (If you identify the Diagram by class, that is.)

1. The two Xiangqi Diagrams used the same value for satellite=xiang. This thwarts the purpose of allowing external elements to recognize which Diagram they belong to by discriminating them by satellite.

I never knew what the satellite value was for before. I have now changed it to xiangqi.

2. Your Diagram was cloned from mine, which was again cloned from the very old Xiangqi Diagram. In that thime Diagrams were recognized by the betza.js script by having id="diagram". Both clones still had that. But in HTML the ids are supposed to be unique, and with getElementById() it would only find the first one. This is why my Diagram was ignored. For allowing multiple Diagrams on one page I later switched to recognizing Diagrams by class="idiagram"; with geteElementsByClassName() you can then get an array of all Diagrams on the page. For backward compatibility it still also looks for an id="diagram", and if it finds one it adds that to the array as last element. This explained why the first Diagram got the highest index in the array.

I have now added CLASS="idiagram" and removed ID="diagram".

BTW, I noticed you were using very many buttons for different styles. I don't know what your objections were to the layout of the auto-generated buttons, but it is possible to control that layout somewhat: If a set name starts with an asterisk, like set=*Oriental, the asterisk would be stripped off the name, and the button would be placed on a new line. That way you can prevent uncontrolled wrapping in a large row of buttons.

That's not the issue. I have two sets of buttons. One is for themes, and one is for boards only, as there are more boards than themes, and this allows someone to choose any combination of set and board. With automatically generated buttons, I cannot separate the two sets and label each one differently. Also, to reduce the space they take, I prefer to not give them a fixed width.

If you don't want to use auto-generated buttons, you can still divide up the Diagram definition in sets, by using numeric values for the set indicators; this suppresses creation of buttons. You can then make your own buttons select a set by having them call TwitchDiag(diagNr, setNr). The diagNr you could get in a reliable way as sats[satelliteValue]. But for the main Diagram on an article page, where no one can pre-empt you with other Diagrams, it would always be 0. (If you identify the Diagram by class, that is.)

Doing it this way, is it possible to have a button that changes the board and not the set? I previously saw you using TwitchDiag() with three arguments. What is the third argument?

Like I tried last night, I added TwitchDiag(sats['xiangqi']); to the beginning of each button, and this time it worked. I also removed Display(); from my board buttons, because tests showed it was unnecessary after just changing the board value.

Doing it this way, is it possible to have a button that changes the board and not the set?

Unfortunately not. The third argument is for different-army contexts. If the parameter perArmy=1 is added the pieces of the sets mentioned in the 2nd and 3rd argument are both included, but for the initial setup the piece lines in the white set would ignore the placement of the black pieces, and vice versa. It will then generate two identical rows of buttons, one for selecting the white and one for the black army.

One last issue I'm having is that the graphics used to mark legal moves are all off-center.

I have been thinking. When you want separate buttons for board and pieces, the board buttons must leave the pieces alone, and vice versa. Since the auto-generated buttons work by reparsing the entire Diagram definition (but accepting different lines as specified by the arguments of TwitchDiag()), the old setting for the set you don't want to change should be remembered.

This is how it already works for different armies: the white and black army settings are remembered in global variables wOld and bOld. And the buttons generated for changing the white army then call TwitchDiag(diagramNr, newWhiteChoice, bOld).

I guess the same method could be used for changing board and pieces. The 2nd and 3rd parameter of TwitchDiag() indicate the two sets of definition lines that should be included in addition to set 0. That piece lines in these sets get their white or black pieces suppressed is of no import when all the piece lines reside in set 0. So the 'white set' could be used for selecting board themes, the 'black set' for selecting piece themes.

The only issue is that when auto-generating a button for a set, the Diagram should know whether this is a button for the 'white' (= board) set, or for the 'black' (= pieces) set, so it can keep the parameter which it is not supposed to alter fixed. (In a different-armies context the perArmy=1 line would force both butoons to be made, in different rows.) Currently (without perArmy) it would always invoke TwitchDiag() with identical 2nd and 3rd argument.

I could make the perArmy parameter control that, e.g. by giving it the value 2 or 3. As long as it is 2, all buttons it generates would call TwitchDiag() with their own 2nd arguement, but with bOld as 3rd argument, and would then be board buttons. (That is, if you put board-defining definition lines in the sets selected by those buttons.) Buttons generated while perArmy equals 3 would pass a new 3rd argument, and use wSet as 2nd argument.

This sounds really simple...

One last issue I'm having is that the graphics used to mark legal moves are all off-center.

In the Diagram here I don't see that. That is, if I select the Old Style or Wood board, the markers seem pretty well centered.

On the initial board, selected by the Background button, this doesn't seem to be the case. But there the pieces are also not well centered. I know why that is: the background image was designed for betzaNew.js (and in use elsewhere), which put the rank coordinates on the left of the board. If the board has more than 9 ranks, the double-digit value of the coordinates forces the with of the left part of the rim wider than their nominal width of half a square. The image takes that into account. But betzaCSS.js now writes the coordinates on the right side. So it really needs another image.

I should take care of that when replacing betzaNew by betzaCSS; I will have to adjust all Diagrams that use background on a board with >= 10 ranks, with small square size. (For 50x50 the rim is wide enough to accomodate double-digit coordinates.)

When you want separate buttons for board and pieces, the board buttons must leave the pieces alone, and vice versa.

But that is not what I want. The theme buttons change both pieces and board together.

This sounds really simple...

What I have currently done is working, and what I'm hoping to eventually do is to replace the buttons with SELECT drop-down boxes that will indicate which options have been selected. So I'm not going to try to use TwitchDiag() any further than I already have.

But that is not what I want. The theme buttons change both pieces and board together.

I thought you had too many combinations for that. Anyway, the Diagram below uses separate selection of board and piece theme, through the method I outlined. When viewed in isolation. (Otherwise it doesn't use betzaCSS, because there is a Diagram lower on the page that doesn't.)

I thought you had too many combinations for that.

It's the same number of buttons either way, as each theme button is for a different set with a board picked especially for it. So you first select the set with a theme button, and if you want a different board, you can then select it with a board button.

I have been thinking. When you want separate buttons for board and pieces, the board buttons must leave the pieces alone, and vice versa.

I now have SELECT elements for individually changing the set and board while I still use buttons for the themes. The buttons will update the values of the SELECT elements to tell which set and board are being used. Both the buttons and the SELECT elements call the changeTheme() function. To get it to work properly, I had to make graphDIR a global variable outside the function, as betzaCSS.js did not already declare it to be one. To keep the set or board from changing when I just mean to change one, the function retrieves its value from the appropriate SELECT element and reapplies it. To handle this, the setTheme() function can take a value of 'same' for either set or board.

In JavaScript any undeclared variable you assign to will automatically get global scope. I left some variables intentionally undeclared in the script, to make it resistant against appearing multiple times on the page. The initialization can only be run once, as it removes all the Diagram definitions and replaces them by the actual images. But global declarations of a variable would also be seen in the second and later loading, and then destroy the value the initial loading and initialization set these to. When the array that holds all the collected original Diagram definitions was erased that way, none of the Diagrams of the page would work anymore.

This problem occurred when loading is so slow that some later loadings of the script occur after initialization (which is done after some delay) has already been done. I would have expected that using an 'onload' handler for calling the Init() routine, rather than performing it after some timeout, would solve that. But I could never get this to work. It is also a pain that for multiple loadings the last loaded script would prevail; I would prefer the first-loaded script to prevail. In general that would be the one that is in the article, and it is a bad thing that anyone could post a Comment to the page that could wreck it, by posting a Diagram that uses some obsolete version of the script.

I suppose this could be done by wrapping the entire script in a function, so that none of the declarations (also those of functions) become local to that wrapper. The wrapper frunction could then assign the functions that need to be global to undeclared global variables to provide access to those for the event handlers, and take measures that would make it return immediately when called a second time. Like

function script() { // wrapper for the entire script
  if(initDone) return;
  initDone = 1;
  F = function (args) { .... }; // declare functions and make them global
  G = function (args) { .... };
  Init = function (args) { .... };
  setTimeout('Init()', 500); // run Init after 500 msec
}
script(); // call it

But this would still offer no protection against older versions of the script that explicitly declare F and G as globals ("function F(args) {...}"), and are loaded later. Unless I would change the name of all functions that need to be accessed globally.

Declaring something as global in script embedded in the article should be harmless, as this will only be seen by the browser's JavaScript engine once.

I managed to dig up your trial Diagram from the Comments listing, and I understand now what you mean by the highlighting markers not being centered. It appears that it was a coincidence that they seemed to be well centered correctly in the Diagram with 35x35 squares.

Apparently the way to center images in a <div> is to declare that <div> to be a flexbox, with additional styles:

display: flex; justify-content: center; align-items:center;

I have now done this. It doesn't look perfect yet, but it is a lot better than it was.

[Edit] It appears that the remaining amount the markers are off-center is due to the fact that they are a bit low in their 33x33 images to begin with.When an image is displayed as content of a <td> element it is vertically alligned to sit on the 'text line', which leaves some margin under it for the 'true decenders' of letters like g, p, q, j and y. But the flex-box alignment seems to ignore that margin.

So the solution is probably to make a new set of marker images.

Yesterday I used JavaScript to write out the form for the Interactive Diagram so that it would not show up if JavaScript is not enabled, but an incomplete duplicate line caused a bug that caused the form to not display at all. I have now fixed this.

I always put the Diagrams in a <div id="someString" style="display:none">, and add a line

<script>OpenDiv('someString')</script>

on the page that would make it visible when JavaScript is enabled.

Apparently the way to center images in a

is to declare that

to be a flexbox, with additional styles:

display: flex; justify-content: center; align-items:center;

place-content is a shortcut for both justify-content and align-content, and place-items is a shortcut for both justify-items and align-items. So, either place-content: center or place-items: center should do the job. They operate the same for one item. They will behave differently if you have multiple items in your container, and Kevin Powell explains the difference in a video called Place-content vs. place-items | What's the difference to vertically & horizontally center?.

If you want to put the CSS on what you want centered instead of on its container, you can use place-self instead. All of these should work whether the container is a grid or a flexbox. I appear to have used both place-items and place-self in the CSS rendering of the square shape in Game Courier.

Actually there are lots of pronounciation error on Chinese Characters. I propose to use The Complete Collection of Ancient and Modern Characters including Hanzi, Tangut, Khitan, Jurchen and Phagspa in 漢字 mode to get the correct pronounciation such as 前 is qián instead of xin.

Actually there are lots of pronunciation error on Chinese Characters.

Since I don't speak Chinese, why don't you tell me what mistakes you think were made?

A lot of fourth-tone(which is 5-1 in IPA) were written in second-tone(3-5). Such as 將 is jiàng instead of jiáng. Also, 前後 is totally wrong -- The pronounciation in it doesn't make sense(qian → xin and hou → han).

I propose to use The Complete Collection of Ancient and Modern Characters including Hanzi, Tangut, Khitan, Jurchen and Phagspa in 漢字 mode to get the correct pronounciation such as 前 is qián instead of xin.

The problem with using this site is that it is entirely in Chinese, which I don't read. The site I'm currently linking Chinese characters to is in English, but it is not including the Pinyin spellings.