Browsers and the relative size of their default monospace fonts
One of the unusual things about Wandering Thoughts and all of my web stuff is that it's almost completely unstyled. In particular, I don't try to specify HTML fonts or HTML font sizes; I leave it entirely up to your browser, on the assumption that your browser knows more about good typography on your system than I do. However, this doesn't mean that my entries live in a pure world of semantic content, because in practice you can't divorce content from its presentation; how Wandering Thoughts looks affects what and how I write. One of the consequences of this is that I end up making some tacit assumptions about how browsers handle default fonts, assumptions that may no longer be correct (if they ever were).
Following a convention that I believe I coped from Unix manpages, I often write entries that intermix normal non-monospaced text with bits of monospaced text, which I use for a whole variety of things ranging from code snippets through Unix commands and filenames or just things I intend as literal text. This is a reasonably common convention in general, but when I use it I'm implicitly relying on browsers rendering normal text and monospaced text in something that is the same size or reasonably close to it. If a monospaced word is either tiny or gigantic compared to the normal text around it, the two no longer combine together well and any number of my entries are going to look weird (or be hard to read).
Unfortunately, it increasingly seems like browsers are not doing this and that they often have their default monospaced font be clearly smaller than their normal text font, sometimes noticeably so. This is of course platform dependent, and I think that common platforms still have the two fonts sufficiently close together in size that my entries don't look glaringly wrong. But I don't know how long that will last or how true it is for people who've tried to change their browser's default size (to make it either bigger or smaller).
If mixing normal text and monospaced text is increasingly risky, this is going to affect what I do here on Wandering Thoughts in some way or another. Most likely I will have to start moving away from mixing monospaced words into my regular paragraphs and confine them to their own out of line sections.
(This is a good part of why I care about Firefox's peculiar handling of font choice preferences. By default Firefox's monospaced font size is too small for me, especially once I adjust the size of its regular font.)
As a side note, this isn't just a browser issue, unless you take an expansive view of browsers. I also run into this in my syndication feed reader of choice, which of course also has to render HTML and also has to chose default sizes for normal and monospaced fonts. Compounding the issue, these programs often give you less control over fonts and HTML rendering in general than browsers do.
Peering into the depths of (presumed) website vulnerability probing
One of the unusual things that DWiki (the software behind here) does
is that it rejects HTTP GET requests with unknown query parameters
and logs them. Usually what this reports is yet another thing using
yet another query parameter for analytics tracking, like Facebook
and their '
fbclid=...' parameter (cf), which is a good
part of why I no longer recommend being cautious in your web
app. But every so often something else
turns up, something that looks a lot like people probing for
vulnerable web applications.
Recently, I've seen moderate number of requests here with some interesting invalid query parameters tacked on the end, for example:
The bad query parameters are the 'mid=qna&act=dispBoardWrite' bit.
Unlike normal browsers following links with bad query parameters, the IPs requesting these URLs don't go on to request my CSS or any other resources (such as a site favicon). The direct requests tend to have HTTP Referers of other pages here, and sometimes there are POST requests for URLs like '/~cks/space/blog/tech/index.php' with a HTTP Referer of a page here that includes these query parameters.
Some casual Internet searches suggest that this may be an attempt
to explode something called 'XPress Engine', which is apparently a
Korean PHP based CMS (cf and
related pages). On the other hand, Google has also indexed a bunch
of pages with these to query parameters in them (often along with
page=NN' additional parameter). So my overall conclusion is
that I don't really know what's under this rock.
(Over the past ten days, 29 different IPs have tried to poke me this way. A number of them have SBL listings, specifically SBL 224619, SBL 214239, and SBL 211023. It turns out that I'd already blocked all of the IP ranges from these SBL listings, so those probes weren't getting anywhere in the first place.)
Firefox's peculiar handling of font choice preferences
On Twitter, I said:
I really don't understand how Firefox decides which particular 'Fonts for ...' preference controls the font sizes of any particular web page. They also seem to keep changing them.
If you look at Firefox's Preferences 'General' tab and scroll down, you'll discover a 'Fonts and Colors' preference which offers you the chance to set your default font and its size, and also has an 'Advanced...' option. As it happens, that default font is basically an illusion. If you go into the Advanced option, you'll discover that you can set fonts and font sizes for a whole range of, well, things (it's not quite languages). In particular you can set them for both 'Latin' and 'Other Writing Systems', and they can be different (and will be, if you only change one).
All of this matters because as far as I know there is no master preference that overrides everything. You cannot say 'in all things, I want my normal font to be X size and my monospace font to be Y size'. Instead you have to set this one by one in as many writing systems or languages as you think Firefox will ever decide web pages are in. If you miss one, your font sizes (and even font choices) can wind up weird and unsightly on some web pages.
On top of that, Firefox seems to sometimes change its view of what 'writing system' a particular web page is in even if nothing in particular changes in the web page itself. Wandering Thoughts has been serving pages with the exact same lack of language and writing system information for years, but I'm pretty sure that at some point some versions of Firefox flipped between using my 'Latin' font choices and my 'Other Writing Systems' ones (or, at the time, my non-choices for the latter; I hadn't set them). In addition, I don't think there's any easy way to see what font preference Firefox is using for any particular web page. You can see what character set encoding it thinks a page is in (and change it), but that's not the same thing as the 'writing system'.
(The writing system is also not the same thing as the language set in HTML attributes, but I suspect that Firefox generally derives the writing system from the language, if there is one.)
Unfortunately I suspect that none of this will ever really change. In the modern web, most websites explicitly set all of their font choices and font sizes, so these preferences are probably only ever used on a minority of websites, and the Firefox developers have higher priority work to do. Font preferences certainly wouldn't be the only bit of Firefox preferences and UI that are quietly being neglected that way.
(Why I care about this as much as I do is a discussion for another entry.)