Dokumente überblenden

[TS]

Hello,

ist es eigentlich möglich mit CSS, die per Navigation gewählten Dokumente sanft überzublenden, anstatt sie hart umzuschalten?

Liebe Grüße
Tom S.

[Matthias Apsel]

Hallo TS,

ist es eigentlich möglich mit CSS, die per Navigation gewählten Dokumente sanft überzublenden, anstatt sie hart umzuschalten?

Wenn es sich um eigene Dokumente handelt, dann nicht.

Bis demnächst
Matthias

[JürgenB]

Hallo Matthias,

warum nicht? Meine spontane Idee hierzu war https://wiki.selfhtml.org/wiki/CSS/Eigenschaften/Animation/Animation.

Gruß
Jürgen

[Rolf b]

Also so was?

Das setzt dann voraus, dass man nach Navigation per Ajax den Content der mainContainer nachlädt.

Für ein ganzes Dokument würde es wohl einen iframe voraussetzen, dem man opacity gibt. Weil - der Browser zeigt entweder das eine oder das andere Dokument an, du brauchst während der Überblendung aber beide.

Gibt's ein Event, dass das Ende der Animation anzeigt? Das Setzen der active-Klasse würde ich gern bis zum Ende der Animation verzögern, und setTimeout finde ich dafür doof.

Rolf

[JürgenB]

Hallo Rolf,

ich hatte daran gedacht, beim Start alle Farben auf Hintergrund oder Transparent zu setzen, und dann per Animation zeitverzögert die Farben/Transparenz zu setzen und per Transition das Ganze etwas weicher zu machen.

Gruß
Jürgen

[JürgenB]

Hallo,

jetzt verstehe ich euren Einwand, ich habe „Überblenden“ mit „sanft einblenden“ übersetzt.

Ob die Zeit nach „onunload“ für ein sanftes Ausblenden reicht, weiß ich nicht.

Gruß
Jürgen

[Gunnar Bittersmann]

@@TS

ist es eigentlich möglich mit CSS, die per Navigation gewählten Dokumente sanft überzublenden, anstatt sie hart umzuschalten?

Bei einer single page app kannst du mit den „Seiten“ machen, was du willst.

Wenn du verschiedene HTML-Dokumente hast, wissen die nichts voneinander. Es ist aber ein Ein- und Ausblenden möglich; also ein Überblenden über Weiß oder über Schwarz. Beispiel (Das Einblenden kann etwas ruckeln, hm.)

Ansonsten wäre es Sache des Browsers, von einer Seite zur nächsten überzublenden. Internet Explorer konnte das mal.

LLAP 🖖

[Mitleser]

Wenn du verschiedene HTML-Dokumente hast, wissen die nichts voneinander. Es ist aber ein Ein- und Ausblenden möglich; also ein Überblenden über Weiß oder über Schwarz. Beispiel (Das Einblenden kann etwas ruckeln, hm.)

Auf "articles" klicken, danach History-Back = opacity bleibt bei 0 = weiße Seite. Aktueller FF, Windows 7.

Internet Explorer konnte das mal.

Hatte mich nicht getraut, dass zu erwähnen 😉

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Es ist aber ein Ein- und Ausblenden möglich; also ein Überblenden über Weiß oder über Schwarz.

Und auch das nicht ohne JavaScript.

Bis demnächst
Matthias

[JürgenB]

Hallo Matthias,

Und auch das nicht ohne JavaScript.

das ist aber mMn aber kein Problem mehr. Ich messe gerade auf meiner Seite den Anteil der Besucher ohne Javascript, gestern und vorgestern waren es weniger als 2%. Da sollte man sich eher um die IE8-User kümmern, als um die Javascriptverweigerer. Und ich schätze, das die Gruppe der User mit Einschränkungen auch größer sein dürfte.

Gruß
Jürgen

[Matthias Apsel]

Hallo JürgenB,

Und auch das nicht ohne JavaScript.

das ist aber mMn aber kein Problem mehr.

Dem stimme ich zu.

Aber die Frage war, ob es mit CSS möglich ist. Wenn man liest allein mit CSS, ist es das nicht.

Bis demnächst
Matthias

[TS]

Hello,

Aber die Frage war, ob es mit CSS möglich ist. Wenn man liest allein mit CSS, ist es das nicht.

So war es eigentlich auch gemeint. Aber mit Glück kann ich das mit "über weiß" oder "über scvhwarz" blenden auch so bauen, dass man es nicht merkt, wenn JS nicht vorhanden ist.

Liebe Grüße
Tom S.

[beatovich]

hallo

das ist aber mMn aber kein Problem mehr. Ich messe gerade auf meiner Seite den Anteil der Besucher ohne Javascript, gestern und vorgestern waren es weniger als 2%. Da sollte man sich eher um die IE8-User kümmern, als um die Javascriptverweigerer. Und ich schätze, das die Gruppe der User mit Einschränkungen auch größer sein dürfte.

Wie hast du den Anteil ermittelt? Selbst grosse Webstatistikportale haben zuweilen sehr unterschiedliche Ergebnisse, und das kann bei Sites mit wenig Zugriffen um so mehr gelten.

[JürgenB]

Hallo

Wie hast du den Anteil ermittelt? Selbst grosse Webstatistikportale haben zuweilen sehr unterschiedliche Ergebnisse, und das kann bei Sites mit wenig Zugriffen um so mehr gelten.

ich gebe einem Element ein Hintergrundbild (ohnejs.gif). In einem am Ende des body eingebundenem Script gebe ich diesem Element ein weiteres Hintergrundbild (mitjs.gif). Im Logfile zähle ich dann die Zugriffe auf die beiden Bilder und sehe so, wie oft das CSS-Bild und das Javascriptbild aufgerufen werden. Besucher ohne css oder Besucher, die keine Grafiken einbinden, werden so nicht berücksichtigt.

