safari en back/forward cache in html 4.01 strict

[Rene59]

Niet echt een overduidelijke topic titel, dus ik zal het even toelichten.

Ik probeer een html 4.01 strict pagina met dynamische content te maken, waarbij de browsercache door het achterliggende php script uitgeschakeld wordt dmv de http header.
Dit werkt, behalve voor de back/forward cache van Safari.
Op http://developer.apple.com/internet/safari/faq.html#anchor5 staat het volgende:

Safari's Back/Forward cache (the cache pulled from when a visitor presses the Back or Forward browser buttons) can also be thwarted by insuring that your page contains a frame. Frame-based pages are never stored in the back / forward cache and you can insure your non-frame based page behaves similarly by adding the invisible iframe below.

code:

    <iframe style="height:0px;width:0px;visibility:hidden" src="about:blank">
        this frame prevents back forward cache
    </iframe>

De workaround werkt, echter, het iframe element wordt niet ondersteund door html 4.01 strict.
Mijn vraag is dus, weet iemand hier een andere workaround voor?

[Verwijderd]

Is er een prangende reden om strict te gebruiken i.p.v. transitional?

[HuHu]

Het iframe via JavaScript in je pagina stoppen nadat je pagina geladen is. Dan valideert 'ie als strict, maar je hebt toch stiekem een iframe erin gestopt .

Maar als Apple zelf dit als de oplossing aandraagt, dan vermoed ik dat er dus geen andere oplossing is. Anders hadden ze die er wel bij gezet.

[RobIII]

Mja, ik lees toch echt:

Safari's Back/Forward cache [...] can also be thwarted...

Nu heb ik niet zo 1, 2, 3 een test-omgeving om het te reproduceren, maar zoals ik het lees is het een laatste optie om dat iFrame _{(pun intended )} te gebruiken. Ik zou toch eens kijken waarom die headers niet gewoon doen wat ze moeten doen.

[ Voor 13% gewijzigd door RobIII op 23-07-2008 18:36 ]

[Verwijderd]

Ik heb het even gecheckt (weliswaar met een developer preview van Safari 4), maar die http-headers werken inderdaad niet voor de back-forward-cache.

Dit wel:

HTML:

<script type="text/javascript">
    document.write('<iframe style="height:0px;width:0px;visibility:hidden" src="about:blank"> </iframe>');  
</script>

Let wel: ingevulde form-velden blijven wel ingevuld!

Door php gegenereerde html wordt wel ge-update.

[crisp]

Verwijderd schreef op woensdag 23 juli 2008 @ 17:58:
Is er een prangende reden om strict te gebruiken i.p.v. transitional?

Ja, transitional is enkel bedoelt voor het 'oplappen' van oude documenten. Voor nieuwe documenten is strict de norm

Rene59 schreef op woensdag 23 juli 2008 @ 17:42:
Niet echt een overduidelijke topic titel, dus ik zal het even toelichten.

Ik probeer een html 4.01 strict pagina met dynamische content te maken, waarbij de browsercache door het achterliggende php script uitgeschakeld wordt dmv de http header.

Welke HTTP header(s)? En krijg je die ook goed door? Confirmeer dat eens met een HTTP sniffer oid...

Dit werkt, behalve voor de back/forward cache van Safari.
Op http://developer.apple.com/internet/safari/faq.html#anchor5 staat het volgende:
[...]
De workaround werkt, echter, het iframe element wordt niet ondersteund door html 4.01 strict.
Mijn vraag is dus, weet iemand hier een andere workaround voor?

Dat is, zoals RobIII al probeert te zeggen, echt een last-resort workaround. Zorg eerst gewoon eens dat je headers goed zijn.

Verder is het niet waar dat iframe niet ondersteund wordt door HTML 4.01 Strict; het is immers nog steeds een UA-requirement om daar support voor te bieden ongeacht de doctype. Validatie is slechts een tool en geen doel (en in HTML5 is iframe gewoon weer conformant omdat er valide usecases voor zijn - waar dit er overigens niet 1 van is )

[Rene59]

In de faq van Apple staat ook een PHP voorbeeld welke headers te sturen om de cache uit te schakelen. Ik heb het met die headers getest.
In andere browsers werkt het, dus ik heb geen reden gezien om ze ook te controleren met een sniffer, dus dat kan ik nog wel doen.
Overigens lees ik in het artikel "Safari's Back/Forward cache can also be thwarted", dus ik denk toch echt dat dit de enige manier is volgens Apple.
De reden dat ik het hier vraag is omdat ik hoopte op een slimmerik die iets anders bedacht heeft

Laatste punt ben ik verder met je eens, ik heb de workaround van Apple dan ook gewoon geimplementeerd. Ik vind het alleen niet zo'n nette oplossing.

[Verwijderd]

Ik zou andere browsers er niet mee lastig vallen en dus via javascript een iframe toevoegen. Ik zou in dit geval aan user agent-sniffing doen, maar je kunt je afvragen of de kool het sop waard is.

Toch vind ik transitional in dit geval te verdedigen.

@Crisp: Je hebt ongetwijfeld een punt, maar ik vind deze manier van werken van Safari een dusdanige afwijking van wat je mag verwachten, dat ik transitional zou accepteren. De javascript-oplossing is m.i. smeriger dan een doctype misbruiken.

[Bosmonster]

Verwijderd schreef op donderdag 24 juli 2008 @ 12:04:
Ik zou andere browsers er niet mee lastig vallen en dus via javascript een iframe toevoegen. Ik zou in dit geval aan user agent-sniffing doen, maar je kunt je afvragen of de kool het sop waard is.

Toch vind ik transitional in dit geval te verdedigen.

@Crisp: Je hebt ongetwijfeld een punt, maar ik vind deze manier van werken van Safari een dusdanige afwijking van wat je mag verwachten, dat ik transitional zou accepteren. De javascript-oplossing is m.i. smeriger dan een doctype misbruiken.

Je doctype aanpassen (die je juist bewust gekozen hebt) voor een klein probleem met 1-2% van de gebruikers vind je een beter idee?

Das imho hetzelfde als een nieuwe auto kopen als je een lekker band hebt.

[Verwijderd]

Ik zie een andere vergelijking: je wordt gedwongen te kiezen tussen een auto met een kras in de lak of één met twee ontbrekende velgen: geen van beide is ideaal.

Ik begrijp uit de TS dat dit probleem het correct functioneren van de pagina onmogelijk maakt in verband met de dynamische gegenereerde content. Dan is 1 à 2% wel weer veel.

Maar goed, het is maar een mening. Ik zeg alleen dat ík zou gaan voor transitional. Wil je dat per se niet, dan maar die andere vieze oplossing.

edit:
Krom Nederlands hersteld.

[ Voor 17% gewijzigd door Verwijderd op 24-07-2008 15:33 ]