Comments/Ratings for a Single Item

I think I somehow replied to the wrong comment of yours, as this conversation should be on the Xiangqi page. But I just got back from a walk and am too tired to deal with that right now.

So if the board is not a table, how would a program specify which image should be drawn where on the page, and to reserve space for that?

If you were to use grid for layout, the HTML element to use would be the DIV for both the board as a whole and for each space, and grid would be used to tell how they line up. If you look at the HTML for a Game Courier preset with a Square shape for the board and CSS for the rendering method, you can see how I've done this. For absolute positioning, you would give the position of each piece in the board with CSS. I have examples of this in Game Courier with the Custom Grid shape (which has nothing to do with CSS grid, as I wrote the code before CSS grid existed) and the CSS rendering method.

Another issue is how to arrange mouse-click input. This is now handled by attaching event handlers (for mouse down or up, touch, hover etc.) to the individual cells, which get the (diagram number, rank, file) as parameters to indicate what was clicked.

For grid, these would attach to DIVs. For absolute positioning, I also create an image map with MAP and AREA elements, and it looks like I'm attaching event handlers to both IMG and AREA elements, possibly for redundancy in case one doesn't work.

I was not aware of this grid style at all. But after some reading up on it, it seems that it is pretty easy to mimic a HTML <table> with a HTML <div> element defined as container, and replace the <td> elements in it by <div> elements. The <tr> level can be omitted entirely, as the length of each table row is implied by the container <div> through its columns template. This is good, because it means there would hardly have to be any change in the current code to use a grid instead of a table. The <td> attribute colspan (which the I.D. only uses for the upper board rim) has an analog in the grid as well.

In detail: the board table currently is defined as

<table id="board' + dnr + '"
       cellpadding="0"
       style="
              border-collapse:collapse'
              + (background ? ';background-image:url(' + background + ')' : '') + '
             "'
       + (coords < 0 ? ' border="1"' : '') +'
       oncontextmenu="return false;"
   ></table>                               // initially empty

The cellpadding seems to become redundant, as the <div> daughters by default would have zero padding, unlike the <td> granddaughters. I have no doubt that a <div> would also support oncontextmenu and a background-image. That leaves the border-collapse style; I suppose the corresponding grid attribute is the column-gap. I am not sure whether setting that to 0 and giving the <div> daughters a border of 1px would make the borders coincide, or whether this would require column-gap to be 1 or -1.

In addition the container would need the style display:grid. The width and height attributes of the <td> elements would be moved to the container <div> as grid-template-columns and grid-template-rows. Cells for the board rim contain (apart from the now redundant height and width styles) only styles for their background and text coloring and alignment.(And in one case a colspan="N", which would become a column-start: 1/span N style.)

It looks like a simple patch; I will try it out.

The <td> elements for the board squares are currently defined with attributes

valign="center"
align="center"
style="
     width:' + sqrSize + 'px;
     height:' + sqrSize + 'px' + ';
     border:' + bb + ';                     // bb = (borders ? 'thin solid black' : 'none');
     font-size:xx-large;
     background-repeat:no-repeat;
     background-position: center center;
     background-size:contain
     "
onmousedown="Down(' + bnr + ',' + j + ',' + h + ',event)"
onmouseup="Up(' + bnr + ',' + j + ',' + h + ',event)"
ontouch="Touch(' + bnr + ',' + j + ',' + h + ')"
onmouseover="Hover(event)"
ondragover="PreDrop(event)"
ondrop="Drop(event)"
ondragend="Relay(event)"

All the handlers would no doubt also work on a <div> element. I am not sure the align and valign HTML attributes would work on a <div>; they might have to be replaced by corresponding style specs. (These serve to position the move-highlighting marker images, which are cell content.) As for the styles, I think border works fine on a <div>, as well as font-size (needed only to display question marks in move diagrams to indicate hidden hopper moves when color highlighting is used). The background details should work too, as <div> elements can have background images. (The actual background-image (of the piece) would be set by Display().) So it is basically a matter of replacing the width and height styles (now handled by the container templates) by style instructions needed to center the content.

It seems that I have something that sort of works, in the previous posting. (Using betzaCSS.js as script source.)

It appears that it is essential to make every item request its position, because the grid container will be filled with more columns than the grid-template-columns specifies, if there is room. (An alternative I did not try was to specify the size of the container.)

I was wrong in <div> elements having no padding; they pad on the left to create a margin. So I did have to set the padding to 0px. This has to be done in every item; unlike for a <table> you cannot do it globally in the container.

Remaining problem is to get a border collapse. With the gap set to 0px the borders of the items touch, and you get a double-width border. Setting the gap to -1 soesn't appear to work.