Gruß
Jürgen

[beatovich]

hallo

ich gebe einem Element ein Hintergrundbild (ohnejs.gif). In einem am Ende des body eingebundenem Script gebe ich diesem Element ein weiteres Hintergrundbild (mitjs.gif). Im Logfile zähle ich dann die Zugriffe auf die beiden Bilder und sehe so, wie oft das CSS-Bild und das Javascriptbild aufgerufen werden. Besucher ohne css oder Besucher, die keine Grafiken einbinden, werden so nicht berücksichtigt.

Das beschreibt natürlich die Methode, wie du Daten erzeugst, aber leider nicht, wie du sie auswertest.

Denkbar sind ja

• Kein JS wird heruntergeladen (du sprichst von eingebundenem Script)
• JS-Datei wird herunter geladen, aber die Ausführung findet nicht statt.
• Die Ausführung des JS findet statt, aber ein Request auf die referenzierte Ressource findet nicht statt.
• Die Kontrollressource wird angefragt, Antwort 304
• Die Kontrollressource wird angefragt, Antwort 200

Ferner die Frage: welchen Einfluss hat JS-Ausführung mit dem Anteil der Wiederbesucher? Also Leute, die deine Seite öfters wieder besuchen sind wohl bevorzugt JS-Anwender, auch wenn sie NoScript benutzen.

[JürgenB]

Hallo,

• Kein JS wird heruntergeladen (du sprichst von eingebundenem Script)
• JS-Datei wird herunter geladen, aber die Ausführung findet nicht statt.

beide Fälle zähle ich als „kein Javascript“.

• Die Ausführung des JS findet statt, aber ein Request auf die referenzierte Ressource findet nicht statt.

würde ich auch als „kein Javascript“ zählen. Aber für diesen Fall habe ich als Kontrolle das CSS-Hintergrundbild.

• Die Kontrollressource wird angefragt, Antwort 304
• Die Kontrollressource wird angefragt, Antwort 200

beide Fälle Zähle ich als „mit Javascript“.

Ferner die Frage: welchen Einfluss hat JS-Ausführung mit dem Anteil der Wiederbesucher? Also Leute, die deine Seite öfters wieder besuchen sind wohl bevorzugt JS-Anwender, auch wenn sie NoScript benutzen.

diese Analyse hat natürlich das Problem, das sie nur die Besucher meiner Seiten zählt, und meine Seiten bieten für Besucher ohne Javascript nicht viel. Daher wäre es natürlich interessant, diese Analyse auf einer JS-freien Seite laufen zu lassen.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

Und auch das nicht ohne JavaScript.

Ja, und?

das ist aber mMn aber kein Problem mehr.

Es ist kein Problem. Überblendeffekthascherei ist progressive enhacement. Natürlich funktioniert der Seitenwechsel auch ohne JavaScript – dann eben ohne Effekt. So what?

Ich messe gerade auf meiner Seite den Anteil der Besucher ohne Javascript, gestern und vorgestern waren es weniger als 2%. Da sollte man sich eher um die IE8-User kümmern, als um die Javascriptverweigerer.

Die Javascriptverweigerer sind nicht mal das Problem. Sondern alle. Jeder ist ohne JavaScript solange das JavaScript nicht geladen ist. Und das passiert bei mehr Leuten als man denken mag.

“While it’s tempting to think that only a small minority of visitors will miss out on a site’s JavaScript, the truth is that everybody is a non‐JavaScript user until the JavaScript has finished loading ...if the JavaScript finishes loading. Flaky connections, interfering network operators, and unpredictable ad‐blocking software can torpedo the assumption that JavaScript will always be available.
“The problem is not with people deliberately disabling JavaScript in their browsers. Although that’s a use case worth considering, it’s not the most common cause of JavaScript errors.”
—Jeremy Keith, Resilient web design, Chapter 4

LLAP 🖖

[JürgenB]

Hallo Gunnar,

wenn die Ladeverzögerung ein Problem ist, kann man die kritischen Teile des Scripts (und evtl. auch des css) direkt ins HTML schreiben.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

wenn die Ladeverzögerung ein Problem ist, kann man die kritischen Teile des Scripts (und evtl. auch des css) direkt ins HTML schreiben.

Das will man aber nicht bei jeder Seite einer Website machen, wenn’s immer wieder dasselbe JS/CSS ist. Das ist im Browsercache besser aufgehoben und wird bei Folgeaufrufen von dort geholt.

Man kann aber beim ersten Aufruf der Website (kein Cookie gesetzt) JS/CSS serverseitig ins HTML-Dokument schreiben, clientseitig in den Browsercache oder localStorage packen und einen Cookie „hab ich schon“ setzen. Bei nachfolgenden Seitenaufrufen von dieser Website mit Cookie „hab ich schon“ wird das JS/CSS nicht erneut ins HTML geschrieben.

LLAP 🖖

[Mitleser]

Man kann aber beim ersten Aufruf der Website (kein Cookie gesetzt) JS/CSS serverseitig ins HTML-Dokument schreiben, clientseitig in den Browsercache oder localStorage packen und einen Cookie „hab ich schon“ setzen. Bei nachfolgenden Seitenaufrufen von dieser Website mit Cookie „hab ich schon“ wird das JS/CSS nicht erneut ins HTML geschrieben.

Wenn man richtig heftig Cachen kann / will / muss, dann gibt es den ersten Aufruf an das Backend womöglich nur ein einziges Mal, danach antwortet der Cache.

[Gunnar Bittersmann]

@@Mitleser

Man kann aber beim ersten Aufruf der Website (kein Cookie gesetzt) JS/CSS serverseitig ins HTML-Dokument schreiben, clientseitig in den Browsercache oder localStorage packen und einen Cookie „hab ich schon“ setzen. Bei nachfolgenden Seitenaufrufen von dieser Website mit Cookie „hab ich schon“ wird das JS/CSS nicht erneut ins HTML geschrieben.

