Syndicate content
Updated: 12 hours 31 min ago

Thidrekssaga VI: A quarrel about Mimung

Tue, 11/24/2020 - 4:05am

Just now I published part VI of the Thidrekssaga: A quarrel about Mimung.

Here the saga reports about the quarrel between Witig and Heime about Mimung in the context of two wars and a search-and-rescue story.


Thidrekssaga V: Detlef

Wed, 11/18/2020 - 3:43am

Just now I published part V of the Thidrekssaga: Detlef the Dane.

The hero Detlef comes to Dietrich's court, initially as a servant, but he pawns off the heroes' equipment to give a great feast. Once that is discovered he has to fight a duel of strength against Walther, and wins. Thus he becomes a hero of Dietrich. Also, this part shows the start of the quarrel between Witig and Heime.


Thidrekssaga IV: Journey to Osning

Wed, 11/11/2020 - 1:46am

Just now I published part IV of the Thidrekssaga: Journey to Osning.

This is a complex story that tells how Dietrich wanted to forget his defeat by going on a journey alone. He defeats the hero Ecke in a curious, myth-heavy nightly fight in a forest, then makes Ecke's brother Fasold his follower. Then some frankly unbelievable hunt adventures happen, and Dietrich and Fasold rescue Sintram, Hildebrand's cousin, from a dragon. Thus Dietrich wins two more heroes before returning to Bern.


Thidrekssaga III: Witig

Tue, 11/03/2020 - 2:55am

You’re in for a treat today. Just now I published part III of the Thidrekssaga: Witig.

It is the second best story in the entire saga, and I give a complete version with only minimal notes. We hear how Witig Wieland's son and bearer of Mimung comes to Bern to fight with Dietrich, how he encounters Hildebrand and Heime along the way, and how Hildebrand becomes worried for Dietrich, mostly because he knows Mimung is better than Dietrich's equipment. We also hear how he solves this problem and teaches Dietrich a lesson in the process.


Monetisation models and user hostility

Thu, 10/29/2020 - 3:00am

Recently Krijn pointed me to the Brave Rewards programme, and asked me what I thought of it. I immediately thought “Meh” but it took me a while to figure out why. Now I know.

If I understand correctly, the Brave system works as follows: you can give money to your favourite content creators (yay!), and can either donate that money yourself to Brave for redistribition (yay!) or earn it by watching ads (booh!). There is considerable choice involved in viewing ads (mkay...).


I tried signing up as a content creator, and now I’m in the phase where I have to pick a payment provider and do all kinds of complicated steps. I haven’t done so yet. The user-friendliness of these steps is appalling. I do not hold this against Brave, because other systems, notably Coil, have the same problem.

Signing up for payment services is a complete hassle, because you don’t know what you’re doing while being granted the illusion of free choice by picking one of two or three different systems — that you don’t understand and that aren’t explained. Why would I pick EasyMoneyGetter over CoinWare when both of them are black boxes I never heard of?

Also, these services use insane units. Brave use BATs, though to their credit I saw a translation to US$ — but not to any other currency, even though they could have figured out from my IP address that I come from Europe. Coil once informed me I had earned 0.42 XBP without further comment. W? T? F?

As long as signing up for an unclear, but probably tiny, reward in made-up units remains such a complete hassle few people will do it. We can’t roll out monetisation with such aggressively user-hostile sign-up and accounting processes in place. We are not cryptocurrency nerds. We just want to get paid.

Oh, and you should remember your password for the payment system in addition to the password for the redistribution system. And if you lose it, you should remember where your special code that I can’t remember the name of is stored — a code you get during sign-up without any indication that it is vitally important, and that is offhandedly and unclearly referred to in Forgot Password-mails. (True story, this.)

The redistribution system that first manages to hide all this junk from the user by reporting in real-world units and by just signing them up to a payment service automatically, without fake free choice — or, better still, by becoming a payment service — will have a significant competitive advantage because regular folk can actually use the system.


These problems are shared by Coil and Brave. The difference between their models boils down to ads. Coil has no ad component; you just pay Coil, and it redistributes your money over the sites you visit, weighted by time spent. Brave does something similar, but it also allows you to watch ads to earn more money to redistribute. This may sound great, but to me it doesn’t really.

