var img = document.getElementById('imageId');
var width = img.naturalWidth;
var height = img.naturalHeight;
This could offer an approach to the problem, but I don't expect tit to be simple. The piece images on the board have no ID, as they are background, and not independent HTML elements. But the images in the piece table are foreground, in HTML img tags. I could assign an ID to those (they currently don't have one), and access their properties in the way you indicate.
But it is a problem that this entire table is generated by the script. In your test you apply the code to an image that was already present in the page source. So it will be available by the time the code gets executed. In the Interactive Diagram the tags specifying the source URL for the images would only be created during execution of the code. And in my experience changes in the HTML brought about by the code would not be processed by the browser until after the code stops executing. (E.g. in the Checkmating Applets, when the End-Game Table is being generated, if I add a row to the results table after every iteration, all rows appear at once, only after all iterations have been done.)
So control would have to be returned to the browser after the HTML for the table with piece images has been generated and inserted into the page, for the HTML to be interpreted y the browser, and make the newly defined HTML elements exist and become accessible. Otherwise getElementById would think the element does not exist, and return null.
This would completely upset the way the Diagram script works now. Which is creating the board first (including the style instructions to scale background images or not), and only then the table. Another problem is that the decision to resize or not can be dependent on the piece: in a set with variable image size some images might be larger than squareSize, and others might be smaller.
I think this opens a can of worms. Which is not worth it for makikng it possible to handle an occasional sloppily designed piece set.
This could offer an approach to the problem, but I don't expect tit to be simple. The piece images on the board have no ID, as they are background, and not independent HTML elements. But the images in the piece table are foreground, in HTML img tags. I could assign an ID to those (they currently don't have one), and access their properties in the way you indicate.
But it is a problem that this entire table is generated by the script. In your test you apply the code to an image that was already present in the page source. So it will be available by the time the code gets executed. In the Interactive Diagram the tags specifying the source URL for the images would only be created during execution of the code. And in my experience changes in the HTML brought about by the code would not be processed by the browser until after the code stops executing. (E.g. in the Checkmating Applets, when the End-Game Table is being generated, if I add a row to the results table after every iteration, all rows appear at once, only after all iterations have been done.)
So control would have to be returned to the browser after the HTML for the table with piece images has been generated and inserted into the page, for the HTML to be interpreted y the browser, and make the newly defined HTML elements exist and become accessible. Otherwise getElementById would think the element does not exist, and return null.
This would completely upset the way the Diagram script works now. Which is creating the board first (including the style instructions to scale background images or not), and only then the table. Another problem is that the decision to resize or not can be dependent on the piece: in a set with variable image size some images might be larger than squareSize, and others might be smaller.
I think this opens a can of worms. Which is not worth it for makikng it possible to handle an occasional sloppily designed piece set.