zdunn

Right, you said you're from the UK so that's in line with what I would have expected. My unstated point was that multinyms are intrinsically tied to dialects so there is no absolute list of multinyms

"e'er" would sound slightly different as it's spoken almost like two syllables, though not quite.

I'm a native English speaker (US). Sometimes when I say "ever"/"never", the 'v' sound drops out. So I end up saying "e'er"/"ne'er" but it sounds like "air"/"nair".

Further down the list, I've just spotted "taught, taut, tot" and "tot" doesn't belong there.

I pronounce all of these the same

In the United States South, its very common to drop the 'g' at the end of a word ending in '-ing'. barren-bearing can definitely sound the same here.

I'm from South Carolina, USA and I pronounce 'greater' and 'grader' the same. There is a subtle difference and that difference can be more noticeable sometimes, but most of the time I'm saying them the same.

For everything in this list, its incredibly common for these groupings to have the same pronunciation where I live.

I think the acronym thing is related but a separate phenomenon. My guess would be that speakers intuitively think the acronym isn't easily understandable so they add an extra word to clarify it, intentionally or unintentionally duplicating one of the actual words in the acronym.

"pont bridge" sounds like the exact phenomenon though. Does it have a more specific meaning that "bridge"?

mistranslated horno to "earth oven"

My argument is that it's not a mistranslation. In Spanish, "horno" means any kind of oven. In English, it means specifically an earth oven because when English speakers started using the word, they always used it to mean that kind of oven.

A sibling comment mentioned chai tea. It's the same phenomenon. Chai means any tea in its original language, but in English it means a specific variety and preparation of tea.

English is a bastardized language and has a lot of words borrowed from other languages. But once they're borrowed, they're English words and have their own meaning separate from their original loanword.

When a common word from another language is borrowed into English, it tends to take on a more specific meaning. Most native English speakers wouldn't use "salsa" to describe any other sauce. Horno oven sounds perfectly reasonable in English to specifically describe an earth oven in that style, not the common household appliance.

EDIT: Probably the reason this happens is that most English speakers wouldn't be familiar with the foreign word, so the speaker uses it as a modifier to the standard English word. The listener doesn't need to know anything specific about the foreign word in that case and can just assume it's a type of the common item.

just make transit more attractive, not make driving less attractive

If ppl drive more than use transit, they won't support improvements to transit. This is the first step to improving transit. Make driving less attractive, more ppl use transit, complain about its shortcomings, and then fixes get implemented.

I also don't see why we shouldn't make driving less attractive. As the grandparent comment said, drivers should be the ones paying for the problems caused by drivers, not residents.

Also, though the author mentions annotations, I don't see how they intend to implement them.

It's discussed at the very end of section 8 and all of section 9 that interactive functionality would use web components.

The basic thing I am saying is that if you call it a web browser and use the same core protocols etc., you have a practically infinite (for an individual) set of requirements to implement and will never be truly compatible

But what the parent is saying is you don't have to be compatible with 100% of websites. If you build a browser with good HTML/CSS/Javascript handling, you'll be compatible with the large majority of the web. Yes, there are other specs that are in use by a tiny portion of the web. But your browser can still exist if it doesn't support them. Users of that website will know or find out that they can't use your browser for that, but for every other user that browser could be exactly what they need.

without having to worry about a fuzzy and ever-expanding definition of what you have to support.

It's only ever-expanding if you're trying to keep up with the Jones's. You can define a subset of the web you want to support and build a clean, small browser that supports that.

Aren't you the developer of Smithereen (a fediverse server)? Nearly every other fediverse software has a web interface that can act as a PWA. I launch lemmy.ml and kbin.social as standalone PWAs from my homescreen. My pleroma instance also has some PWA features (though not standalone display mode). I don't use Mastodon, but @nolan@toot.cafe did some amazing work years ago to make it a really fast and responsive PWA (which has since been undone ).

It's ok if you don't like to use PWAs but that doesn't mean nobody does or that they're worthless.

I asked for it, and a lot of other ppl did too. These are great features and removing them would cause more than 1% of websites to lose some functionality.

But, importantly, they shouldn't lose their core functionality (if they're written well) because that's the "Progressive" part of PWA. If you don't use the feature or your browser doesn't support it, the website should still have basic functionality. One of the big ideas behind PWAs is "progressive enhancement", where you layer on features that may not be supported everywhere but add value when they are supported.

