That’s not a great setup to be running: there have been several serious vulnerabilities since then, including the WebP zero-day.
Sure. The larger point is that (again, as per caniuse.com) MathML support is available to only 90% of users globally. That’s somewhat less than ideal, if you want your site to cater to a diverse user base.
In general I don’t think it makes sense for site owners to make changes to support users who are running dangerous configurations, and skimming caniuse it looks to me like this 10% is almost all people running very old versions of browsers.
I also suspect that a lot of what looks like people running really old browsers is actually bots, since it’s common to make a bot that emulates whatever the current version is at the time you made it (often because it’s based on that browser version and they’re not getting around to updating, or because they hardcode a UA and don’t prioritize updating).
That’s a lot of readers to throw away, and if you go to 95%, it isn’t that limiting, especially with various kinds of backwards compatibility.
I also suspect that a lot of what looks like people running really old browsers is actually bots
Caniuse isn’t reporting raw numbers that bots could trivially inflate, but using Statcounter’s statistics, which claims to screen for bots. (How successful they are at this is unknowable, of course.)
Depends on how popular you are. Even if you make the highly questionable assumption that browser statistics collected on sites like cnn.com and such are representative of the readership of jefftk.com, if jefftk.com has hundreds of readers, he’s still doing a lot of work for a group that can only manage to claim that there are “dozens of us”, and in any case really ought to upgrade to a proper browser (and in probably most cases, OS) anyway, for security reasons.
You are losing >10% if you deliberately break it for 10%. Breakage is the union of all breakages. Like, your site is already on thin ice: you have nonsense like margin-left: em; in your CSS (how large is that margin, exactly?) and <li> list items which are… not… inside any <ol>/<ul> lists? (Almost like a Zen koan. If list items don’t need to be inside a list, isn’t everything a list item, in some sense...) Also, I have no idea what <script nonce="this-is-not-a-real-nonce" type="text/javascript"> is supposed to do, but it very much makes me wonder if it’s doing what it’s supposed to do for anyone at all.
Given the hell that is web dev, even if you have immaculate HTML/CSS and carefully code to the standards, you will still run into hilarious breakage for many users, particularly the many mobile and/or Mac users. And remember: silence is not golden, because on the contemporary Internet, “they’ll never tell you”. (I have had literally half a million people go to a website which was broken, and not a single one sent in a report or comment.) Everything has to be tested, and not taken for granted, like, say, simply assuming that pasting MathML would work out-of-the-box because it worked for you and you hadn’t heard otherwise from readers...
I don’t disagree, but none of the things you pointed out are actually breakage as far as I can tell:
margin-left: em;
That was a typo for margin-left: 1em, but the browser ignoring the directive doesn’t actually do anything because it only ever appears immediately to then right of something that has margin-right: 1em. Fixed!
<li> list items which are… not… inside any <ol>/<ul> lists
Looks like at some point I missed the <ul>; added. (This is already only semantic—I have css removing all the list-specific display already)
I have no idea what <script nonce=”this-is-not-a-real-nonce” type=”text/javascript”> is supposed to do, but it very much makes me wonder if it’s doing what it’s supposed to do for anyone at all.
The validator is complaining because type="text/javascript" is no longer something you need to write, but it’s not really wrong to include it.
The nonce="this-is-not-a-real-nonce" is something I added when I temporarily served my site with a CSP (but without taking the time to fully set it up) as part of verifying that some other code I was testing on my site did the right thing in the presence of a CSP. It’s not doing anything, but also not breaking anything. This is annoying enough to rip out that I’m leaving it for now.
immaculate HTML/CSS and carefully code to the standards, you will still run into hilarious breakage for many users
As long as you verify that you’re coding to a standard that’s supported by the versions of the browsers you’re trying to support, what sort of breakage are you thinking about? This does happen (ex: Chrome/iOS advertising in its Accept header that it supported webp when it didn’t support inline webp) but it’s pretty rare, especially in the last ~5y.
For my own site I normally approach this by testing in multiple browser engines: Chrome + Firefox, sometimes also Safari. When I worked in this area professionally I additionally used careful A/B tests, but that’s not worth it for my personal site.
I don’t disagree, but none of the things you pointed out are actually breakage as far as I can tell:
I didn’t say they were. If you are ‘skating on thin ice’, you have by definition not fallen through and started to drown, because you can’t skate and drown simultaneously. (At least, I can’t.) My point is that you are engaged in sloppy coding practices, and so it’s unsurprising that you are making mistakes like casually assuming that MathML can be copied around or would be compatible with random web applications, when you should know that the default assumption is that MathML will be broken everywhere and must be proven supported. That Internet math support is parlous is nothing new.
because it only ever appears immediately to then right of something that has margin-right: 1em.
Until, of course, it doesn’t, because you refactored or something, and hit a spot of particularly thin ice.
but it’s not really wrong to include it.
Not at all. (My site has a few instances of unnecessary type declarations not worth ripping out.) I merely quoted that for the nonce part, which did concern me. CSP is one of the most arcane and frustrating areas of web dev, and the less one has to do with it, the better. Leaving in anything to do with CSRF or CSP or framejacking is indeed tempting fate.
As long as you verify that you’re coding to a standard that’s supported by the versions of the browsers you’re trying to support, what sort of breakage are you thinking about?
Web dev is crack & AIDS. We run into problems all the time where we code to a standard and then it breaks in Chrome or Firefox.
The day before yesterday I discovered that when I added dropcaps to my essay on why cats knock things over, it looked fine in Chrome… and bad in Firefox, because they define ‘first letter’ differently for the opening word ‘Q-tips’. (Firefox includes the hyphen in the “first letter”, so the hyphen was getting blown up to the size of the drop cap!) My solution was to put a space and write it ‘Q -tips’. Because we live in a world without a just and loving god and where standards exist to be honored in the breach.
Especially in Safari, which was created by a fallen demiurge in a twisted mockery of real browsers. Yesterday, Said had to fix a Safari-specific bug where the toggle bar breaks & vanishes on Safari. Worked fine everywhere else, coded against the standard… He also had to polyfill the standardized crypto.randomUUID (2021) for iOS.
And today Said removed the CSS-standardized-and-deployed-since-at-least-2015 property box-decoration-breakand-webkit-box-decoration-break from Gwern.net because it breaks in Safari. (‘webkit’ = ‘Safari’, for the non-web-devs reading this. Yes, that’s right, the Safari version breaks in Safari, on top of the standardized version breaking in Safari for which the Safari version was supposed to be the fix. Good job, Apple! Maybe you can fix that after you get around to fixing your Gill Sans which renders everything written in it full of random typos? And then make your browser hyphenation not suck?) He also had to remove hanging-punctuation due to its interaction with the link text-shadows on Safari, but arguably link text-shadows are a hack which hanging-punctuation shouldn’t try to play well with, so might be our fault.
I look forward to tomorrow. (That was sarcasm. If every day were like this, I would instead look forward to the sweet release of death.)
Sure. The larger point is that (again, as per caniuse.com) MathML support is available to only 90% of users globally. That’s somewhat less than ideal, if you want your site to cater to a diverse user base.
In general I don’t think it makes sense for site owners to make changes to support users who are running dangerous configurations, and skimming caniuse it looks to me like this 10% is almost all people running very old versions of browsers.
I also suspect that a lot of what looks like people running really old browsers is actually bots, since it’s common to make a bot that emulates whatever the current version is at the time you made it (often because it’s based on that browser version and they’re not getting around to updating, or because they hardcode a UA and don’t prioritize updating).
That’s a lot of readers to throw away, and if you go to 95%, it isn’t that limiting, especially with various kinds of backwards compatibility.
Caniuse isn’t reporting raw numbers that bots could trivially inflate, but using Statcounter’s statistics, which claims to screen for bots. (How successful they are at this is unknowable, of course.)
Depends on how popular you are. Even if you make the highly questionable assumption that browser statistics collected on sites like cnn.com and such are representative of the readership of jefftk.com, if jefftk.com has hundreds of readers, he’s still doing a lot of work for a group that can only manage to claim that there are “dozens of us”, and in any case really ought to upgrade to a proper browser (and in probably most cases, OS) anyway, for security reasons.
I wouldn’t be ok serving pages that didn’t work for 10% of my visitors, but I’d be really surprised if the number is really that high.
You are losing >10% if you deliberately break it for 10%. Breakage is the union of all breakages. Like, your site is already on thin ice: you have nonsense like
margin-left: em;in your CSS (how large is that margin, exactly?) and<li>list items which are… not… inside any<ol>/<ul>lists? (Almost like a Zen koan. If list items don’t need to be inside a list, isn’t everything a list item, in some sense...) Also, I have no idea what<script nonce="this-is-not-a-real-nonce" type="text/javascript">is supposed to do, but it very much makes me wonder if it’s doing what it’s supposed to do for anyone at all.Given the hell that is web dev, even if you have immaculate HTML/CSS and carefully code to the standards, you will still run into hilarious breakage for many users, particularly the many mobile and/or Mac users. And remember: silence is not golden, because on the contemporary Internet, “they’ll never tell you”. (I have had literally half a million people go to a website which was broken, and not a single one sent in a report or comment.) Everything has to be tested, and not taken for granted, like, say, simply assuming that pasting MathML would work out-of-the-box because it worked for you and you hadn’t heard otherwise from readers...
I don’t disagree, but none of the things you pointed out are actually breakage as far as I can tell:
That was a typo for
margin-left: 1em, but the browser ignoring the directive doesn’t actually do anything because it only ever appears immediately to then right of something that hasmargin-right: 1em. Fixed!Looks like at some point I missed the
<ul>; added. (This is already only semantic—I have css removing all the list-specific display already)The validator is complaining because
type="text/javascript"is no longer something you need to write, but it’s not really wrong to include it.The
nonce="this-is-not-a-real-nonce"is something I added when I temporarily served my site with a CSP (but without taking the time to fully set it up) as part of verifying that some other code I was testing on my site did the right thing in the presence of a CSP. It’s not doing anything, but also not breaking anything. This is annoying enough to rip out that I’m leaving it for now.As long as you verify that you’re coding to a standard that’s supported by the versions of the browsers you’re trying to support, what sort of breakage are you thinking about? This does happen (ex: Chrome/iOS advertising in its
Acceptheader that it supported webp when it didn’t support inline webp) but it’s pretty rare, especially in the last ~5y.For my own site I normally approach this by testing in multiple browser engines: Chrome + Firefox, sometimes also Safari. When I worked in this area professionally I additionally used careful A/B tests, but that’s not worth it for my personal site.
I didn’t say they were. If you are ‘skating on thin ice’, you have by definition not fallen through and started to drown, because you can’t skate and drown simultaneously. (At least, I can’t.) My point is that you are engaged in sloppy coding practices, and so it’s unsurprising that you are making mistakes like casually assuming that MathML can be copied around or would be compatible with random web applications, when you should know that the default assumption is that MathML will be broken everywhere and must be proven supported. That Internet math support is parlous is nothing new.
Until, of course, it doesn’t, because you refactored or something, and hit a spot of particularly thin ice.
Not at all. (My site has a few instances of unnecessary
typedeclarations not worth ripping out.) I merely quoted that for the nonce part, which did concern me. CSP is one of the most arcane and frustrating areas of web dev, and the less one has to do with it, the better. Leaving in anything to do with CSRF or CSP or framejacking is indeed tempting fate.Web dev is crack & AIDS. We run into problems all the time where we code to a standard and then it breaks in Chrome or Firefox.
The day before yesterday I discovered that when I added dropcaps to my essay on why cats knock things over, it looked fine in Chrome… and bad in Firefox, because they define ‘first letter’ differently for the opening word ‘Q-tips’. (Firefox includes the hyphen in the “first letter”, so the hyphen was getting blown up to the size of the drop cap!) My solution was to put a space and write it ‘Q -tips’. Because we live in a world without a just and loving god and where standards exist to be honored in the breach.
Especially in Safari, which was created by a fallen demiurge in a twisted mockery of real browsers. Yesterday, Said had to fix a Safari-specific bug where the toggle bar breaks & vanishes on Safari. Worked fine everywhere else, coded against the standard… He also had to polyfill the standardized
crypto.randomUUID(2021) for iOS.And today Said removed the CSS-standardized-and-deployed-since-at-least-2015 property
box-decoration-breakand-webkit-box-decoration-breakfrom Gwern.net because it breaks in Safari. (‘webkit’ = ‘Safari’, for the non-web-devs reading this. Yes, that’s right, the Safari version breaks in Safari, on top of the standardized version breaking in Safari for which the Safari version was supposed to be the fix. Good job, Apple! Maybe you can fix that after you get around to fixing your Gill Sans which renders everything written in it full of random typos? And then make your browser hyphenation not suck?) He also had to removehanging-punctuationdue to its interaction with the link text-shadows on Safari, but arguably link text-shadows are a hack whichhanging-punctuationshouldn’t try to play well with, so might be our fault.I look forward to tomorrow. (That was sarcasm. If every day were like this, I would instead look forward to the sweet release of death.)