Bryce WrayModify

2026-06-21 05:21:00

Apple may never give us this answer to a long-standing itch; but, fortunately, someone else did.

We macOS users have long been familiar with using Apple’s included TextEdit app for, as the name suggests, editing plain-text files. However, we macOS users who also like using Markdown have found TextEdit lacking — it can open and edit such files, of course, but it can’t do Markdown-ish things in them — and wished Apple would make it Markdown-savvy. While there’s no indication Apple ever intends to do that, the good news is that there now is a FOSS app, MarkEdit, which is essentially TextEdit that speaks Markdown. And that may well be good enough.

The vast majority of my Markdown-editing endeavors over the last few years, especially for this website, have been spent in iA Writer, and I suspect that will continue to be the case long-term.¹ That said, I wrote this post mostly in MarkEdit, and found the experience to be a good one.

Other than its ability to be “Markdown-savvy TextEdit,” another of MarkEdit’s key advantages is that it’s a native macOS app. To put that another way, it doesn’t rely on Electron or any other bloated framework. This keeps it small (four MB as installed), light, and quick, even on older Macs — although it’s mainly for newer ones, albeit with special, additional versions for macOS iterations from several years ago. MarkEdit also works, looks, and feels like a real macOS app. As its GitHub page explains:

UI controls remain native to macOS in both aesthetics and behavior, including force-touch word lookup, inline predictions, and Writing Tools.

Oh, and for those like me who care about such things: it appears MarkEdit is not (yet?) vibe-coded. How long that will continue to be the case, I obviously can’t know; but, for now, MarkEdit seems to be a human(s)-built endeavor.

Correction: I looked again at MarkEdit’s GitHub repo and saw that multiple LLMs are in the list of contributors. [Sigh.] My apologies for the mistaken and now stricken-through assumption above.

Incidentally: to date, although the original TextEdit is on iOS/iPadOS as well as macOS, MarkEdit is macOS-only.

One other (and unrelated) item while I have your much-appreciated attention . . .

I’ve spoken here a number of times about how I converted my old Intel iMac to Linux. Most recently, my Linux distribution of choice was the Arch-based CachyOS, after I’d spent over two years with Fedora. But, while I still think CachyOS itself is pretty interesting, I’ve now reversed course and gone back to Fedora because of the craziness — still ongoing as of this writing — that we’ve seen in the Arch Users Repository (AUR) over the last few weeks. Yes, I knew and observed the correct procedures for safely using the AUR; and, besides, I really wasn’t using the AUR all that much anyway (just two packages, one of which is provided by no less than 1Password); but I simply felt better and safer in going back to Fedora. At my age, I’ll gladly pass up a little performance for greater peace of mind.

Reply via email

2026-06-04 03:27:00

AVIF support in Hugo, hashes in action(s), floaters, and clankers.

For no major reason other than that I feel like writing about a few odds and ends which have recently occupied my mind, here’s yet another “Mixed nuts” post.

Although I haven’t yet tried it on this here site, the Hugo static site generator has added AVIF support to its already impressive image processing capabilities as of v.0.162.0. The curious may want to check out this demo repo and its corresponding site. Note that, apparently, not all browsers handle the HDR aspects equally well.

When I build this site through CI/CD, I typically use a GitHub Action which, in turn, calls on other actions to facilitate things — e.g., checkout for accessing the site repo’s contents. After reading about one supply-chain attack after another over the last few months, I finally decided to heed widely discussed advice and pin those actions by their respective commit-hashes, not their release tags. This means that even if a bad actor manages to hijack the repo of (again, e.g.) checkout, my overarching GHA won’t be affected. This article by Rafael Gonzaga explains; and this one on the StepSecurity website gives you additional details, notably how you get each hash in the first place.¹

Ah, me, but getting old does so bite sometimes. To quote T. S. Eliot’s The Love Song of J. Alfred Prufrock:

I grow old . . . I grow old . . .
I shall wear the bottoms of my trousers rolled.

