AMP + HTML5 Validator

Ich muss ehrlich sagen, dass ich der ganzen Idee hinter AMP etwas skeptisch gegenüber stehe und deshalb bislang davon Abstand gehalten habe.

Von daher bin ich dir da keine große Hilfe.

Das ist eine spannende Frage!

Xenotyp schrieb:

[...] scheinbar leichter als gedacht ist die Spezifikationen von AMP einzuhalten.

Ja, solange Du keine Formulare oder für die Nutzung relevantes JavaScript verwendest. Ich war auch angenehm überrascht.

Xenotyp schrieb:

Kann man HTML5 überhaupt valide machen, wenn man AMP einsetzt?

Meines Erachtens: Nein, nicht mit der "standalone canonical AMP page"-Variante (https://www.ampproject.org/docs/tutorials/converting/resolving-errors#include-canonical-link). Mit 2 Versionen der Seite natürlich schon.

Ich kann keine HTML-Spezifikation finden, in der amp geschweige denn ⚡ als erlaubte Attribute erwähnt werden würden. Deshalb gab es hier schon die Diskussion, auf eine CSS-Klasse oder ein Custom data-Attribut auszuweichen:

github.com/ampproject/amphtml/issues/472

Matthes schrieb:

Ich muss ehrlich sagen, dass ich der ganzen Idee hinter AMP etwas skeptisch gegenüber stehe [...]

Ja, ganz meine Meinung. Es macht viele Errungenschaften der letzten Jahre mit einem Schlag zunichte. Was will man mit einer Seite ohne Formulare? Inhalte nach Bedarf via XHR nachzuladen ist doch viel effizienter für Mobilgeräte als auf Verdacht mal alles (bis auf Bilder außerhalb des sichtbaren Bereichs) runterzuladen. Und gibt es nicht genug Fallstudien, die Caching ausgelagerter und gz-komprimiert ausgelieferter CSS-Dateien als viel effizienter aufzeigen, als das ganze Gedöns in die html-Seiten zu packen und bei jedem Seitenaufruf wieder mit zu schicken?

Aber wenn Tantchen uns ein neues Spielzeug schenkt, muss man es ja mal ausprobieren

Ich danke auf jedenfall schon einmal für die Infos. Ich muss sagen ich steh dem auch sehr zwiegespalten gegenüber. Browser Caching G-Zip und Ajax machen meine Testseite eigentlich auch sehr geschmeidig mit dem mobilen Gerät. Ich wollte AMP nun jetzt endlich einfach mal testen. Ich werde beide Seiten parallel laufen lassen und testen was letztlich schneller ist. Ich finde es, wie gesagt, nur schwierig eine Website zu erstellen die AMP optimiert ist. Grundsätzlich müsste man zuerst eine valide HTML5 Seite erstellen, um nachträglich die AMP Änderungen vor zu nehmen und diese zu validieren. Besser wäre ein Validator der beides berücksichtigt. :/

Vllt. nice to know für euch. Ich habe meine Tests nun abgeschlossen. Tatsächlich ist die AMP Version durchweg langsamer als die NonAMP Version meiner Seite. Liegt wohl daran, dass meine Seite von Natur aus sehr winzig ist. Falls ihr euch das mal ansehen wollt: Navigiert ein bissel auf meiner Testseite umher: xeno-4aa45.firebaseapp.com

Und dann checkt die AMP Version dagegen: xeno-4aa45.firebaseapp.com/amp

Ah, danke.

Naja klar, Du sparst in der AMP-Version Deine 708 Byte CSS-Datei und Deine 668 Byte JavaScript-Datei. Dafür wird die 68,4 KB JavaScript-Datei von ampproject.org geladen.

Wenn ich es recht im Kopf habe, sollte dieses JavaScript-Monster (jQuery 1.12.4 hat mit 33,2 KB gerade mal die Hälfte) relativ zuverlässig bei allen Usern schon im Cache liegen. Bei 50 Minuten Vorhaltezeit und überhaupt habe ich da aber meine Zweifel.

Außer bei "Stuff" wirft Deine Ajax-Navigation übrigens immer einen 404er Fehler und wechselt die Sprache, wenn ich einen schon aktiven Menüpunkt anklicke.

d_spaete schrieb:
Außer bei "Stuff" wirft Deine Ajax-Navigation übrigens immer einen 404er Fehler und wechselt die Sprache, wenn ich einen schon aktiven Menüpunkt anklicke.

Hatten wir den Fehler nicht ganz zu Beginn schon, Xeno...?

Ja, grundsätzlich müsste die AMP Version schneller sein ... wenn man sich die Zahlen anschaut und einmal alles addiert und sich die Differenz anschaut. Praktisch werden bei mir aber die Bilder deutlich langsamer geladen. Das bemerke ich vor allem bei Seiten die 3 Thumbnails zeigen. Da kann ich sogar kurzzeitig eine Platzhaltergrafik sehen, die einen Ladebalken imitiert. Das ist echt merkwürdig. Naja, ich behalte es weiterhin im Auge. Die AMP Version meiner Seite verlinke ich nun mit <link rel="amphtml" href="https://www.example.com/url/to/amp-version.html"> im Header der normalen Version. So bekomme ich den AMP Benefit vllt. von Google, mal sehen.

@Matthes, ja ich stehe noch immer auf Kriegsfuß mit dem ollen Javascript für die Browser History Api. \'

//E: @spaete, trotzdem danke für die Info. Dass ich bei Stuff das Problem nicht habe, ist sehr sehr seltsam. Vllt. finde ich ja so ein Lösung.

//E: Bei stuff hab ich für den Aktiven Link ausversehen eine falsche id eingetragen. Hmmm, sollte das die Lösung des Problems sein?

Xenotyp schrieb:

//E: Bei stuff hab ich für den Aktiven Link ausversehen eine falsche id eingetragen. Hmmm, sollte das die Lösung des Problems sein?

Nein, das ist ein zusätzlich Problem bzw. ist es insofern eine Lösung, dass es die Ajax-Navigation außer Kraft gesetzt hat.

Ich bin mir jetzt nicht 100%ig sicher, weil\'s ja selten vorkommt, dass eine id doppelt vergeben wird, aber ich nehme stark an, dass Dein Event-Handler nur auf das erste Element mit der id "design" zugegriffen hat. Bei Klick auf Stuff wurde somit ohne irgendwelche XHRs ganz normal die stuff.html aufgerufen.

Die Lösung zu dem Problem hatte ich bereits in deinem ersten Beitrag hier vorgestellt.
Es liegt daran, dass Du ein onclick-Event vergibst, egal ob ein a-Tag vorliegt oder nicht, denn du wählst die Elemente nur per ID aus - die ID hat aber auch der derzeit aktive Menüpunkt als span-Tag.
Da Du den neuen Inhalt über das href-Attribut festlegst, der span aber naturgemäß keines hat, wird ein onclick-Event festgelegt, das ins Leere läuft.

Lösung: in ajaxify_link prüfen, ob das Element ein a oder ein span ist und bei letzterem abbrechen. Fertig.