Wenn man richtig heftig Cachen kann / will / muss, dann gibt es den ersten Aufruf an das Backend womöglich nur ein einziges Mal, danach antwortet der Cache.

Es geht darum, beim ersten Seitenaufruf keine separaten HTTP-Requests für JS/CSS zu brauchen.

LLAP 🖖

[TS]

Hello,

Es geht darum, beim ersten Seitenaufruf keine separaten HTTP-Requests für JS/CSS zu brauchen.

Wie war doch gleich der Algorithmus, durch den entschieden wird, ob die Ressource nochmal neu angefordert werden muss, oder ob sie schon voerliegt? Kann man sich auf einen einzigen gültigen verlassen?

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

Wie war doch gleich der Algorithmus, durch den entschieden wird, ob die Ressource nochmal neu angefordert werden muss, oder ob sie schon voerliegt?

Ist Cookie gesetzt?

Bzw.: Ist der Inhalt im localStorage?

LLAP 🖖

[TS]

Hello,

Wie war doch gleich der Algorithmus, durch den entschieden wird, ob die Ressource nochmal neu angefordert werden muss, oder ob sie schon vorliegt?

Ist Cookie gesetzt?

Bzw.: Ist der Inhalt im localStorage?

Das kann ich jetzt nicht wirklich glauben! Der Inhalt interessiert doch mMn nicht.
Es ging um Link Relations (CSS) oder andere secondary Requests (SRC=), wie JavaScript oder Bilder/Videos.

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

Das kann ich jetzt nicht wirklich glauben!

Hat Rolf b dich inzwischen gläubig gemacht?

LLAP 🖖

[TS]

Hello,

Das kann ich jetzt nicht wirklich glauben!

Hat Rolf b dich inzwischen gläubig gemacht?

Er hat mir eine Interpretation deiner einen Aussage (Local Storage) gegeben, die man nachverfolgen kann. Aber so ganz sicher, wie Du as wohl gemeint haben könntest, erschien er mir auch nicht.

Wie das in der Praxis dann aussieht, ist mir trotzdem noch schleierhaft. Wenn ich z. B. ein generelles Stylesheet (das für alle Dokumente der Site gelten soll) im Local Storage halten will, wie würde das aussehen müssen, damit man auch einen Fallback hat?

Und was ein Cookie hier zu suchen hat, hast Du leider auch nicht näher ausgeführt. Soll da ggf. auch ein Stylesheet reinpassen?

Generell frage ich mich immer noch, wie ich den Fallback (Das Laden des Stylesheets vom Server) verhindern soll für den Fall, dass das Local-Storage das Erwünschte enthält. Und wie erkenne ich, dass das Gespeicherte wirklich das Erwünschte ist?

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Ich glaube da liegt noch ein Grundsatz-Verständnisproblem vor.

Es ging in diesem Zweig hier nicht mehr darum, ein externes Stylesheet zu laden, sondern es ging darum, dass das Stylesheet ins HTML-File geschrieben wird und bei Bedarf (wenn der User es schon einmal geladen hatte und im Local Storage vorhält, weil ein Skript es da reingeschrieben hat) bei der Erzeugung des Dokuments durch den Webserver weggelassen wird.

Wie das in der Praxis dann aussieht, ist mir trotzdem noch schleierhaft. Wenn ich z. B. ein generelles Stylesheet (das für alle Dokumente der Site gelten soll) im Local Storage halten will, wie würde das aussehen müssen, damit man auch einen Fallback hat?

Fallback ist hier der Standardfall - wenn der User das nicht im Local Storage hat ist das Cookie nicht gesetzt, also liefert der Server das Stylesheet im HTML mit aus.

Nach dem Ausliefern greift ein ebenso vorhandenes Skript, das das CSS in den Local Storage schreibt und das Cookie setzt, sofern das erlaubt ist. User ohne Cookies laden eben jedesmal das HTML mit Stylesheet, das ist der größte flaw gegenüber echtem Caching, das ja auch ohne Cookies und nur mit normalen HTTP-Headern funktioniert.

Und was ein Cookie hier zu suchen hat, hast Du leider auch nicht näher ausgeführt. Soll da ggf. auch ein Stylesheet reinpassen?

Nein, das Cookie zeigt dem Webserver schon beim Request an, ob die Ressource im Local Storage vorhanden ist, weil sich der Local Storage selbst ja durch den Webserver nicht abfragen lässt.

Generell frage ich mich immer noch, wie ich den Fallback (Das Laden des Stylesheets vom Server) verhindern soll für den Fall, dass das Local-Storage das Erwünschte enthält.

Weil dein Skript in dem Moment, in dem es das gewünschte gespeichert hat, ein entsprechendes Cookie gesetzt hat, das der Server zur Zeit des Requets dann mitbekommt.

Und wie erkenne ich, dass das Gespeicherte wirklich das Erwünschte ist?

Zum Beispiel, indem du eine Checksumme (bspw. einen md5-Hash) deines gespeicherten Stylesheets als Wert des Cookie setzt - der Server kann das dann gegen seine Ressource prüfen und falls die Checksummen sich unterscheiden neu ausliefern.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Fallback ist hier der Standardfall - wenn der User das nicht im Local Storage hat ist das Cookie nicht gesetzt, also liefert der Server das Stylesheet im HTML mit aus.

Nö. Fallback sollte sein: Server liefert das HTML-Dokument mit <link rel="stylesheet" href="http://example.net/mystylesheet.css"/> aus.

Nein, das Cookie zeigt dem Webserver schon beim Request an, ob die Ressource im Local Storage vorhanden ist, weil sich der Local Storage selbst ja durch den Webserver nicht abfragen lässt.