Shall I part my hair behind? Do I dare to eat a peach?
I shall wear white flannel trousers, and walk upon the beach.

Well, that’s all well and good, but Eliot never said a word about floaters; and, boy, are they ever in my eyes (which are both aged and myopic², an especially floaters-friendly combo). So much so, in fact, that my web-browsing habits have veered away from a position I took here six years ago — in one of the earliest “Mixed nuts” posts, as a matter of fact — on the question of light mode vs. dark mode. Despite studies I cited back then, I am now making use of dark mode whenever possible because, simply put, the floaters make reading light text on dark backgrounds far less aggravating than is the case with dark text on light backgrounds. I will reserve judgment on the trousers, the hair (as if I had enough to consider), the peach, and the beach.

I’ve added another “slash page.” This one explains my stances on AI where the site is concerned. The bottom line: I don’t use AI for writing, although I do let it give me limited assistance in coding. The day when I can no longer write without the help of clankers will be the day when I call it a day, website-wise. There’s already enough slop out there without this site’s adding to it.

Reply via email

2026-05-05 04:29:00

Improving my scripting following hvm’s recent changes.

Late last year, I had to adapt this website’s repository to accommodate a change in how Hugo’s macOS version is packaged. In short, I started to use the hvm (Hugo Version Manager) app to manage my computer’s use of the Hugo binary. More recently, after a change to hvm itself, I made a further adaptation. Fortunately for me, as in the case of that earlier post, Hugo maintainer and hvm creator Joe Mooring gave me help in overcoming, as I described to him, “my embarrassing lack of scripting-fu.”

I will assume you’ve already read the aforementioned post from last December; that way, I needn’t go into a huge amount of detail about why I switched to hvm, how it works, and so on. Instead, this post is about the latest incarnation of hvm, how it works, and what that meant — and, to be fair, made possible — for my purposes.

When I first began using hvm, it was at v.0.9.0. At that point, and for a few versions thereafter, it was providing only one edition of Hugo, the extended one. As a result, hvm’s auto-generated .hvm file needed to give you only the Hugo version number being used by your repo, such as:

v0.153.0

Then, a few weeks ago, Mooring released hvm v.0.14.0, the first version which allowed the user to choose from among multiple different Hugo editions. Currently, those are standard, standard-with-deploy, extended, and extended-with-deploy.¹ This change in hvm, thus, would require the resulting .hvm file to provide more information. For example, as I write, here is the content of my repo’s .hvm file:

v0.161.1/standard

I initially thought this change would bollix up the local scripting I described in that previous post, but it didn’t because hvm 0.14.0+ installs the user-specified Hugo binary in a directory structure that corresponds exactly to the mini-path in that .hvm file. In other words, this:

/Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo

. . . still works the same, because $HUGO_VERSION continues to be the same as what’s in .hvm:

/Users/$USERNAME/Library/Caches/hvm/v0.161.1/standard/hugo

I got an additional benefit from hvm 0.14.0+, thanks to Mooring’s helpful suggestion: it now makes my site-deployment CI/CD a little less needful of my attention. (After all, automation is supposed to be less troublesome, not more so, than doing everything manually.) He showed me, in part of a demo repo he maintains, how he uses the .hvm output to tell a GitHub Action which version of Hugo it should download. Previously, I’d always provided that information through manually updating my GitHub Actions workflow file whenever I updated Hugo. Now, with a slight variation² on Mooring’s code, the workflow file gets that info from .hvm:

- name: Hugo download/install
 run: |
 if [ -f .hvm ]; then
 hvm_raw=$(cat .hvm)
 HUGO_VERSION=$(echo "${hvm_raw%/*}" | tr -d 'v')
 fi
 wget https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-amd64.deb -O hugo_${HUGO_VERSION}_linux-amd64.deb
 sudo dpkg -i hugo*.deb

