Comments/Ratings for a Single Item

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.

I now have a combination of fonts I am happy with for the main body and headings. The body text will be either EB Garamond for wide screens or Volkhov for narrow screens. Both are good looking serif fonts that bear some resemblance to each other. For example, both let the capital M stretch its legs, and various other letters bear a close enough resemblance to each other. The main difference between them is in their color, which is a typography term referring to how dark or light a font is. To illustrate what this means, bold text is normally darker than regular text. Garamond is a thin, old style font. It has class and looks good when it has enough space. Volkhov appears too dark on a full-size monitor, but being darker makes it very legible on a small mobile screen. So it gets used there in place of Garamond.

The first and second level headings use Germania One. This is a dark Roman typeface that has a medieval look to it without actually being Blackletter or Fraktur. The medieval look seems suitable for Chess, and being a Roman typeface, it is more legible than Blackletter or Fraktur would be. This font is more eye-catching than a sans-serif, yet it has enough elements of a sans-serif to contrast well with the serif body text.

The third through sixth headings use Francois One. This is a dark gothic/grotesque sans-serif that matches Germania One in color. This match in color allows it to fit well with Germania One. But being a sans-serif helps it distinguish the lower headings from the top headings, and since the lower headings use smaller type, being sans-serif helps make it more legible at the smaller sizes it is used in.

Well, I don't know about others, but if I would rate last-week's style as 8-out-of-10, the way it looks now doesn't even qualify as 5-out-of-10.

• Text font: too large, low information density, needs lots of scrolling
• Text font: too light, looks vague
• Headers: awful typeface. Only one notch above using Hebrew.

I don't understand.  The text size hasn't changed at all for me.  The font might be different, I'm not sure, I'm seeing no obvious changes.  And the text doesn't look any lighter either...

You need to refresh your cache, Greg.

I am using Google fonts, because this allows me to use the same fonts on all devices, no matter what fonts they may have installed. I am currently trying out Radley as a body text instead of EB Garamond. It is darker than Garamond, which makes it more legible, but it is still not as dark as Volkhov, which is a bit too much on a desktop. It appears to be a transitional font, which means it combines elements of old style with the thick/thin line contrasts of modern. Its character designs resemble Volkhov, and it differs from it mainly by being lighter.

I'm currently trying out Libre Baskerville with a font-size of 1vw. A font-size of 1.25 vw made Garamond about the same size as I had it with 20px, but using the vw unit would keep it at about the same size if I changed the screen resolution. Since Libre Baskerville has bigger characters, I dropped it to 1vw. Using vw units should keep the text from appearing larger on laptops than it does on larger monitors.

Using the vw unit made the text miniscule on my phone. So that's not a viable option.

Presently, it uses 20px EB Garamond for the widest screens, 18px Radly for narrower screens like you would find on a laptop, and 16px Volkhov on mobile devices.

I'm checking things out on the laptop right now, and EB Garamond looks better than Radley on the laptop.

I have replaced Radley with Lusitana. Like Radley, its color is lighter than Volkhov and darker than EB Garamond. Unlike Radley, it looks more like Volkhov and Garamond. I find that on the bright screen of my desktop monitor, EB Garamond is more comfortable, but on the darker screen of my laptop, Lusitana is more comfortable. So, it now uses 20px EB Garamond on the widest screens, 18px Lusitana on laptop wide screens, and 16px Volkhov on mobile devices. If you're on a desktop with a wide enough monitor, you can see each of these by narrowing your browser window.

That's how things will remain for the rest of the night. As a reminder, this only affects global.css so far. So you have to go to a different page than the comments page to see what it looks like. Firefox has an extension for reloading a page with an empty cache, but Chrome does not. For Chrome, you may need to go to settings and empty your cache before you can see the changes.