Firefox has a little handy font-related thing on Unix (or at least Linux)
On Linux in specific and Unix more generally, there is a notion of default system fonts that are known by the magic names of 'serif', 'sans-serif', and 'monospace'. What these magic names map to is determined by a complicated pile of decisions that are spread around the system in the form of Fontconfig (also). These decisions are generally fairly opaque and hard to peer into unless you're relatively experienced with command line tools.
Unless you configure it otherwise through Preferences, Firefox normally uses these standard font names if a website doesn't set specific fonts (or uses the generic names, which often show up as the last fallback in CSS). This means that Firefox is exposed to mysterious changes in what your Linux system actually maps these fonts to, which can vary. However, I discovered today that Firefox has a very convenient feature here.
If you go to the general section of Preferences and haven't customized your font choices, you will probably see the "Default font" listed as something like "Default (DejaVu Serif)". What this means is that Firefox is using the default meaning of 'serif', but is also telling you what font it actually maps to. If you go into "Advanced..." and have not customized your font choices, you can see what all three of the magic names map to. This can be very handy for sorting out strange font issues.
(This doesn't quite give you complete details, as it omits the Fontconfig style, which can vary and theoretically may make a difference.)
Firefox's Web Developer tools will give you a version of this for any web page (including ones that don't set any CSS fonts and so are using the system ones). However, as far as I can see the "fonts" pane won't tell you exactly why 'DejaVu Sans' is being used, just that it is (and that it's a system font). I also don't know if this will peer through other Fontconfig font aliases to tell you what they map to, or if it will faithfully report them under their pre-alias names.
(Because I was curious I just checked and Chrome does not show this information in its font preferences; it just tells you you're using the generic names. Chrome also appears to give less information about fonts in its Web Developer tools, but I probably don't know what I'm doing there.)
Web page generation systems should support remapping external URLs
Some web pages and web sites are hand authored, but many more are generated (dynamically or statically) through web page generation systems and content management systems of various sorts. Also, often our writing in these systems has links to external pages; to other people's writing, to reference documentation, to Wikipedia, to whatever. This presents us (the people running web sites and writing on them) a long term problem, because in practice some or many of those external URLs will eventually change.
Today, we don't have good support in our page generation systems for this unfortunate reality of web life. If you find out that a an external URL you reference has moved, you generally have to hunt around through all of your content and update it, either completely manually or at best semi-automatically. The unsurprising result of this is that people often don't, even when they know old links have changed; it's simply too much work to go back through everything and fix it all up.
So here's an idea: all of our web page generation systems should support a remapping file (or data source) for external URLs, which would list the old URL and its new replacement. A fancier version could also have site matching, prefix matching or general pattern matching. When you're generating a page and the page has a link pointing to such an old URL, it would automatically get replaced with the new URL. The obvious advantage of this remapping system is that it's less work; the subtle one is that it's automatically universal, with you not having to hunt down every last obscure corner of the site where the URL is mentioned.
(In some systems it would make sense to automatically edit this change into the source data; generally I think those are systems where the source data is already held in a database by the web generation system and is not edited by people by hand.)
One additional advantage of doing this in the web page generation system instead of in external tools is that the web page generator generally has the best idea if what it's really dealing with is a link target, instead of some other text that happens to mention or include the URL. You probably don't want to rewrite mentions of old URLs in plain text, for example, especially not automatically.
PS: This remapping should be applied repeatedly, because replacement URLs can themselves get replaced. Yes, sure, theoretically people could go through and update the original mappings again, but let's make it easy and as foolproof as possible. Since link rot is going to happen, we should make it easy to deal with.
(This idea was sparked by Aristotle Pagaltzis linking to a web.archive.org copy of a diveintomark.org entry in a comment on this entry, causing me to realize that I had entries with direct links to diveintomark that needed to be updated to web.archive.org. This shows both how long it can take me to write some Wandering Thoughts entries and how I still haven't gotten around to finding and editing all of those entries (or implementing a remapping file here).)
Firefox is improving its handling of HTTP Basic Authentication (on Unix)
We're big users of HTTP Basic Authentication, and I use Firefox (and what is effectively Firefox Nightly). Recently I noticed a nice little quality of life improvement in Firefox Nightly's handling of HTTP Basic Authentication, at least for people on Unix.
(I haven't tried to check how Firefox on Windows handles HTTP Basic Authentication, either in released versions or in Nightly.)
Today, if you go to a website that requires HTTP Basic Authentication with even the very latest Firefox 81.0.1, you'll get a very old fashioned modal dialog popup (at least on Unix), with all of the many problems that those have. These days, at least the popup only blocks that Firefox window instead of all Firefox windows, but it does stop you from doing things like interacting with other tabs you have in the window, and if you used "Open Link in New Tab", Firefox force-switches you to that tab (and throws the modal dialog in your face) the moment the HTTP Basic Authentication pops up.
(If you're someone who mostly or entirely uses tabs instead of windows, this means that a HTTP Basic Authentication prompt basically locks your Firefox up.)
At some point recently, Firefox Nightly has changed this to make Firefox's authentication prompt to you effectively a modal thing attached to the tab, not a separate modal dialog popup (in other words, how Chrome behaves on Unix, more or less). This doesn't jump in front of you in quite the same way, is much less annoying, and no longer locks you out of other tabs in that Firefox window until you answer the authentication prompt.
(Firefox still force-switches you into the tab that wants you to authenticate, in contrast to Chrome, which just lets the tab sit there if it's not the current tab.)
On the one hand, this is a nice quality of life improvement that makes HTTP Basic Authentication better for Firefox people on Unix. On the other hand, it turns out that I'm so used to how Firefox works now that the new way feels a bit jarring every time I run into it (which is more often than you'd think, but that's another entry). I'm sure I'll get completely used to it in a few months, though.