nicht angemeldet
Hallo, Christian.
Ich sehe dennoch keine Notwendigkeit, Benutzern aus anderen Zeitzonen unbedingt eine an ihre Zeitzone angepasstes Stylesheet zu verpassen.
Wieso nicht, ist doch eine nette Spielerei. *g* Außerdem ist die Seite immer noch in nicht-JS-Browsern funktional.
Naja, schon. Wieso denke ich nur sofort an "Willkommen auf einer Homepage!!!" im Zusammenhang mit solchen JavaScript-Spielereien...
Im Übrigen könnte man so etwas mit einer Vorschaltseite machen, welche bei aktiviertem JavaScript den Zeitzonenparameter ausliest, per GET übergibt. Mit Session könnte der Parameter dann gespeichert werden. Nur eine Idee, Vorteile hat das wahrscheinlich nicht, nur eben dass die Seiten selbst kein JavaScript enthalten müssen.
Im Gegenteil - da hast Du _noch_ mehr HTTP-Requests.
Jein, es ist eine Kosten/Nutzen-Rechnung: Wenn ich auf jeder Seite zwei Stylesheets einbinde, habe ich im schlimmsten Falle pro Page Impression zwei Stylesheet-Requests (welche bei der zweiten PI mit 304 Not Modified beantwortet werden). Mit einer Vorschaltseite könnte man realisieren, dass bei x PIs pro Visit nur im schlimmsten Falle x Stylesheet-Requests eintrudeln, da auf jeder Seite nur ein Stylesheet eingebunden wird (nämlich das tageszeitspezifische).
Und: x+1 != 2x (wenn x>1 ;))
Das Problem ist nur, dass sich die Tageszeit während eines Visits ändern kann. Okay, das mit der Vorschaltseite ist eine schlechte Idee, merke ich gerade :), das System aber könnte man übernehmen:
1. Der Benutzer ruft irgendeine Seite des Angebots auf (Startseite||Unterseite).
2. nacht.css wird über eine bedingte Anweisung per JavaScript eingebunden, falls die Benutzerzeit $Nacht entspricht.
2. An das mit JavaScript eingebundene Stylesheet wird die Session-ID weitergegeben.
3. Der Session wird der Flag "JavaScript aktiviert und Nachtzeit" hinzugefügt.
4. Alle mit Session-ID aufgerufenen Seiten binden nur ein Stylesheet ein.
Ach nein! (Heureka! ;)) Das ist ja auch töricht, denn so oder so müssen tag.css und nacht.css eingeladen werden, deshalb ist es auch den Folgeseiten nicht möglich, nur *ein* Stylesheet zu laden, denn nacht.css sollte bestenfalls ein Zusatz für tag.css sein. Aber wenn man nacht.css vollständig und "standalone" macht, fallen auf den Folgeseiten immerhin die 304-Request auf tag.css weg, nach 3-4 PIs macht diese Trafficeinsparung die Größe von nacht.css wett.
Hm, ich gebe zu, eine simple JavaScript-Abfrage auf jeder Seite wäre einfacher als das obige System. :) Eine serverseitige Abfrage wäre am einfachsten.
(Stylesheets wurden nicht verwendet - die fonts und bgcolors wurden templatebasiert eingebunden).
*würg*
Wieso würg, selbst heute noch setzen diese und viele andere große Seiten auf HTML-Formatierungen mit font usw. Dort kann man sich nicht leisten, NS4 CSS-formatierte Seiten zu liefern - "Interoperabilität" (aka muss auf allen Grafikbrowsern gut aussehen) um jeden Preis. (Bzw. zum würgen ist es zweifellos, aber immer noch gängig, auch wenn die genannte Seite zwei Jahre alt ist.)
Was hast Du denn eigentlich gegen JavaScript? Solange die Seite noch komplett benutzbar bei ausgeschaltetem JavaScript ist, warum nicht? WAI ist sicherlich ein Argument, aber wenn das auch mit berücksichtigt wird (ist hier der Fall), warum nicht JavaScript?
In diesem speziellen Fall finde ich eine serverseitige Überprüfung sinnvoller, sie spart viel Aufwand, Traffic und Ladezeit. (Im Winter bauen die wenigstens Seiten zusätzlich zu einem jahreszeittypischen Design eine JavaScript-Abfrage ein, nur weil auf der südlichen Hemisphäre Sommer ist.)
Abgesehen davon habe ich nur das Übliche gegen JavaScript. :) Es schadet hier natürlich niemanden, da stimmt ich dir zu.
(irgendwie noch nicht ganz wach.)
Um 8:08? Was meinst Du, wann ich aufstehen muss, um in die Schule zu kommen? 5:30!
Tja, ich bin kein Schüler mehr. Dafür Nichtstuer, insofern war das relativ späte Aufstehen auf ein relativ sehr spätes Zubettgehen zurückzuführen.
Mathias