I have updated my Xiangqi Interactive Diagram to use betzaCSS.js, and it has fixed the problem of the extra board on my iPad, but it has also introduced new problems that can be seen on both my iPad and my desktop. I will leave it like that to help you with your debugging.

I already fixed some problems (which where due to writing cellpadding where it required padding). Only remaining problem seems to be the vertical alignment of the coordinates on the left of the board.

BTW, after I am done debugging betzaCSS.js will probably replace betzaNew.js, and disappear itself.

If I view my diagram on a page listing multiple comments that also includes your diagram, then it looks fine, but the buttons are not working. If I view it by itself, it looks messed up with rank and file markers getting on the board, some pieces being too small, and the board tiling.

Did you refresh the browser cache? I was just making some changes to get the rank inscriptions on the right side of the board, to conform with how the Diagram Designer does it.

For me it looks OK now, with rim and coordinates. Didn't test without yet.

If there are other Diagrams on the page, you are probably not using betzaCSS.js, as they all go accompanied with a link to load one of the betza.js scripts. And the last one loaded will prevail.

[Edit] Oh, with rimColor=#FFFFFF I get sick behavior. The Diagram uses this as a kludge to suppress the top and left part of the rim (which have no text).

[Edit2] It seems to work now.

I just added uniqid=7 to the query string to force it to use the latest version of your script, and it is looking a lot better, but there are still issues. On both my desktop and my iPad, the pieces are shifted toward my right. The Rooks on the right side are usually going over the edge a bit, while the Rooks on the left have a bit of margin with the left side. Also, on my desktop at least, there is some tiling. You should be able to turn tiling off by setting background-repeat to 'no-repeat'. While you're rewriting Display(), you might also add support for changing the background to the value of the background variable.

Can you post a screenshot? Initially I had problems too with pieces shifted to the right and partly leaving their cells, but this appeared to be due to a default padding in <div> element, which I now overrule with padding:0px.

There already is no-repeat for the background. ([Edit] That is for the cell background = piece image. But I guess you meant the board image. If that is not the same size as the Diagram something is wrong, which cannot be completely cured by a no-repeat. I now added the no-repeat, but would probably make more sense to add a backround-size:contain to scale the image so it will be diagram-filling. If a board rim with coordinates is requested the rimColor would cover any tiling anyway.)

For me it looks like this (FireFox on Win 7):

I already put replacing of the backgroundImage in the routines that are called by the auto-generated buttons, (TwitchDiag(diagramNr, whiteSet, blackSet)), and made nearly all parameters of the Diagram subject to the set=... lines that would make them conditional depending on the currently selected set. So it should now also be possible to use the auto-generated buttons for changing the board look.

To change piece sets would still require the piece names in the sets to be compatible. Or double definition of the entire collection of pieces in the different sets, only differing in image name.

Here is a screenshot of how it looks with the Abstract pieces on the checkered board. The markers on the Pawn and Cannon spaces help give a good indication of how these pieces are misaligned. Also, the top row of pieces is too close to the top, and the bottom row is too close to the bottom.

OK, the container <div> also had some padding on the left side, which I now suppressed. In addition the 1px gap to achieve border collapse with outlined cells was also used when no border was specified, expanding the Diagram with one pixel per file or rank. The background image did not suffer such expansion, (as I did not include a background-size:contain yet), hence the misalignment.

Both problems should be fixed now; I also repaired the border that is drawn around the entire Diagram (making it outline instead of border), and that shows the container <div> indeed coincides with the circumferene of the drawn squares.

It's now looking good enough to put on the page.

I already put replacing of the backgroundImage in the routines that are called by the auto-generated buttons, (TwitchDiag(diagramNr, whiteSet, blackSet)), and made nearly all parameters of the Diagram subject to the set=... lines that would make them conditional depending on the currently selected set. So it should now also be possible to use the auto-generated buttons for changing the board look.

That's something I don't know how to do. I was mainly suggesting that if I gave background a value in a button that Display() would change the background image, but in tests, that did not work.

Well, you can now write things like:

files=9
ranks=10
squareSize=50
set=Western
background=cambuca.png
graphicsDir=/graphics.dir/alfaeriePNG/
set=Oriental
background=gridboard.png
graphicsDir=/membergraphics/MSxiangqi/
set=0
borders=0
...

and the script would automatically create buttons Western and Oriental above the board that you could use to switch board and piece images.

As a test, I added this:

