Improve readability

[Kellegram]

Hi, first of all, great write-up. I do want to mention however that the theme of the site could be improved for readability. With popularity of dark mode, choosing dark colors could be the obvious first step, however it's not best for everyone of course. I recommend opening the website in reading mode via firefox or other browser, they offer different colors and formatting to make it more accessible for everyone, including those with reading problems. I did a quick few changes via inspector to see how it would look otherwise. The font is not variable so I couldn't set the text to be semi-bold (to make it look less wiry in certain situations). Using a more readable font like manrope could be great for accessibility.

Here is what I got by using colors from my website as well as increasing font-size by 10% (to 1.1em) of parent as well as increasing header4 size by 20% (1.2em) as well as content width by 10rem: https://i.imgur.com/NBCK4XU.png

A change of font could improve this, here are some example using firefox reading mode:

• Dark version: https://i.imgur.com/ZQMXLZX.png
• Sepia: https://i.imgur.com/5VGR3tJ.png
• Dark with more content width (still within decent eye travel): https://i.imgur.com/R4C0n9I.png

I would love to create a Pull Request to help, however I am not sure where is the source of css for this project, I am unfamiliar with the process used to build this page. I tried running a lighthouse Audit via web.dev/measure but it gives a network error on your page. I ran it via Edge devtools instead and while the score is overall pretty good, including for accessibility, it does fail somewhat on contrast ratios.

Themes are mostly subjective of course but it seems like we are moving into dark mode era, so perhaps it's something to consider, but at the very least using some kind of sepia colors or a theme like Solarized could vastly improve the experience for folk with very bright screens, people working at night, people with sensitive eyes, etc. Something in-between light and dark mode is always a good balance assuming good contrast ratios are maintained.

The page is almost missing meta description which in turn would give it a worse pageRank score and will fail to display embeds that can summarise the content of the page. This is mostly an SEO issue but worth noting.

[fennecJ]

Hi @Kellegram , thanks for informing us about themes and SEO issue.
Currently the css file is generated automatically via make4ht with a configuration
file html.cfg , and you can check css file in branch gh-pages.

See #20, #43, #45 for css related PR.

[Kellegram]

I see, I will take a look at those.

[Kellegram]

@fennecJ Hi sorry, got busy with unrelated development. I took a look at the cfg and also the result of the generation. The website scores quite poorly on performance, which is unusual for plain text sites, I am unfamiliar with make4ht, but on mobile especially my phone seems to struggle to load the page. Making the website dark would be a pain due to code syntax highlight, but making the website sepia and ofc make the changes to sizing like I proposed should still be a big improvement, so i will get on pull requesting that so that you can take a look and judge it.

[jserv]

After #96, the text with hyperlinks would look slightly larger than plain text, at least in Chrome web browser. Is there any effective tweak to make all text more consistent?

[Kellegram]

After #96, the text with hyperlinks would look slightly larger than plain text, at least in Chrome web browser. Is there any effective tweak to make all text more consistent?

They are set to have the same scaling, which means there is manual size set for them elsewhere. All i can really understand is the html.cfg, anything else done by make4ht I don't really get. I set both p and a to 1.2em which means 120% of parent. So the parent for a has bigger size set in pixels than p and that does not happen in the html.cfg. I will try and figure out where this happens, unless you know. Ideally the size per device size should be 100% consistent when it comes to pixels and only modified using em. It's common for mobile to have base size of 16px, 18-20 for laptops/tablets and 22 for desktop, roughly. For that one can use media queries and the entire site will adapt accordingly thanks to using responsive units.

One workaround would be to set a smaller em value for a in html.cfg, but that is a workaround, not a solution.

[Kellegram]

I think using rem instead of em might work here, because the LaTeX conversion seems to apply css to every single paragraph separately, so using the parent element causes inconsistencies. Using rem instead will use the root element and that seems to make it consistent and it computes the same size value. Will investigate a bit more.

Edit: Just verified that using rem does indeed work and make the p and a consistent. Will PR for now so the document looks clean.
Edit: See #100

[Kellegram]

Going back to Manrope, there is two ways to add it. We can ofc access it remotely or we can serve it locally. I think the latter is ideal. While the font would not be grabbed from a CDN, using remote fonts comes with other potential problems, especially since I think Manrope is hosted on google fonts and people might block that. If you are interested in using Manrope let me know, I would just need to figure out where the font file should be located. Based on what I can see it would be simply located at the root in the gh-pages branch correct?

[fennecJ]

I think it would be good to use Manrope for our page.
To put the font file in the root of gh-pages branch, you have to configure the html target in Makefile.

[Kellegram]

Alright, I will try to do it then, do make sure I do it right though, as I am kind of guessing how this is supposed to be done based on current contents of the makefile.

[Kellegram]

As far as I understand, the OFL license does not require crediting, or rather including full license text, although since we are adding the font locally instead of remotely, the font file is distributed, so I am unsure how to interpret the OFL license in this case. Worst case scenario, the license text has to be included somewhere, OFL does not require attribution.

Do be sure I did it correctly, this is still very unfamiliar to me, should the @ symbol be escaped? It might be better to set manrope in html/body instead of p/a as I think the pre tag forces monospace font to be used, so I may have been wrong in assuming that manrope would have overwritten the font in codeblocks, although that would be easy to change if that's the case, I will test that soon, need to leave for the moment.

[fennecJ]

Do be sure I did it correctly, this is still very unfamiliar to me, should the @ symbol be escaped?
It's ok to use @ in the configuration file.

By the way, I just noticed that explorer cannot load the font file correctly due to security reason (it prevents you from reading parent directory, so you cannot access the file linked to parent directory's file)
Perhaps we need to copy the font file into /html.

As for the license issue, let me consult @jserv

[Kellegram]

Huh, I thought I made it go to html/ but maybe I should have put those lines in the html: section instead of creating font: in the makefile, that's probably what's wrong, or maybe the symlink makes no sense and it should just be moved there?

[fennecJ]

I have tested if explore can read the soft linked font file well, and just as I mentioned before.
It seems like explore cannot read parent directory without permission.
So I think even if you put those after html: target, it might still fail to load the font file.

[Kellegram]

I see. I guess I will modify it to copy it there then.

[Kellegram]

Ok, now that new font and some styling is added, it exposed a problem that I guess wasn't visible before since the styling was basically almost browser default.

This screenshot shows the problem: https://i.imgur.com/DfCYBhA.png
I imagine this is a result of the latex to html conversion, something must be wrong with the configuration, but that I don't know how to help with, styling html would technically do something but it would be bad practice and would just cause a different problem, so probably a separate issue to file. I think this issue can now be closed, this is all I wanted to discuss readability wise, I think I will open an issue about missing meta tags, as they are significantly worsening SEO/PageRank score.