PR proposal for font-size breakpoints

[danielfdickinson]

I've got some CSS I use for increasing the font size as the screen resolution gets larger (because often higher resolution means higher DPI, and I'm not aware of a working way to check DPI using only CSS, especially on 2K and 4K displays).

In addition, this enhances the experience for those with low vision (even if just because one is tired or one's glasses need cleaning).

The proposed CSS (I would add this in the appropriate assets/css files, if the idea gets accepted) is:

@media not speech {
    body {
        font-size: 16px;
    }
}

@media screen and (min-width: 28em) {
    body {
        font-size: 17px;
    }
}

@media screen and (min-width: 36em) {
    body {
        font-size: 18px;
    }
}

@media screen and (min-width: 48em) {
    body {
        font-size: 19px;
    }
}

@media screen and (min-width: 56em) {
    body {
        font-size: 20px;
    }
}

@media screen and (min-width: 64em) {
    body {
        font-size: 21px;
    }
}

In addition, in order to keep the nav consistent with the rest of the page, I suggest:

.gdoc-nav {
    font-size: 1rem;
}

I already use this for myself via the custom CSS hook, but I think it might be useful for others as well.

[xoxys]

Thanks for your request. In general, I'm not against such a change, but I would like to understand it a bit more. Where does the min-width values are coming from? Is there some kind of best practice to use exactly this break-points? Do you have some screenshots or a way to test the issue? On my 4k ThinkPad display it looks good already (using the UI scaling of the OS of course).

[danielfdickinson]

Before I get to the questions, I will note that that is some years old as I discovered with the same proposal on another theme (adityatelange/hugo-PaperMod#496) there are now better ways to achieve the same thing so I will be working on a more modern version and get back to you.

• The font-sizes and min-width values came from my own testing. I am not aware of a best practice of a particular font-size at a particular breakpoint.
• I will include screenshots when I update this to newer CSS.
• Before I do any of that, though, I will double-check how well (or not) geekdoc zooms; my main concern is the accessibility of the theme for those with vision impairment (even if only due to fatigue or glasses that need to be cleaned[1]) and many themes do not zoom well.
• I think having a larger font size (scaled by viewport) by default is better, but with the updates to CSS it looks like themes can now be designed to include this as a parameter instead of being hard-coded.

Upshot is I'm still learning the best way to do this for 2021+ and will be creating an improved proposal (hopefully soon).

[1] Cleaning glasses without ruining them over time requires special cloth and cleaner; just wiping with a shirt or tissue deteriorates the quality of vision offered by the lens over time, for those wondering "why not just clean the glasses, then?".

[danielfdickinson]

I hope you don't mind if I do this in increments, over time.

The following are using the default geekDoc font settings.

Here is a screenshot on Chrome-based Edge on Windows[1] on a 2K display when using the Microsoft 'recommended' 100% (no) scaling of the display (I do have a larger UI text than the default, via the accessibility options).

[1] Windows 10 (at least) is a bit of mess as far as dealing with screen sizes, especially if one has multiple monitors that have different differing pixel density (DPI). Old programs appear (including 'Control Panel' and such) far too small if one doesn't use whole screen scaling, but if one uses whole screen scaling a couple of things are true:

• 'Modern' Windows apps tend to have too large fonts, while old are comfortable
• Edge and other Gecko-based browsers end up with larger pixels (but smoothed, so not pixelated) for fonts effectively reducing the resolution of the screen (but the fonts are larger).
  Actually, it's worse than that, but this isn't meant to be a rant about Windows display handling.

Here is a the same page on a 1440 pixel (no double-density) display at recommended 100% scaling, with the same 'Easy of Access' increased UI font.

As you can see, that looks ok.

The issues start to occur with a pixel width of greater than (approximately) 1376px. A 2K display with 150% scaling doesn't run into the issue because its effective web font resolution doesn't reach the 1376px resolution (but the fonts are larger because of scaling).

Here is the same 1440 pixel display without increasing UI font size via 'Ease of Access':

And finally the 2K display without the UI font increase via 'Ease of Access':

[danielfdickinson]

And here is my work in progress for updated CSS:

:root {
    --min-font-size: 16px;
    --max-font-size: 22px;
    --body-font-multiplier: 1;
    --body-font-size: 1rem;
    --main-width: 75vw;
    --nav-width: 23vw;
    --main-width-in-chars: 55;
}
/* Fall back base font-size for old browsers */
html {
    font-size: 16px;
}

@media screen and (min-width: 1376px) {
    html {
        font-size: 17px;
    }
}

@media screen and (min-width: 1536px) {
    html {
        font-size: 19px;
    }
}
@media screen and (min-width: 1600px) {
    html {
        font-size: 20px;
    }
}

@media screen and (min-width: 1728px) {
    html {
        font-size: 21px;
    }
}

@media screen and (min-width: 1880px) {
    html {
        font-size: 23px;
    }
}

@media screen and (min-width: 2048px) {
    html {
        font-size:25px;
    }
}

@media screen and (min-width: 3172px) {
    html {
        font-size:32px;
    }
}

body {
    font-size: 1.125rem;
}
/* End of Fall back base font-size for old browsers */

/* Set the base font-size using the method supported by the browser
   1. clamp & calc
   2. min, max, and calc
   3. calc plus media query
*/
@supports (font-size: clamp(var(--min-font-size), calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier))), var(--max-font-size))) {
    html {
        font-size: clamp(var(--min-font-size), calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier))), var(--max-font-size));
    }
}

@supports ((font-size: min(max(var(--min-font-size), calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier)))), var(--max-font-size))) and (not (font-size: clamp(var(--min-font-size), calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier))), var(--max-font-size))))) {
    html {
        font-size: min(max(var(--min-font-size), calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier)))), var(--max-font-size));
    }
}

@supports ((font-size: calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier)))) and (not (font-size: min(max(var(--min-font-size), calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier)))), var(--max-font-size)))) and (not (font-size: clamp(var(--min-font-size), calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier))), var(--max-font-size))))) {
    html {
        font-size: calc(var(--main-width) / (var(--main-width-in-chars) * var(--body-font-multiplier)));
    }
    @media screen and (min-width: 3172px) {
        html {
            font-size: var(--max-font-size);
        }
    }
}
/* End Set the base font-size using the method supported by the browser */

/* Override the body font-size via var, if supported 
@supports (font-size: var(--body-font-size)) {
    body {
        font-size: var(--body-font-size);
        line-height: 1.6;
    }
}
/* End Override the body font-size via var, if supported */


.container {
    max-width: unset;
    width: 100vw;
}

.gdoc-page {
    min-width: 20rem;
    max-width: var(--main-width);
}

.gdoc-nav {
    flex: 0 0 var(--nav-width);
    font-size: 1rem;
}

[danielfdickinson]

I've looked at the situation some more, and I think that most people using scaled displays, so that this becomes a non-issue. So, I'm abandoning this concept. Thank you for your thoughts.

[xoxys]

I think so too, and the CSS to fix it has gotten really complex, which makes me think about it a bit more. Nevertheless, thanks again for all the effort!