In the third line of that if/fi loop, ${hvm_raw%/*} reads the .hvm file’s contents up to the slash, while tr -d 'v' removes the v that precedes the version number (since that v isn’t used in the actual file names for the Hugo release assets). The result provides only the Hugo version number as HUGO_VERSION, which the succeeding lines use to download the desired version of Hugo onto the GitHub Actions runner.

Incidentally, if you prefer a GitLab CI/CD version of this, here’s one I’ve used:

- >
 if [ -f .hvm ]; then
 hvm_raw=$(cat .hvm)
 HUGO_VERSION=$(echo "${hvm_raw%/*}" | tr -d 'v')
 fi
- echo "Downloading and installing Hugo v.$HUGO_VERSION ..."
- curl -LJO https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-amd64.deb
- apt install -y ./hugo_${HUGO_VERSION}_linux-amd64.deb

Of course, given how the various CI/CD platforms seem increasingly overwhelmed by AI-created traffic, I may end up reverting to my previously used direct deployment method — in which case, I wouldn’t have to inform any remote code runner of the Hugo version I’m using. However, while I’m still using remotely hosted CI/CD, I’m pleased to use these methods to simplify things just a tad.

Update, 2026-05-05: On a slightly related note, I learned while researching for this post that, at long last, GitHub Actions now allows you to set your runner’s time zone (including for cron jobs) by simply using a TZ variable, as has long been possible in GitLab CI/CD. This eliminates the need to access other, mostly (apparently) unmaintained Actions to perform that one basic function within one’s workflow file.

Reply via email

2026-04-03 01:19:00

A recent update can make it easier than ever to style your site, depending on how you want to do that styling.

As I mentioned in my previous post, I was intrigued when the release of Hugo v.0.158.0 introduced its css.Build function. The new powers that resulted are worth a look when you consider all the aspects of styling a site you’ve built, or plan to build, on Hugo. Still, the enhancements have certain limitations of which you’ll also want to be aware.

When forming the styling structure for a Hugo-based website, you have a variety of options. CSS itself has gained many additional features over the years, and browsers have improved to handle them.

For example, it wasn’t so long ago that simply nesting your CSS like this . . .

.my-div {
 background-color: #ffffaa;

 h1 {
 font-size: 2rem;
 color: #005500;
 }

 p {
 font-size: 0.75rem;
 }
}

. . . required pre-processing through Sass or post-processing through something like PostCSS or Lightning CSS; but, now, you can deliver CSS in production just like you see above, and any browser compatible with Baseline 2023 will display it as you intend. However, unless you’re sure everyone in your site’s target audience is using a sufficiently updated browser, you have to adapt your site’s production styling accordingly — manually by using only pre-2023 vanilla CSS, or automatically through Sass-processed CSS or using a post-processor to transpile modern CSS for compatibility with older browsers. That post-processing is one way that css.Build shines (mostly; more on that in a little while).

Unless your site’s styling is very simple, you may want to organize your CSS into multiple files. If so, you then must determine how best to deliver all that CSS in production. Of course, your HTML can just link to multiple stylesheets, but it’s often better to combine multiple CSS files, especially for critical CSS, into one production-side bundle. That, too, formerly required one or more external packages, but CSS-bundling is another advantage css.Build can give you.

Also, you almost certainly want to minify your CSS for production. Although Hugo’s long been able to do that for CSS, as it does for other delivered files, css.Build now provides another way to do it for just CSS.

All that said, css.Build has some gotchas which you’ll need to take into account when assessing whether this feature can be your sole “helper” where CSS is concerned rather than having to use, say, Sass in development and/or PostCSS on the production side.

What it comes down to is that you must make a judgment call about which newer-style CSS features your site may require. Since css.Build works atop the esbuild package, the best source for what css.Build can and can’t do in this regard is the actual CSS-specific documentation for esbuild itself; this information lists the features for which esbuild performs either transpilation or browser-prefixing. And, even when armed with this knowledge, you still must test how/whether css.Build converts all the newer-style CSS you wish to deploy.

For those items which esbuild (and, thus, css.Build) currently can’t convert to your liking, you’re left with two choices: (a.) add some post-processing that will fill in the gaps; or (b.) decide to target only those browser versions that “know” those CSS items. While deciding, you’ll appreciate the convenience of tools like the Browserslist playground and the Baseline-specific list of supported browsers.¹

Such limitations notwithstanding, css.Build’s other capabilities that I mentioned above can reduce or eliminate your needs for other CSS processors. Bundling and minification work right out of the box. And, best of all, css.Build works very quickly, which is an especially big advantage during development. The bigger your site and the more CSS you’re using, the more you’ll appreciate the speed of css.Build.

Perhaps, after thinking through all this, you decide css.Build might just work for your site. Other than those specific CSS gotchas we already mentioned above, what else, if anything, would you lose by going with just a vanilla-CSS-and-css.Build solution? To help answer that, let’s conclude by looking at the alternatives as you would use them in Hugo:

• Sass pre-processing (involves writing .scss or .sass files, rather than .css files)

  • Requires use of the Dart Sass binary (but works smoothly and very quickly with Hugo Pipes).
  • Provides no browser-prefixing. Remember, it’s a pre-processor. For that, you need to use Sass and a post-processor, which adds more complexity and likely slows down your work, especially in development.
  • Lets you nest your styling , but currently doesn’t support native CSS nesting — which may not matter to you if your styling code is all-Sass anyway.
  • Provides bundling through Sass’s @use command.
  • Performs minification through the “compressed” outputStyle option.
  • Offers math functions, logical functions, and mixins — some or all of which either already are, or might become, part of Baseline CSS at some point in the not-too-distant future.

• PostCSS post-processing

  • Works well with Hugo Pipes but, due to PostCSS’s JavaScript foundation, is much slower than the other options described here.
  • Uses various plugins to:
    • Perform transpilation, polyfills, and browser-prefixing for older browsers.
    • Provide bundling through a plugin’s interpretation of CSS’s @import command.
    • Perform minification.

• Lightning CSS post-processing

  • Must be “shoehorned” into Hugo. Also, Lightning CSS has no file-“watching” capability for use during development, so that, too, must be part of the “shoehorning.”² To be fair, though, the Rust-based Lightning CSS is very fast (although not as fast as either css.Build or Dart Sass) when properly “shoehorned.”
  • Performs transpilation, polyfills, and browser-prefixing for older browsers.
  • Provides bundling through Lightning CSS’s interpretation of CSS’s @import command.
  • Performs minification.

Reply via email

2026-03-17 05:46:00

A new name for Eleventy, trying CachyOS, some new powers for Hugo, and other folderol from my noggin.

Here we go once again with an entry in my “Mixed nuts” series of posts, each of which contains musings on multiple topics that have recently occupied my semi-reasonable facsimile of a brain.

Perhaps soon we’ll be referring to “the static site generator formerly known as Eleventy,” at least in jest, but it will be true. Eleventy’s creator, Zach Leatherman, announced earlier this month that the SSG now will be called Build Awesome. You may recall that this open-source project came under the aegis of Font Awesome in 2024, apparently settling any remaining worries about Eleventy’s long-term financial sustainability. Despite the name change, Build Awesome will remain free. However, there also will be a paid “Pro” version that will add more features; exactly which features, and what the Pro package will cost, remain TBA. (An earlier announcement, containing more details, was removed.) Also, Leatherman promised to keep future versions as backward-compatible as possible with existing Eleventy sites and the current ecosphere of Eleventy plugins.

My Linux-on-the-old-Mac adventures continue. Now, after about a year and a half on Fedora, I’m running the Arch-based CachyOS distribution. Its purpose is to provide the flexibility of Arch Linux, but with greater ease of use plus — and this is what got me to try it — special enhancements to optimize performance. It’s early, but I’ve been quite pleased with CachyOS. It seems to have many of the aspects I preferred about Arch compared to Fedora, such as far faster mirrors when it’s update time, yet without my having to tinker quite so much to keep things running smoothly.

While I was starting to draft this post, the Hugo team released v.0.158.0, the most interesting new feature (IMHO) of which is called css.Build. As the documentation says, css.Build lets you “bundle, transform, and minify CSS resources” — which, up to now, I’ve been using a combination of PostCSS plugins and bespoke code to do, especially in production. Now, Hugo can do all those things on its own! Indeed, after spending a couple of hours fixing a few things in my existing layout files, I was able to go Hugo-only for handling the site’s styling even in production. If you’re a fellow Hugo user, I suggest you view the docs and see if you might be similarly interested.¹

I recently put aside this site’s Sass files after realizing I had little or no remaining reason to keep maintaining them. Sass long ago lost its main advantage for me over vanilla CSS, namely the nesting that became native to the latter years ago; so continuing to keep around the Sass versions of my CSS files, much less having to change them for consistency’s sake every time I edited their CSS counterparts, had ceased to be anything other than a nuisance.

The growing weight of “you-must-use-AI-no-matter-what” demands upon developers by various firms’ IT overseers makes me ever gladder that I retired well before the craze ramped up to today’s cacophonous level. My final job was mainly managing websites and the servers on which they were living, so I might have escaped the worst of the madness at first, but that relative calm wouldn’t have lasted. After all, when a company spends big bucks to make a Thing available to its IT team, the folks on that IT team had better-by-God be using the Thing if they know what’s good for them.

Reply via email

2026-02-20 06:00:00

Some suggestions for making websites easier to read — in more ways than one.

If you spend lots of hours per week perusing content on one or more web browsers as I’ve been doing since, oh, the mid-1990s, there are ways you can tailor that activity somewhat more to your liking. Many of you probably already know about the potential solutions I’ll mention in this post but, on the off-chance that you don’t, here are some tips for improving your browsing experience. Specifically, this is about: (1.) adjusting how the browsers actually render web pages; and (2.) filtering out ads and certain other content types that interfere with one’s browsing pleasure. To be sure, there’s a certain degree of interaction between those two, but I’ve found that they require two different sets of solutions.

(This is almost entirely about browsing from a computer, not from within a phone or tablet, particularly since the vast majority of my readers still view my content from their computers rather than their other devices. However, I still will have a few comments about browsing with the latter.)

Controlling appearances

A few months ago, I noticed that I was constantly editing certain sites’ CSS in the browser Inspector because, more and more, the sites’ default styles were unkind to my aging eyes. Hacker News is a particularly onerous offender in this regard. For example, HN’s default shows sharply downrated comments in so light a gray color — on top of a very light tan background, to boot — that they’re almost illegible to me. (While I often agree that such a comment deserves its bad numbers, I still want at least to see what it said.) In addition, given the lighting conditions in my usual spot for viewing HN content, I prefer to see it in dark mode; but HN’s default styling doesn’t “respect” one’s dark- or light-mode settings. To paraphrase an already often-paraphrased Henry Ford quote, “You can have any mode you want, as long as it’s light.”

That kind of manual, page-by-page editing gets old fast, especially when you’re doing it many times a day; and HN isn’t the only such trouble spot for me. So, I soon realized, a better solution would do it in a way that works every time I go to a site. That led me to the open-source Stylus browser extension for Chrome- and Firefox-compatible browsers. It automatically loads site-specific CSS, rather than my making manual edits every page visit.¹

The interest in doing this sort of thing isn’t new, of course. Back in the early days of Firefox’s existence, We Of A Certain Age would use an extension called Greasemonkey which, I was delighted to see when researching for this post, is still around, although it and Firefox certainly aren’t nearly as popular as each once was. It allows customization of not only a web page’s appearance but also its functionality. Greasemonkey’s wiki is probably the best place to go if you need a better explanation.

Where changing only a page’s CSS is the intended result, there’ve been other notable extensions over the years:

• The venerable Stylish began in 2005 as an open-source project, but was acquired in 2017 by an advertising analytics company. As can sometimes result unfortunately from that type of acquisition, Stylish since has become infamous for significant privacy violations (e.g., see this 2018 article). Even to this day, more than a few reviewers flatly call it “spyware” and downrate it severely. You can do better than Stylish.
• Stylebot used to be one of the favorites for this sort of thing, but it hasn’t had a new release on its repo since v.3.0.1 appeared 2020-07-29. As of this writing, Stylebot’s Chrome extension is at v3.1.4 from 2024-05-17 and its Firefox extension is at v.3.1.3 from 2024-07-24; I’m thus presuming anything newer than v.3.0.1 is closed-source.

By contrast, Stylus is still actively developed and open-source, so it’s the choice I recommend.

With Stylus, I can change the appearance of Hacker News from this:

. . . to this:

Note: I use browsers’ zoom functions to view each HN page at higher magnification because, as I said, my eyes are old. I find the default text size on many web pages to be unacceptably small and, when I inspect their CSS, what I find leads me to believe they were designed by young folks for whom It Looks OK To Them. I was inveighing against such short-sightedness years ago, even before my eyes needed as much help as they now do.

In case you’d find it useful, here’s the CSS I use with Stylus to view Hacker News content that way:

html {
 filter: invert(90%) hue-rotate(180deg);
 background: #fff;
 /* For viewing ALWAYS in dark mode */
 /* h/t to https://news.ycombinator.com/item?id=46663782 */
}

