JavaScript SEO, Barrierefreiheit und JavaScript/AJAX/JSON unter einen Hut zu bekommen?

[ice-breaker]

Klingt brauchbar oder nicht?

ehrlich? nein.
Wenn sowieso ein Rendering für Non-JS-Seiten existiert würde ich mir niemals die Arbeit machen das Rendering nochmal clientseitig mit JavaScript-Templates zu implementieren, es ist im Endeffekt nur doppelte Arbeit und irgendwann vergiss man mal, in JS oder der serverseitigen Sprache das Template anzupassen.

Wenn du für jede Seite auch erst die Templates zum Client schicken musst (deine "globale" JS-Datei), dann kannst du das Argument mit der Trafficreduzierung sowieso gleich vergessen.

 

[benneq]

Aber es geht ja auch irgendwo darum, dem Benutzer mit JS-Unterstützung ein nettes Feeling auf der Seite zu geben. Und gerade bei Bildergallerien hasse ich es wie die Pest, wenn die Seite bei jedem Klick neu lädt

In dem Fall bleibt einem dann wohl wirklich keine Alternative zu 2 vollkommen unterschiedlichen Templates...
Oder hast du eine bessere Idee?



Wobei mir fällt noch folgende Möglichkeit ein:
URL: /link/zur/gallerie -- Stellt in einem <div> einfach alle Bilder in Vorschau-Größe dar
Das könnte man per AJAX abholen und z.B. als Overlay über die gesamte aktuelle Seite legen. Dann wäre hier schonmal nur ein einziges Template nötig.
URL: /link/zur/gallerie/1 -- Stellt ein Bild im großen Format dar
Die Seite könnte man dann natürlich auch wieder per JS holen und anzeigen.

Das ergäbe dann wieder sowas, nur dass man irgendwo darin noch die ganzen IDs der Bilder speichern muss, z.B. als data-Attribut:

<a href="link/zur/gallerie" class="gallery" data-image-ids="1,4,6,32,55,104">
  <img src="bild.jpg />
  Hier geht's zur Gallerie
</a>

Dann könnte man per JS die IDs auslesen und mit dem "vor" und "zurück" Button verbinden. Alternativ speichert man nur die aktuelle ID des Bildes (z.B. 14) und ruft dann so eine URL auf: link/zur/gallery/14/prev oder link/zur/gallery/14/next
Und der Server schickt einem dann den HTML Code für das Bild davor oder dahinter. Oder halt eine einen 404 Status Code oder sowas.


So hunderprozentig zufrieden stellt mich das noch nicht. Vielleicht kommen einem dafür ja noch ein paar geniale Gedanken

 

[Daaron]

Ohne JS wird einfach nur das Bild angezeigt mit dem Text drunter. Ein Klick darauf bringt den Benutzer zur gewünschten Gallerie.

...und der User hat gleich eine feste URL, die er bookmarken, seinen Freunden schicken oder auf FB&Co teilen kann.... Das hat er bei ner JS-Lösung nicht, ist dasselbe Problem wie damals mit Frames.

Mit JQuery UJS wird natürlich wieder nach dem data-remote=true Attribut gesucht und wenn zusätzlich class="gallery" gefunden wird, wird das dann einfach so ersetzt (Hier kommen die ein paar Vorzüge von Rails zum Vorschein):
- JS fragt auf der selben URL, wie der Link, nach Daten. Wobei im Header steht, dass als Response JSON sein sollte
- Der Rails Controller liefert nun nicht den HTML Code für die normale Gallerie-Ansicht zurück, sondern ein JSON Array wo jeweils Preview-Bild, Fullscreen-Bild und Beschreibung zusammengefasst sind.
- JS baut aus dem JSON Code eine Gallerie auf und ersetzt den kompletten <a href=...>...</a> Teil durch die JS-Gallerie

Wo is da der angebliche Vorteil von Rails? OK, als Framework ist es evlt. leichter zu schreiben, mit einem guten PHP-Framework (oder Framework für sonstwelche Sprache) hast du sowas aber auch.
Du schickst mit dem Request einfach irgend n öden kleinen GET-Parameter mit (z.B. $_GET['async']) und reagierst dann im Script darauf. Passenden HEader wählen, unnötiges Rahmenwerk um den eigentlichen Content nicht erzeugen, Content in einen String schreiben statt echo'n,... fertig. Ist kein Hexenwerk.


