nicht angemeldet
Rolf BHallo derkps,
Hallo, in der Endversion wird ein 'panorama.svg' benutzt und das bedingt ein iframe.
Öhm. Warum? Welches Problem verursacht <img src="panorama.svg" alt="Panorama von Hengasch"> an Stelle eine iframe?
Es zeigt keine Wirkung
Weil du einen Syntaxerror drin hast, der zum Abbruch des Scripts führt.
Verwende die Entwicklerwerkzeuge des Browsers, da steht's in rot geschrieben!
Dein Code hat einen Kopierrest, der weg muss. Es sieht so aus, als wolltest Du für Seite 1 window.scrollTo aufrufen. In den Funktionsklammern dieses Aufrufs sollten dann zwei Zahlen folgen (bzw. zwei Variablen mit diesen Zahlen drin). Aber statt dessen folgen Anweisungen. Das ist syntaktisch falsch.
Wenn Du auf Seite 1 mit scrollFrame.scrollTo arbeiten willst, dann nimm diesen Überrest von window.scrollTo weg (Zeile 2 und Zeile 7)
Zweitens: Dein CMS lädt die user.js im <head> Bereich der Seite. Es ist eine BLÖDE Eigenschaft der Browser, bei Antreffen eines script-Elements erstmal anzuhalten, das Script zu laden, auszuführen und dann erst die Seite weiter aufzubauen. Heißt: document.querySelector(".com-content-article__body .scroll") greift ins Leere, weil der Body noch gar nicht aufgebaut ist.
Der nachfolgende Code, der eine vorhandene Browserfunktionalität sinnlos nachbaut (der goBack-Button), zeigt Dir eine Lösungsmöglichkeit: Ein DOMContentLoaded Eventhandler. Der Code, der in der Funktion steht, die da als Eventhandler registriert wird, läuft dann, wenn das HTML der Seite fertig verarbeitet ist (Bilder sind eventuell noch nicht geladen).
Eine andere Möglichkeit wäre, dem <script> Element das defer-Attribut zu geben, aber ich weiß nicht, ob dein CMS dir das ermöglicht. Scripte mit defer laufen direkt vor den Funktionen, die für DOMContentLoaded registriert sind.
ich verstehe auch nicht, wie der Code der SEITE1 zugeordnet wird.
ich verstehe auch nicht, wie der Code der SEITE2 zugeordnet wird.
Kannst Du auch nicht verstehen. Weil es keine Zuordnung gibt.
Es ist ja nett, dass Du JavaScript mit Kommentaren mitteilen möchtest, dass manche Codeteile für Seite 1 und andere Codeteile für Seite 2 gelten sollen. Aber das ist JavaScript total schnuppe, es führt stur alles aus, was nach richtigem Code aussieht.
Wenn Du möchtest, dass ein Teil Code nur auf Seite 1 läuft und ein anderer Teil Code nur auf Seite 2, dann musst Du entweder für Seite 1 und Seite 2 getrennte .js Dateien vorsehen, oder Du musst ein Merkmal der Seite finden, woran Du erkennen kannst, ob Seite 1 oder Seite 2 geladen ist. Dieses Merkmal kannst Du abfragen, und damit erreichen, dass Code für Seite 1 nur auf Seite 1 läuft, und entsprechend für Seite 2. In deiner Demo könntest Du beispielsweise location.pathname verwenden, da steht der Teil der URL drin, der auf deinem Server liegt (also z.B. '/ueber-mich'. Alternativ kannst Du auch mit querySelector schauen, ob bestimmte Seitenelemente vorhanden sind. Für Seite 1 könntest Du abfragen, ob der querySelector was gefunden hat (d.h. ob in scrollFrame was drinsteht), und nur dann die Zentrierung machen.
So in etwa:
const scrollFrame = document.querySelector(...);
if (scrollFrame) {
const excess_y = ...
scrollFrame.scrollTo...
}
Auf Seite 2 ist so wenig spezifisches, da muss wohl tatsächlich der pathname ran. Oder deine reale Seite bietet bessere Möglichkeiten, keine Ahnung, die kenne ich ja nicht.
Ich habe von 20Jahre mal ernsthaft mit JS gearbeitet, da ist vieles weg
Offensichtlich, und vor 20 Jahren gab's vieles von dem, was heute üblich ist, noch gar nicht. Statt DOMContentLoaded hast Du damals das load-Event nehmen müssen, meine ich, und für EventListener musste man zwischen IE und Rest der Welt unterscheiden. Weshalb jQuery auch damals so erfolgreich war. Heute ist das meiste standardisiert.
Aber auch damals galt: wenn Code nur auf der Seite X laufen soll, dann darf er entweder nur dort geladen werden, oder er muss prüfen, ob Seite X gerade vorhanden ist.
Und damals galt auch schon: Bau nicht nach, was der Browser eh schon kann. Einen Back-Button zu bauen, der einfach in der History zurück geht, ist sinnfrei. Es gibt Formularketten, bei denen man das Zurückgehen in der History ausdrücklich verhindern will (weil man sonst am Server durchdreht) und dem User sagt: Verwende unbedingt die "Zurück" und "Weiter" Buttons. Diese führen dann aber auch als Form-Elemente oder Links auf entsprechende Seiten und verwenden nicht die History.
Rolf
sumpsi - posui - obstruxi
Gunnar Bittersmann
MudGuard