And a progressively built browser that doesn't implement every spec goes hand-in-hand with that. I think having more under-featured browsers like that would push webdevs into caring more about progressive enhancement.

I've found https://tiddly.packett.cool/ is great on desktop and mobile

Discoverability is a little better since Pleroma exposes the public timelines for non-logged in users (though the admin can disable that). I'm not sure about search.

The repos they linked are just for the clients. I think the server software would be way more interesting, but it's also their secret sauce so it unlikely they'll open source that.

I'm with you that allowing the clients to connect to a different sync server (gpodder, etc) would be a great feature. Though, again, I don't see that happening because it would cut into their subscription service.

Except in situations exactly like this one. A user shouldn't have to worry about local vs remote videos if they want to share the link outside the fediverse and someone clicking that link definitely shouldn't have to know about instances, federation, etc to be able to watch the video. Clicking the link should take them to a watchable video; if for some reason, it's not available for watching on the instance, it should use a http redirect instead of loading an intermediary page

Right, but that doesn't mean the server can't support other post types or leave complex UI to other clients. Each server could fallback to displaying a link to an external post at a bare minimum, or display whatever the `content` field. I'm just arguing that the C2S is perfectly viable and would make the fediverse so much richer and more usable. Using the Masto API to federate only specific types with specific software is limiting the fediverse.

The UX is important. It's important that all users have the same one. For link aggregators, you want comments displayed as a tree. For microblogging, flat lists work better, especially when people post "threads", which they do.

That's subjective and exactly the type of thing that could be handled in a client. In both cases you're displaying the exact same data. A microblogging thread may be displayed as a flat list, but it's still a tree like a link aggregator thread.

I meant a Facebook-style social network. So a platform to post what are essentially blog posts. In ActivityPub, that would be the Article type, which, according to the spec, has no semantic difference from Note. An Article could be created as a Note and vice versa with no semantic difference or loss of data. Just like above, the data is the same and the only distinction is the visual presentation of it.

You could ask around the indieweb irc, https://chat.indieweb.org/ Some of the people there have messed around with syndicating to ActivityPub. I think one of them maintains a Wordpress activitypub plugin

You could also check out Pleroma; Mastodon isnt the only microblogging software on the fediverse

https://pleroma.social/#featured-instances https://fediverse.party/en/pleroma/

That's the basis for https://indieweb.org which i think is a much better solution than ActivityPub. See micro.blog if you want an example of a productized form of those ideas

You can't shove Reddit into Twitter UX and expect something nice to come out, no matter how hard you try.

Why not? it's text; you could make the same exact post on reddit and twitter (barring the length, which could be truncated in a federated context). Link aggregation is basically just microblogging with the extra constraint that the initial post has to have a link.

Smithereen is a social network

What does this mean? Every other platform you mentioned are social networks. On all of these platforms, a user posts text or media posts. Displaying them in a different UI doesn't make them radically different.

But you can't post a video to Peertube or start a thread on Lemmy. There's a level of interoperability that was envisioned for the fediverse that we're missing right now. If you post a video, Peertube users won't see it despite being the fediverse's main video software. If you post a link with your commentary, Lemmy users won't see it despite being link sharing software.

The microblogging platforms ingest most types of posts from the other activitypub softwares, but the other platforms don't ingest posts from the (micro)blogging platforms. With the client-to-server API, the other platforms would just be clients on top of your Friendica account.

I am not sure why the ecosystem went this way

Because when activitypub was still getting off the ground, mastodon built their own client api. A lot of excited people built apps for mastodon so pleroma, and then others, started building Masto API support so that their instances could use mastodon clients. Now the Masto API is the de facto client api.

I super agree with you, using the client-to-server protocol so that we could have one account would be the best situation. I've been arguing that on the fediverse for a while, but all the developers in the space seem to think the client-to-server protocol isn't useful enough so you would have to fallback to a custom API for the missing pieces anyway so you might as well use the API everyone's already using.

https://indieweb.xyz is a reddit-like link aggregator and https://www.indieforums.net/ is a forum for independent blogs. Neither is curated since theyre user submitted content, but still might be of interest to you. I think the "indie" in both of these is less directly about being IndieWeb and more about being small, independent blogs, so hopefully more likely to be "No news or tweets or blurbs, just good high quality writings"

You're right, my bad. I was getting ahead of my self. The JS fallback covers older, non-evergreen browsers and the HTML fallback covers everything (including the described issue)

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)