There are a few updates that need to be made to the way Drupal handles some things in Core to make HTML5 App Cache something that can be realistically accomplished. I'm looking at the HTML5 Rocks' A Beginner's Guide to Using the Application Cache.
IMO, there are three things that need to change in Drupal Core for this to happen:

  1. AddType text/cache-manifest .appcache needs to be added to Drupal's .htaccess
  2. Aggregated CSS needs to have a reliable, non-hashed name and location. I'd suggest something like files/css/css-aggregate.css
  3. Aggregated JS needs to have a reliable, non-hashed name and location. I'd suggest something like files/js/js-aggregate.css

These three items, at a minimum, are needed in order for themes to implement appcache manifests and, as far as I can surmise, won't affect any theme that doesn't choose to implement an appcache manifest. As such, I'd love to see this not only implemented in D8, but also backported to D7.

Comments

cosmicdreams’s picture

cosmicdreams commented

I'm no expert when it comes to all of the previous discussions about aggregated css and js, but based on the limited amount I know I think that requirements 2 and 3 may prevent this from getting into core.

Perhaps this should be pursued as a Contributed module. (And maybe we can have the contributed module fully-replace the aggregation scheme we currently use.)

jacine’s picture

jacine
she/her
Location New York
commented
Status: Active » Closed (won't fix)

Yeah, we discussed this in the last IRC meeting:

[4:32 PM] Anyone have thoughts on these: http://drupal.org/node/1435040 & http://drupal.org/node/1435040
[4:32 PM] http://drupal.org/node/1435040 => Make Core more Appcache Friendly => Drupal core, other, normal, active, 0 comments, 2 IRC mentions
[4:32 PM] jacine: I did some manifest file skunkworks last year.
[4:32 PM] Honestly, I don't think it's viable for Drupal in its current form.
[4:33 PM] Crell: That's sad :(
[4:33 PM] Maybe we should "won't fix" it?
[4:33 PM] Given the design flaws of appcache, I don't think it's useful for a non-trivially-sized website. It's ONLY for full on applications.
[4:33 PM] jacine: I would.

Based on that I'm going to mark this "won't fix" for now. It is possible to do this in contrib, and would likely be better off there unless there are huge changes made to the way Drupal handles aggregation.

ohnobinki’s picture

ohnobinki commented

To respond to the items in the report:
1. I don't think that modifying .htaccess is necessary. Most everything served up by drupal, which would include a hypothetical application cache manifest, are dynamically generated. You can set the MIME type of any arbitrary page you serve using drupal_add_http_header('Content-Type', 'text/cache-manifest; charset=utf-8');
2 and 3. How in the world would having a static CSS or JS path name help with application caches? The only thing that matters is that your cache manifest _knows_ the URI of the CSS or JS. Having aggregated files named with a hash actually helps application caches because it works around browsers trying to hold onto ancient .js files. The real issue here, I am going to guess, would be if different pages add different sets of scripts to the page. Then producing the application manifest would mean actually loading or at least executing every single page which would need to be cached to detect the javascript URIs. However, if you write an offline app which only relies on a single HTML page being loaded (more common), it should be possible to calculate a manifest for just that page. Though your manifest generator will have to essentially wrap around the normal page load and, at the last moment, before the page is printed out to the browser, hook in somehow and send the manifest instead.

Snugug’s picture

Snugug commented

Why would you resurrect a 6 month old closed thread?