-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Add details to the Application cache deprecation #5505
Conversation
@annevk This is per our discussion on blink-dev about Chrome experimenting with a reverse origin trial in deprecating AppCache. This description is how I was planning to implement this in Chrome (patch in flight) for any application cache that does not have a valid origin trial token in its manifest. I tried to write this in such away that it could apply to all browsers and not talk about origin trials here. This is my first spec edit, and this also seems a little bit abnormal of an addition to a spec, so I would take any and all guidance in this pull request. |
<!-- NON-NORMATIVE SECTION --> | ||
|
||
<p>As this feature is being removed from the Web platform, it may go through a stage where | ||
the back-end implementation has been disabled, but the Application cache API is still available |
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.
the back-end implementation has been disabled, but the Application cache API is still available | |
browser engines have disabled or removed their underlying implementations, but are still exposing the Application cache API |
…or something like that
cache</a> via a manifest attribute will result in the behavior of the | ||
<span>cache failure steps</span>, as if the manifest had a parse error.</p> | ||
|
||
<p>Additionally, when the back-end is disabled, the application cache should behave as if no |
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.
<p>Additionally, when the back-end is disabled, the application cache should behave as if no | |
<p>Additionally, when the underlying implementation has been disabled or removed, the application cache will behave as if no |
The word should can’t be used in non-normative spec content.
Or if the normative requirements that mandate the behavior described here aren’t already specified elsewhere in the spec, then this “the application cache should behave as if no resources have been cached” text would need to be moved out of this non-normative part and into a normative section.
I think this matches what Firefox will do. @valenting can confirm. I think I'd rather see if this works out in implementations and then remove all the relevant text from the standard. That is, I don't think we need to merge this, but this can serve as useful documentation until we get there. (Removal is tracked by #151.) |
Our upcoming deprecation event in Firefox 79 will disable the storage backing appcache - this means that the |
Thanks for the clarification. The important part to me is the conversation here to make sure the browser engines are behaving in similar ways during the removal process.
Thanks for the clarification. Chrome will go through |
At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
/index.html ( diff )
/offline.html ( diff )