HN user

chrismorgan

26,482 karma

https://chrismorgan.info/, me@chrismorgan.info

I’m available for hire for consulting, training and mentoring in Rust, everything web, performance and more: https://chrismorgan.info/hire-me/

[ my public key: https://keybase.io/chrismorgan; my proof: https://keybase.io/chrismorgan/sigs/rEm41-0pghG3ITW8S5HeuFLA9TznvPSlg9NKgXXRXqQ ]

Posts25
Comments6,387
View on HN
chrismorgan.info 2mo ago

A few ways of specifying per-theme colours in only CSS

chrismorgan
2pts0
news.ycombinator.com 1y ago

Ask HN: If building a computer, what will be good for possible local GenAI use?

chrismorgan
3pts2
chrismorgan.info 4y ago

The Unlicense is an inferior license wrapped in an atrocious name

chrismorgan
123pts177
chrismorgan.info 5y ago

Make me a sandwich

chrismorgan
62pts21
developer.mozilla.org 5y ago

The HTML autocomplete attribute

chrismorgan
2pts1
chrismorgan.info 6y ago

Using `make` and `git diff` for a simple and powerful test harness

chrismorgan
239pts46
news.ycombinator.com 6y ago

Ask HN: Why do many systems now turn emoji into :emoji_shortcodes: and similar?

chrismorgan
2pts0
blog.fastmail.com 9y ago

How we moved to a new datacentre in two days

chrismorgan
29pts0
chrismorgan.info 10y ago

Tween: a middleware library experiment

chrismorgan
3pts0
chrismorgan.info 11y ago

Rust ownership, the hard way

chrismorgan
4pts0
chrismorgan.info 11y ago

Why your first Rust FizzBuzz implementation may not work

chrismorgan
183pts129
github.com 12y ago

A safe and convenient store for one value of each type in Rust

chrismorgan
3pts0
play.rust-lang.org 12y ago

Rust playpen

chrismorgan
4pts1
arewewebyet.com 12y ago

Is Rust web yet? Not really

chrismorgan
101pts157
chrismorgan.info 12y ago

Teepee design: a careful look at the HTTP/1.1 Status-Line

chrismorgan
3pts0
chrismorgan.info 12y ago

Introducing Teepee: the next step for rust-http

chrismorgan
43pts10
chrismorgan.info 12y ago

Blindly random (or: old stories + computers = ?)

chrismorgan
1pts0
chrismorgan.info 12y ago

Say “no” to import side‐effects in Python

chrismorgan
148pts85
cmr.github.io 12y ago

The State of Rust 0.9

chrismorgan
33pts10
lilypond.org 12y ago

Lilypond 2.18.0 released

chrismorgan
1pts0
news.ycombinator.com 12y ago

Ask HN: what would an Unmanned Arial Vehicle look like?

chrismorgan
1pts1
chrismorgan.info 12y ago

GitHub: a case study in link maintenance and 404 pages

chrismorgan
36pts38
worldsbestflashdrive.com 13y ago

PortableApps.com Carbide: the safest, most secure USB flash drive on Earth

chrismorgan
1pts0
hacks.mozilla.org 13y ago

Building A Paid App For Firefox OS

chrismorgan
108pts45
kbdyn.chrismorgan.info 13y ago

Can you help me collect keystroke data for a Uni project?

chrismorgan
1pts0

Some review of Jelly UI itself.

—⁂—

It requires JS to work, which could have been avoided at some arguable ergonomic cost. Personally I’d disqualify it from being considered “native HTML form controls”—it’d need to be just an enhancement to qualify in my mind.

—⁂—

Your sets of chips like mode auto/dark/light should be marked up and behave as radio buttons: when one is checked, it should be the only one in the tab order, and arrow keys and such cycle through them. <jelly-segmented> gets this right.

—⁂—

The demos show a “click” toast on buttons even if you move out of the button before releasing, which should cancel it. Either the event handler is linked to something other than activation (which should be fixed), or activation behaviour is wrong (which should be fixed).

—⁂—

<jelly-checkbox indeterminate>

Oh how I wish <input type=checkbox> had an indeterminate attribute and a way of telling it to cycle through indeterminate when clicking. As it is, it’s purely a property, not attainable in serialised HTML.

—⁂—

<jelly-otp>

I hate it. Do not under any circumstances use a sequence of single-character inputs for OTPs. It behaves really nastily. Sure, you made the simple paste case work, but all kinds of other normal interactions are busted. You must use one input. If you want to style it in a way that shows the intended length and puts characters in those boxes, you can still do it. Use `font-variant: tabular-nums` or `font-family: monospace`, then rely on the ch unit and probably add some letter-spacing (one of the very few legitimate cases for letter-spacing), and draw behind. Or, if you want more control… contenteditable is available.

—⁂—

<jelly-range>

I thought we were talking “native HTML form controls”? There ain’t no such thing in HTML. (It becomes apparent the further I go that it’s not intended to be limited to what HTML has.)

—⁂—

<jelly-switch>

There’s a gap in the hit target between the switch and the label. This needs to never happen. It didn’t seem to with checkboxes or radio buttons.

—⁂—

<jelly-textarea>

Hold down a letter until it gives up expanding, and I found text and scrollbar drawn on top of the jelly border.

—⁂—

<jelly-alert dismissable>

The × hit target is much too small.

—⁂—

<jelly-pagination>

Not pleasant to use. Bad hit targets (too small, gaps between), poor choice of pages to offer (‹ 1 … prev self nextlast ›: you want 2 instead of … if prev is 3, and you want more than one prev/next), and if it’s ever going to be interactive, the layout changes far too much.

—⁂—

<jelly-tabs>

Ugh. Ugh. Unpleasant appearance, presenting tab bar and panel as unrelated widgets. Bad cross-fade (opacity drops below 1).

—⁂—

<jelly-dialog>, <jelly-drawer>

Opening it in dark mode was very jarring: no transition, and the backdrop lightens (should darken; that may require changes to the dialog background colour).

—⁂—

<jelly-menu>

You reused a <select> dropdown, and it shows. Interactions are all wrong. It also says “typeahead keyboard support” but I see no such thing.

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration.

Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

The guy that is making stdx has been doing various shady stuff in his books and code which have resulted in all his stuff being banned on /r/rust. In stdx, he’s been forking good code, violating licenses, completely rewriting stuff with LLMs (including cryptography code, and definitely introducing bugs in the process)… it’s not a good approach.

They push this message hard: unless you pay us, the bad guys will eat your lunch.

The truth is that if you uninstall their software (and hopefully also if you just let the trial lapse, though I don’t actually know whether Defender Antivirus gets enabled automatically in that case) Microsoft will defend you against the lunch-eating bad guys just as well as McAfee, for free.

That easily qualifies it as fraud.

For that reason, I’m willing to call it a scam when preinstalled or otherwise installed without user intent. I wouldn’t call it a scam if people installed it deliberately (though I would still disparage it and its tactics).

When preinstalled (as multiple major OEMs do), or when bundled in unrelated installers in these sorts of ways, it matches the definitions of scam excellently, and protection racket not badly.

When you uninstall, they give you an opportunity to type a reason. I wonder if anyone actually reads my accusations of them being scammers and bad people. I have uninstalled McAfee from more people’s computers than I care to remember.

Diffing diffs is so valuable for that reason, seriously underrated. Once I even found a use case for diffing diff diffs.

I also often wish to edit commits or resolve rebase conflicts or whatever by editing the patch rather than the files.

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.

98% isn't much 15 days ago

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 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.

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.

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.

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.

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.)