Why involve ads at all?

Shouldn’t we teach people to pay for content they like? To see paying as a matter of honour, and of keeping the web clean and healthy?

I feel that involving ads shows that you’re unwilling to think outside the box. OK, it’s easy money, but in order to truly take back the web we have to break our dependence on easy ad money streams and travel the more complicated route of actually asking people to actually pay for what they consume — to tear down the free content entitlement that’s one of the least appealing aspects of the web development community.

YOU should pay. In, like, money — and not in “attention.”

But the Valley is unable to think outside the ad box. I don’t think we should look to it for a solution.

To me, the entire point of the coming wave of monetisation is to get rid of ads. Brave isn’t doing that — yet. That’s why I dislike its model and prefer Coil’s.

Thidrekssaga II: Wieland the Smith

Tue, 10/27/2020 - 3:35am

Just now I published part II of the Thidrekssaga: Wieland the Smith.

Here we are told about Wieland the Smith and why and how he forged the sword Mimung that will be carried by his son Witig and will play an important role in the saga. It is so hard and sharp that no armour can stand against it, as will be proved by an impressive casualty list, starting with a competing smith. Even Dietrich himself will have to contend against it.

Note that Mimung is not a magic sword — in fact, the saga tells us exactly how it is forged, and the tale even makes chemical sense. No ladies in lakes here, or even dwarves, although Wieland was apprenticed to dwarves and might have learned his art there.


Linkbait 47

Mon, 10/26/2020 - 4:18am

Insert funny tagline here.

  • The State of CSS 2020 survey is running, Please take it! It’s important for fifguring out where CSS should go next, and what people actually know. Slight disadvantage: you have to register. I’m not totally sure what to make of that, and hope that future versions leave it out, but in the end I did register because I think the survey is important enough.
  • Excellent question: What does 100% mean in CSS? I always tell my CSS students to ask that question, and sometimes the answer is non-obvious. This page treats a few of the simpler use cases, as well as margin and padding, which are not so much complicated but rather counter-intuitive.
  • Rachel Andrew explains CSS masking. Does more need to be said? No.
  • Lea Verou invents a way to unset CSS custom properties. This can be very useful for toggling page-wide or component-wide states. The trick? Simply making the custom property’s value a whitespace. It’s allowed, but doesn’t have any meaning, ergo, the property is unset.
  • Nicholas Zakas explains JavaScript promises (in a multi-part series) by writing a promises tool, which requires you to fully understand the underlying technology.
    I mainly include this for myself; I need to fully understand promises as well, and this series is just what I need.
  • Coil, the most interesting web monetisation project of the moment, releases its developer site. Unfortunately, creating a Coil account is not a smooth process, but this page helps. Also gives information about the web monetization standard. Still fairly bare-bones, but hey, it’s been out there only for a couple of week. Let’s give it time to grow.
  • Oh, and TechDirt decided to give Coil a spin and see what happens.
  • Another money-related system is Libra, though it is not specifically for the web. Instead, as far as I can glean from the fairly bare-bones information, it works by storing money on your phone, like systems such as mPesa do. Also, it has a new programming language (why?) and buzzwords.
    Not to disparage them immediately, but a clearer idea how how the system works for users in four paragraphs would have been useful.
  • And privacy: The Global Privacy Control specification and its implementations are coming online. Not yet in the major browsers, but once it works you should be able to have control over what you do and don’t tell websites. Unfortunately Chrome will never implement it; the idea is to much at odds with Google’s interest as an ad supplier.
  • An important piece by Benedict Evans: The end of the American internet. With TikTok, Americans have to face a foreign social network being used massively in their country for the first time. The American internet is over. Let’s see if it adjusts their preconceptions. (My guess: no.)
  • The Mozilla Browser Compatibility Report 2020 is here, focusing on how web developers see browser compatibility. The two top pain points are IE (duh) and layout and style, which is a rather broad category but ties in with my idea that layout is badly understood, though I'm still not sure why. Fortunately the report contains many examples.
  • A Brief Totally Accurate History Of Programming Languages. As it says on the tin.
  • What did the Roman emperors look like? We have quite decent portraits of especially the earlier ones, and the Romans believed in realistic portrayal: if you have a wart on your nose your portrait has a wart on its nose. Now this has been taken one step further by adding some modern algorithms to the portraits, stirring in some ancient written sources, and the result is life-like portraits in modern CGI. No proof that these are 100% correct (skin colour is rarely described explicitly, for inatance, and cannot be inferred from marble busts), but it’s still fascinating to see.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Notes on the web, take 2