Die Verbindung Cookie – localStorage wollte ich nicht herstellen, sondern entweder das eine oder das andere verwenden.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Nö. Fallback sollte sein: Server liefert das HTML-Dokument mit <link rel="stylesheet" href="http://example.net/mystylesheet.css"/> aus.

Oder so - okay.

Nein, das Cookie zeigt dem Webserver schon beim Request an, ob die Ressource im Local Storage vorhanden ist, weil sich der Local Storage selbst ja durch den Webserver nicht abfragen lässt.

Die Verbindung Cookie – localStorage wollte ich nicht herstellen, sondern entweder das eine oder das andere verwenden.

Hm? Aber du schriebst doch eben noch, dass du da ein Cookie-Flag setzen willst und das ist bei der Verwendung des local Storage ja auch sinnvoll - von nichts anderem sprach ich.

Nur dass ich da die Notwendigkeit sehe, eben nicht nur ein Flag zu setzen, sondern tatsächlich eine Checksumme (oder wegen mir auch eine Idee/Versionsnummer/was-auch-immer, nur ist die Checksumme eben vergleichsweise einfach zu machen) zu verwenden. Nur mit Flag läufst du in Probleme wenn du etwas änderst. Und das ist auch das, worauf TS (zurecht) mit seiner letzten Frage raus wollte, denke ich.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Die Verbindung Cookie – localStorage wollte ich nicht herstellen, sondern entweder das eine oder das andere verwenden.

Hm? Aber du schriebst doch eben noch, dass du da ein Cookie-Flag setzen willst

Nö, das schrieb ich nicht. Ich hab zwei Lösungen vorgestellt: eine mit localStorage (die nichts mit Cookies zu tun hat), eine mit Cookie (die nichts mit localStorage zu tun hat).

Ich hätte die <hr> wohl dicker machen und mit Abstand versehen sollen‽ (Ach nee, das hat der @Christian Kruse ja gesperrt‽ Oh, da hab ich auch noch einen Knoten im Taschentuch.)

Bei der Variante mit localStorage ist das einmalige Holen des Stylesheets per AJAX ein zusätzlicher HTTP-Request.

Bei der Variante mit Cookie ist das einmalige Holen des Stylesheets per AJAX ein zusätzlicher HTTP-Request (aber erst nach dem Rendern der Seite; damit das Stylesheet dann im Browserchache ist).

und das ist bei der Verwendung des local Storage ja auch sinnvoll - von nichts anderem sprach ich.

Sicher kann man auch beides kombinieren: Beim erstmaligen Aufruf schreibt der Server das Stylesheet ins HTML, ein clientseitiges Script nimmt sich den Inhalt dieses style-Elements und packt ihn in den localStorage.

Nur dass ich da die Notwendigkeit sehe, eben nicht nur ein Flag zu setzen, sondern tatsächlich eine Checksumme (oder wegen mir auch eine Idee/Versionsnummer/was-auch-immer, nur ist die Checksumme eben vergleichsweise einfach zu machen) zu verwenden. Nur mit Flag läufst du in Probleme wenn du etwas änderst.

Da magst du recht haben.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Sicher kann man auch beides kombinieren: Beim erstmaligen Aufruf schreibt der Server das Stylesheet ins HTML, ein clientseitiges Script nimmt sich den Inhalt dieses style-Elements und packt ihn in den localStorage.

Das sollte dann in etwa so aussehen (ohne die Versionskontrolle, die man sicherlich noch mit einbauen möchte):

<?php if (isset($_COOKIE['myStylesheet'])): ?>
  <script>
  if (localStorage && localStorage.getItem('myStylesheet'))
  {
    var styleElement = document.createElement('style');
    styleElement.innerText = localStorage.getItem('myStylesheet');
    document.head.appendChild(styleElement);
  }
  else
  {
    var linkElement = document.createElement('link');
    linkElement.rel = 'stylesheet';
    linkElement.href = 'http://example.net/mystylesheet.css';
    document.head.appendChild(linkElement);
  }
  </script>
<?php else: ?>
  <style id="myStylesheet">
    <?php readfile('mystylesheet.css'); ?>
  </style>
  <script>
  if (localStorage)
  {
    localStorage.setItem('myStylesheet', document.querySelector('#myStylesheet').innerText);
    document.cookie = 'myStylesheet=true';
  }
  </script>
<?php endif; ?>

Das ist noch nicht das Ende der Fahnenstange. Für Browser, die kein localStorage unterstützen, wird jedes Mal das Stylesheet ins HTML geschrieben. Um das zu verhindern, braucht man wohl zwei Cookies.

LLAP 🖖

[Mitleser]

Bei der Variante mit localStorage ist das einmalige Holen des Stylesheets per AJAX ein zusätzlicher HTTP-Request.

Ich versuche mir gerade vorzustellen, wie eine Seite dann bei einem Erstbesuch zunächst wie aus dem Jahr 1994 aussieht und dann einmal heftig rumzappelt, um danach in strahlendem Glanz zu erscheinen. Interessante Vorstellung.

[Camping_RIDER]

Aloha ;)

Bei der Variante mit localStorage ist das einmalige Holen des Stylesheets per AJAX ein zusätzlicher HTTP-Request.

Ich versuche mir gerade vorzustellen, wie eine Seite dann bei einem Erstbesuch zunächst wie aus dem Jahr 1994 aussieht und dann einmal heftig rumzappelt, um danach in strahlendem Glanz zu erscheinen. Interessante Vorstellung.

Das hast du in den falschen Hals gekriegt - das per AJAX geladene CSS wird nur zum Speichern verwendet.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Ich verstehe inzwischen inwiefern ich dich falsch verstanden habe. Allerdings fehlt mir für die LocalStorage-Methode immer noch der Mechanismus, wie der selbstgebastelte Cache „invalidiert“ werden kann.

