From MDN：
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
Because it was replaced by Service Workers.
AppCache has a not so good API design and Service Worker can be used more flexible.
Related
Is ServiceWorker intended to replace Appcache, or is the intention that the two will coexist? Phrased another way, is appcache about to become deprecated?
Blink's Service Worker team is keen on deprecating AppCache (We will follow our usual intent to deprecate process). We believe that Service Worker is a much better solution. Also, it should be pretty easy to offer a drop-in replacement for AppCache built on top of SW. We'll start by collecting usage metrics and do some outreach.
AppCache and Service Worker should coexist without any issue since offering offline support via AppCache for browsers that don't support Service Workers is a valid use case.
#flo850 If it's not working, please let us know by filing a bug.
I must say that Services Worker is not only the replacement for AppCache, but it’s far more capable. An AppCache can’t be partially updated, a byte-by-byte manifest comparison to trigger the update seems odd and there are several use cases leading to security and terrible usability problems.
Even Chrome and Firefox are planning to stop support for AppCache in the near future. Now that service workers are supported by Chrome, Opera, and Firefox.Also, The noises coming from Microsoft and Safari have been positive with respect to implementation and under consideration.
As a cache tool, it will coexist with appcache. Appcache works on virtually every browser.
But service workers are a solid foundation that will permit new usage like push (even when the browser is in the background) , geofencing or background synchronization.
I am in the process of implementing an "offline" option of a web application and am uncertain wether to proceed with the HTML Application Cache or the browser cache.
There are several aspects of the Appcache that make it attractive, name the ability to leverage the FALLBACK section to support the loading of a "minimal" version of the app if the client is disconnected.
My primary concern with the Application Cache is it's longevity and browser support. While I am willing to only support modern browsers, I fear the Application Cache may become phased out in future HTML specs. This fear is founded in this line of the current spec :
The following features are at risk and may be removed due to lack of implementation.
Application Cache
http://www.w3.org/TR/html5/
Any insight into this would be greatly appericiated.
I checked out the site at http://www.w3.org/TR/webdatabase/ and I saw a huge banner there that said
"Beware. This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further."
What's that supposed to mean? I was thinking of implementing something using this feature. But I don't want to implement something in it if its not going to be standardized(eventually).
Do you suggest that I go ahead working on it? If not, is there an alternative that would be standardized? Or is it just another spec that has been scrapped?
It means exactly what it says: the W3C has dropped the standard and isn't planning to do any further work on it.
You're looking for IndexedDB, which is under active development.
From three paragraphs further on in the document:
This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.
If not, is there an alternative that would be standardized?
Web Storage
Ok, so it isn't a huge worry yet as it is only supported by a few browsers:
Mozilla Firefox: Supported
Google Chrome: Supported since version 13 (Use an alternate syntax)
Safari: Currently not supported Internet
Explorer: Currently not supported
However, prefetch makes me twitch. If the user lands on your page and bounces off to another site have you paid for the bandwidth of them visiting your prefetch links?
Isn't there a risk of developers prefetching every link on the page which in turn would make the website a slower experience for user?
It looks like it can alter analytics. Will people be forcing page views onto users via prefetch?
Security, you wont know what pages are being prefetched. Can it prefetch malicious files?
Will all this prefetching be painful for mobile users with limited usage?
I can't call myself an expert on the subject, but I can make these observations:
Prefetch should be considered only where it is known to be beneficial. Enabling prefetch on everything would just be silly. It's essentially a balance of server load vs user experience.
I haven't looked into the HTML5 prefetching spec, but I would imagine they've specified a header that states "this request is being performed as part of prefetching", which could be used to fix the analytics problem - i.e. "if this is a prefetch, don't include it in analytics stats".
From a security standpoint, one would expect prefetch to follow the same cross-domain rules as Ajax does. This would mitigate any cases where XSS is an issue.
Mobile browsers that support HTML5 prefetch should be smart enough to turn it on when using WiFi, and off when using potentially expensive or slow forms of network connection, e.g. 2G/3G.
As I've stated, I can't guarantee any of the above things, but (like with any technology) it's a case of best practices. You wouldn't use Cache-Control to force every page on your site to be cached for a year. Nor would you expect a browser to satisfy a cross-domain Ajax request. Hopefully the same considerations were/will be taken for prefetching.
To answer the question of analytics and statistics, the spec has the following to say:
To ensure compatibility and improve the success rate of prerendering requests the target page can use the [PAGE-VISIBILITY] to determine the visibility state of the page as it is being rendered and implement appropriate logic to avoid actions that may cause the prerender to be abandoned (e.g. non-idempotent requests), or unwanted side-effects from being triggered (e.g. analytics beacons firing prior to the page being displayed).
All the decent browsers (Chrome, FX, etc) now support built-in spell checking.
However the popular but rubbish axis of IE doesn't (not even IE8 - pointless 'accelerators': yes, much needed dictionary support: no). Unless you download an excellent free plugin, but you can't expect corp users to do that.
Our clients want spell checking in the enterprise web app that we supply, so we bought in a 3rd party spell checking component to keep them happy. It works, but isn't terribly good - especially when compared to anything built in to the browser.
It also looks like the spell check dialog in Word 2000 (probably current back when it was developed). Not such a problem for our clients, half of whom are stuck on Office 2000 and IE6.
I want to only enable this component when the user doesn't have built in spell checking.
Does anyone know a way to detect this?
You already know which browsers have built-in support and which browsers don't so you may use some form of browser sniffing to decide whether you enable the spell-checking component or not.
You may also try to ask your users if they already have some spell-checking enabled and let them answer Yes/No/Don't know. If they don't know, fall back to automatic detection. This is better than using sniffing only because sniffing is known to be unreliable in some circumstances.
Detecting things that are part of a browser's UI is hard, if possible. Due to browsers' security policies, a web site can't access most part of the API that could expose something useful for feature detection. And even if security was not a problem, you would probably still face one distinct API for every browser, since internal browser mechanics are not standardized.
Not sure if this is possible even with something like browsercap or Microsoft Browser Definition File Schema, as mentioned above it is kind of outside the allowed scope.
Have you considered just going with a server side spell checker? So they can use the client if they like or click the spell check button like in GMail. This also means that you can control any updates to the dictionary.