Thu, 10/22/2020 - 5:23am

Today I updated the Thidrekssaga mini site with a first attempt at a decent mobile view. I also did some work on the mobile view for the notes, and I’m asking for a quick review.

As I discussed two weeks ago I want the notes to my texts to be visible at all times in order to emulate the footnote experience in books. I was worried about mobile devices, since with their narrow screens there is not much space to show both the main text and the notes.

I was afraid I’d have to show the notes under the paragraph they belong to, but today I figured out a way to avoid that and keep them in the margin. My question is if this system is good enough.

Chapter 352 is a good test since it contains a lot of notes in a single paragraph. So please go to that chapter on a mobile phone of your choice and try to access the notes.


  1. Although it is impossible to show the full notes on narrow mobile screens, I want to show at least a little bit of them so that users know there are notes.
  2. When touching/clicking the notes they should not only be highlighted, but also scroll into view for easy reading. This is the bit of interaction I’d particularly like feedback on. Good idea or bad? If bad, why?

The notes are still positioned absolutely, and thay may mean they cover one another. The feedback to my previous article convinced me that this needs to be changed, but I haven’t actually done so yet. So please do not comment on this problem. I have a vague idea what to do, but that was predicated on the idea that I had to show the notes below the paragraphs on mobile. If that turns out to be unnecessary I will have to revise my idea. (Also, it would require some serious grid magic.)

On my iPad with iOS 14.1, Safari refuses to scroll smoothly to the notes. Apparently it does not support the behavior: 'smooth' option of scrollIntoView(). That surprises me a bit, since usually Apple is gung ho on smooth animations and behaviours. I assume there’s a performance problem in extreme scenarios. A quick search for alternative syntax or something yielded nothing.

Technical details

Technically it’s quite simple. I added the meta viewport and a single simple body rule that does away with most of the left margin but adds a fat padding-right.

@media all and (max-width: 850px) { body { margin-left: 1em; padding-right: 2em; } }

The padding-right makes the paragraphs contained in the body somewhat less than 100% wode. Since the notes are positioned relative to the paragraphs, they, too, are drawn leftward, and that makes them just barely visible on the right edge of small screens — enough to alert the user they’re there, or so I hope.

One drawback of this fat padding on the body is that when the user double-taps on a paragraph of main text the browser zooms in to the width of the paragraph, and not the body. This may mean the notes are not visible any more. I’m not yet sure what to do about this, or, indeed, whether to do anything at all.

e.target.ref.scrollIntoView({ behavior: 'smooth', block: 'nearest', inline: 'end', });

A simple scrollIntoView(), called onclick, delivers the finishing touch. This makes the browser scroll to the note or back to the marker if necessary; and if it’s not necessary nothing happens.

  • behavior: 'smooth': scroll smoothly. Doesn’t work on iOS.
  • block: 'nearest': don’t scroll in the block direction (i.e. up or down) unless required — and it should never be required. I don’t fully understand this option yet, but it does what I want.
  • inline: 'end': in the inline direction (i.e. left to right), scroll to the very end (the right). This makes the note scroll fully into view, and markers are also scrolled as much to the right as possible, which effectively means the main tex column is fully in view.

Thidrekssaga I: Dietrich's youth

Tue, 10/20/2020 - 7:10am

I have been busy with my Thidrekssaga side project. Today I start a series that I call A First Reading, or a guided tour through the saga, with the first part: Dietrich’s youth.

I temporarily shelved technical considerations such as footnotes (which are really sidenotes) or a decent mobile view in favour of producing actual content. I enjoyed reading through the saga again and meeting old friends, although I may switch to technical stuff now just to give myself a varied diet.

