I've been working on redesigning the headings so that one can intuitively tell one level from another. Besides decreasing in size, they also differ in style.

Heading One: Centered

Heading Two: Double Underlined

I had originally just used underlining, but I changed it to double underlining to avoid confusion with links, which are normally underlined with a single line.

Heading Three: Normal

Heading Four: Italics

Heading Five: Small-Caps with Overline and Underline

Because small-caps are more compact, they are used for lower headings rather than for higher ones. The use of lines parallels the use of lines in the second heading. Because small-caps all have the same height, words have a more straight appearance, which works better with the overline.

Heading Six: Small-Caps

Like the change from heading two to heading three, heading six omits the lines used in the heading just above it.

I learned last night about a new type of font file called a Variable font. This includes all the styles for a typeface within a single file. Previously, each style of a typeface would get its own font file. Since the typeface used for the main body of this site was now available as a Variable font, I updated it. But while I was at Google Fonts today, I decided to check out other fonts.

I ended up replacing Lora with Literata. This typeface was designed for use with Google Play Books, and its basically the Google counterpart to Amazon's Bookerly. I liked it better than Lora for a few reasons.

1. It looks cleaner at small sizes. At the size of text used on the website, some characters in Lora have a bit of a blur to them, because they are being anti-aliased to look good at a smaller size than they were actually designed for. At the same size, characters in Literata lack this blur.
2. Its lowercase letters have a lower X-height, which creates more contrast between upper and lowercase letters.
3. Although its Q does reach underneath the next letter, it's only by a little bit, and I otherwise prefer the look of its Q, whose curved tail is similar to the one used in Century Schoolbook.

I also replaced FreeMono with Courier Prime, because with Game Courier on the site, I wanted a Courier monospace font. I have begun using it instead of the sans serif font for headings.

While I did try some other sans serif fonts, I stuck with Noto Sans. Presently, Literata is the only Variable font on the site. The others use individual font files for each style.

This site now uses Lora for body text and Noto Sans for header and menu text. These are both free web fonts available through Google fonts. I purged the global CSS files from the cache, which allowed me to see changes to them on mobile devices. I increased the font size on mobile devices to 18px, matching what it is on desktops, and I set the size of blockquote text to 16px, which seems a bit more legible than using smaller.

For now, I have gone back to using Average, Kurale, and Volkhov for the body text. I'm looking for a single serif font with its own italic style that I could use for the body text on both desktop and mobile. When I have the time, I'll try out Lora, which is by the same designer as Volkhov.

On my phone, Noto Serif is looking better than Volkhov.

I created a test file and previewed the Noto fonts in action. They look fine on mobile, which is not too surprising, since they are based on the Droid fonts, which were designed for mobile devices. On the desktop, Noto Sans looks fine, but Noto Serif looks a little too large. As I was looking over the sans-serif fonts, I settled on Noto Sans, because it put bars on the capital I and generally looked good. It is also part of the Noto series, which has been designed to support more languages than any other font. I thought it would be nice to use matching serif and sans-serif fonts, and Noto Serif is a good font in many respects. It also includes a real italic. The Average font came with only one style, and I was using the Kurale font to handle its italics, since it's a more italic looking font that otherwise resembles Average. When it comes to Chinese characters, Noto Serif looks better than Average, though I still like how Average+Kurale looks on the desktop, and I still like how Volkhov looks on mobile. I'll go with Noto Serif for now and continue looking at other fonts.

I installed Opera to my Kindle Fire, but it didn't help. It is still showing Average, Kurale, Volkhov, and Catamaran instead of the Noto fonts. I may be dealing with caching at the DNS level. I could try creating some test files that don't use the cached files.

I'm trying out Noto Sans and Noto Serif as the two main fonts used by the site. They look fine on my desktop, but when I have tried my Kindle Fire and my iPad, I have been unable to reload the CSS to see what these look like on these devices. While my desktop browers make this easy, the same browsers on mobile are less functional. Maybe I'll try downloading a new brower I haven't used before.

For the sake of consistency, I'm looking into using a Google web font for the menu instead of fonts on computers. I previously had it set up so that on my desktop, it would use Segoe UI, which comes with Windows. I checked out some Google web fonts today, and I narrowed the choice down to Noto Sans, Open Sans, Roboto, Signika, Source Sans Pro, and Tauri. Here is a graphic image showing all of these plus Segoe UI being used for the menu for the homepage. I wrote the name of each in Segoe UI with the graphics program.

I have learned from Responsive Font Size with CSS that 

most computer screens have similar pixel densities and modern mobile devices adjust by reporting viewports smaller than their real resolution to make up for their high pixel densities. For example, some 1920x1080px phones have a viewport size of just 640x360. What this means is that 16px text takes much more than 16 real pixels, 48px in fact (16*1920/640). 

What this means for me is that phones with high resolutions should still display Volkov at appropriate sizes, and I may as well keep the cutoff at 960. On my 10.1 inch tablet, I should still expect to see Average in landscape and Volkhov in portrait.

