chrismorgan

When distributing software, it’s very useful to know which OS and which architecture the user is on in order to present them with the appropriate file.

I don’t like strict mode because it quite unnecessarily thwarts better strict types in the application layer: by restricting the spellings of column types, it stops you from using more meaningful names and prevents code from using those names when mapping database and application types:

https://hn.algolia.com/?query=chrismorgan+strict+sqlite&type...

If you’re going to work with a database through something like the Rust sqlx crate, I think you’re better to eschew strict mode.

Most common methodologies were already garbage even a few years ago, with general consensus being that Firefox was probably undercounted by at least 30%; and in more technical arenas, it can be a lot higher, perhaps up to 80%. (Unfortunately, that’s still probably not a lot.)

Even back then, Chrome was commonly being significantly overcounted due to user-agent string shenanigans. And these days I’m confident (without any figures, or even relevant recent commercial experience) that will have increased sharply. I expect that it is now massively overcounted, at the same time as Firefox is significantly undercounted.

Statcounter is particularly commonly used, and honestly one of the worst. Its mobile figures, for example, are completely useless because they don’t report browser versions. CanIUse figures (which lean heavily but not solely on Statcounter) are lousy and unrealistic due to some of these sorts of issues, and just generally being out of date. (I examined the matter closely on 2023-05-27 and the figures corresponded with being about six weeks behind.)

It depends on what ecosystem you exist in whether reStructuredText or AsciiDoc is more common. reStructuredText came from Python and is vastly more common there, AsciiDoc came from Ruby and is vastly more common there. Me, I’ve seen a lot more reStructuredText than AsciiDoc. Also having studied lightweight markup languages closely (and designed and used my own for the last five or six years, which I’ve almost finished implementing at last!), I think AsciiDoc has more serious design problems than reStructuredText. And without doubt it’s uglier.

I can see the video poster, but clicking on it opens a login popup rather than playing it. However, the thing is a link, and opening https://x.com/MaximeRivest/status/2073544461473169432/photo/... directly does play it.

I know approximately nothing about the specific case here, and don’t believe I have any skin in the game. I intended my comment purely abstractly: I’m not commenting on anything technical, merely mentioning a procedural concern: that the line I quoted can sound reasonable, but that I don’t think it’s actually a reasonable argument by itself, because of the likely consequences of such actions. (That is: if that happened to be the only argument—though I doubt it is—there’s a compelling case for rejecting it.)

> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document

“People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.

(There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.)

This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.

> This is all Firefox's implementation of the client.

Nothing to do with Firefox, it’s just the browser rendering the page.

I don’t know if “Injected” is the name of some service, or a description of what is to happen (in which case it’s lousy wording). Whatever it is, the failure mode is clearly atrocious. I hope that’s avoidable.

Quite apart from whether the concept can succeed after having failed a number of well-funded and well-publicised times—

I open https://shtein.me/api/joke in a normal-enough browser (Firefox Nightly with Enhanced Tracking Protection and uBlock Origin). After loading its 2.3MB response (no useful HTML, just a huge inlined JS blob, and served without transfer compression), it asks me to select a wallet. There are two choices.

I select “Injected” and press “Connect wallet” (ugh, why did it require me to click three times instead of just one!?). Nothing discernible happens. No errors or network activity in the dev tools.

I select “Coinbase Wallet” and press “Connect wallet”. It opens a popup window, <https://keys.coinbase.com/connect?sdkName=%40coinbase%2Fwall...>. The TLS connection fails, PR_END_OF_FILE_ERROR. Operating on a hunch, I discover it’s blocked in India:

  $ curl keys.coinbase.com
  The website has been blocked as per order of the Ministry of Electronics and Information Technology under IT Act, 2000.

(coinbase.com and www.coinbase.com are similarly affected.)

Not sure quite what to make of that, given that https://www.coinbase.com/en-in/blog/coinbase-launches-in-ind... sounds (from the snippet exposed in a search engine) like Coinbase started fully operating in India five weeks ago.

Can’t say it leaves a positive impression.

It sounds like that’s an input mode (which maps immediately to rich structures), not a markup language.

This is not simpler or nicer (per the current submission title) or better or cleaner (per the linked article). Well, it may be simpler in some regards if it lacks Markdown’s HTML basis (source of all kinds of problems but also of its popularity). Oh, and definitely simpler in being limited to two levels of headings (read: document title plus one level of heading). But nicer, better, cleaner? It seems to be determinedly different in a variety of capricious ways that are not obviously superior, and are sometimes obviously inferior. And only supporting one level of heading after the document title is… a choice; and not one I’m willing to consider better or cleaner.

