It's pretty generally accepted that the correct way to do web standardization is for proponents of some new thing to implement that thing and deploy it and then once it has been shown to actually work bring a spec to the the standards folks for standardization.
That usually works fairly well, although sometimes if that first pre-standard implementation does too well the original implementor may have trouble replacing theirs with something that follows whatever standard is eventually approved, because there are often significant changes made during the standardization process.
An example of that would be CSS grid layout. That was a Microsoft addition to IE 10, behind a vendor prefix of -ms-. Nearly everyone else liked it and it was standardized but with enough differences from Microsoft's original that you couldn't just remove the -ms- prefixes from your CSS and have it work great with the now standard CSS grid.
It was 4.5 years between the time Microsoft first deployed it in IE 10 and it appearing in other browsers by default (Chrome had it within a year of Microsoft, and Firefox had it about two years after that, but both as an experimental feature the user had the specifically enable). In that 4.5 years enough sites that only cared about IE were using the -ms- form that Microsoft ended up stuck with that on IE 10 and 11 instead of the standard.
- Behind dev flags
- And then wait for consensus
- And then there have to be at least two independent implementations
And only then does this become a standard.
Chrome doesn't care. They create a semblance of the spec, create a semblance of a discussion, and then enable it APIs in Chrome. And then pretend it's a standard.
So no, you shouldn't ask for forgiveness and pretend that you're just gathering data.
That's why what Google is routinely doing now (releasing APIs after a very short period in origin trial and without ever reaching consensus) is so dangerous.
And this particular feature? They want to pretend it's s standard. You don't create a spec proposal for a feature you don't just develop internslly
All of the following are true statements:
- Not all chrome flags are related to spec proposals
- Not all spec proposals are related to chrome flags
- Not all chrome-led proposals are finalized
- At least one browser must implement and test the proposal before the proposal can really be considered, and multiple other browsers must implement it before it can be accepted.
And yet, we've seen many such proposals go through this process because Chrome is paying lip service to it. Whatever Google wants it ships. And Google wants this.
As an adjacent (ads- and tracking-related) example: Google's FLoC flopped, hard. So they immediatey shipped the replacement Topics API [1] despite there being no consensus. E.g. Firefox is against [2] (but Chrome presents Firefox's position as "No signal" in the feature status). And despite the fact that its status is literally "individual proposal, not accepted" [3]
Do not assume any good intent on Google's part when it comes to Google's business interests. Their intent is always malicious until proven otherwise. And there have been fewer and fewer cases when they have been proven otherwise.
[1] https://chromestatus.com/feature/5680923054964736
[2] https://github.com/mozilla/standards-positions/issues/622
If chrome implements WEI and it isn't standardized, you're not going to be knocked off the internet if you use firefox. That's extremely silly.
[1]: Keep in mind that things that aren't standardized include third party cookie behavior, so the behavior that FF and Safari have, that you support, isn't standardized either. If you're fully against browsers implementing nonstandard apis or features, you can't be in support of third party cookie sandboxing at all.