Comments/Ratings for a Single Item

This screws up tables. I think you should revert to the old typography.

This page has the piece diagram as a table, and the squares aren't uniform. Sometimes they even get bigger or smaller when you move a piece. Also, I liked the old font.

The shape of the squares is easily fixed by setting the height and width of each table cell to the same value, as I do for diagrams rendered as tables in Game Courier.

There was no body font before. It just used whatever font was default in your browser. This could be Times New Roman in Windows, Droid Serif on an Android, or Helvetica on a Kindle Touch, which is what I am using now.

While the spaces in the diagram seemed fine on my desktop, they are elongated on my Kindle and on my phone. Since I ran Chrome on both my desktop and phone, it seemed that the screen width was the important factor, not the browser. To confirm this, I changed the window size on my desktop, and when I made it narrow enough, the spaces in the diagram became elongated. More precisely, they were narrow but tall. It seems that the piece size shrank to fit the narrower screen, allowing the spaces to get narrower, but nothing happened to make the spaces shorter.

I temporarily undid the changes in the typography and checked the diagram for Chess and a Half again. When I made the window narrow enough, it still had elongated spaces. So, this problem appears to be unrelated to any changes I've made to the typography.

I just checked how a diagram table works in Game Courier, and it behaves differently when I narrow the screen. It does not change size at all, and it limits how much I can narrow the window. To make the window even narrower, I switched tabs. When I switched back, the Game Courier table for Chess was no smaller, but less of it appeared in the window. The way Game Courier fits diagrams on small screens is by resizing them to fit the screen, using information on the screen size that it has previously stored in cookies.

But right now, the spaces are elongated even if the window is full width or even full-screen!

I took a copy of the generated source for Chess and a Half, changed the height and width of each cell from 51px to 3vw, and each cell remained a square even when I made the window very narrow. Here is the test page I created. The vw unit is 1% of the view width. So, a vw of 3 is 3% of the view width. While a value of 3vw closely matches 51px on a wide screen desk monitor, it doesn't make the best use of the available space when the window gets narrower. I also tried a value of 5vw, and this looks a lot better in a narrow window.

That's good, but now the pieces are immovable.

That is due to it being a copy, not to any changes I made to the width and height.

EB Garamond looks better than Crimson Text. The latter has some miniscule artefacts around the letters that shouldn't be there.

Volkhov is too dark for the desktop, but being darker than Garamond aids legibility on my Kindle and on my phone. So, I have presently setup the CSS to use EB Garamond as the default body typeface and to use Volkhov when the screen becomes narrow enough to drop ads from both sides.

I have been working on improving the typography of the site today. If you need a specific font size, I suggest you use absolute values instead of relative values. Inspecting the generated source on one of your diagrams, it looks like you might have already done this. I saw a font size of 7px for each TD instead of xx-small.

I have indeed tried a lot of things, but no luck so far. The best explanation of the problem (extra margin below images) that I could find is here. It gives a number of possible solutions / work-arounds, (some of which also mentioned on stackoverflow.com) and I tried them all, but none of them has the slightest effect.

I had this problem of extra margin below images before, and the xx-smal font did ameliorate it (but still required the square size to be defined 3 pixels larger than the actual images, 53x53 for Alfaerie). But this work-around stopped working, and setting an absolute size of 7px doesn't make any difference. It seems completely ignored, as for a 7-px font the descenders should only be ~3px, the margin I already account for. But they are obviously much larger.

I would prefer to make the problem go away completely. But defining the images with an in-line style="display:block;" has no effect, and eather has the "float:left" or "vertical-align:top". (I tried on FireFox and Chrome.) I can live with the work-around of a small font. But I have no idea why that stopped working. What was changed? Did you define another DOCTYPE, or another size default font? All articles are suddely in a ridiculously large font.

I can try a negative margin under the images; testing locally it responded to that, and I could even have the images stick out under the cells. It would be tricky to find a margin size that works for all image sizes, and would be robust against future typography chages if I don't know what I am combatting here. Setting a fixed size of the page width doesn't seem a satisfactory solution. Anyway, setting a size for the cells never succeeded in making this problem goeas away: if the image (+added margin) is larger than the width I specify, it just expands the cell to fit the image, rather than clipping the image. Do you know a way to get around that?

[Edit]

Uh? I now changed the font in the <td> elements to xx-large, and this made the problem go away entirely. The images themselves have style="veritical-align:top", but in combination with font-size:xx-small that did not have the slightest effect.

Did you see my comment about using the vw unit instead of the px unit? That seems to be the solution.

Did you see my comment about using the vw unit instead of the px unit? That seems to be the solution.

As I understand the meaning of vw, this would make the size of the cells dependent on the size of the window of the client, while the piece images have a fixed size. That seems an infinitely worse problem than the one we are trying to solve. Of course you can get it right for one particular window size of one particular user, but everyone else would see crap, and even if the user to which it was tuned would size his window, his image would also be destroyed.

But I just had some success by setting font-size:xx-large . Which completely baffles me, as it is exactly the opposite of what I expect.

Tentative theory is that having a font size that is too small somehow prevents the normal work-arounds for making the bottom margin of images go away from working. (Which should be considered a browser bug, but it is strange that both FireFox and Chrome exhibit it.) Your typography change must have done something that brought us into the realm where things do not work as advertized. When you undid that change, I had already defined the font-size as an absolute 7px, which is very small, and thus also in the broken realm, and no longer affected by typography. With font-size:xx-large we now apparently have a font size where the vertical-align:top trick does work.

As I understand the meaning of vw, this would make the size of the cells dependent on the size of the window of the client, while the piece images have a fixed size. 

No, piece images shrink when the width narrows. In the CSS, all images have max-width set to 100% and height set to auto.