—⁂—

Code blocks are indented by six spaces. Oddly specific. Four spaces or one tab I could understand, even two or eight spaces have some precedent, but six spaces?

Combining that with treating “### ” as special… very odd.

—⁂—

Link syntax is possibly even worse than Markdown’s.

Now Markdown’s is terrible: people mix up the square brackets and parentheses frequently, the fact that the href is next to the delimited text rather than inside (e.g. [text <href>] or [text|href]) is dubious, and it uses as its closing delimiter the right parenthesis which doesn’t get escaped in URLs <https://url.spec.whatwg.org/#url-code-points> so that you have to add an extra step after normal URL serialisation, { '(' → %28, ')' → %29 }, for general correctness.

But Shrimple’s? The idea of merging hrefs with footnotes is definitely appealing, but the way it’s been done is hard to read and quite unmanageable. The link is essentially delimited by a "-> " prefix and a "[N]" suffix. Tough to read, though syntax highlighting may make it more bearable. But really, paired delimiters are generally safer. In Markdown, it would have been a "[" prefix and a "][N]" suffix, and that would have been nicer.

Then the URLs (as text, not linked) remain at the end of the document, devoid of context.

And you can only use numbers, not names. And to be frank, inline hrefs are better a significant fraction of the time.

Footnotes are a bad idea in general: you have to go all the way to the end of the document to resolve them, then find your way back. By contrast, in languages like Markdown and reStructuredText you can define your links closer to where they’re used, if you wish.

  reStructuredText_ lets you link a single word with a trailing underscore.
  Multi-word link targets need `backtick delimition`_.
  In either form, double the underscore for an anonymous link__,
  which you can place after the paragraph.
  That might sometimes be neater than using an `inline reference <https://example.com>`_.

  __ https://example.com/

  .. _reStructuredText: https://docutils.sourceforge.io/rst.html
  .. _backtick delimition: https://docutils.sourceforge.io/docs/user/rst/quickref.html#hyperlink-targets

I also think that notes sources should be spanned: mark which words the footnote applies to. But that sort of thing is going beyond what Markdown covers.

(Content-wise: looking at the footnotes, I see two orphaned footnotes, and one of them seems to have bad HTML escaping done to it, > becomes &rt; which is invalid; where I would have expected that -> to become a link.)

—⁂—

Lists: requiring two-space indentation is bizarre. For bullets, it can be nice to match four-space block indentation, and that’s how I’ve tended to write things in my own lightweight markup language (LML), but then for numbers you want one or zero spaces to keep up that concept. In the end, it’s just… why?

> Subsequent items may be numbered normally (unlike Markdown, where they all have to be "1").

That’s flat-out wrong about Markdown.

> Numbers don't have to be consequtive, but they will be normalized to be consequtive. It just werks!

Yuck, yuck, yuck. That’s what Markdown does, and I hate it. If I wrote 44, I meant 44. If you really want to, have tooling that detects sequence breaks and warns “did you actually mean 44?”, but changing what the user clearly wrote is nasty.

—⁂—

Parse and render dictionaries: seems a very specific feature that is unlikely to compose well. The basic concept can definitely be useful, but I don’t think it’s exposed well.

Not just dogs; more than a few humans don’t cope with loud noises of various kinds.

Perhaps we’re not talking about the same thing. What I refer to has the button light up while you bump it, and then go dark again, whereas if you press it more deliberately, it stays lit (and takes effect). This can apply to the buttons inside or outside the lift.

Around 2011, my grandfather with Parkinson’s and deteriorating eyesight received an iPad from family. They didn’t use it for much, mostly video calls and reading the Bible, with the text steadily getting larger and larger (up to letters being more than 5cm tall towards the end). It was funny just how good it was if an app only supported iPhone and not iPad, because then the iPad would scale it up to double physical size.

That was a common problem in JS-based menu opening and closing, long ago: they were treated as animations and queued. This was sometimes quite ludicrous.

Nowadays, you use transitions instead, which are not queued. But I still very occasionally see things that use queued animations.

I have long presumed that sort of thing to be deliberate, avoiding activation on accidental bump.

Although it is conceptually straightforward, it’s technically fundamentally impossible. At best, you can mitigate it so that it normally works.

> Cut it out. You’re only hurting yourself.

Were it so, I wouldn’t mind so much. But they hurt others, too.

If it makes you feel any better, the Markdown part is optional (and has no semantics). Somehow it feels about right that the Markdown file can actually just be a YAML file with the wrong extension.