table.fatitem p,
table.fatitem .toptext {
 color: #000;
}

div div a, div p a {
 color: #00008b;
}

div.commtext.c5A {
 color: #5a0000;
}

div.commtext.c73 {
 color: #730000;
}

div.commtext.c88 {
 color: #880000;
}

div.commtext.c9C {
 color: #9c0000;
}

div.commtext.cAE {
 color: #ae0000;
}

div.commtext.cBE {
 color: #be0000;
}

div.commtext.cCE {
 color: #ce0000;
}

div.commtext.cDD {
 color: #dd0000;
}

div.commtext.c00 a {
 color: #00008b;
}

div.commtext.c5A a,
div.commtext.c73 a,
div.commtext.c88 a,
div.commtext.c9C a,
div.commtext.cAE a,
div.commtext.cBE a,
div.commtext.cCE a,
div.commtext.cDD a {
 color: #8b0000;
}

div.commtext.c5A a:visited,
div.commtext.c73 a:visited,
div.commtext.c88 a:visited,
div.commtext.c9C a:visited,
div.commtext.cAE a:visited,
div.commtext.cBE a:visited,
div.commtext.cCE a:visited,
div.commtext.cDD a:visited,
div.commtext.c00 a:visited {
 color: #8b008b;
}

div div pre {
 color: #006400;
}

