Getting MathML to render properly in Chrome, Chromium and Brave
The other day I posted about adding mathematical typesetting to this blog using markdown2, LaTeX and MathML. One problem that remained at the end of that was that it looked a bit rubbish; in particular, the brackets surrounding matrices were just one line high, albeit centred, like this:
...rather than stretched to the height of the matrix, like this example from KaTex:
After posting that, I discovered that the problem only existed in Chromium-based browsers. I saw it in Chromium, Chrome and Brave on Android and Linux, but in Firefox on Linux, and on Safari on an iPhone, it rendered perfectly well.
Guided by the answers to this inexplicably-quiet Stack Overflow question,
I discovered that the prolem is the math fonts available on Chromium-based browsers.
Mathematical notation, understandably, needs specialised fonts. Firefox and Safari
either have these pre-installed, or do something clever to adapt the fonts you
are using (I suspect the former, but Firefox developer tools told me that it was
using my default body text font for <math>
elements). Chromium-based browsers
do not, so you need to provide one in your CSS.
Using Frédéric Wang's MathML font test page,
I decided I wanted to use the STIX font. It was a bit tricky to find a downloadable
OTF file (you specifically need the "math" variant of the font -- in the same way
as you might find -italic
and -bold
files to download, you can find -math
ones) but I eventually found a link on this MDN page.
I put the .otf
file in my font assets directory, then added the appropriate stuff
to my CSS -- a font face definition:
@font-face {
font-family: 'STIX-Two-Math';
src: url('/fonts/STIXTwoMath-Regular.otf') format('opentype');
}
...and a clause saying it should be used for <math>
tags:
math {
font-family: STIX-Two-Math;
font-size: larger;
}
The larger
font size is because by default it was rendering about one third of
the height of my body text -- not completely happy about that, as it feels like an
ad-hoc hack, but it will do for now.
Anyway, mathemetical stuff now renders pretty well! Here's the matrix from above, using my new styling:
I hope that's useful for anyone else hitting the same problem.
[Update: because RSS readers don't load the CSS, the bad rendering still shows up in NewsBlur's Android app, which I imagine must be using Chrome under the hood for its rendering. Other RSS readers are probably the same :-(]
Adding mathematical typesetting to the blog
I've spent a little time over the weekend adding the ability to post stuff in mathematical notation on this blog. For example:
It should render OK in any browser released after early 2023; I suspect that many RSS readers won't be able to handle it right now, but that will hopefully change over time. [Update: my own favourite, NewsBlur, handles it perfectly!]
Here's why I wanted to do that, and how I did it.
Blog design update
I was recently reading some discussions on Twitter (I've managed to lose the links, sadly) where people were debating why sites have dark mode. One story that I liked went like this:
Back in the late 80s and 90s, computer monitors were CRTs. These were pretty bright, so people would avoid white backgrounds. For example, consider the light-blue-on-dark-blue colour scheme of the Commodore 64. The only exception I can remember is the classic Mac, which was black on a white background -- and I think I remember having to turn the brightness of our family SE-30 down to make it less glaring.
When the Web came along in the early 90s, non-white backgrounds were still the norm -- check out the screenshot of the original Mosaic browser on this page.
But then, starting around 2000 or so, we all started switching to flat-panel displays. These had huge advantages -- no longer did your monitor have to be deeper and use up more desk space just to have a larger viewable size. And they used less power and were more portable. They had one problem, though -- they were a bit dim compared to CRTs. But that was fine; designers adapted, and black-on-white became common, because it worked, wasn't too bright, and mirrored the ink-on-paper aesthetic that made sense as more and more people came online.
Since then, it's all changed. Modern LCDs and OLEDs are super-bright again. But, or so the story goes, design hasn't updated yet. Instead, people are used to black on white -- and those that find it rather like having a light being shone straight in their face ask for dark mode to make it all better again.
As I said, this is just a story that someone told on Twitter -- but the sequence of events matches what I remember in terms of tech and design. And it certainly made me think that my own site's black-on-white colour scheme was indeed pretty glaring.
So all of this is a rather meandering introduction to the fact that I've changed the design here. The black-on-parchment colour scheme for the content is actually a bit of a throwback to the first website I wrote back in 1994 (running on httpd on my PC in my college bedroom). In fact, probably the rest of the design echoes that too, but it's all in modern HTML with responsive CSS, with the few JavaScript bits ported from raw JS to htmx.
Feedback welcome! In particular, I'd love to hear about accessibility issues or stuff that's just plain broken on particular systems -- I've checked on my phone, in various widths on Chrome (with and without the developer console "mobile emulation" mode enabled) and on Sara's iPhone, but I would not be surprised if there are some configurations where it just doesn't work.
A new beginning
If you're reading this, you're seeing my new and shiny blog :-)
Blogging has been quite light here over the last few years; as PythonAnywhere has taken off, life has become ever-busier, so, less time to post.
But I also feel like one of the reasons that I've not been posting has been that I was using a Wordpress blog. Not that there's anything wrong with Wordpress, mind, but every time I logged on to it there were a pile of security updates to download and install, which was very demotivating. So often I'd think, "oh, I should post about that" but just never get round to it.
(There's also the faint embarrassment factor of running one of the most popular Python hosting platforms, and having a blog based on PHP...)
For a long time I'd been vaguely planning to switch over to some kind of static site generator like Hugo or Sphinx. They are both well-regarded, but our experience in porting the PythonAnywhere blog over to the former gave me some pause; while Hugo was really configurable, it always seemed to be really hard to configure it the specific way we wanted.
And then I thought, wait a minute. I'm meant to be a programmer. How hard can it be to write a simple static site generator?
That's the kind of sentence that feels like it should be followed by, "it was actually really hard". But it wasn't, because all of the pieces have been coded by generous people already and it was just a case of plugging them together.
With the help of wpparser to parse an export of my old blog (which I fed into a little script that spat out the articles in a Hugo-like format) and then markdown2 to format markdown-based posts, Pygments to highlight my code blocks, and then Jinja2 to let me bung the results in some templates, and feedgen to write out an RSS file, it was pretty easy to put together something that replicated the URL structure of the old blog.
To be honest, I've spent significantly more time fiddling with the CSS to make it all look pretty. I doubt that bit shows.
Anyway, now I have something where I can knock together a quick post in markdown, run a command, and have it published. Welcome to my new blog!
I'll be scanning through the old posts over the coming days and fixing any formatting issues I find.
The next step will be to work out some way of bringing the comments
over, as they (of course) don't really fit in with the whole "static site" side of
things. I have some ideas, though... But if you'd like to leave a comment in the meantime, @ me on Twitter.
(Update 2021-02-22: comments are back!)
Clicking the tabs from left to right
It looks like visitors to the Resolver Systems website are predisposed to clicking through the tabs at the top of the page, from left to right. Does anyone else see this kind of thing?
The figures I'm using are from Google Analytics, which is based on JavaScript embedded in the page and run in the browser, so I don't think it's caused by bots/crawlers just clicking each of the tabs in turn because they appear in the page source code in that order -- and in addition, if it were a result of automated systems, you'd expect a consistent bias, whereas it's actually quite variable.
Here's the full dataset. Each line below shows a Google Analytics overlay, which tells you for each selected tab what percentage of people clicked on each of the other tabs during July 2009:
It looks like we managed to break tracking of access to our "About us" page for that month, so I put the results for that tab aside and did a bit of simple statistical analysis (in Resolver One, naturally) on the remaining data. The results:
The "from" tab is top to bottom, the "to" tab is left to right -- so, the chance of someone who is currently on the "Buy" tab clicking "Download" is 29%. The average chance of someone clicking on a given tab across all sources, and the standard deviation of those figures, are summarised at the bottom. Each cell is coloured based on how many standard deviations from the average it lies -- if it's more popular than it normally is, it appears red, if it's less popular it's green. The intensity of the red/green is based on how much more/less popular it is.
I think there's a very clear pattern -- the line of red starting at the "Home tab to Buy tab" cell, and going down and to the right to the "Screencasts tab to Get help tab" cell. That indicates that people are significantly more likely to click on a tab when it's the one to the right of the one they're currently looking at.
You can download the analysis spreadsheet from here, and if you don't already
have a copy of Resolver One to run it on (shame on you ;-), you can get an eval
version here.
This is interesting -- is it just our visitors, or have other people seen similar results?