Ein Cookie mit einer Checksumme zu setzen, das dann im Konfliktfall den Server dazu bringt, eine Art Trigger zum Neuladen des Stylesheets zu setzen würde ich nicht für falsch halten. Ich dachte, du hättest sowas vorgehabt - daher das Misverständnis.

Ich halte das aber immer noch für eine gute Idee, auch wenn es aus einem Misverständnis heraus entstanden ist. Im Endeffekt muss ja der Server entscheiden, ob der Client-Cache überschrieben werden muss, und ein Cookie mit Checksumme ist mMn da eine sehr sinnvolle Möglichkeit, dem Server einen Anhaltspunkt zu geben, ob hier ein LocalStorage-Cache überschrieben werden muss.

Grüße,

RIDER

[Gunnar Bittersmann]

@@TS

Hat Rolf b dich inzwischen gläubig gemacht?

Er hat mir eine Interpretation deiner einen Aussage (Local Storage) gegeben, die man nachverfolgen kann. Aber so ganz sicher, wie Du as wohl gemeint haben könntest, erschien er mir auch nicht.

Wie das in der Praxis dann aussieht, ist mir trotzdem noch schleierhaft. Wenn ich z. B. ein generelles Stylesheet (das für alle Dokumente der Site gelten soll) im Local Storage halten will, wie würde das aussehen müssen, damit man auch einen Fallback hat?

So in der Art (ungetestet):

<script>
var myStylesheetURL = 'http://example.net/mystylesheet.css';

if (localStorage) // wenn localStorage vom Browser unterstützt wird
{
  if (localStorage.getItem('myStylesheet') // wenn myStylesheet schon im localStorage ist
  {
    // schreibe myStylesheet aus dem localStorage in ein style-Element
    createStyleElement(localStorage.getItem('myStylesheet'));
  }

  else // wenn myStylesheet noch nicht im localStorage ist
  {
    // hole http://example.net/mystylesheet.css per AJAX
    var httpRequest = new XMLHttpRequest();
    httpRequest.open('GET', myStylesheetURL);

    httpRequest.onreadystatechange = function ()
    {
      if (httpRequest.readyState === XMLHttpRequest.DONE)
      {
        if (httpRequest.status === 200)
        {
          // schreibe myStylesheet in localStorage
          localStorage.setItem('myStylesheet', httpRequest.responseText);

          // schreibe myStylesheet in ein style-Element
          createStyleElement(httpRequest.responseText);
        }
        else
        {
          createLinkElement();
        }
      }
    };

    httpRequest.send();
  }
}

else // wenn localStorage vom Browser nicht unterstützt wird
{
  createLinkElement();
}

function createStyleElement(stylesheet)
{
  var styleElement = document.createElement('style');
  styleElement.innerText = stylesheet;
  document.head.appendChild(styleElement);
}

function createLinkElement()
{
  var linkElement = document.createElement('link');
  linkElement.rel = 'stylesheet';
  linkElement.href = myStylesheetURL;
  document.head.appendChild(linkElement);
}
</script>
<noscript>
  <link rel="stylesheet" href="http://example.net/mystylesheet.css"/>
</noscript>

---

Und was ein Cookie hier zu suchen hat, hast Du leider auch nicht näher ausgeführt.

Nicht „hier“, sondern das ist eine gänzlich andere Art der Implementierung.

Soll da ggf. auch ein Stylesheet reinpassen?

Nein. Der (das?) Cookie muss nur ein Flag sein, das clientseitig gesetzt wird und serverseitig ausgewertet wird (ebenfalls ungetestet):

<?php if (isset($_COOKIE['myStylesheet'])): ?>
  <link rel="stylesheet" href="http://example.net/mystylesheet.css"/>
<?php else: ?>
  <style>
    <?php readfile('mystylesheet.css'); ?>
  </style>
  <script>
    window.onload = function ()
    {
    // hole http://example.net/mystylesheet.css per AJAX
    var httpRequest = new XMLHttpRequest();
    httpRequest.open('GET', 'http://example.net/mystylesheet.css');

    httpRequest.onreadystatechange = function ()
    {
      if (httpRequest.readyState === XMLHttpRequest.DONE)
      {
        if (httpRequest.status === 200)
        {
          // setze Cookie
          document.cookie = 'myStylesheet=true';
        }
      }
    };

    httpRequest.send();
  }
  </script>
<?php endif; ?>

LLAP 🖖

[TS]

Hello,

Danke. Nun kann ich deine Gedanken wenigstens nachvollziehen ;-)

Gleich die nächsten Fragen zum Thema "Local Storage":

• Wer darf da wann reinschreiben und lesen?
• Wie werden concurrent actions gehandhabt?
• Gibt es sowas, wie Locking oder Semaphore?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Gleich die nächsten Fragen zum Thema "Local Storage":

• Wer darf da wann reinschreiben und lesen?

Die Scripts, die im Browser laufen, dürfen das jederzeit.

• Wie werden concurrent actions gehandhabt?

Wie stellst du dir Concurrent Actions beim Local/Session Storage vor?

• Gibt es sowas, wie Locking oder Semaphore?

Nein, nicht in der Storage API.

dedlfix.

[TS]

Hello,

Gleich die nächsten Fragen zum Thema "Local Storage":

• Wer darf da wann reinschreiben und lesen?

Die Scripts, die im Browser laufen, dürfen das jederzeit.

Der Storage wird pro Domain gehalten, oder?

• Wie werden concurrent actions gehandhabt?

Wie stellst du dir Concurrent Actions beim Local/Session Storage vor?

Mehrere Seiten einer Domain sind gleichzeitig offen, Mehrere XHRs laufen parallel. Das hatten wir ja noch nicht abschließend geklärt, welche Browser wieviele gleichzeitige XHRs auf eine Domain gestatten. Das können schon mal acht werden.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Der Storage wird pro Domain gehalten, oder?

