Das eigentliche Problem besteht (mal wieder) darin, dass man serverseitig nicht die nötigen Infos hat, um bspw. das Manifest entsprechend on-the-fly zusammenzustellen.
Das Grundproblem ist vielmehr, dass ein deklaratives Manifest den Ansprüchen heutiger Webapps nicht genügt. Sie laden Daten gemäß einer komplexen Logik, die sich nicht so einfach deklarativ ausdrücken lässt.
ACK.
Es wäre demnach wesentlich hilfreicher und effizienter, wenn man das Anlegen eines Manifests dem Browser überlassen würde. Also ihm quasi sagen könnte, packe alle Resourcen dieser Seite (mit Ausnahme von 'xyz') in den Application Cache und erzeuge eine entsprechende Manifest-Datei.
Ich denke nicht, dass man dem mit Headern beikommen kann. Dieses Modell skaliert nicht. Wie sollte man irgendwelche JavaScript-Fähigkeiten, die ein Polyfill benötigen oder nicht, in einem Header ausdrücken? Das kann nur in JavaScript geschehen.
Wieso sollte dieses Modell denn "skalieren" können!?
Die Fähigkeiten eines Browsers skalieren doch auch nicht, und nur darauf kommt es an.
Beispiel (Schriftarten):
X-Fonts:woff=0.8,ttf=0.5,svg=0.3
Beispiel (Pixelratio):
X-Pixel-Ratio: 2
Alleine mit diesen Infos auf der Serverseite ließen sich viele Dinge ganz einfach lösen, für die man heutzutage entweder Javascript braucht, sie dem Browser überlassen muss (der sich bspw. aus mehreren Alternativen seine Bevorzugte selbst raussucht) oder mit einem Fallback leben muss!
Alternativ sind wir ansonsten wieder beim UA-Sniffing
Im Moment erscheint mir eine Variante, die Local Storage verwendet da fast besser geeignet zu sein, als der Apllication Cache. Denn dieser besitzt imho zu viele Nachteile, bzw. Unzulänglichkeiten.
Das ist glaube ich Konsens. ;)
Na immerhin - ist ja schön, wenn es auch mal einen Konsens gibt ...! ;-)
Wobei localStorage und IndexedDB noch keinen Sync-Mechanismus und kein Asset-Management mitbringen. Die müsste man selbst entwickeln. PouchDB geht in eine solche Richtung, wobei es weniger für Assets gedacht ist.
Hmmm ..., also wäre aktuell ggf. ein "Mix" aus Application Cache, Local Storage und Browser Cache die "beste" Variante ...!?
Um auf meine eigentliche Ausgangsfrage zurückzukommen:
Wie wir festgestellt haben, sind Fonts denkbar "ungeeignet", um sie im Application Cache zu speichern (da man alle Formate speichern müsste, weil es keine Möglichkeit gibt, vorher festzustellen, welches Format der jeweilige Browser unterstützt).
Aber eine oder mehrere fehlende Fonts-Files hindern den Browser ja nicht daran, eine Seite trotzdem anzuzeigen. Also könnte man z.B. auch hingehen und sagen:"OK, fast alle Browser, die Application Cache unterstützen, verstehen auch das WOFF Format (mit Ausnahme vom Android Browser < 4.4)! Also packe ich entweder nur die WOFF Files in mein Manifest, oder zusätzlich auch noch die TTF Files (für besagte Android Browser), oder ich versuche das serverseitig per UA-Sniffing zu ermitteln (was bei der Mobile Version noch relativ einfach & zuverlässig möglich ist)."
Wirklich "schön", bzw. praktisch & zweckmäßig ist das aber alles nicht ...! :-(
Gruß Gunther