Where Apple’s WebKit-based Safari browser is concerned, the outlook is more grim: there is no Stylus extension for Safari, for which third-party extension availability is much more limited.² The closed-source, paid Cascadea extension for Safari on macOS would seem to provide similar capabilities (I haven’t tried it), but its last update was apparently 2021-11-02.

Update, 2026-05-29: I later learned of a paid Safari extension called Noir that provides a less customizable, but helpful, dark-mode experience on sites which otherwise don’t respect one’s viewing preferences.

If you’re on macOS and prefer to avoid Chrome- and Firefox-compatible browsers, there may be another possibility. The Orion browser, also based on WebKit, actually allows the enabling of extensions built for Chrome and Firefox, although many such extensions’ actual in-Orion performance remains problematic at this writing. You can try using an older version of the Stylus extension for Chrome — I got it to work on Orion with v.1.5.51 — since anything newer apparently isn’t compatible with Orion. It’s possible to install the current Stylus version, but its functionality is broken in Orion.

Blocking ads

Obviously, the existence of most content I follow on the web depends to some extent on advertising dollars. Still, there’s a lot of problems with how some ads are delivered on the web these days, right down to the inclusion of out-and-out malware in more than a few cases; so I choose to perform whatever ad-blocking I can. Besides, there are hundreds of millions of young folks out there using their totally non-ad-blocked phones to cruise the InterWebz, so I’m sure old goats such as I are no longer that important to the poor, oppressed advertisers. They won’t miss me. I surely don’t miss them.

