chrismorgan

Read through https://www.theverge.com/2020/8/11/21363424/mozilla-layoffs-...: six years ago, Mozilla laid off 250 people, about a quarter of their staff, in order to focus on… two specific services that they have since killed (Pocket, Hubs), one service completely unrelated to the browser (VPN, though they have recently decided to set more money on fire by integrating some VPN stuff into Firefox, where it never had any place and is frankly an affront), and new and unspecified “security and privacy” tools (probably things like Relay and Monitor) which are almost certainly completely unrelated to the browser.

They are focusing on things that are nothing to do with their core product, and have been acting so for a long time.

Mozilla is deeply unhealthy, and has been slowly collapsing for more than a decade at this point. I believe that the significant majority of its staff are doing things of no or negative value to Firefox.

I suspect that ten developers not beholden to Mozilla but with a mandate to make a good browser would be better custodians of Firefox. If you raised the budget to forty, I’m all but certain of it.

I don’t say it’s the case there (it probably isn’t, you probably need hardware access or root), but sometimes those sorts of things do actually matter because there’s a way of causing them to be run anyway.

This is why it’s good to exclude things you don’t need. The less there is, the fewer places there are for problems to lurk.

I should clarify that I speak only of English and general web content CSS. I’m happy to disqualify 4 and 6 on those grounds (you decide which grounds I use for Fraktur!).

As for 5, I’m not convinced letter-spacing is the right tool for it: at those scales I’ve tended to prefer condensing or expanding the text, glyphs and all, which you can do in SVG. But I will allow it as a place where very careful letter-spacing use with kerning and ligature control can be acceptable.

I have seriously considered blocking letter-spacing outright in user stylesheet a few types over the last four or five years, but decided to keep it to keep an eye on how badly people are doing things.

And really, I’d prefer problematic properties to have prefs whereby you can disable them outright, rather than trying to add a style on top to nullify it. Newer stuff often does, but the old stuff doesn’t. user_pref("layout.css.letter-spacing.enabled", false) would make me happy.

letter-spacing is massively overused. I have Firefox set to only use my chosen fonts (and highly recommend it: it makes the web much better), and this reduction in variation makes non-zero letter-spacing much more obvious to me. At typical body sizes, I will tend to notice (and be displeased by) letter-spacing changes of less than 1% (I notice even 0.1px often).

There are only three places where I hold letter-spacing of any kind to be acceptable:

1. Art. (This is pretty much the intended context of the article, but I just know it’s going to be taken out of that context.)

2. In large headings, slightly reducing letter-spacing may be reasonable, as fonts are often spaced for smaller size usage. But whereas reducing line-height is all but essential, reducing letter-spacing is of marginal value at best. Ideally you have a variable font with optical sizing (the opsz axis), so this is handled automatically.

3. In all-caps, small-caps or all-small-caps text, as fonts are generally spaced for runs of lowercase letters. https://practicaltypography.com/letterspacing.html suggests 5–12% (which you can spell in CSS as 5% or 0.05em). Ideally you have a font that optimises this itself within the caps, smcp and/or c2sc features.

Do not, under any circumstances, set non-zero letter-spacing for body text. It’s just wrong. If you feel your preferred font is too spacious or too tight, fix or replace the font.

(If you want another reason: letter-spacing is incompatible with ligatures, not so often used in sans-serif faces, but in serifs things like fi not having the ascender and dot collide messily is often valuable.)

http:// → https:// → https://www. is actually the recommended technique, because it lets an HTTP-Strict-Transport-Security subdomains directive work.

But the rest could have been flattened into the second redirect.

• Portability: unreasonable claim, HTML is more portable than what you will use instead.

> Take the humble <input type="text"> element, for example. With it, you get crispy rendering at any resolution, support for tab, focus, selection, mouse interactions and arrow key navigation, internationalization for right-to-left text and Asian compound characters, accessibility for screen readers… the list goes on.

This is a poor choice of example for “why wouldn’t you use Canvas”, because even pure-canvas apps will use a backing <input type=text> for text input (probably invisible, hopefully appropriately positioned), because that’s the most primitive thing there is in this way; you cannot emulate it.

—⁂—

The rest of the article is fairly reasonable, showing some of the important considerations and why doing it to acceptable quality is more complex than people often imagine, because you’re basically reinventing a sizeable subset of what the browser already offers; and you can’t do as good a job of it in various areas, and are unlikely to do as good a job in most of the rest.

I’d say: things like Canva and Google Maps should obviously use canvas; things like Google Docs and Sheets should almost certainly not. I see enough of their product to see why they would choose canvas, but I’m not yet convinced that HTML only wouldn’t have served them better, and I strongly suspect that, if not, HTML + SVG would have been a better choice than HTML + canvas (and I hope they’re not pure canvas, because that’s an irredeemably bad approach for the foreseeable future of browsers).