Ja.

Mehrere Seiten einer Domain sind gleichzeitig offen, Mehrere XHRs laufen parallel.

Die XHRs innherhalb eines Tab sind nicht das Problem, Javascript im Browser ist erstmal single-threaded, wenn du nicht explizit mit Web Worker hantierst. Aber da solltest du vielleicht lieber das Speichern nur in einem der beiden (Web Worker vs. Forground Thread) ausführen und die Daten per Messages zum jeweils anderen schicken.

Ob Tabs separat laufen oder sich einen Thread oder Prozess oder was auch immer teilen, ist laut Internet browserspezifisch.

Innerhalb eines Tabs sorgt die Event Loop dafür, dass alles der Reihe nach ausgeführt wird und nicht ein anderes Event in deinen Eventhandler reingrätscht. Dabei gibt es das Problem des gleichzeitigen Zugriffs nicht, solange du deine Operationen nicht auf mehrere Eventhandler aufteilst.

Bleibt die Frage übrig, was mit in mehreren Tabs ausgeführten Websites ist. Das musst du dann mit deinem Anwedungsfall abstimmen, ob das ein Problem werden kann. Das ist ja dann nicht nur eine Frage des Zugriffs auf die Storage API. Du hast ja dann auch andere Daten im RAM (oder wo auch immer), die sich nicht abgleichen, wenn die Datenhaltung geändert wird.

Wenn es verschiede Dinge sind, die mit derselben Anwendung verwaltet werden sollen, dann könnte man da mit Catch-All-Subdomains den Anwendern beliebig viele "Namespaces" zur Verfügung stellen. Zum Beispiel, wenn es da ein Spiel gibt, das mehrere Spielstände anlegen kann, oder das man in mehreren Welten spielen kann, und man stellt eine Website zur Verfügung, mit der man zu diesem Spiel ein paar Daten verwalten kann, dann kann und sollte man je Spielstand oder Welt separiert vorgehen.

Eine andere Vorgehensweise wäre ein individueller Prefix für die Local-Storage-Daten. Das Internet weiß auch noch, dass der Session Storage je Tab separat ist. Die Frage ist nur, wie man einen individuellen Key bekommt, der sich nicht mitkopiert, wenn man Tabs dupliziert.

dedlfix.

[TS]

Hello,

Das Beispiel hat ein Problem mit dem Target.

Stimmt das wirklich? "window.sessionStorage: - speichert Daten für eine Session (Daten werden gelöscht, wenn der Tab geschlossen wird) "

Wird der nicht erst gelöscht, wenn der Browser geschlossen wird, in dem er angelegt wurde?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Stimmt das wirklich? "window.sessionStorage: - speichert Daten für eine Session (Daten werden gelöscht, wenn der Tab geschlossen wird) "

Probier es. Man braucht da ja kein umständliches Script, sondern besucht eine beliebige Seite (vielleicht eine eigene bereits vorhandene, die nicht mit der Storage-API hantiert) und tippt über die Konsole die Funktionsaufrufe ein.

Wird der nicht erst gelöscht, wenn der Browser geschlossen wird, in dem er angelegt wurde?

Im Firefox bleibt der Wert im Session Storage sogar erhalten, wenn nur der Browser geschlossen wird. Ansonsten hatte ich es in Firefox und Chrome, dass beim Schließen des Tabs die Einträge weg waren.

dedlfix.

[Camping_RIDER]

Aloha ;)

So in der Art (ungetestet):

<script>
var myStylesheetURL = 'http://example.net/mystylesheet.css';