set=Xiangqi Scans
background=/play/pbm/backgrounds/chinese-blue-green.png
graphicsDir=/play/pbm/showpiece.php?uniqid=6%26size=50%26size=50%26set=xiangqi-scanned%26piece=
set=Eurasian
background=/play/pbm/backgrounds/chinese-eurasian.png
graphicsDir=/play/pbm/showpiece.php?uniqid=6%26size=50%26size=50%26set=eurasian1%26piece=
set=0

When I click on one of the automatically generated buttons, it will change the pieces but not the board. I have two buttons so that I could test this without interference by my other buttons, which do it differently. This makes no difference, but it at least tells me that my buttons are not the cause of the automatically generated buttons not working right.

There was a bug there; when the auto-generated buttons were used to switch, I assigned the plain URL to style.backroundImage. While it has to be wrapped in 'url(...)'.

I corrected that now, and tried to test it. But I cannot even get a board background to work without any switch buttons. The Diagram in the Comment I am now replying to should use a board background. But instead the board shows up all greyish, like the Comments background color. Even though I set the background color of the <div> that contains the Diagram definition (which will get to contain the container <div> of the board as one of its daughters) to green, the green doesn't shine through.

(I get some sick behavior there too; sometimes the area  of the Diagram is all green, as I expect, but then, after a few second, usually at the same time the ads appear, most of the green diappears, and only a tiny bit between the buttons is left.)

It seems that something is not transparent, and that also seems to cover the background image of the board. Any background color I specify for the container <div> also doesn't become visible. So I suppose it is the grid-item <div> elements (i.e. the board squares) that fail to become transparent even when Display assigns an empty string to their style.backgroundColor attribute. When the squares are <td> elements in a table I did not have that problem.

Although the test Diagram there has buttons, the problem already occurs before any of the buttons is pressed, on first parsing of the Diagram. The set lines that define the buttons thus cannot be the problem, these just cause some lines in the definition to be skipped on parsing. And indeed I verified that the behavior remains the same when I delete all these lines.

[Edit] The background (color or image) of the container <div> does not seem to be covered by the background of its daughter items. I can force the latter to a semi-transparent color by using 8-digit color codes for their background, like #FF000080. That gives a pinkish board, showing that the color is indeed used, and that something nearly white shines through. Even though the background color of the container is set to blue.

A small test

It appears that in principle this should work: specifying a background-image for the container, and then (semi-)transparent background color for the items, so that these do not cover it. So why doesn't it work in the Diagram???

Could it be float or z-index related?

Could it be float or z-index related?

Well, the Diagram or Comment I put it in uses neither. If there would be a z-index on the container <div> that puts it behind the Comment background, the latter could block the view. But I made the background of the <div> that contains the entire Diagram green, and it is clearly in front of the Comment background. But the green doesn't show through the board squares, even if I can see that these are partly transparent.

I used the FireFox inspect function to see what attributes the container <div> HTML element has, and this looks fine. It has both a blue backgroundColor and a backgroundImage, and it shows a demagnified image of the board image when I hover over the link, so I know the URL is OK.

Ah, solved! I noticed that hovering over a line in the inspect window highlights the corresponding HTML element in semi-transparent blue on the page itself. This way I saw that the <div> of the first grid item, (that with span 12), supposed to be the upper rim of the board, extended over the entire board as a 390 x 390 square. Now this <div> had an explicit width:390px style, rather than relying on the grid-template-columns value. I suppose I did this at a time when the container <div> was not yet properly aligned with the items because of the default left padding.

Apparently specifying a width also automatically sets the same height????

Anyway, I removed the explicit width, and now all paddings have been set to 0px this produces an upper rim of exactly the desired size, no longer covering the board.

Ah, solved!

What is it that you've solved? The automatically generated buttons are still not changing the board's background image. So I suppose it's not that.

I solved that I could not see a background image at all. But this was only when the Diagram had a board rim; apparently part of the rim was growing out of proportion, and covered the entire board.

I now solved the other problem too, though. I had forgotten to write 'document.' before the 'getElementById' when I assigned the new background to style.backgroundImage. In the Diagram below the background switch now works for me:

Unsolved (but unrelated) mystery is why after a short time most of the green background disappears. I don't know if others experience that too.

The automatically generated buttons do seem to be working now, but I am now having an issue with my own buttons. I put the diagram on the page, but on my desktop, my own buttons would not change the board. With Web Developer Tools in Firefox, I could see that it was using board1 instead of board0. I then tried it on my iPad, which does not display the comments, and it worked fine. I figure that because multiple Interactive Diagrams were on the desktop version, it was using different board numbers for each. This is why it is important to be able to use background= instead of getElementById('board0').style.backgroundImage= in the JavaScript for a button. Since I would prefer to use my own buttons for better control of the layout, I'm hoping you can update Display() to change the background image to whatever the value of background is.