Update WritableStream.json to set experimental to false #6873
Conversation
The WritableStream standard is stable an unchanging at this point.
github-actions
bot
added
the
data:api 🐇
|
But WritableStream is still only implemented in Blink, right? In the BCD taxonomy, experimental is defined as follows (emphasis added):
Given that, when we have only one implementation of a particular feature, it make sense to flag that feature as experimental. The experimental status doesn’t mean the spec is unstable; instead it means the implementation status of the feature is not mature, and because of that it’s a feature that is still in the state of being intended to be an addition to the Web platform — but it isn’t part of the Web platform yet, because it doesn’t become part of the Web platform until it has multiple implementations, and developers can begin using it cross-browser. So if WritableStream is still only implemented in Blink, then we’re not there yet, and it should remain flagged experimental. |
Not sure I agree that this is the only way to determine when a feature "is mature, and no significant incompatible changes are expected in the future."
Why are there single-implementation web platform features not marked experimental? Some examples:
WritableStream has been in Firefox Nightly behind a pref for nearly a year. If we want to wait until one or both of these implementations are in released versions of the browser, that's fine. |
|
Looks like this hinges on the definition of experimental, with some previous discussion in #1528. I don't think the definition in https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#status-information really helps resolve whether WritableStream should be considered experimental. Who's going the "intending" in this definition? @ddbeck to the rescue? |
OK, I actually didn’t know that; and given that, it seems like we should we should update the What I mean by “if are current policies actually permit that” is: Whether our policies provide us with a way to mark this as implemented even if it’s only been enable-able (by turning on a pref) in Nightly builds, but not being enable-able (even not by flipping on a pref) in any major release. https://bugzilla.mozilla.org/show_bug.cgi?id=1582348 seems to indicate that it first shipped in version 71 of Nightly. And then it’s been usable in every Nightly version since then. But is the case that this feature has not be enable-able yet in any major Firefox releases? Only in Nightly? |
I think those should actually be marked as experimental too. So I’ve raised PRs to mark them as such: #6893, #6894, #6895 And I realize you were just citing those as examples. So I plan to also look through the data and identify other such features that we should be flagging as experimental. As @foolip points out in #6873 (comment), we have an open issue at #1528 about dropping the So I think we have an obligation to try to either (A) systematically identify the features that should be marked as experimental, and consistently mark them up as such, or else (B) remove the |
Yeah, I agree that based on https://trac.webkit.org/changeset/266172/webkit it seems to have been enabled since August. Which means it should at least be in TP 114 and probably was also in since TP 113. But even if we can confirm it’s shipped in a TP release, our current policies unfortunately don’t provide a way for us to mark up the BCD data to indicate it. That’s because we’ve so far basically been choosing to ignore TP releases. I think that’s a mistake, so I’ve raised #6896 to discuss it — with a concrete proposal about how we could fix things. |
Well that part is a moot point now, given the information you’ve provided that we actually have more than one implementation — and that in fact, the feature is implemented in all three browser engines. By the criteria we apply when evaluating feature maturity in the WHATWG/W3C standards words, being implemented in all three engines makes the feature relatively quite mature, and not experimental at all. Given that, it’s clear to me that we shouldn’t have it marked as experimental in BCD either — so I now think we should go ahead and merge this PR as-is. |
|
First, @mconca, I see that this is your first PR to the repo. Thank you for opening it and welcome to BCD! Now, there's a bunch of other things to go over here. 😅 The summary: this is fine to merge, we have work to do on docs, and there are other unanswered questions for pre-releases. The main question: is this experimental?The trouble here mostly stems from a lack of good documentation for our use of "experimental". We should improve on that! In the mean time, we have the schema docs text ("no significant incompatible changes are expected in the future") and an unformalized convention that 2+ implementations means a feature is no longer experimental. I think this PR clears both hurdles, even without the pending implementations having yet shipped, though on a technicality. I say a technicality because this is a slightly weird case. The data says that this did have two distinct shipping implementations: Blink and EdgeHTML (Edge before 79). At least at one time in the not too distant past, this did satisfy the 2+ implementations convention. I'd be reluctant to merge this change on this basis alone—withdrawal of an implementation would ordinarily be an indicator of instability—but with forthcoming implementations in Safari and Firefox, I feel good about overlooking this fact. Other questions
We should review and, if applicable, fix these! I'm appreciate of @sideshowbarker's efforts to do just that. Generally, there's a question, what does "experimental" mean? #1528 raises removal of @sideshowbarker has also raised #6896 as a way to introduce pre-release data into BCD. There's extensive background there and that's where I'll take that discussion. I think that covers everything, but please @ me if I've missed something. I'll mark this as approved and merge this PR now. Thank you, @mconca, @foolip, and @sideshowbarker. |
This change adds an implementation_url value for WritableStream in Safari and iOS Safari, per https://trac.webkit.org/changeset/266172/webkit, which says > Implementation is now ready and is up to date with the latest specification. As mdn#6873 (comment) notes, that change means this feature shipped in at least TP 114 and probably was also in since TP 113.
The Writable Streams standard is stable an unchanging at this point.