earlier replies
Replying to @domenic @briankardell @rachelandrew @matthewcp @rob_dodson @eisaksen
I wouldn't think "Chrome should implement things spec'd and approved by the various governing bodies of the web" would be that controversial. Or should we just disband them and let you guys call the shots from now on?
2
3
I think your second sentence is needlessly inflammatory. But no, it has never been the case in the history of software that standards have either forced implementation, or gated it. Standards are a tool for increasing interop; they are not a universal law.
2
6
> or gated it Not true. W3C Candidate Recommendation phase was used in past to gate implementors, coordinate feedback, avoid premature standardization. See w3.org/Consortium/Process/Pr…. It was a hardfought condition, which members honored in interest of interop testing & reciprocity.
1
1
Brendan, come on. I can find tens of examples from when whenever this was in place of Netscape/IE/Firefox/Safari/any other W3C member implementing before CR.
1
1
Please do. I was at Mozilla and we held back on *shipping* until CR. @davidbaron probably can cite bugs.
1
2
XHR reached CR in 2010. Firefox shipped it in Firefox v1. Shall I continue? Just look through everything in Firefox v1. You'll find a lot of them did not have CR specs.
1
1
Some didn't even have specs at all: developer.mozilla.org/en-US/… for example.
1
XHR was before we had a functioning w3.org — it was off in the XML weeds. Try the early Chrome era, through 5 years ago.
1
2
Sure, easy enough. developer.mozilla.org/en-US/… shipped in only Firefox with only a WD, no CR. Moved behind a flag in Firefox 41 but unflagged before that.

CanvasCaptureMediaStreamTrack - Web APIs | MDN

The CanvasCaptureMediaStreamTrack interface represents the video track contained in a MediaStream being generated from a following a call to HTMLCanvasElement.captureStream().

developer.mozilla.org
2
2
-moz-transform, -moz-animation, all done while the relevant spec was not in CR.
2
Replying to @domenic @BrendanEich @AdamRackis @briankardell @rachelandrew @matthewcp @rob_dodson @eisaksen
That was the recommended practice by the CSSWG at the time. (Today it would be feature flags or other mechanisms that keep things off by default for release channel users.) They also followed -webkit-prefixed versions.

Apr 30, 2020 · 5:28 PM UTC

2
2
Replying to @davidbaron @domenic @BrendanEich @AdamRackis @briankardell @rachelandrew @matthewcp @rob_dodson @eisaksen
Though I think the bigger picture was that, at the time, all the browser makers saw that shipping something interoperably across all browsers was a much bigger win than shipping it in one browser. So all were willing to do what it took to get that. Much less true today.
2
5
Sometimes they/we didn't because it was an experiment that didn't work out, but that nobody ever bothered to remove. And some browsers had larger markets for single-engine content that they cared about sometimes. But there was still a broad push for interop, though uneven.
2
Replying to @davidbaron @domenic @AdamRackis @briankardell @rachelandrew @matthewcp @rob_dodson @eisaksen
Thanks. On reflection I was thinking of CSS rather than DOM or WebAPI or other WGs. Although the W3C process docs were supposed to be for all groups.
1