zdunn

the es5 build will reach less and less users over time, but it has no cost for other users or even the developer. Load it with a script nomodule tag and you always have a JS fallback that covers weird edge cases like the one described in the article.

And building with the right HTML foundation, means you have a fallback for any breaking javascript, that will cover even more edge cases.

> but it's hardly a case of "progressive enhancement" that the author is talking about.

This is definitely a case of progressive enhancement. If the site had started out with a basic form, it would have worked on the referenced devices/browsers when the javascript broke.

> but how many such targets should one have?

2. You should have your main script which can have the latest features and compile it down to ES5, which will work in nearly every browser. Compiling to ES5 is one of the easiest web development tasks to automate so laziness isn't a valid excuse. Just using this technique of ES5/ESNext would support nearly every legacy browser/version.

It's not extra work. The site in question was for making a reservation. A basic HTML for would have satisfied that requirement and worked completely without javascript. Any additional features could have been built with javascript and the site would be no different to users on modern browsers as the current build, but it would still work on the author's mom's browser.

Progressive enhancement isn't about building sites completely without JS. It's about building resilient sites that work on edge cases like this.

> So are you looking at Chrome (and Firefox) back to 4-5 years past (via caniuse?), and not using something if they don't support it back that far?

I don't think that's whats the author meant, since they mentioned progressive enhancement. The site in question was for making a reservation to volunteer. This could have been written as a simple HTML form and it would have worked on any version of Chrome/Firefox/Safari and most other browsers. Any dynamic feature the site authors wanted to add should have used [feature detection](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...).

You can also use JS modules and `nomodule` script tags to deliver the latest and greatest JS to modern browsers and a compiled ES5 script to older browsers (though that wouldn't work in the case of an older evergreen browser that does support modules)

No. Unfortunately, the fediverse has kind of given up on the idea of a single identity using a variety of services. Every new ActivityPub services wants to own the user account and the interactions are one way or extremely limited (likes/reposts).

I like the use of the fediverse for adding comments to a blog, but this is another example of conflating mastodon with the fediverse. I'm glad OP found a solution that works for them, but I hope too many people don't start using this technique.

A user could comment using any fediverse account, including Pleroma, Friendica, PixelFed, etc. Summing that up with 'mastodon account' is damaging to the whole idea of the fediverse. Non-technical people might not realize that they can choose to use the other platforms.

Also, I hate that the mastodon API has become the de facto standard for interacting with any fediverse platform. The other platforms implemented the API to maintain compatibility with mastodon clients. Now this not-quite-standard API is controlled by a single person who doesn't care about compatibility with other platforms.

> But it's unclear how they plan to get website owners to migrate.

And it's unclear why they should have to. OpenSearch is a standard that all modern browsers currently support. Why should a site author have to support OpenSearch for every browser and build/maintain a WebExtension just for Firefox?

The title is a quote from the second sentence in the article. The original title of the post is about the immediate change, but Mozilla is still planning to deprecate OpenSearch.

Firefox definitely has supported OpenSearch. When you arrive at a page that has an OpenSearch description document, there is a button in the address bar triple-dot menu to add the site's search engine to firefox. On mobile, you could long press on an input field to do the same.

Maybe I'm reading this wrong, but it seems like Mozilla plans to remove custom search engines from Firefox, except through WebExtensions. So you won't be able to go to a site and easily install a search engine for it. The site author has to build a web extension and submit it to the firefox addon site.

Yes, it's open source and the possibility is there, but it's not likely. There isn't any Florence instance yet. The other masto forks are all relatively close to mainline and aren't drastically different.

Dansup has said he doesn't want to support other AP types. It's not about who writes the patch. He wants pixelfed to be an image sharing service, akin to Instagram.

Even when it's completed, it will never support incoming Notes/Articles/Any other AP type.

Another major obstacle is the limited scope of a lot of these projects. Each project, excepts the microblogs, focus on a single media type and ignore others. So you still have to have multiple semi-siloed accounts to participate with various parts of the fediverse. As a pixelfed user, you can't interact with plume/write.as users or vice-versa. It's cool that I can follow all of these users from my Pleroma (or microblog.pub/mastodon) account, but they can't interact with me. It's only one way interaction.

Yea pixelfed has always been bad at onboarding. It's been brought up before but nothing has improved except making a pretty landing page. On instances where registration is closed, the only thing you see is a message telling you that and external links.