if (localStorage) // wenn localStorage vom Browser unterstützt wird
{
  if (localStorage.getItem('myStylesheet') // wenn myStylesheet schon im localStorage ist
  {
    // schreibe myStylesheet aus dem localStorage in ein style-Element
    createStyleElement(localStorage.getItem('myStylesheet'));
  }

  else // wenn myStylesheet noch nicht im localStorage ist
  {
    // hole http://example.net/mystylesheet.css per AJAX
    var httpRequest = new XMLHttpRequest();
    httpRequest.open('GET', myStylesheetURL);

    httpRequest.onreadystatechange = function ()
    {
      if (httpRequest.readyState === XMLHttpRequest.DONE)
      {
        if (httpRequest.status === 200)
        {
          // schreibe myStylesheet in localStorage
          localStorage.setItem('myStylesheet', httpRequest.responseText);

          // schreibe myStylesheet in ein style-Element
          createStyleElement(httpRequest.responseText);
        }
        else
        {
          createLinkElement();
        }
      }
    };

    httpRequest.send();
  }
}

else // wenn localStorage vom Browser nicht unterstützt wird
{
  createLinkElement();
}

function createStyleElement(stylesheet)
{
  var styleElement = document.createElement('style');
  styleElement.innerText = stylesheet;
  document.head.appendChild(styleElement);
}

function createLinkElement()
{
  var linkElement = document.createElement('link');
  linkElement.rel = 'stylesheet';
  linkElement.href = myStylesheetURL;
  document.head.appendChild(linkElement);
}
</script>
<noscript>
  <link rel="stylesheet" href="http://example.net/mystylesheet.css"/>
</noscript>

Und in dem Moment in dem sich das Stylesheet serverseitig ändert schaut ein User mit LocalStorage in die Röhre - oder braucht doch wieder ständig aufs neue HTTP-Requests?

<?php if (isset($_COOKIE['myStylesheet'])): ?>
  <link rel="stylesheet" href="http://example.net/mystylesheet.css"/>
<?php else: ?>
  <style>
    <?php readfile('mystylesheet.css'); ?>
  </style>
  <script>
    window.onload = function ()
    {
    // hole http://example.net/mystylesheet.css per AJAX
    var httpRequest = new XMLHttpRequest();
    httpRequest.open('GET', 'http://example.net/mystylesheet.css');

    httpRequest.onreadystatechange = function ()
    {
      if (httpRequest.readyState === XMLHttpRequest.DONE)
      {
        if (httpRequest.status === 200)
        {
          // setze Cookie
          document.cookie = 'myStylesheet=true';
        }
      }
    };

    httpRequest.send();
  }
  </script>
<?php endif; ?>

Gut, die Lösung verstehe ich (und halte ich für sinnvoll), da hier normales Caching-Verhalten ausgenutzt wird.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Gut, die Lösung verstehe ich (und halte ich für sinnvoll), da hier normales Caching-Verhalten ausgenutzt wird.

Okay, nein. Tatsächlich verstehe ich sie doch nicht. Denn sie bietet in meinen Augen keinerlei Vorteil gegenüber einem einfachen

<link rel="stylesheet" href="http://example.net/mystylesheet.css"/>

bis auf das, dass beim ersten Aufruf die Angaben eben schon inline verfügbar sind. Was man sich mit dem fast doppelten Traffic erkauft (weil das Datenvolumen ja jetzt nochmal inline steht und AJAX ja auch nochmal losläuft und einen normalen Requet ausführt). Aber ab dem zweiten Aufruf ist das exakt gleich (es werden trotzdem jedes Mal 304er-Requests fällig).

Für den erstmaligen Aufruf wärs mir das nicht wert, wenn man nicht ansonsten auch noch HTTP-Requests einspart (was man nicht tut).

Ich glaube ich bleibe dabei, dass die LocalStorage-Variante in Verbindung mit einem Checksum-Cookie für mich die einzige wirklich sinnvolle Lösung darstellt.

Ist denn eigentlich sichergestellt, dass ein Cookie, egal in welcher Variante man es denn dann einsetzt, nicht „lügt“? Also: kann ich davon ausgehen, dass es unwahrscheinlich bis unmöglich ist, dass mein Cache oder mein LocalStorage geleert werden bevor das Cookie abläuft? Wenn das nicht der Fall ist, stellt das für mich den Sinn der gesamten Operation in Frage.

Grüße,

RIDER

[TS]

Hello,

Okay, nein. Tatsächlich verstehe ich sie doch nicht. Denn sie bietet in meinen Augen keinerlei Vorteil gegenüber einem einfachen

<link rel="stylesheet" href="http://example.net/mystylesheet.css"/>

Den Vorteil habe ich auch nicht wirklich sehen können.

Aber ab dem zweiten Aufruf ist das exakt gleich (es werden trotzdem jedes Mal 304er-Requests fällig).

Es sind zwar Responses, aber genau danach habe ich eben sicherheitshalber auch nochmal geguckt. Bei normal üblicher Cache-Strategie und Server-Einrichtung fragt der Browser kurz an, ob es eine neue Version gibt und bekommt meistens den 304-Status geliefert.

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@Camping_RIDER

Aber ab dem zweiten Aufruf ist das exakt gleich (es werden trotzdem jedes Mal 304er-Requests fällig).

Wieso? Der AJAX-Request steht doch im else-Zweig (wenn myStylesheet noch nicht im localStorage ist).

Für den erstmaligen Aufruf wärs mir das nicht wert, wenn man nicht ansonsten auch noch HTTP-Requests einspart (was man nicht tut).

Der Unterschied ist, dass der HTTP-Request asynchron nach dem Rendern der Seite erfolgt. Die Seite wird also initial schneller geladen.

Ich glaube ich bleibe dabei, dass die LocalStorage-Variante in Verbindung mit einem Checksum-Cookie für mich die einzige wirklich sinnvolle Lösung darstellt.

Das beste aus beiden Welten.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Aber ab dem zweiten Aufruf ist das exakt gleich (es werden trotzdem jedes Mal 304er-Requests fällig).

Wieso? Der AJAX-Request steht doch im else-Zweig (wenn myStylesheet noch nicht im localStorage ist).

Wenn du das im if-Zweig als link-Element hast gibt es trotzdem immer zuerst HTTP-Anfragen (dann eben mit if-modified-since) bevor das Dokument wegen 304: Not Modified aus dem Cache geladen wird. Was auch passiert, wenn du es initial nicht über AJAX, sondern über link eingebunden hast. Was die Einbindung über AJAX für alle Aufrufe außer dem allerersten quasi sinnlos macht, weil ab dem zweiten Aufruf kein Unterschied besteht.

Für den erstmaligen Aufruf wärs mir das nicht wert, wenn man nicht ansonsten auch noch HTTP-Requests einspart (was man nicht tut).

Der Unterschied ist, dass der HTTP-Request asynchron nach dem Rendern der Seite erfolgt. Die Seite wird also initial schneller geladen.

Das verstehe ich nicht - zumindest nicht wo der Unterschied dazu sein soll, wenn man gleich link verwendet.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Der Unterschied ist, dass der HTTP-Request asynchron nach dem Rendern der Seite erfolgt. Die Seite wird also initial schneller geladen.

Das verstehe ich nicht - zumindest nicht wo der Unterschied dazu sein soll, wenn man gleich link verwendet.

link blockt das Rendern der Seite, bis das Stylesheet geladen wurde – sei es vom Server oder aus dem Cache.

Wenn ein ins HTML eingebundenes(!) JavaScript feststellt, dass das Stylesheet aus dem localStorage geholt werden kann, wird das Rendern der Seite nicht geblockt.

LLAP 🖖

[TS]

Hello,

link blockt das Rendern der Seite, bis das Stylesheet geladen wurde – sei es vom Server oder aus dem Cache.

Wenn ein ins HTML eingebundenes(!) JavaScript feststellt, dass das Stylesheet aus dem localStorage geholt werden kann, wird das Rendern der Seite nicht geblockt.

Das ist mir noch zu ungenau. Wann wird das JavaScript geladen, wann ausgeführt? Wann ist das DOM fertig aufgebaut? Wann sind secondary Requests abgeschlossen?

Was verstehst Du unter "Rendern"? Es gibt mMn nicht ein einziges Rendern, sondern bei Bedarf dutzende, bis die Seite fertig anzusehen ist.

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Wenn ein ins HTML eingebundenes(!) JavaScript feststellt, dass das Stylesheet aus dem localStorage geholt werden kann, wird das Rendern der Seite nicht geblockt.

Jaja, schon - nur gings ja hier um die reine Cookie-Lösung und die hat das ja nicht 😂

Aber wegen mir können wir das Thema auch einfach jetzt beerdigen, es wurde sowieso glaub schon alles gesagt.

Grüße,

RIDER

[TS]

Hello,

Das Thema "Local Storage" ist allerdings noch nicht beendet, andere Teilthemen vielleicht :-)