Anyway, enjoy Dietrich’s youth. If you like it, we will need about twelve to fifteen of such articles to bring us to Dietrich’s death and the end of the saga.

Notes on the web, take 1

Tue, 10/06/2020 - 3:22am

I decided to definitively solve the problem of notes on the web in the context of my Thidrekssaga side project. What I offer today is not that definitive solution, but just my first take. I’m looking for feedback.

So let’s talk notes.

First we should ask ourselves how notes should work on the web. Then we’ll look at the technical details of my first take.

Please open my first, as-yet insufficient, version in a new tab or something; I’ll refer to it from time to time. Today’s question is whether this is a good (the best?) way of visually displaying notes.

The user experience

My purpose with this side project is to transfer the user experience of footnotes in books to the web. So let’s first be clear on what we want to achieve.

Take a look at this page from the Quedlinburger Annals in the historical source collection MGH. It uses traditional footnotes, and this is the effect I’m after.

The purpose of such traditional footnotes is to allow the reader to rapidly scan both main text and notes, or to even go through the notes first and then find the main text sections they apply to. The crucial part is that both main text and footnotes are on the same page; above the fold, in web terms. By moving their eyes readers can quickly scan both of them.

Footnotes should also allow the reader to scan the notes first and then find the main text they apply to. This is a valuable method of reading, since you may find unexpected material in the notes that is not mentioned in the main text.

On the MGH example page, the notes contain clarifications as well as references to the Liber Pontificalis, another source. By reading main text and notes at the same time, the reader can view the clarifications in the context of the main text, and can find out exactly which bits of the Annals use the Liber Pontificalis as a source.

The other option is to place all these notes at the end of the book; to make them endnotes. I dislike books with endnotes because the user experience is just wrong: it is hard to find the note you want, and it is impossible to go back from a note to the main text it refers back to.

When we port footnotes to the web, the worst thing we can do is place them at the end of the document. It is likely the reader will be unable to see main text and notes at the same time: they have effectively become endnotes. What we should do instead on the web is place the notes to the side of the main text.

Footnotes in book => side notes on web
Endnotes in book => footnotes on web

So that’s what I’m aiming at with this first take. The notes are to the right of the main text, and the reader can scan both of them at the same time. This is the proper user experience.

There’s one practical technical advantage to using side notes as well: you don’t need backlinks.

If you use footnotes on the web (i.e. what would be endnotes in a book) each saparate note must refer back to the note market in the main text, like Wikipedia does. If we use side notes such links are not necessary, since the user will be able to see both texts at the same time.


With our purpose clear in our minds, let’s start coding.

Here is an example of HTML with notes from the example. This is how I, as an author, would like to write the main text plus notes. (You can see this code example as XML instead of HTML if it helps you; it is not quite the code the browser works with.)

<p>Thus king Hertnit gathered a great army. And his wife Ostacia went out and moved her hand<note><span lang="non">hrærði sinn gand</span>; Google Translate gives "stirred her hand". Von der Hagen says "<span lang="de"> rief ihre Götter an</span>", which is unhelpful.</note>, which is what[...]</p>

Then a script (JavaScript in the example page, but PHP in the main application) adds two spans and a tabindex to each note:

<p>Thus king Hertnit gathered a great army. And his wife Ostacia went out and moved her hand<span class="note ref" tabindex="0"></span><note> <span class="note"></span> <span lang="non">hrærði sinn gand</span>; Google Translate gives "stirred her hand". Von der Hagen says "<span lang="de">rief ihre Götter an</span>", which is unhelpful.</note>, which is what[...]</p>

Once the main note has been lifted out of the text flow the first span remains in place as the container for the note marker, which is a simple CSS counter.

span.note:before { content: counter(notes); }

The tabindex is for keyboard accessibility: users can ow tab through notes. In itself this is worthless without a highlight functionality, which we’ll get back to later.