Trotz allem ist den Ansatz ineffizient ohne Ende, weil du serverseitig allen möglichen Kram doppelt und dreifach berechnen und cachen musst. Dem User tust du nix gutes und deinem Server nur schlechtes.

 

[ice-breaker]

In dem Fall bleibt einem dann wohl wirklich keine Alternative zu 2 vollkommen unterschiedlichen Templates...
Oder hast du eine bessere Idee?

per AJA"X" direkt eine vorgenerierte HTML-Antwort schicken.

...und der User hat gleich eine feste URL, die er bookmarken, seinen Freunden schicken oder auf FB&Co teilen kann.... Das hat er bei ner JS-Lösung nicht, ist dasselbe Problem wie damals mit Frames.

Richtig, und wer heute immernoch dieses Standardverhalten bricht, sollte gesteinigt werden!
Wobei man heute auf die wirklich schöne Lösung der HTML5 History API setzen kann, dann hat man wenigstens echte URLs beim Ajax-Request und nicht dieser Hashbang-Mist.
Für die ganzen Browser-Quirks gibts dann History.js von balupton, und wer die History API nicht kann, dem würde ich ganz normale HTML-Seiten vorsetzen, keine Hashbang-Geschichte keine falschen URLs, die sich nicht ändern. Entweder etwas richtig umsetzen oder gar nicht.

 

[benneq]

Der Vorteil ist, dass das Framework schon da ist

Statt Hashbang könnte man es auch einfacher per "www.seite.de/?page=news&show=article&id=42" machen
Finde ich jetzt nicht so groß den Unterschied zum Hashbang

Aber korrekt: Ist beides nicht das gelbe vom Ei.


Trotzdem ist die Lösung für eine integrierte Gallerie-Funktion immernoch nicht so wirklich zufriendenstellend. Ich befinde mich also unter "url/zur/news/25". Innerhalb der Seite soll eine JS Gallerie erscheinen.
Meintest du jetzt, dass ich beim Bilderwechsel die URL setzen soll, damit das jeweilige Bild beim aufrufen der URL angezeigt wird? Z.B. "url/zur/news/25?gallerie=8
Oder, dass man dann auf das gerade angezeigte Bild klickt, dann eine Vollbildansicht bekommt und sich dann erst die URL ändert? Z.B. "url/zum/gallerie/bild_id"

 

[ice-breaker]

Statt Hashbang könnte man es auch einfacher per "www.seite.de/?page=news&show=article&id=42" machen
Finde ich jetzt nicht so groß den Unterschied zum Hashbang

Aber auch nur mit der HTML5 History API, ist die nicht vorhanden, hast du Pech gehabt.

Meintest du jetzt, dass ich beim Bilderwechsel die URL setzen soll, damit das jeweilige Bild beim aufrufen der URL angezeigt wird? Z.B. "url/zur/news/25?gallerie=8
Oder, dass man dann auf das gerade angezeigte Bild klickt, dann eine Vollbildansicht bekommt und sich dann erst die URL ändert? Z.B. "url/zum/gallerie/bild_id"

Wenn in dem statischen Inhalt eine url "/gallery/24" wäre, dann muss diese Gallery existieren. Wenn du dann im "JS-Modus" bist, fängst du eben die URL ab, lädst per Ajax den HTML-Inhalt davon, stellst ihn dar, wie wenn es eine statische Seite wäre und änderst die URL per History API auf "/gallery/24".
Du machst also haargenau das gleiche, wie ein Browser ohne JavaScript die Seite behandeln würde, nur dass du nun alles implementieren musst, da du die Inhalte unbedingt in JavaScript nachladen wolltest.

 

[benneq]

Ah sorry, ich war vorhin wohl nicht ganz bei der Sache. Ja, ist alles klar

Aber mal ehrlich, willst du Bildergallerien ohne JS wirklich den statischen vorziehen?

 

[ice-breaker]

wenn die Seite ordentlich gebaut ist und auf schnelles Rendering optimiert ist, ist da kaum noch ein Unterschied. Dann darf eben nur keine externe Werbung (hallo CB) das Rendering blockieren, irgendwelche Social Buttons und wenn das Caching korrekt konfiguriert wird, dann ist das auch verdammt fix und es macht Meilen weniger Aufwand.