Hi,

Status mittels Hash? Was könnte mir das sagen? Dass sich bei Ajax die URL ja auch nicht ändert, also das wie ein interner Ankersprung verbucht wird?

In Ajax wird für die (im URL ja ansonsten nicht nachvollziehbaren) Änderung ggf. der Hash im URL geändert (s. JavaScript: location.hash). Der Vorteil dieser Variante ist es, daß man den URL eines einzigen Framesets zur Laufzeit so anpassen kann, daß man erkennen kann, welcher Contentframe gerade aktiv ist (für Bookmarking z.B.).

Aber dies nur als Möglichkeit mittels JS das zu machen. Prinzipiell finde ich das nicht gut, denn a) kann JS ausgeschaltet sein und b) bevorzuge ich eben *deutlichst* die "1 Frameset pro Contentframe"-Variante, wo dies ohnehin nicht notwendig ist (es gibt ja eh einen sichtbaren URL pro Contentframe).

Bei der Coding-Website verwende ich das "klassische" "Content-URL als Parameter"-Prinzip (also z.B. index.htm?/dhtml/index.htm). Das hat den Vorteil, daß auch bei deaktiviertem JS der korrekte Contentframe geladen wird (via PHP, das Zugriff auf URL-Parameter hat, nicht aber auf den clientseitigen Hash). Der Nachteil ist halt, daß sich der URL inkl. Parameter während des Surfens durch meine Site nicht ändert (das wäre beim Hash mit JS kein Problem). Hier muß der Surfer das Frameset auflösen, um die richtige Seite zu bookmarken (via "Exit"-Papierkorb oder der auf jeden Seite genannten Kurz-URL zum Bookmarken).

Dies wird von den Framegegnern als Nachteil genannt - und auch von mir(!) als Nachteil gesehen! Wie gesagt: Usablity und SEO standen bei mir *vor* dem Umgang mit Frames auf der Tagesordnung, und dem hat sich jede Technik, auch Frames, unterzuordnen.

Aber bei der Coding-Site ist es a) Absicht und b) hat sie als Zielgruppe User, die selbst Coden (und von daher ein wenig mehr Verständnis aufbringen sollten, als Oma Krawupke von nebenan ;-)). Da fand ich den Nachteil in Abwägung mit der Absicht als nachrangig.

Bei einer normalen "Wald und Wiesen"-Site käme so eine Umsetzung für mich aber niemals nicht (;-)) in Frage ...

Gruß, Cybaer