A few more remarks about this HTML structure:

  1. The note text comes directly after the text it refers to. As an author I find this the easiest way to write notes. A possible downside would be that screen readers read the note text as part of the main text. Right now I assume they do; the question is whether we can solve that problem. If we can, I feel that this is the best way of authoring notes. If we can’t we have to revise this somewhere; for instance by moving the notes to their own paragraph or something.
  2. I currently use a <note> tag even in the rendered HTML. This is wholly my own invention, non-standard, and non-validating, and will eventually be replaced by whichever HTML element turns out to be the correct one. (But which one is correct turns out to be a fairly tricky question.) So for now I’ll stick with <note>.
    There’s no problem for CSS and JavaScript: they always work on all elements, whether they’re officially HTML or not, so I can style and script the <note>.
Moving the notes to the side

Now it’s time to create a visual side note. The <note> element itself is taken out of the main flow and positioned to its right. There’s a slight trick here not everyone may know: We give the note an absolute position, but do not set the top, which effectively means top: auto. Now the note will stay at the original top it had as a static element, and thus on the same line as its marker in the main text. This has always worked in all browsers. (Of course left: auto works the same, but horizontally.)

note { position: absolute; left: calc(100% + 1em); /* implied top: auto */ width: 15em; padding: 1px calc(1em + 1px); }

There is one huge drawback to this technique: if there are two notes on the same line they end up in the same position on the side, and the last one is on top of all earlier ones — the effect occurs in the example page.

What to do? First, we need to highlight individual notes when the user interacts with them (see below). But even if that works brilliantly, it would be useful to give a visual hint that a note is hidden under another one.

For a brief moment I hoped the CSS counters I already use could be used to do this, but no such luck. I hoped for something like this:

note { margin-top: calc(--var(counter(notes)) * 1 )em; /* nah */ }

Take the counter, re-interpret it as an em value, and set the margin-top to that value — but that doesn’t work yet. It turns out that using counters in variables is being discussed but not yet operational. If anyone needs another use case, this is one.

For now I’ll do nothing, but I’ll have to revisit this question in the future.


Now we need a highlighting function. If the user mouses over (or tabs to) a note marker it is helpful if the note itself is highlighted. We could do this with pure CSS:

span.ref:hover + note,span.ref:focus + note { /* highlight styles */ }

The problem is that I also want a reverse highlight. If the user mouses over notes, I want to highlight the note marker in the main text. This is not possible by CSS alone, we must use JavaScript.

For now I decided to implement both highlights in JavaScript because I do not like mixing two layers for the same effect. document.addEventListener('mouseenter',addHighlight,true); document.addEventListener('mouseleave',removeHighlight,true); document.addEventListener('focus',addHighlight,true); document.addEventListener('blur',removeHighlight,true); /* and make sure they're executed only on notes and note markers */

(Remember, in the bubbling phase, with false as the last argument, focus and blur events never end up at the document level. But in the capturing phase, with true as last argument, they do. So that’s what we use.)

The mouseenter/mouseleave pair also gives us a first approximation of a touchscreen solution. When the user touches a note marker or note, eventually the mouseenter event is fired and does its thing. When the user touches something else the mouseleave event fires. This is not yet a perfect touchscreen solution, since the dreaded 300 millisecond delay is operational, but for this primitive version it’s good enough.

So far I like the highlight effect a lot; it’s that bit of usability that makes the notes easier to use. The only question is if I should still split off the marker-to-note highlighting and inplement it in CSS after all. Right now I’m not sure.


So this is where we stand, and here are the questions we should solve:

  1. Is the current version the best way to visually render side notes? Or is the overlap effect a show-stopper?
  2. What HTML element are we going to use for the note text? I’ll eventually have to replace <note>, but with what?
  3. What accessibility problems do we encounter when the source code leaves the note texts embedded in the main text? Are these problems solvable by, for instance, an ARIA attribute? (I don’t know ARIA well enough to answer that last question.)
  4. Should we implement the marker-to-note highlighting in CSS, even though note-to-marker must remain JavaScript? The benefit would be that the highlighting even sort-of works without JavaScript, the drawback is more complicated code.
  5. Do we need a radically different highlighting user experience for touchscreen, or is the current version kind-of good enough? (I’d like to get rid of the delay in any case.)

For now I’ll await feedback and continue summarising the saga, which gives me a larger corpus of notes to play with. Once enough feedback has come in I’ll create take 2.

Side project: the Thidrekssaga and footnotes

Fri, 10/02/2020 - 3:18am