As with the CSS-editing stuff I described earlier, my approach to blocking ads is mostly extension-based. The best ad-blocker out there is Raymond Hill’s superb open-source extension, uBlock Origin. Although uBO has always worked best on Firefox, it also was a must-install on Chrome until 2024. That’s when Google began implementing its Manifest V3 extension platform which, combined with similar developments in other browsers (some earlier, as in the case of Safari), neutered how uBO works due to the blocking of certain network requests upon which uBO’s blocking and filtering depends. As a result, Hill came up with the Manifest V3-compatible (and therefore more limited) uBlock Origin Lite for Chrome-compatible browsers and, more recently, Safari. In my own use cases, uBOL works better than a lot of people think and certainly is better than no ad-blocker at all on those browsers, although it surely doesn’t “catch” as much as the real uBO still does in Firefox.

For fans of Chrome-compatible browsers, the Brave browser gives you nearly uBO-like ad-blocking and content-filtering through its built-in, Rust-powered Brave Shields feature, some settings for which — notably, its filter lists — are largely compatible with similar settings for uBO and certain other blockers, such as AdBlock. (As you’ve probably read elsewhere, Brave does still support full-fledged uBO, at least for now, but the widespread advice is not to use both Brave Shields and uBO together; the former is sufficient.)

As mentioned above, the Orion browser on macOS allows use of some extensions from the respective Chrome and Firefox web stores; and, as of this writing, the full-fledged uBO extension for Firefox still works with Orion. How long that will still be true (i.e., whether a Manifest V3-like situation catches up with Orion at some point) remains to be seen.