Was für Mechanismen für den konkurriedrenden Betrieb bietet der local Storage?

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Was für Mechanismen für den konkurriedrenden Betrieb bietet der local Storage?

Von sich aus keine, afaik. Wenn du kritische Bereiche hast kannst du dir aber sehr leicht eigene Semaphoren basteln, dank window.setTimeout auch fast ohne aktives Warten. Die Frage ist, ob das nicht unter YAGNI fällt. Wie soll es denn überhaupt zu Problemen kommen? Doch höchstens mit mehreren Browsertabs die gleichzeitig geöffnet sind. Diese Problematiken kann man auch anders umgehen (durch entsprechendes Code-Design zum Beispiel).

Grüße,

RIDER

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Wenn das Überblenden wirklich so wichtig ist, würde ich einfach die jeweils eine Zeile JS und CSS direkt in das Dokument schreiben.

<script>
  document.addEventListener("DOMContentLoaded", function(ev) {
    document.documentElement.classList.add('fade');
  });
</script>

<style>
  html
  {
    transition: opacity 1s ease;
  }

  .fade
  {
    opacity: 0;
  }
</style>

<script>document.addEventListener("DOMContentLoaded",function(ev){document.documentElement.classList.add('fade');});</script>

<style>html{transition:opacity 1s ease}.fade{opacity:0}</style>

Bis demnächst
Matthias

[Mitleser]

Wenn man richtig heftig Cachen kann / will / muss, dann gibt es den ersten Aufruf an das Backend womöglich nur ein einziges Mal, danach antwortet der Cache.

Es geht darum, beim ersten Seitenaufruf keine separaten HTTP-Requests für JS/CSS zu brauchen.

Was nicht geht, wenn auf Serverseite ein aggressiver Cache vorgeschaltet ist.

[Gunnar Bittersmann]

@@Mitleser

Es geht darum, beim ersten Seitenaufruf keine separaten HTTP-Requests für JS/CSS zu brauchen.

Was nicht geht, wenn auf Serverseite ein aggressiver Cache vorgeschaltet ist.

?? Was hätte ein serverseitiger aggressiver Cache mit dem Inhalt von script- und style-Elementen im HTML zu tun?

LLAP 🖖

[Mitleser]

?? Was hätte ein serverseitiger aggressiver Cache mit dem Inhalt von script- und style-Elementen im HTML zu tun?

Du schlägst vor, serverseitig folgendes zu tun: "if (!$cookieHabeSchonCssJsUndSo) then echo $cssJsUndSo". Aggressives Caching lässt diese Fallunterscheidung aber nicht zu, weil man keinen Interpreter mehr zur Hand hat, da der Cache die Antwort für den Client generiert. Look ma, no PHP oder so.

[TS]

Hello,

Look ma, no PHP oder so.

Achtung!

Ich habe manchmal den Eindruck, dass Gunnar Tischtennisspieler ist. Viele seiner Bälle hier sind verdammt angeschnitten ;-P

Liebe Grüße
Tom S.

[Rolf b]

Whut?

Ich kann ein im HTML integriertes CSS clientseitig (also per Script??) in den Browsercache packen?

Ich kann ein Stylesheet aus dem Localstorage auf meiner HTML Seite referenzieren?

Rolf

[Gunnar Bittersmann]

@@Rolf b

Ich kann ein im HTML integriertes CSS clientseitig (also per Script??) in den Browsercache packen?

Gute Frage. Vermutlich nicht, oder?

Man könnte das Stylesheet nach dem Rendern der Seite nochmal anfordern, dann ist es im Cache. Dabei werden die schon vohandenen Daten ein zweites Mal übertragen – aber der Nutzer dürfte davon nichts mitbekommen. Es sei denn, er bezahlt pro übertragenem Byte.

Ich kann ein Stylesheet aus dem Localstorage auf meiner HTML Seite referenzieren?

Du kannst es aus dem localStorage holen und in ein style-Element packen, ja.

LLAP 🖖

[TS]

Hello,

Ich kann ein Stylesheet aus dem Localstorage auf meiner HTML Seite referenzieren?

Du kannst es aus dem localStorage holen und in ein style-Element packen, ja.

Als (JSON-)Objekt, oder wie mache ich das am besten?

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

Du kannst es aus dem localStorage holen und in ein style-Element packen, ja.

Als (JSON-)Objekt, oder wie mache ich das am besten?

Als String.

LLAP 🖖

[TS]

Hello,

Du kannst es aus dem localStorage holen und in ein style-Element packen, ja.

Als (JSON-)Objekt, oder wie mache ich das am besten?

Als String.

Zeig mal bitte. Kann ich mir jetzt nicht vorstellen, wie das gehen soll. Gibt's da sowas wie "include"?

Liebe Grüße
Tom S.

[Rolf b]

Nein, so wie ich Gunnar verstehe, erzeugst Du ein style-Element, gibst ihm Content aus dem localStorage und hängst es an das head-Element an.

So ähnlich wie hier

Rolf