Long ago, before I became a web developer, I was a historian of the Later Roman Empire. One of the texts I studied was the Thidrekssaga, a 13th-century Old Norse story about the great German hero Dietrich von Bern and several others, such as the Niflungen, better known from the Nibelungenlied.

When I went into web development I mostly stopped this research, but recently I decided to restart it by writing an extended summary of the Thidrekssaga. Except for being useful in its own right, this side project forces me to learn PHP and Old Norse.

For those few who are interested in such matters, here is the Thidrekssaga site I am creating. I might set up a blog about the saga and related topics; I’m not sure yet. For now I wrote an introduction to the saga for those who are new to it, and I summarised about one quarter of the saga so far.

For those who only come for web development content, you’ll get your reward later. One of the things I aim to do is definitively solve the problem of footnotes on the web.

Right now my implementation of footnotes is mostly shit. I know. I’ll improve them eventually.

Before I do so, I want to have some actual footnotes to play with, instead of just a contrived example. My saga project gives me that. Right now I’m just writing articles and summaries, and I insert footnotes wherever I feel the need. This will eventually build a corpus of real-world footnotes that we can use to determine the best way of showing them on the web.

I create the summary in PHP, a language which I now have about four days’s of experience with. I already noticed that PHP arrays are very, very different from JavaScript arrays, and that I need to re-learn part of what I thought I knew. Also, I loathe the way PHP handles booleans, though I might be missing something here. Maybe there’s material for an interesting web dev article or two here as well.

Stay tuned.

The argument that kills any monetisation discussion

Wed, 09/09/2020 - 1:38am

When I was going through Stephanie Rieger’s presentation about regulation for the web, I had an idea: what if we forced people to pay for social media use?

Today I’d like to discuss not that idea but a counterargument leveled against it: What about people who cannot afford to pay for social media? Wouldn’t they be left behind? This observation turns up sooner or later in any monetisation discussion.

I have a problem with this argument.

Killing the discussion

My problem is not that it’s untrue — I wish it were; that would make any monetisation discussion a lot easier.

My problem is that it effectively kills the discussion.

Giving in to this argument raises the interests of people who are unable to pay to the top of our priority list, trumping the interests of other constituencies, notably content creators. If we accept this argument in full, we are effectively unable to make any further progress — or so it seems to me.

The current system of giving away everything for free benefits people who are unable to pay. That is a good feature, but I feel that the fact that a system has a good feature does not mean we should accept all of the bad ones.

In order to change the status quo we have to temporarily ignore the interests of people who are unable to pay. Considering them, and drawing up plans in case of a (so-far hypothetical) victory of sane monetisation is fine. Killing the discussion in their name is not.

That’s why in the future I am going to respectfully reject this argument while acknowledging it is true. The fact that some people are not able to pay for monetisation scheme X is a problem to be solved, but it is not a reason to reject scheme X.

Paying for access

Assume for a moment that sites like this, or, much more importantly, MDN, require payment, or at least that there is strong social pressure to pay for usage. Some people are unable to do so. How should we solve that problem?

To me, the answer is obvious: create a sort of fund that buys subscriptions wholesale (with a bit of bulk discount?) and dontes them to affected people.

I don’t know a lot about such funds, but I do have ample experience with diversity tickets for conferences, which is a somewhat-comparable use case. In our experience, gathering the money to pay for a few diversity tickets is no problem. Companies will chip in, some speaker will waive their fees, or sometimes even their travel budgets, we’ll give a discount and add one or two free tickets, and before we know it we have enough budget for about ten diversity tickets.

Access costs less money per person than a diversity ticket, although we need many more units. That’s why I am assuming that acquiring the budget to pay for access for even a few hundred people is quite possible, although it may take some time.


The problem lies in the selection. Who exactly should receive support from this fund?

This is usually the bottleneck for our diversity tickets, because we decided long ago that we ourselves are not going to take that decision. We used to use a service that made a selection for us, but even before the Corona crisis broke they decided to cease their selection service. That leaves ... nothing, as far as we know.

A hypothetical system that pays for access to content would run into the same problem. Who deserves such support? Who decides who deserves such support? Somebody will have to take decisions here, will have to — dare I say it? — keep the gate.