(Actually, to be more specific, a YAML file with no directives, explicitly-signalled start-of-document-content, and followed by a second null document. I will note that frontmatter syntax is not specified; the non-normative Appendix B is the only place that suggests it means prefix and suffix --- lines. And no, frontmatter is not part of Markdown, or CommonMark, and is in fact incompatible with both. And it’s invalid YAML too, the end-of-frontmatter line should be ... to indicate end of document without starting a new document.)

For comparison: <https://duckduckgo.com/?q=%22indian+standard+english%22>, exactly zero results.

Some of the spellings are simplified, but the rest of it (units and such) is complicationified.

I have never heard of a thing called “Indian Standard English”, nor (as an Australian who has moved to India) does it sound a very realistic concept. Can’t find any search results for it as a phrase, either.

I started writing something a while ago with preliminary title “Do en and en-US, not en and en-GB”.

If you cluster English dialects by various characteristics, you’ll end up with en-US as a clear outlier. I believe that, if you’re going to divide English into two camps, the best is “English (International)” and “English (US)”. Canadian English is the one that’s closest to US English, but even it works at least as well based on International English as regards spelling (https://en.wikipedia.org/wiki/American_and_British_English_s... is an interesting read).

But there’s a lot more to it than spelling, and here the distinction is even clearer: the US has its own length, area, volume, weight and temperature units that no one else uses; its own stupid date format that everyone else loathes; its own paper sizes that no one else knows what to do with.

Not everyone else agrees on which date format to use, but we do all agree that any of our formats (DD/MM/YY, DD-MM-YYYY, YYYY-MM-DD, &c.) are better than the US’s middle-endian monstrosity. Though if we see the likes of DD/MM/YYYY we may mistrust whether it’s actually MM/DD/YYYY.

I also believe that you should default to English (International) for all users geolocated outside the USA.

Once you’ve get this divide right, adding further dialects also probably becomes quite a bit easier. But I do wish for diamond inheritance of locales: so you can mix in -ise/-ize, -yse/-yze, -re/-er, -ence/-ense, program/programme, and thereby deduplicate a fair bit across locales.

(There are still plenty of differences: such as time formats; decimal/grouping separators though I believe all places where English is a main language use . for decimal and , for grouping; even number grouping varies: en-IN does 1,23,45,678 rather than 12,345,678; keyboard layout; word choices; and lots more.)

(One last point: the naming is a bit fiddly. “Spanish (International)” means Spanish as used outside Spain. “English (International)” means the broad international/non-US consensus of what English is, generally following what England does but probably with kilometres instead of miles for long distances.)

I’ve seen a fair bit of bloatware, spyware and what I’d count as malware on people’s Android phones. Every last piece of it has come with the OS or from the Play Store.

This is my favourite single character to demonstrate that you cannot lay text out without knowing the font, which people sometimes try to claim is possible in terminals: in some fonts, it’s 10em wide and less than 1em tall, but in others, it’s under 3em wide and perhaps 2em tall.

(If people aren’t convinced by that, my next area is complex text layout, starting with my name in the Telugu script, <https://temp.chrismorgan.info/క్రిస్.svg>, also augmenting that with how the r can be drawn to the left or underneath or even a little to the right of the k, which I really should add to that SVG file.)

> A 2020 lawsuit raised the same issue, but a California judge dismissed it in 2021 because the plaintiff had never actually lost access to her purchased videos, leaving her without standing.

Seems kinda off. They’re pointing a knife at you menacingly and have promised that in a variety of circumstances they will stab you, but because they haven’t actually stabbed you yet, you’re not allowed to complain. Feels like maybe (maybe; I’m not entirely convinced) that threat should be standing enough, just as conspiracy and attempted murder can be criminal matters, and not just a successful murder.

It does still happen not infrequently on a certain sort of site which I’ll simplify to “marketing homepage”, but it’s not happening anywhere near as often as it did three years ago. I haven’t tried to assess if this is because more-sensible frameworks have gained popularity, or if the stupid frameworks support server-side rendering better now.

Gotta say, though, that I don’t think one actually misses much in such cases.

Of sites that require JS to not be blank and don’t fit into this main category, my vague feeling is that the rate hasn’t changed much.

You missed the two absurdities:

1. Springer Nature are happily selling an empty PDF for $39.95.

2. Springer Nature responded that they’re not going to tell you why they retracted it, because retraction details are normally only shared with the author (who in this case died almost 80 years ago).

The fade affects scroll bars, which is quite unpleasant (and arguably catastrophic if you have two-dimensional scrolling). The traditional background-image technique avoided this by sitting inside the scroll area. I don’t think you can achieve that with mask, without an additional element. But I think it might be worth that extra element.