> The irony of telling people how to use something you're opposed to...

It's a documentation site. You want it to pretend the API doesn't exist, or what?

> It's clear that mainstream browsers have become the exact opposite of user agents.

If I'm interpreting you correctly, please explain how you got from "mozilla.org documents this API" to "firefox is not acting as a user agent".

It's Mozilla's documentation site. Firefox doesn't have the API. It has no obligation to even mention its existence. The only thing that documentation is doing is helping Chrome.

If I'm interpreting you correctly, please explain how you got from "mozilla.org documents this API" to "firefox is not acting as a user agent".

I'm speaking about browsers in general.

It's bigger than that

>MDN Web Docs content is maintained by Mozilla, Google employees, and volunteers (community of developers and technical writers). It also contains content contributed by Microsoft, Google, and Samsung who, in 2017, announced they would shut down their own web documentation projects and move all their documentation to MDN Web Docs

https://en.m.wikipedia.org/wiki/MDN_Web_Docs

In other words, it's already been infected by the enemy.

> It's Mozilla's documentation site.

I kind of want to emphasize "Mozilla's" too. It's not firefox documentation, it's web documentation.

> I'm speaking about browsers in general.

But you're specifically including firefox because of this page, right? That's a hell of extrapolation to make from them "helping" chrome by writing/hosting an article.

If it makes you feel any better, this sort of nihilist puritanism, combined with the people who actually sell data complaining to the EU it's "anticompetitive" they can't track me via 3P cookies, means this is DoA. And users are the only ones worse for it, modulo Google's sunk cost in investment in trying to do something better.

> The only thing that documentation is doing is helping Chrome.

In what way is documenting the API helping Google? There's a big banner right at the top of the page saying Firefox and Safari aren't going to implement it.

Should Mozilla also not document -webkit- prefixed CSS properties?

> It's a documentation site. You want it to pretend the API doesn't exist, or what?

MDN is a documentation site for web technologies.

In order for something to become a web standard, it needs two independent implementations. If Google can’t build consensus or convince anybody outside of Google to implement it, it’s not a web technology, it’s just some Google API that Google built for Google’s needs.

This is out of scope for a site dedicated to web technologies. This is like expecting them to document Android APIs.

It's a proposal for a web technology. Every web technology starts as a proposal, even if nobody but a single vendor implements it. MDN includes documentation for serious proposals at all stages, regardless of the standardization process.

In fact, MDN includes non-standardized APIs as well. Browser-specific interfaces are included, because it turns out that if you only document the APIs that went through the standardization process and not the ones that actually exist, it makes for a bad documentation site.

It’s a proposal that was rejected by everybody who isn’t Google. It isn’t going to be part of the web platform. It has exited the standardisation process. It’s at stage “never”. It belongs on MDN about as much as JSSS does.

JSSS is long dead.

I'd say a better comparison is JSX, and searching for that I do see pages on MDN about it.

That doesn't change anything. Whether or not it ever ships doesn't mean it shouldn't be documented. There's zero cost to documenting it. Just because you don't like it and it didn't make it past the proposal stage doesn't mean it shouldn't be on MDN. That's not how MDN works.

Mozilla started working on a similar API with Facebook back when Google announced FLOC. They are most likely more opposed to the bad press FLOC got than they are to the idea itself.

> They are most likely more opposed to the bad press FLOC got than they are to the idea itself.

I'm not well informed of how Mozilla is run, but isn't it just a business? Does it have any consistent values? I would assume that all decisions made by Mozilla are a balancing act between money and pr.

> The irony of telling people how to use something you're opposed to...

To a certain extent, I expect people to do exactly that as part of an argument in good faith, especially in a technical context. If you can't explain to me how something works, why should I trust your feedback, be it positive or negative?

I don't care how something works if I'm against the purpose. The same "but we should have a technical argument" BS was used by proponents of WEI, and thankfully most people saw through it.

No means no. DO NOT WANT. End of argument.

I think you misunderstood me. I'm not trying to move the goalposts by suggesting "we should have a technical argument". Discussing whether the feature should even exist is itself a technical discussion.

Let's use WEI as an example. You're clear enough in your opinion: you think it shouldn't exist. Why, though? What does it do that you object to? Do you understand how it works well enough to be sure it does the bad thing you think it does? Imagine I'm interested in the discussion, but haven't formed an opinion. I just have Google on one side talking about guaranteeing the integrity of the browser environment somehow, and you saying "DO NOT WANT" on the other. You'll have a much easier time convincing me of your point of view if you can simply show me that you actually understand WEI, and if you can make me understand it too.

I don't care how it works. When the goal is the problem, the method is irrelevant. WEI is a problem because it takes away user's freedom to interact with sites using the software they want. It doesn't matter at all how it accomplishes that goal.

Understanding how something works is the first step in circumventing it.