But who? To me, this is the crucial question. I have no easy answer.

If you have an answer please share it. Note, however, that I’m looking for something structural, something that can stay in place for years and years to come. Right now I’m not interested in temporary solutions.

Or do we want to keep the current system in place so that we don’t have to answer this question?

Or am I worrying too much and will the situation sort-of solve itself? Am I maybe erecting a straw-man argument? I just don’t know right now.


As to my original idea of paying for social media usage, feel free to think about it, ask hard questions like Dean Bubley did, and mull it over in your head, but the more I think about it, the more I feel that it’s too complicated to actually execute.

Linkbait 46

Wed, 08/26/2020 - 3:45am

Baiting you into clicking.

  • This presentation by Stephanie Rieger makes the case for regulation of the web in order to get rid of hate speech and fake news. Worth thinking about.
    While reading through it I had a thought: what if we’d require payments for social media memberships? It’s certain to be quite complicated, so before we do anything we should discuss if it would help at all.
  • Rachel Andrew explains an interesting payment experiment that I missed: Igalia, the company that implements rather more browser features than most people know, started an Open Prioritization drive where people can pay to get CSS features implemented. Once a feature is fully funded it’s pushed into Igalia’s work queue.
    Simple idea, might work. More of this, please!
  • An ambitious project: Web History, chapter 1: Birth, chapter 2: Browsers, and chapter 3: The Website. The first chapter is less interesting to me, because I already know most of the story. 2 and 3 already contain a few items I didn’t know about. I expect this series to become much more interesting to me once we get to later chapters, the ones I can remember.
  • Nice project: Modern CSS solutions for old CSS problems. It revisits a few golden oldies such as always keeping the footer at the page bottom no matter the content size. How would we solve these problems with modern CSS?
    Even better, Stephanie Eckles is running Style Stage, a showcase site where people can provide their own CSS for a given HTML page. (Sounds familiar to an old-timer?) Let's hope it’s a massive success; we need it.
  • Interesting details about CSS gap: it’s supported on flex and grid, except in Safari, where it only works on grid. And how do you detect support? Safari does support gap, so @supports (gap: 1em) will return true but hide the fact that it’s not supported on flex. (See also this discussion.)
    Ahmad Shaheed offers a JavaScript workaround that works, but it involves creating and measuring a test element, which is something that could kill your performance if overused.
    Anyway, interesting read if you’re into the problems of @supports, as I am.
  • An in-depth look at the load and DOMContentLoaded events and their differences. Contains quite a few details I didn’t know about, such as the rules for deferred and async script tags. Worth a look if you’re struggling with initialisation and up-front load times.
  • Native JS formatting options for numbers: a very useful overview, with simple pictures to begin with. Turns out there are quite a few more internationalisation options for numbers in JavaScript than I was aware of.
  • An serious discussion of the performance consequences of React and Preact when creating a simple site. The message is familiar: React, and to a lesser extent Preact, degrade your website’s performance. That doesn’t mean you shouldn’t use them, but it does mean you should think before using them, especially in cases of simple websites.
    The article also calls for keeping sites accessible to users of old or low-specced devices. I agree, but the chance of this happening is slight.
  • Speaking of old or low-specced devices, here’s a look at their cost, not in money but in days worked.
    Device cost is but one factor, and connection cost is the other, but it’s an up-front one that people may struggle with. Governments can help here, especially in times of Corona.
  • An interesting story about Yugoslavian microcomputers in the eighties. Turned out there was quite a scene, and one radio DJ even broadcast programs! Programs were stored on cassette tapes (C64 aficionados will know how that goes), and listeners to this show could just tape whatever program the radio station broadcast and run it on their own computers. Never heard of this trick before.
    Update: A reader told me this broadcasting of computer programs also took place in the Netherlands. So it's not as unique as I thought.
  • I always love this sort of project: a to-scale map of the solar system where the Moon is one pixel. Takes a LONG time to scroll through. We are unable to truly understand these huge amounts of space.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

The cult of the free must die

Wed, 08/12/2020 - 4:13am

