Comments/Ratings for a Single Item

This had indeed no effect. But the difference between the FRC and Ultima Diagram is that the latter had the coordinates displayed. So I added a firstRank=1 to the FRC Diagram definition. And now it does show up.

It seems the absence of the rim cells causes the height of the table cells to collapse to a height of 0px.

[Edit] The inspector says the <td> cells corresponding to board squares still have a height: 0px. But the left rim cell has

height: 50px; width: 25px; height: min(10vw, 11vh, 50px); width: min(5vw, 5vh, 25px)

and is apparently forcing the rows open.

height: 50px; width: 25px; height: min(10vw, 11vh, 50px); width: min(5vw, 5vh, 25px)

To give an explanation for that line, the min function is being used to make all the spaces fit on a phone screen. On the desktop, the vw and vh values will normally be larger, and it will use the px values. But on a phone, the smallest value will sometimes be a vw or vh value, which are defined as percentages of the view width or view height. If a browser does not support the min function or vw/vh units, it will default to the pixel unit, which is not even an issue on desktops, though it may stop some older phones from fitting the diagram on the screen.

OK, I got it! I searched for style.height in the script, and it turned out that there is an assignment cellp.style.height = cellp.clientWidth to all board squares in Display(). I think this was an attempt to force the squares to remain square when the browser window starts to compress the Diagram in the horizontal direction. But it appears the way you handle the square sizes causes the clientWidth to become 0px, while the assignment erases your setting of the height in vh units.

After commenting out this assignment from betzaFlex.js the Diagram now also shows up when the coordinates are not displayed. Newer browsers might be more clever in calculating the clientWidth.

I searched for style.height in the script, and it turned out that there is an assignment cellp.style.height = cellp.clientWidth to all board squares in Display().

That's a bit of your code that I overlooked, because I didn't know what it was doing.

I think this was an attempt to force the squares to remain square when the browser window starts to compress the Diagram in the horizontal direction.

What I'm doing by taking the minimum of three values is handling the same problem. When the default size is too large for the screen, it finds the largest size that will comfortably fit the available space and uses it for both height and width.

But it appears the way you handle the square sizes causes the clientWidth to become 0px, while the assignment erases your setting of the height in vh units.

After commenting out this assignment from betzaFlex.js the Diagram now also shows up when the coordinates are not displayed.

Since what I'm doing handles the same problem, it looks like this clientWidth assignment is no longer even needed, and commenting it out was the right thing to do.