In the examples you give of where stretching is helpful, the image is larger than the space. So, perhaps you could check the size of each image and apply stretching only if the image is larger than the space.
This would be ideal, but I am not sure whether it is possible. The JavaScript is only aware of the URL of the image; it does not have access to the actual image data. It passes the URL to the browser by inserting it into the innerHTML of some element on the page, and then the browser takes care of loading and formatting the image. This process can only be controlled through the style specifications, in particular background-size. There doesn't seem to be a directive there to demagnify only if needed. The betzaNew.js script uses contain.
I admit there is a problem here, but I am not sure what the best solution is. To allow the use of overly-large images for zoom friendliness, there will have to be a size specification for the size background image. Otherwise too-large images would be clipped to the size specified for the table cell. I never tried using SVG as background, but I suppose the behavior would be the same there, as such images also have a natural size.
But in the early days of the Interactive Diagram pieces were displayed as cell content (and highlighting could only be done through background color, not by symbols, which made it unsuitable for monochrome displays). This posed the problem that it always tried to make the height of the cells larger than that of the image (apparently to leave space for 'true descenders' of the font). This would lead to expansion and contraction of board ranks depending on whether these were empty or contained a piece, unless the squareSize was specified larger than the piece images. So many Diagrams made in those days would specify squareSize=54 when using the 50x50 Alfaerie GIF set. This is no longer needed now that the standard script displays the images as background; the size of a background image does not affect the size of the cell, like the content does. But it would be undesirable if these Diagrams now started scaling the GIF piece images to 54x54, with loss of image quality.
I could make the inclusion of the background-size:contain style specification dependent on a parameter, so that it gets omitted by default, and would not affect existing Diagrams. But if our future default for this website will use overly large (say 100x100) raster images or SVG for the piece sets to improve quality on zooming, it means we will have to include an extra parameter for this in the Diagram specification for eternity. I don't like that very much. It would be better to just keep the old betza.js script as it was for Diagrams that already use it, and let future Diagrams use the new script, which scales the images by default (but can suppress that through an option). Keeping two versions of the script for eternity is also not ideal, but only the newest version would have to be maintained, as the old version should alreaady satisfy the needs of all existing Diagrams that used it.
This would be ideal, but I am not sure whether it is possible. The JavaScript is only aware of the URL of the image; it does not have access to the actual image data. It passes the URL to the browser by inserting it into the innerHTML of some element on the page, and then the browser takes care of loading and formatting the image. This process can only be controlled through the style specifications, in particular background-size. There doesn't seem to be a directive there to demagnify only if needed. The betzaNew.js script uses contain.
I admit there is a problem here, but I am not sure what the best solution is. To allow the use of overly-large images for zoom friendliness, there will have to be a size specification for the size background image. Otherwise too-large images would be clipped to the size specified for the table cell. I never tried using SVG as background, but I suppose the behavior would be the same there, as such images also have a natural size.
But in the early days of the Interactive Diagram pieces were displayed as cell content (and highlighting could only be done through background color, not by symbols, which made it unsuitable for monochrome displays). This posed the problem that it always tried to make the height of the cells larger than that of the image (apparently to leave space for 'true descenders' of the font). This would lead to expansion and contraction of board ranks depending on whether these were empty or contained a piece, unless the squareSize was specified larger than the piece images. So many Diagrams made in those days would specify squareSize=54 when using the 50x50 Alfaerie GIF set. This is no longer needed now that the standard script displays the images as background; the size of a background image does not affect the size of the cell, like the content does. But it would be undesirable if these Diagrams now started scaling the GIF piece images to 54x54, with loss of image quality.
I could make the inclusion of the background-size:contain style specification dependent on a parameter, so that it gets omitted by default, and would not affect existing Diagrams. But if our future default for this website will use overly large (say 100x100) raster images or SVG for the piece sets to improve quality on zooming, it means we will have to include an extra parameter for this in the Diagram specification for eternity. I don't like that very much. It would be better to just keep the old betza.js script as it was for Diagrams that already use it, and let future Diagrams use the new script, which scales the images by default (but can suppress that through an option). Keeping two versions of the script for eternity is also not ideal, but only the newest version would have to be maintained, as the old version should alreaady satisfy the needs of all existing Diagrams that used it.