For a terrible half an hour last night I thought Firefox was on the brink of disappearing as an independent browser and rendering engine. I was frightened silly by the rumour that Mozilla laid off significant portions of its browser team. The official press release being full of useless corporate open web blah didn’t help — the vaguer the press release, the worse the situation, in my experience.

Fortunately, the news is not quite that bad. Still, it set me thinking.

To my mind, Mozilla’s core problem is the cult of the free. To my mind, we should eradicate the cult of the free from web development, and Mozilla should take a small step in that direction by requesting donations from inside Firefox — on an entirely voluntary basis.

First, though, let’s review the news. From what I’ve been able to cobble together from Twitter, the layoffs have severely affected devtools, the Servo team, MDN, and likely also the events/sponsorships team. The core Gecko team is unaffected, and that’s good. Firefox will continue to exist as an independent browser — for now.

From a money-saving perspective the gutting of the events team is understandable. Frankly, I’ve been wondering for years where Mozilla got the money to run all their events and sponsorships. Now we know the answer, I guess. It will have a minor effect on me as a conference organiser, but it can be survived.

The other three are more serious: although the core Gecko team survives, many supporting teams have been gutted. If this is the last round of layoffs ... ok, we can survive this. But if it isn’t ...

The cult of the free

The gutting of MDN strikes closest to home. Part of the reason I stopped doing browser research is the advent of MDN: it took over my role of documenting web standards (and sometimes browser differences) quite efficiently, so this site was less vitally necessary.

The bigger reason I stopped doing research, however, was that I was tired of doing all of this vital web-supporting work for free. That’s also the main reason I never contributed to MDN; I don’t mind doing it, but I do very much mind doing it for free. I’ve done my duty.

And who is going to give web standard and browser compatibility information now that MDN might go away? For a few minutes I considered returning to my old job, but I refuse to do it for free, and there is no financial support in sight.

Truth, I made some money with my work. In the end Google, Microsoft, and Mozilla granted me sponsorships for a few years. It wasn’t enough, though. And of course Apple never paid up, even though from the release of Safari/Mac to the release of the iPhone they referred to my site for JavaScript compatibility information. For a while I was the Safari documentation team — for free.

This brings us to the core point I’d like to make: the culture of volunteering in web development, and especially within the Mozilla segments of our community. To my mind it’s not only outdated and should be replaced, it should never have been allowed to take root in the first place.

I see the cult of the free as the web’s original sin. To my mind it’s an essentially random historical development that could have gone quite differently, but, once the idea of everything on the web being free took root, became a cultural touch point that is almost impossible to dislodge.

Granted, the cult of the free also has its positive points. But today I’m focusing on the negative ones that, to my mind, outweigh the positivity by a rather large margin. If we continue to give everything away for free, the big companies will win.

Small company gives away software for free. Large companies give away the same software for free, and to them the cost is essentially peanuts, and they own the platforms the sofware runs on. Therefore small company will lose, decreasing diversity in the browser market. Simple as that.

Asking for donations

Isn’t it time to change this? Isn’t it time Mozilla distances itself from the cult of the free? I know it’s deep in their DNA, but that hasn’t prevented it from hitting a very rough spot. Maybe the model is not as viable as we all thought.

So allow me to make a modest proposal: build in a donations function in Firefox itself — for instance by adding a simple “Please support us” message to the update page you get to see whenever you update the browser, and by adding a Donations item to the main menu.

Oh, and don’t bother with perks for paying members. It’s not about perks, it’s about supporting the software you’re using. The software is the perk.

I’m not saying Mozilla should erect a paywall around Firefox. That would far worse than the problem it’s supposed to solve. (The fact that it would be such a terribly bad move is part of the problem, though. If people had just learned to pay for the good stuff ...)

I’m also not saying this will solve Mozilla’s financial problems — in fact, I’m quite certain that it won’t. Still, it would be one step in the direction of a better web where consumers slowly get used to the idea of paying. Also, it might help Mozilla itself veer away from the cult of the free towards a more sustainable model, mostly by putting psychological pressure on the organisation as a whole.

We need a break with the past. Trying times like these might be the best opportunity to make that break.

The cult of the free must die so that Firefox may live.

©2003 - Present Akamai Design & Development.