The original cutoffs were based on how much room was available for the sidebar ads, and when I added Google fonts, I used the same cutoffs. It is hard to pick where the cutoff should be. On the one hand, I want it to use Volkhov on phones, and the greatest width I have found listed for a phone is 1920, which is actually wider than my own desktop monitor, which is only 1680. Lower phone widths I've found include 1334, 1136, and 960. 960 is about where the change feels comfortable on my desktop, and that is where I have now set it, but a larger value might be more suitable on phones with high resolution displays. I could try testing width in units of inches or centimeters, but I would still be working in the dark concerning how the display would look on phones I don't own.

I noticed that you switch to a denser font (almost like boldface) when the viewport width shrinks below a certain value. I can see this is useful, because at low resolution you need a deser font to maintain visibility. But it doesn't seem to happen in a logical way: When I gradually narrow the window, the width of the article part goes through a kind of sawtooth motion, because the ASIDEs are switched off one by one. The switch to the denser font now occurs when the last ASIDE (the narrower "rightcol") closes. But at that point there are some 240 more pixels in the ARTICLE width then there were just before that ASIDE closed. So there isn't really any reason to switch to the denser font yet. I would expect this to occur only after the viewport is narrowed so much that even without ASIDEs the width is forced smaller than it ever was with any ASIDE open.

I'm trying to use a different font for italics on wide displays that use Average. Smaller displays using Volkhov will still use Volkhov. Here is Roman type:

ABCDEFGHJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890?

Here is italics:

ABCDEFGHJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890?

I have been thinking of doing something along those lines. I have plans to replace the multiple commenting pages with a unified page that responds differently to different form data. This is basically how other scripts I've made work. This will make it easier to include a Revise button alongside a Submit button. As it is now, these two buttons would need completely separate forms, since they would call different scripts. With a unified script, they would both call the same script, and that one script would handle each button differently.

There's an issue with the commenting page (commentonitem.php).  When you submit, it takes you to a preview page that says to click the back button if you want to make a change, but when you go back, the text box is blank.  I'm not sure why this would be the case.  I suspected it had to do with the CKEditor, but that turns out not to be the case.  I commented out the script line that replaces the edit box with CKEditor just to text adn the standard text box has this problem too.

I'm not sure how to fix this issue, but as an alternative, I think I can add a Revise button next to the Submit button that calls up the commentonitem.php page again.  This might be superior anyway.  Going back doesn't require a page load, but I think use of the browser's back button is discouraged in modern web apps.

The text does not appear in all italics on the iPad version of Safari. If it is limited to Safari on Windows, I can live with that, since Safari is probably one of the least popular browsers on Windows. But if this also happens with Safari on the Macintosh, that is more serious, and I will probably have to precede Volkhov with an appropriate Macintosh system font. I can't test this myself, since I don't have a Macintosh. If anyone out there does have a Macintosh, please let me know if all the serif text appears in italics when you narrow the window enough for the sidebar ads to disappear.

I fixed some ad alignment problems with Safari for Windows. One typography problem I noticed with it, which I've been unable to fix, is that when it uses the Volkhov font, all the text is in italics. Does anyone else experience this with Safari?

I just installed Safari for Windows, since at least some of the browsers that I saw a difference in on Android were Safari-based. Although there is no difference in which word each each line ends with, I could detect small differences by taking a screenshot and using a veritical line in a graphics program as a guide. Unfortunately, optimizeLegibility and geometricPrecision are both turning on ligatures in Safari.

I tested browsers on my two Android phones, but I waited until I turned on my computer to report the results. On my large Android 6 Marshmellow phone, I tested Chrome, Firefox, Boat Browser, and the default Android Browser, and I saw no difference between any of the text samples with any of them. On my small Android 4.1.2. Jelly Bean phone, I tested Chrome, Firefox, Boat Browser, Dolphin, Maxthon, and the default Android Browser. Of these, I saw a difference between the text samples in the Android browser, in Boat Browser, and in Maxthon, but I did not see any difference in Chrome, Firefox, or Dolphin. For reference, my Thrive runs Android 4.0.4. Ice Cream Sandwich.

I am seeing the same effect with Boat Browser, which uses Droid Serif instead of the Google fonts. I also noticed that words like main and spain are tighter with oL or gP.

Using the Android Browser on my Toshiba Thrive tablet, I do see a difference. Less text fits on the line with optimizeSpeed than with the other two. For the latter two, the spacing is narrowed between some letters, such as the two l's in will, the two f's in different, the ow in brown, the ov in over, or the whole word jiffy. I have not noticed any difference between the effects of optimizeLegibility and geometricPrecision.

It's just a test, Greg. I learned about a new CSS property, and I was testing what effect its different values would have. For the fonts I chose, they appear to have none.

If the three paragraphs are supposed to appear different, either they don't or it's too subtle to see.

I'm starting to worry about you, dude.  You migth be getting a little OCD with the font stuff :)