Es allen Recht machen: Cookies, W3C, WAI, CSS, JS

ZodiacXP

Erfahrenes Mitglied
Das sind ja gleich 5 Dinge auf einmal.
Rein theoretisch bedeutet das 31 verschiedene Designs.

Aber wie macht man es denn nun allen recht?
Kann ja nicht sein das man eine Style-Weiche vorschaltet und dann zu einem von den 31 Designs weiterleitet.

Problem der Cookies
Manche haben sie ausgeschaltet - und dann? Dann überträgt man die SessionID und den Namen einfach über die Adresse / über die Links (z.B. $_GET in PHP). Aber wie erhält man Sonderfälle, wie zB das jemand dauerhaft Eingeloggt ist für 24h oder "die Seite" sich den Login-Namen "merkt". Kurz: Wie immitiert man Cookies?

Problem des W3C UND WAI
Naja, W3C ist kein Problem. Das ist eine Richtlinie. Aber sobald hier WAI ins Spiel kommt steht man vor einer Mauer. XHTML hat xml:lang im <body> drin stehen, während WAI verzweifelt nach dem Attribut "lang" sucht. Fügt man "lang" ein meckert wieder W3C wegen XHTML rum. Und das ist nur ein Beispiel von mehreren.
Wichtiger ist aber das Problem des Traffics und der Ladezeit einer Seite. WAI möchte so viele sachen extra aufgeführt haben. Zum Beispiel bei Bildern ein d-link, ein Attribut "longdesc" im <img>-Tag und so weiter. Was macht man wenn man WAI AAA (Stufe 3) erfüllen will? Man überläd sein Design doch völlig!

Problem von CSS
Lustig wird es vor allem wenn WAI Stylesheets fordert:
  • Zum einen interessieren Textbrowser oder sowas wie Screenreader kein CSS
  • zweitens fordert WAI AAA wieder nach Verwendung von CSS: man solle aufpassen das es auch ohne geht
  • und am Ende möchte man selbst das die Seite auch ohne CSS ein bisschen vom Design behält
...wobei einem wieder W3C im Wege steht, da es hier nicht erlaubt ist "bgcolor" in <body> zu verwenden oder "height" in <td>. Wie also ohne CSS?

Problem von JS
Die Seite lädt, über eine meta-Angabe (die auch nicht jeder Browser kennt) wird man nach 2 Sekunden weitergeleitet, oder auch sofort zu einer anderen Seite / einem anderen Design wenn JavaScript aktiviert ist. Super - jetzt haben wir herausgefunden ob JavaScript aktiviert ist. JS ist aber das kleinste Problem, obwohl einem dadurch so tolle Funktionen wie AJAX (was auch nicht jeder macht) verloren gehen, was ganz gut wäre weil unsere Seite durch WAI leicht überladen ist.

Hoffentlich sind die Probleme mit denen ich mich seit ca. 4 Tagen rumschlage klar geworden. Will man wirklich alle beachten bräuchte man 31 verschiedene Versionen von einem Design (nachrechenbar über Variaion mit Zurücklegen: 2^5 - 1 = 31).

Und jetzt Frage ich die erfahrene Community:

Wie macht man es allen recht?
 
Problem der Cookies
Manche haben sie ausgeschaltet - und dann? Dann überträgt man die SessionID und den Namen einfach über die Adresse / über die Links (z.B. $_GET in PHP). Aber wie erhält man Sonderfälle, wie zB das jemand dauerhaft Eingeloggt ist für 24h oder "die Seite" sich den Login-Namen "merkt". Kurz: Wie immitiert man Cookies?

Gar nicht. Wer Cookies deaktiviert hat, hat sicher seine Gründe (ob diese sinnvoll sind oder nicht steht auf einem anderen Blatt) und wird sowieso davon ausgehen, dass Funktionen, die über Cookies realisiert werden bei ihm nicht zur Verfügung stehen werden. Also wieso sollte man diese Funktion immitieren?

Problem des W3C UND WAI
Naja, W3C ist kein Problem. Das ist eine Richtlinie. Aber sobald hier WAI ins Spiel kommt steht man vor einer Mauer. XHTML hat xml:lang im <body> drin stehen, während WAI verzweifelt nach dem Attribut "lang" sucht. Fügt man "lang" ein meckert wieder W3C wegen XHTML rum. Und das ist nur ein Beispiel von mehreren.

Wie überprüfst du die WAI Kompaktibilität? Ist diese Art der Überprüfung überhaupt XHTML kompaktibel?

Wichtiger ist aber das Problem des Traffics und der Ladezeit einer Seite. WAI möchte so viele sachen extra aufgeführt haben. Zum Beispiel bei Bildern ein d-link, ein Attribut "longdesc" im <img>-Tag und so weiter. Was macht man wenn man WAI AAA (Stufe 3) erfüllen will? Man überläd sein Design doch völlig!

Was heisst hier überladen? Nur weil du die Informationen nicht siehst heisst es nicht, dass diese beispielsweise für einen Blinden und seinen Screenreader nicht interessant und wichtig sind.