Where Safari is concerned, there are two other possibilities you can try, each of which is free/open-source and works by performing ad-blocking and content-filtering at the device level, rather than the browser level:

• wBlock is available for macOS, iOS, and iPadOS. Its feature comparison chart lets you see how it stacks up against several other, better-known ad-blocking solutions for Safari, including uBOL. By being a device-level ad-blocker rather than a browser extension, it avoids the limitations that would hamper a uBO-like blocker while working — at least, in my own observations over the last few weeks — quite well on all my Apple devices. If Safari is a sufficient browsing experience for you, I can recommend wBlock quite highly. (For just one example: before I installed wBlock, I found it unbearable to view Reddit on Safari.)
• Zen, which probably should be called something else so it’s easier to find in a web search (since there’s already a popular Firefox fork called Zen), is available for macOS as well as Windows and Linux; to my knowledge, there’s no mobile version at this time. It blocks ads and the like from all browsers, not just Safari as is the case with wBlock. While I found Zen to be competent enough — e.g., it blocks more from Chrome than uBOL does — it also seems to have some technical quirks that made me stop using it after a few days of testing. One glitch that bugged me in particular was that it seems to interfere with certain HTTP requests in such a way that HTTP/3 content was dropped down to HTTP/1.1. (Yeah, I do care about that sort of thing.) Still, it’s a fairly young project compared to others in this genre, so perhaps such issues will lessen over time. (I did find some online comments lamenting Zen’s requirement to install a local root certificate; while its documentation does explain this rather fully, some individuals fully “noped out” of it over just that item.)

Note: Finally, since I suspect at least one visitor will wonder about it . . . yes, I do know about router-level ad-blocking, but it simply involves more futzing than I care to do. I’ll tinker with my computers, devices, and/or browsers to get desired ad-blocking results, because I’m the only one who will suffer if I err; but I won’t Go There where our shared TV is concerned. Maybe a twenty-years-younger version of me would’ve tried something like that, but the 2026 version of me neither cares that much about it nor needs the potential, resulting headaches.

If you feel any or all of the above suggestions will be more of a hassle than you have either time or patience to handle, don’t worry. It simply means you’re not as cantankerous as I, and that’s probably a good thing. However, if you are willing to give these a try, I think you’ll like the results. They took a while to get the way I wanted them — and I’m still making adjustments here and there — but I’ve found them quite worth the time and effort. I hope you will, too.

Reply via email