-
Notifications
You must be signed in to change notification settings - Fork 68
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
Content Indexing #166
Comments
This seems pretty intimately tied into service workers. Is that correct? It seems like this might be something sites want to be able to do, possibly in a declarative manner, without having to entirely switch over to service workers.... |
Yeah, it takes service workers as a given, but I think that that's necessary for anything in this space: SWs are the general solution for making websites work offline, and any website that works offline is already all-in on SWs. Coming up with a workable declarative API here has already failed once in AppCache, and there are all sorts of thorny questions that need answers in the spec that SWs don't have to answer (often because those thorny questions are kicked up a level for website authors to deal with, but still). Most likely, any future offline web stuff will use SWs or at least be defined in terms of the SW model, even if the surface level is declarative. I'm generally a fan of the declarative style and limiting the power of interfaces (not to mention working without JS), but offline websites are complicated and varied enough that an imperative API seems unavoidable - at least as a first draft, until some general patterns get distilled down from actual experience. This particular proposal seems like it'd be useful out of the gate for a whole variety of use cases, and I think comparing it to an ideal integrated declarative offline website system risks having the perfect be the enemy of the good. On the proposal itself: I have a couple of concerns, though none of them are particularly severe. Mostly it just looks thin and under-specified. I filed a bunch of issues there to try and tidy some of my worries up. A big part of the usefulness of this proposal comes down to implementation - and, specifically, how, where & when the offline content is displayed. If it's in some side panel that no-one ever checks, it might not be worth bothering; if it's presented any time the browser hits network trouble, it could see lots and lots of use. |
Some more up-to-date links:
|
Request for Mozilla Position on an Emerging Web Specification
Other information
The text was updated successfully, but these errors were encountered: