Xenotyp
Mitglied seit: 05.06.2015

Themenersteller
Guru (151 Beiträge)

AMP + HTML5 Validator

21.08.2017, 16:58 Uhr    HTML5 & CSS    2876 mal gelesen    26 Antwort(en).

Ich bastle gerade zu Testzwecken meine HP zu einer AMP Seite um. Dabei ist mir aufgefallen, dass es doch scheinbar leichter als gedacht ist die Spezifikationen von AMP einzuhalten. Jedoch fehlt mir ein Tool, dass mir sagt, dass AMP und HTML5 valide sinde oder nicht. Kann man HTML5 überhaupt valide machen, wenn man AMP einsetzt? In einem Forum habe ich gelesen, dass die AMP Spezifikationen HTML5 valid sind, aber die üblichen Validatoren sagen mir da was anderes. Zum Validieren von AMP benutze ich Google:

search.google.com/test/amp


matthes
Mitglied seit: 08.05.2010

Foren Moderator
Evil Genius
Content Halbgott (967 Beiträge)
21.08.2017, 22:15 Uhr

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.


Make Seitenreport great again!

d_spaete
Mitglied seit: 20.12.2012

Webentwickler
Fortgeschrittener (59 Beiträge)
21.08.2017, 22:21 Uhr

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

Vielleicht meinte der Autor in dem Forum, dass es keine Probleme in den Browsern gäbe. Aber valides HTML5 können AMPs m.E. nicht sein.


d_spaete
Mitglied seit: 20.12.2012

Webentwickler
Fortgeschrittener (59 Beiträge)
21.08.2017, 22:31 Uhr

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 2


Xenotyp
Mitglied seit: 05.06.2015

Guru (151 Beiträge)
22.08.2017, 09:21 Uhr

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. :/


Xenotyp
Mitglied seit: 05.06.2015

Guru (151 Beiträge)
24.08.2017, 13:16 Uhr

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

Somit war das Ganze für mich eine nette Übung aber nichts, was ich auf kleinen Internetpräsenzen einsetzen würde. Im mächtigen Wordspress CMS, Newsportal, whatever macht das vllt. Sinn.
Jetzt warte ich noch darauf dass Edge und FF webp unterstützen, dann gibts wieder was zu basteln. 4


d_spaete
Mitglied seit: 20.12.2012

Webentwickler
Fortgeschrittener (59 Beiträge)
25.08.2017, 13:26 Uhr

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.


matthes
Mitglied seit: 08.05.2010

Foren Moderator
Evil Genius
Content Halbgott (967 Beiträge)
25.08.2017, 13:45 Uhr

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...? 2


Make Seitenreport great again!

Xenotyp
Mitglied seit: 05.06.2015

Guru (151 Beiträge)
25.08.2017, 15:04 Uhr

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

im Header der normalen Version. So bekomme ich den AMP Benefit vllt. von Google, mal sehen. <br /> <br />@Matthes, ja ich stehe noch immer auf Kriegsfuß mit dem ollen Javascript für die Browser History Api. <span style="font-family:smiley-font;font-size:30px;color:#2c3e50;cursor:default;">s</span>\' <br /> <br />//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. <br /> <br />//E: Bei stuff hab ich für den Aktiven Link ausversehen eine falsche id eingetragen. Hmmm, sollte das die Lösung des Problems sein? <span style="font-family:smiley-font;font-size:30px;color:#2c3e50;cursor:default;">s</span>


d_spaete
Mitglied seit: 20.12.2012

Webentwickler
Fortgeschrittener (59 Beiträge)
25.08.2017, 16:21 Uhr

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? s



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.


matthes
Mitglied seit: 08.05.2010

Foren Moderator
Evil Genius
Content Halbgott (967 Beiträge)
25.08.2017, 16:28 Uhr

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.


Make Seitenreport great again!


Neuen Beitrag erstellen

Um einen Beitrag zu erstellen, müssen Sie eingeloggt sein. Bitte melden Sie sich an.
EinloggenRegistrieren



« zurück zu: HTML5 & CSS

Das Seitenreport Forum hat aktuell 4134 Themen und 36059 Beiträge.
Insgesamt sind 47832 Mitglieder registriert.