Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adopt new definition and guideline for experimental status #9933
Adopt new definition and guideline for experimental status #9933
Changes from all commits
54386ee
9c5f1aa
41d8eb3
36dd033
4ab8d66
05429dc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the feature is in a W3C recommendation and it just happens that Safari reached the finish line first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Safari crosses the finish line first, then it's still experimental until at least one engine catches up.
Part of the goal here is to clearly distinguish between experimental and standard track. Under this revised approach, experimental can be set independently of the standard track value (that is to say, the two values don't depend on each other—you don't even have to know what the standards status is to set the experimental status). This makes it more clear what experimental actually adds to our data set (a marker of consensus, or failing that, stasis) and lets us deal with features that are unchanging, but not standardized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get all that. It just seems misapplied here. If a feature is a full W3C recommendation, it's not a matter of if the second browser will implement. It's a matter of when. Knowing that fact is useful to developers. This information can help developers make other vendors aware that they should prioritize something. Here's how this would play out for Chrome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, a question: do you mean that the guideline and definition as written shouldn't result in this outcome? Or that you'd like to see different text that leads to a different outcome?
Second, what I want from this PR is to encourage the scenario you describe. Ideally, the experimental flag should be a signal to web developers to tell browser vendors and spec authors what they think of an emerging feature, including saying "I want this feature." I want to upstream the new experimental definition to MDN itself too, so this signal is stronger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You overall heuristic seems misapplied to the case of a completely speced feature with one implementation, where 'speced feature' means one in a full recommendation.
The scenarios for a speced and unspeced feature are different.
Web developers would treat these differently as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jpmedley I'm not really following here. How good a spec here is actually very hard to judge, and browser implementers will not trust the status the spec claims for itself, whether that's "Unofficial Draft", "Living Standard", or "Recommendation".
I don't think we should use the spec's own claim about how stable it is as input to the "experimental" setting here, but base it entirely on implementation status, like @ddbeck is suggesting in this guideline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow Joe either. I think this guideline is a lot clearer and I agree with @foolip and @ddbeck that it is good that we don't need to make any assumptions about the status of specs. @jpmedley feel free to start a discussion in an issue if you feel strongly about it.
Let's merge this. There is a lot of useful guideline work in here.