-
Notifications
You must be signed in to change notification settings - Fork 344
Add API surface for feature levels #4868
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
Conversation
This provides a dictionary member that can be used for feature level requests in the future. It currently does not accept any value; the only thing it does is make sure that _if_ a feature level is requested, it can be rejected. This is the appropriate behavior for a browser to have before it adds support for any other feature levels. It has type `any` so that it `requestAdapter()` can return `null` (rather than rejecting) regardless of how we end up phrasing feature levels in the future. This is planned to be used for Compat mode, likely simply by accepting a string value of `"compat"`. Issue: 4656
|
Previews, as seen when this build job started (e7f7a0e): |
|
I might be overthinking this, but using the word "feature" for |
|
You're right, I even made that comment myself on the last PR and totally forgot about it. |
This reverts commit e706930.
|
Reverted to |
|
Oh, I should update the compat proposal doc too. |
toji
left a comment
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.
LGTM as a first step.
|
Actually I'm going to update the compat proposal separately because the change is nontrivial. |
This provides a dictionary member that can be used for feature level requests in the future. It currently does not accept any value; the only thing it does is make sure that if anything is passed to
featureLevel, we know not to ignore it. This is the appropriate behavior for a browser to have before it adds support for any other feature levels.Proposing this for M0 to set up the API surface.
It has type
anyso that itrequestAdapter()can returnnull(rather than rejecting) regardless of what types we end up using to describe feature levels in the future. This is to make it consistent with the future case where the browser does understand the feature level but the hardware doesn't support it (which probably should returnnull- the request was OK but there was no adapter to return).This is planned to be used for Compat mode, likely simply by accepting a string value, e.g.
"compat"(% bikeshedding).Issue: #4656