Problem von CSS
Lustig wird es vor allem wenn WAI Stylesheets fordert:
  • Zum einen interessieren Textbrowser oder sowas wie Screenreader kein CSS
  • zweitens fordert WAI AAA wieder nach Verwendung von CSS: man solle aufpassen das es auch ohne geht
  • und am Ende möchte man selbst das die Seite auch ohne CSS ein bisschen vom Design behält
...wobei einem wieder W3C im Wege steht, da es hier nicht erlaubt ist "bgcolor" in <body> zu verwenden oder "height" in <td>. Wie also ohne CSS?

Das klingt so als würdest du die Seite mit Gewalt versuchen in allen Versionen einheitlich darzustellen. Dieses Vorhaben kannst du eigentlich direkt vergessen. Wichtig ist nur ob die Seite benutzbar ist. Schalte das CSS und Javascript ab und überprüfe ob die Seite voll benutzbar ist und selbst wenn am Ende nur ein weisses Dokument mit schwarzer Browserstandardschrift übrigbleibt. Hauptsache man kann

  • über die Seite navigieren.
  • die Inhalte sind logisch strukturiert. (Beispielsweise war es für manche Designs nötig die Navigation an das Ende des Dokuments zu stellen und dann per CSS zu positionieren. Das ist der grundlegend falsche Ansatz. Wo würdest du denn die Navigation suchen? Am Anfang oder am Ende der Seite?)

Problem von JS
Die Seite lädt, über eine meta-Angabe (die auch nicht jeder Browser kennt) wird man nach 2 Sekunden weitergeleitet, oder auch sofort zu einer anderen Seite / einem anderen Design wenn JavaScript aktiviert ist. Super - jetzt haben wir herausgefunden ob JavaScript aktiviert ist. JS ist aber das kleinste Problem, obwohl einem dadurch so tolle Funktionen wie AJAX (was auch nicht jeder macht) verloren gehen, was ganz gut wäre weil unsere Seite durch WAI leicht überladen ist.

Für diesen Fall gibt es doch den noscript html tag.

Und jetzt Frage ich die erfahrene Community:

Wie macht man es allen recht?

Das wird nicht funktionieren. Du musst die entsprechenden Prioritäten setzen. Im Zweifelsfall wenn keine Funktionen wie Cookies, CSS oder Javascript bereitgestellt werden ist das halt so. Die Seite muss nur benutzbar bleiben, selbst wenn du nicht alle deine gewünschten Designkniffe umsetzen kannst.
 
Zuletzt bearbeitet:
Also wieso sollte man diese Funktion immitieren?
Damit die, die Cookies nicht erlauben trotzdem alle Funktionen und Vorteile nutzen können.

Wie überprüfst du die WAI Kompaktibilität? Ist diese Art der Überprüfung überhaupt XHTML kompaktibel?
Zum einen über ein Firefox-Plugin ("HTML Validator") und zusätzlich über http://www.sidar.org/hera . Ersteres ist auf jeden Fall XHTML Kompatibel und gibt genau diesen "lang"-Fehler aus.

Was heisst hier überladen? Nur weil du die Informationen nicht siehst heisst es nicht, dass diese beispielsweise für einen Blinden und seinen Screenreader nicht interessant und wichtig sind.

Ja ok, überladen war hier das falsche Wort. Es sind einfach einige KByte mehr pro Besucher. Da würde ich gerne trennen können oder Vorschläge haben.


Das klingt so als würdest du die Seite mit Gewalt versuchen in allen Versionen einheitlich darzustellen.
Nein, einheitlich soll sie nicht sein. Es soll nur wenigstens ein Hauch von Design drin sein. Man kann ja für jeden Sachverhalt ein eigenes Design anlegen, nur jeder weis wie viel arbeit das ist. Aber mit der Idee CSS und JS einfach abzuschalten spiele ich auch.

Für diesen Fall gibt es doch den noscript html tag.
Ich kann aber doch nicht die Seite zwei mal in einem Dokument übertragen. Ok, man kann aber da ist die doppelt so groß.

Idee (beide W3C-Konform):
  • Ein behindertengerechtes Design ohne JS mit CSS
  • Ein Design mit JS und mit CSS

Fehlt mir noch das mit den Cookies...

Danke für die schnelle Antwort
 
Zuletzt bearbeitet:
Problem der Cookies
Manche haben sie ausgeschaltet - und dann? Dann überträgt man die SessionID und den Namen einfach über die Adresse / über die Links (z.B. $_GET in PHP). Aber wie erhält man Sonderfälle, wie zB das jemand dauerhaft Eingeloggt ist für 24h oder "die Seite" sich den Login-Namen "merkt". Kurz: Wie immitiert man Cookies?

Die Session wird doch meistens, wenn der SERVER entsprechend eingestellt ist von eben diesem verwaltet, sodass man SessionID/Namen nicht per Cookie transportieren muss...
Also können Cookie-Daten auch in der $_SESSION bleiben...

