> If Google can take unilateral action to fundamentally change the basic principles of the web, then the W3C is already useless. This will give Google a clear choice: if they want to maintain the idea that the W3C matters, they should withdraw this implementation.
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.
Basically, the ask for forgiveness approach. It's common in large, dysfunctional organizations as well. Sometimes the easiest way to get attention is to break things. Then once enough pain is felt, everyone starts taking interest. Trying to follow a proper change control based process only works when everyone is invested in the process.
In the browsers anything that's not behind a flag is immediately relied on by people.
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.
> 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.
- 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.
A feature behind a flag in a browser isn't for the public web sites. It's for devs (web devs and browser devs) to figure out if the feature works, if an API is ergonomic, the various edge cases etc.
Sure, but not all (or even most) chrome features are web standards, so it makes sense that those are deployed without consensus, because there isn't anyone to get consensus with.
Yes and the standard development process starts by designing a spec proposal and testing it! That's the first step. If the proposal ends up not being implemented, the implementation may be removed, but you still need the implementation to write the spec, that's more or less how WHATWG works.
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.
You seem to be taking things that are factual, normal, everyday, aspects of the WHATWG working process and trying to imply that chrome is doing something unusual, or untoward with its process here, but it isn't. It's doing what is necessary to make a proposal with WHATWG: have a trial.
> You seem to be taking things that are factual, normal, everyday, aspects of the WHATWG working process and trying to imply that chrome is doing something unusual, or untoward with its process here, but it isn't. It's doing what is necessary to make a proposal with WHATWG: have a trial.
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.
I don't follow, is the issue that Google is lying about trying to standardize something (what you claimed before, and which clearly isn't true), or that they're implementing things that aren't standardized[1] and which you dislike (true, but, like, fine. You can use other browsers)?
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.
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.