> The document in Google Docs is a Canvas.

This is only mostly true, and no justification at that. I’ll just quote myself from a couple of years ago <https://news.ycombinator.com/item?id=42253177>:

> Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications.

I haven’t ever examined Google Sheets closely, but it looks to use a similar approach, but worse in scrolling (it’s very obnoxious compared with native on my device—lags fiercely, and breaks inertia).

Excel I can’t comment on.

Docs should definitely have stayed HTML.

Sheets and Excel should probably be HTML, or possibly SVG.

For Hivekit’s scheduling interface as shown, I’d say most of the area should be HTML, but that I wouldn’t object to canvas or SVG for the centre area.

Now, for their reasons.

• Speed: at the level of complexity they’re talking about, this is flat nonsense. Yes, the browser does more than necessary, but a lot of effort has gone into making it perform far better than it has any right to, and DOM performance is not your bottleneck. (I mean by this that, if it looks like it is, it would be if you did the same thing with canvas too.) And as soon as it comes to things like scrolling, you cannot perform or behave as well as the browser, because the browser is a compositor and you can’t work at that level. Even in the rest, unless the entire thing is owned by a single small team skilled at saying “no” and at implementing everything from scratch rather than leaning on others’ libraries, your code is very unlikely to do better than the browser.

• Control: it undermines its own point completely by talking of scrolling. You must use real DOM for the scrolling, or else it will be horrible to use on a reasonably large fraction of devices. Note how the likes of Google Docs and Sheets use real DOM and render slices with the adding and removing and such that it criticises.

• Consistency: you only get this if you do all the text rendering yourself from first principles, which Google Docs and Sheets don’t do because it performs terribly. So no, this one falls flat too.

(I’ll continue more later, got to go again.)

The Assistance and Access Act is completely irrelevant to Fastmail, because Fastmail doesn’t offer end-to-end encryption. Fastmail was always subject to the Telecommunications Act, which allows Australian police access with warrants, and Fastmail has always made it clear that it complies with legal warrants.

Fastmail has never used AWS, and this article is pretty clear about how they have always used their own hardware and traditional colocation.

Fastmail used to be based in Melbourne only, but after the Pobox merger it ended up with an office in Philadelphia too. No idea how the balance of things is between the offices now.

This only works because it’s a wildcard certificate. Since 2019, TLS certificates must not be issued for names containing underscores <https://cabforum.org/2018/11/12/ballot-sc012-sunset-of-under...>.

It certainly should be. Filtering user-registrable names that will end up in host names or URL paths is table stakes. You want to block names like www, admin, root, robots.txt, .well-known, _*, and so forth.

Some remarks. The entire thing ends up feeling tasteless to me: it has a whole bunch of knobs (metaphorical and for a change pseudo-physical), half of which shouldn’t exist and some others which should being missing, with terrible calibration, poor defaults, and just… it lacks a certain je ne sais quoi.

Various factors make me suppose this is low-effort vibe-coding, but I make this response anyway for the potential benefit of others.

• Modular type scales are harmful nonsense. I wrote about it in more detail a few years ago in https://news.ycombinator.com/item?id=36000879. They’re often presented as virtuous, but they actually produce arbitrary, bland, inferior results, mediocre at best.

• The range of base sizes is excessive. I think everyone should agree there’s no point in offering below 14px (8px!), and I wish everyone would agree beyond 24px is madness (32px!). Personally I recommend 16px on small screens, up to a maximum of 18–20px (or if you must, 22px) on large screens.

• Styling all heading levels the same is not a great idea. Yes, I know you have per-element overrides. Encouraging people to treat them the same is not wise. h1 especially is too often not treated differently enough from h2–h6. Sometimes I blame HTML for that, because despite its name, it’s not a heading, it’s the page title. Varying weight, and often varying size massively, between titles and headings and different-level headings, tends to be better than just using an anaemic modular scale with single steps. But there I go on that again…

• The auto-balancing button does some sensible things that show the nature of some of the other problems.

• Changing letter-spacing on headings (as is done by default) is a tad dubious.

• Changing letter-spacing on body text, and word-spacing on any text, should never be done; yet this option is offered.

• For “eyebrow” (interesting term, searching suggests it’s well-established yet somehow this is the first time I’ve come across it), 0.2em letter-spacing is definitely excessive. https://practicaltypography.com/letterspacing.html suggests 5–12% (0.05–0.12em). Incidentally, the per-element overrides doesn’t seem to know about that 0.2em, claims it’s at 0.