Absichern kann man sich da indem man die IP inner DB speichert zusammen mit der SessionID, dann kann man sich auf Serverseite absichern...

Und ebenso kann man dann doch auch die Daten des Cookie/Session komplett über ne entsprechende "temporäre" Tabelle lösen...

Das einzige wofür mir keine Lösung einfällt is den Auto-Login über den IP-Change nach 24Std hinaus aufrecht zu erhalten ohne Cookie...
Aber für den Fall kann man neben die Checkbox "eingeloggt bleiben" noch ein "(nicht ohne Cookies möglich)" setzen...

Ich bitte um Berichtigung!
 
Die Session wird doch meistens, wenn der SERVER entsprechend eingestellt ist von eben diesem verwaltet, sodass man SessionID/Namen nicht per Cookie transportieren muss...
Also können Cookie-Daten auch in der $_SESSION bleiben...
Du scheinst das Konzept einer Sitzung nicht verstanden zu haben. Die Daten werden zwar auf der Serverseite gespeichert, der Client muss sich jedoch mit der Sitzungs-ID identifizieren, damit der Server ihm die Sitzungsdaten wieder zuordnen kann.

Absichern kann man sich da indem man die IP inner DB speichert zusammen mit der SessionID, dann kann man sich auf Serverseite absichern...
Die IP-Adresse ist kein verlässliches Identifikationsmerkmal da sich einerseits mehrere Clients dieselbe IP-Adresse teilen können und andererseits sich die IP-Adresse auch bei jeder Anfrage ändern kann.
 
Du scheinst das Konzept einer Sitzung nicht verstanden zu haben. Die Daten werden zwar auf der Serverseite gespeichert, der Client muss sich jedoch mit der Sitzungs-ID identifizieren, damit der Server ihm die Sitzungsdaten wieder zuordnen kann.
Hab ja auch nie Anspruch darauf erhoben, dass ich 1000%ig richtig liege, oder!? ^^
Ich portiere auf meiner Site zur Zeit die SessionID weder inner URL, noch im Cookie oder sonst wo...
Trotzdem landet jeder User in seiner eigenen Session ohne, dass es da zu fehlern kommt...
Liegt am Server, der vermutlich selber nen Cookie setzt o.ä...
Naja is halt Server für Anfänger (funpic) ;)

Aber Faktum ist, dass es ohne eigenes zutun geht ^^

Die IP-Adresse ist kein verlässliches Identifikationsmerkmal da sich einerseits mehrere Clients dieselbe IP-Adresse teilen können und andererseits sich die IP-Adresse auch bei jeder Anfrage ändern kann.
Sicher nicht, ändert sich in der Regel alle 24Std automatisch...
Drum muss man sich an der Stelle mit nem Cookie auf Clientseite absichern...


Mir schient iwie, als hättest du den einen oder anderen Satz von mir übverlesen, Gumbo ^^
 
Die PHP-eigene Sitzungsverhaltung übernimmt diese Aufgaben bei entsprechender Konfiguration bereits selbstständig, sodass meist nur der Aufruf von session_start() notwendig ist.

Sicher nicht, ändert sich in der Regel alle 24Std automatisch...
Drum muss man sich an der Stelle mit nem Cookie auf Clientseite absichern...
Du solltest nicht von dir auf die Allgemeinheit schließen. Eine Vielzahl mag zwar vielleicht über eine Flatrate verfügen und rund um die Uhr online sein, sodass der Anbieter die Verbindung zwangsweise unterbrechen muss. Doch es gibt auch welche, die Anonymisierungsdienste nutzen, bei denen jede Anfrage über eine ganze Reihe von Server geleitet wird, bevor sie ihr Ziel erreichten.
 
Die Anonymisierungsdienste hab ich ausser acht gelassen, stimmt...
Is aber das selbe wie bei der Zwangstrennung...
Die IP ändert sich/variiert... Bei dem einen öfter als bei den anderen...

Und diese Rechner kann man dann nurnoch mit nem Cookie identifizieren, oder gibt es da noch andere alternativen?
 
Hallo.

Sorry, aber hatte diesen Thread fast vergessen.

Nicht nur per Cookie holt sich die Session ihre ID sondern es geht auch über die Adresse ($_GET).

Dann steht zum Beispiel dort: "http://....../index.php?sessionname=sessionid..." und noch vieles mehr.

Problem dabei ist, das die URI verdammt lang wird. Und es gibt das Sicherheitsproblem:
Ist man zum Beispiel bei seinem Mail-Konto eingeloggt und gibt dann die URI mit dieser session-ID an einen anderen, kann dieser die Mails lesen.

Leider musste ich auf diese Variante nun zurückgreifen. Die Sicherheitslücke wird dadurch abgefangen, dass serverseitig die IP zur jeweiligen Session gespeichert wird. Sollte also ein anderer mit deiner Session-ID ankommen, der nicht hinter deinem Router sitzt, kann er auch nicht deine Mails lesen.
 
Zurück