I’ve been testing out Firefox Quantum recently, which is a post for another day, but it made me realize one thing and that is that this site right here barely functioned for anyone using Firefox. Either Quantum or the old engine (Gecko? Is Quantum a replacement for Gecko or a version of it?). Frankly, it’s much stricter than I would have imagined, and assuming that something that functions fine in IE/Edge and Chrome/Safari would also function fine in Firefox was… not a safe assumption, apparently. Here are a few things that I’ve fixed over the past few days, some related to Firefox and others not.
- The width/height of SVGs can’t be specified in
remunits, which makes sense upon reflection. An SVG is really a standalone bit of XML that just happens to be acceptable to dump into an HTML file. I was thinking in HTML tidiness terms and declaring
width="auto" height="13rem", but obviously something that hypothetically can stand alone has no master em to be relative to. It’s definitely not valid SVG, but I never thought twice about it since it seemed like a best practice from an HTML standpoint, and Chrome, Safari, IE, and Edge all handled it as expected. Firefox rendered at 100% width and the height to match, and those suckers got big. I temporarily slipped in a JS patch, but I think I have now edited every post to use ems instead of rems.
- My SVG-in-a-data-URI-in-CSS didn’t work, because I wasn’t properly percent-encoding the data (notably, the hashes and percent signs). This, again, makes perfect sense but I hadn’t really thought about it because WebKit-based browsers didn’t care. This also failed in IE/Edge, I just never noticed, largely because I had only made use of SVGs in this way in one post – A chessboard for pebbling. Luckily, none of the browsers tested seemed to care about spaces. Also, protip: do
- My drawers got stuck, or, you know, just didn’t work. Those drawers up top, when you click ‘categories’, or the like. They didn’t work because I was using
addRuleand I guess
insertRule, while far more obnoxious is also the more ubiquitous solution. I temporarily had a wedge in there to conditionally choose between the two, but I think that only matters for very old IEs and… I have to draw the line somewhere. Unfortunately, the drawers are very hackish no matter what I do; injecting rules into stylesheets is not something I would recommend, but here we are.
- Fixing the drawers broke the drawers on iOS. Which was super frustrating,
insertRuleshould have been pretty much universal. I had never attempted to use the iOS web inspector before, and there is a reason for that: it is a fucking terrible experience. You have to use Safari on the phone, you have to tether the phone to your Mac, and then you have to use Safari on your Mac. I don’t like doing any of these things, and juggling them all while trying to get work done is, well, fucking terrible. Anyway, turns out iOS’s version of WebKit doesn’t like injecting CSS at index 0 for some reason. So, now I do index 1, who cares, does not matter. Index -1 is supposed to place the rule at the end, so I thought, but it overflows on everything I’ve tried it on with ‘the end’ being like 4 billion elements deep. Again, don’t care.
- So now the drawers work, but still have a weird graphical glitch which isn’t new, I just haven’t solved it yet – on iOS, the text is very large when you open up a drawer. The drawer is sized such that the text is the right size, and on Chrome (but not Safari) it jumps back to the right size after scrolling. Very odd.
- Unrelated, but I patched some other things in my Hugo template while I was meddling, like having a really broken process for
<meta name="description">before, which I probably half-assed because when I think about meta tags I start thinking about SEO, and then I vomit. But, I tweaked this, and hopefully I’ll have some reasonable descriptions in the Googleverse at least.
- I also started fixing some minor issues with some posts, primarily capitalization of categories, since the drawer doodad lowercases them anyway. But Hugo inexplicably has no inbuilt alphabetical sort, and therefore sorts all uppercase letters before all lowercase letters. You can see this by opening the categories drawer up top and seeing ‘svg’ before a bunch of ‘a’s. I need to make a decision on how to handle this soon – lowercase all of my categories, sacrificing semantics for aesthetics; or use an awful fucking hack. I mostly included this list item for the sake of not losing that link.