• I pressed random preset a few times, got some obviously bad results; e.g. Grand Hotel + Lato has a heading font with significantly smaller metrics than the body one, and where the negative letter-spacing is particularly bad, and where bold is not great. Significantly more than half the time, I strongly disliked the pairing. They felt completely random, even though it felt like half of the presets shown in the list were fine.

I was thinking to myself “… doesn’t it have that?” then I remembered I was thinking of the Public Transport Victoria journey planner.

I think it was a poor choice of example, because people will expect payment to be involved. They’re actually just inserting a row into a database for the order; presumably payment is to be handled out-of-band.

I don’t know how much a human was involved in making this, but clearly not enough. Some parts of the timing it’s talking about make no sense, the ordering of some parts is incoherent, and it promptly goes into unreasonable and irrelevant detail while completely missing other actually relevant aspects of that detail. For example, “HSTS preload”: it’s utterly irrelevant, because you already know it’s HTTPS; and even if it were HTTP, you should talk about HSTS, the preload list is effectively just a prefilled cache; it then adds more to that cache as you visit sites that have HSTS headers.

I’m very confident that if I looked further I’d find it riddled with errors. I just skimmed it and looked at a couple of the bits I’m most familiar with and immediately found notable errors.

You’re talking about writing it. The question here is reading it.

I already addressed that in this ancestor thread.

SVG is completely unsuitable for recording pen stroke data, and fairly unsuitable as a publishing format for handwriting. It’s capable of representing a technical pen/fineliner with opaque, constant-width stroke tolerably well, but nothing else. For all other pen styles, you need variable stroke width (for which you have to switch to using a filled instead of stroked path, bloating it hugely and making it essentially uneditable), and also want some degree of variable opacity and/or texturing of the stroke (both impossible in SVG).

The domain has changed hands. What it was then is now at https://handwritten.danieljanus.pl/.

You haven’t engaged with my second paragraph, or my responses to other responses in this thread. Meaningful inconsistency is already easy with just Unicode, nor does limited HTML make things materially inconsistent.

I was very disappointed, when that happened, that the paper aspect of it was purely at authoring time; that it was converted into text. This one gets it right, preserving the handwriting aspect.

It’s genuinely easier to get it right than to get it wrong.

When an XML document contains HTML, the DOM representation is of elements in the http://www.w3.org/1999/xhtml namespace.

When you parse a document or fragment that is in HTML syntax, the DOM representation is of elements in the http://www.w3.org/1999/xhtml namespace.

There is no difference.

Here’s one verse from the Bible itself that shows that language changed: 1 Samuel 9:9:

> (Formerly in Israel, when a man went to inquire of God, he said, “Come, let us go to the seer”; for he who is now called a prophet was formerly called a seer.)

I love that one because it translates so well into English because we also have an older and a newer word for close enough to the same thing. Though when saying older and newer I should note that the words “prophet” and “seer” have been used consistently since the very first English translation, Wycliffe’s in ~1382. Maybe it’s more the feel of the words. (In Bible Gateway’s catalogue of English translations, only the CEV doesn’t use both of those words: <https://www.biblegateway.com/verse/en/1sam9.9>; I disqualify OJB as not English.)

That’s the only one I can think of off the top of my head that’s specifically about language, but there are plenty of others about changed customs over time, in Old and New Testaments.

Even the trends should be taken with caution. By the very nature of their collection methodology and Firefox’s user base, they massively undercount Firefox (almost certainly by more than 30%, from the last estimates I remember; and possibly significantly more). I would expect them to heavily undercount Linux for similar reasons.

The blocking is being done by linuxiac.com, not by the government or by your ISP. (If it were done by them, you’d get TLS connection errors over https:, and a message over http: something like “The website has been blocked as per order of the Ministry of Electronics and Information Technology under IT Act, 2000.”)

… yes? It’s simple XML parsing, and then taking it as text, serialised HTML, or an already-parsed DOM tree. You are using an actual XML parser, right?

In most environments it’s no harder, and in browsers themselves (which is where half of it is consumed) it’s arguably easier.

As far as I can ascertain, and as I described in the last section of this article, they never actually supported it meaningfully. I believe that the iTunes client got Atom support, but not the iTunes Music Store, and that was the part that actually mattered.

> Imagine the same title in a list of post titles.

Sounds wonderful. I think you aren’t realising that it’s already easy to abuse this stuff, with uppercase and exotic Unicode letters <https://yaytext.com/> and such. But people don’t abuse it in feeds.

I’m not talking about allowing <font face=Impact style=color:red>, just some relevant semantic HTML elements like <code>, <em> and <kbd>, which are pretty harmless to add, and useful.

Perhaps I should have gone with the MATHEMATICAL MONOSPACE characters for my plain text title. Alas, HN strips them. Demo in https://temp.chrismorgan.info/2026-08-02-titles.html. Doesn’t look any good for me with my specific fonts, would look better for some people.