Kompletten Inhalt von content.htm ausgeben - OnePage

[lck]

Wenn JavaScript deaktiviert ist, dann bleiben die Flexslider einfach leer, und die ursprünglich angesprungene Stelle bleibt.

Nur so ein Gedanke, evtl. müsste man in der onepage.js in der "function scrollToId " den Wert für "offsetTop" individuell anpassen, bei einem fixeden Header? Beispiel

[cmb]

Nur so ein Gedanke, evtl. müsste man in der onepage.js in der "function scrollToId " den Wert für "offsetTop" individuell anpassen, bei einem fixeden Header?

Ja, das wäre sinnvoll, wenn man, um den "Versatz" bei Links ohne JavaScript auszugleichen, eben ein margin-top (oder ähnlich) definiert. Man müsste dann wohl die Höhe des margin-top einfach von endOffset abziehen, also etwa:

Code: Select all

endOffset = element ? element.offsetTop : 0;
endOffset -= 60;

Den Wert dynamisch zu berechnen geht natürlich auch, aber das ist zumindest ohne jQuery etwas vertrackt (IE 8 lässt grüßen). Das größte Problem ist aber wohl diesen margin-top per CSS überhaupt richtig zu setzen. Dazu muss man die genaue Höhe des Header kennen, was im allgemeinen nicht unbedingt möglich ist. Bei Deinem Beispiel-Template z.B. sind ja die Menüpunkte floatend, und bei unterschiedlichen Seitenüberschriften wird bei bestimmten Fensterbreiten unterschiedlich umgebrochen (da nutzen also auch Media-Queries nichts).

Man kann die genaue Höhe des Headers dynamisch (also per JS) berechnen, und dann das margin-top dynamisch setzen, aber das hilft dann bei deaktiviertem JS nicht weiter, und das ist ja das eigentliche Problem. Denn wenn kein margin-top gesetzt wird, dann funktioniert das Scrollen per JS ja bereits jetzt wie gewünscht.

Ist irgendwie vertrackt.

[knollsen]

Komm jetzt erst dazu mich zu melden! Klasse Umsetzung der letzten Version und schön das Du meinen Vorschlag mit eingearbeitet hast! Durch die numerische ID ist jetzt definitiv das Browserproblem (Safarie, IE, Firefox, etc.) beseitigt. Würde dies als default mir wünschen. @cmb - Auch das mit toplink u. Überarbeitung der onepage.js haste fein gemacht - Respekt

Dazu muss man die genaue Höhe des Header kennen, was im allgemeinen nicht unbedingt möglich ist....

Mit fixen Header ist das sowieso immer so eine Sache, aber gerade da kann man mit margin-top den Content gut auslesen, da der Body im Offset immer einen exakten Wert ausgibt - nämlich den margin-top!

Code: Select all

jQuery('body').offset().top

Bearbeite die Seite jetzt mit dem selben Template. Das passt auch ganz gut. Da die Admin-Leiste auch fix ist, ist zwar der fixe Header darunter verschwunden, stört mich persönlich nicht, weil das Problem ja schon immer da war. Der IE spinnt zwar beim ausloggen bissel rum, das der Content nicht gleich die exakte Position hat, aber beim 2. klick ist alles OK, So etwas kann man echt vernachlässigen.

Es gibt nur noch andere Kleinigkeiten wie RSS-Feed beim calendar-Plugin oder warum <php echo toc(2,3,1); ?> nicht funzt. Aber das gehört ja nicht hier her!

[smaxle]

So ich hab mir jetzt mal Gedanken wegen den numerischen URL`s gemacht.
Und ich bin immer mehr davon überzeugt !

Auf meiner Seite ist Seite 4 jetzt mal mit Zeichen versehen und nicht numerischen URL`s im Plugin.
Damit es ersichtlicher wird.Vorlage:HIER
IE11 und Chrome 40 versagen.
Als einziger macht da Firefox mit.

Ich denke mal Google wird es egal sein,was da oben drinne steht.
Oder liege ich da falsch ?

Ich hab auch im Web viele Seiten gesehen die nur noch die eigentliche URL anzeigen.

Also für mich persönlich sehe ich die Zukunft bei numerischen URL`s oder eben nur noch die standard URL zeigen.

Fazit für mich im Moment: Im Plugin als Standard:numerischen URL`s und als Auswahl nicht numerischen URL`s

[cmb]

Zunächst mal vielen Dank für das Lob und das viele konstruktive Feedback -- ich bin angenehm überrascht, das Onepage_XH so interessiert.

Durch die numerische ID ist jetzt definitiv das Browserproblem (Safarie, IE, Firefox, etc.) beseitigt. Würde dies als default mir wünschen.

Fazit für mich im Moment: Im Plugin als Standard:numerischen URL`s und als Auswahl nicht numerischen URL`s

Der Nachteil der numerischen URLs ist, dass diese sich ändern, wenn man Seiten einfügt oder löscht. Das ist in der Praxis bei Onepage-Sites vermutlich kein großes Problem, aber toll finde ich es nicht (daher mag ich die vielen Onepage-Sites, die beim Navigieren ohne JavaScript kein Hash-Tag zeigen, auch nicht wirklich; und Websites, die JavaScript oder gar Flash erfordern, um benutzbar zu sein, mag ich schon gar nicht -- evtl. sind diese sogar rechtlich problematisch). Immerhin können die URLs ja als Lesezeichen gespeichert oder geteilt werden. Ich lass mir den Vorschlag die Voreinstellung zu ändern aber noch mal durch den Kopf gehen -- andererseits: es ist ja nur eine Konfigurationseinstellung, die man ja auch leicht ändern kann.

Auf meiner Seite ist Seite 4 jetzt mal mit Zeichen versehen und nicht numerischen URL`s im Plugin.
Damit es ersichtlicher wird.Vorlage:HIER
IE11 und Chrome 40 versagen.
Als einziger macht da Firefox mit.

Ich habe ja mittlerweile eingesehen, dass es ein Bug im Plugin ist; vielleicht gelingt es mir auch, diesen zu fixen. Aber grundsätzlich: ich würde solche eine URL nicht haben wollen, ob nun mit Onepage_XH oder ganz normal CMSimple_XH. Die ist völlig nichtssagend, und wenn ich sie eintippen sollte, würde ich ausflippen.

Ich denke mal Google wird es egal sein,was da oben drinne steht.
Oder liege ich da falsch ?

Guter Punkt! Ehrlich gesagt weiß ich nicht, ob Suchmaschinen normalerweise an URL-Fragmenten (also #...) interessiert sind. Ich glaube aber eher nicht. Wäre aber vielleicht mal zu recherchieren.

Dazu muss man die genaue Höhe des Header kennen, was im allgemeinen nicht unbedingt möglich ist....

Mit fixen Header ist das sowieso immer so eine Sache, aber gerade da kann man mit margin-top den Content gut auslesen, da der Body im Offset immer einen exakten Wert ausgibt - nämlich den margin-top!

Ja, das stimmt schon. Allerdings ging es ja darum, dass man per reinem CSS den Abstand festlegen sollte, damit das Menü auch ohne JavaScript richtig funktioniert. Wenn JavaScript verfügbar ist, dann sollte das Scrollen auch jetzt schon korrekt funktionieren -- egal wie hoch der fixe Header ist.

Es gibt nur noch andere Kleinigkeiten wie RSS-Feed beim calendar-Plugin oder warum <php echo toc(2,3,1); ?> nicht funzt. Aber das gehört ja nicht hier her!

Stimmt. Der Thread ist sowieso schon furchtbar lang -- also einfach neue Threads aufmachen.

[meltemi]

ob Suchmaschinen normalerweise an URL-Fragmenten (also #...) interessiert sind.

Vielleicht helfen die beiden Antworten von Thomas Hey'l weiter, auch wenn die ursprüngliche Frage anders gelagert ist: https://productforums.google.com/forum/ ... tD89709yxo

[cmb]

ob Suchmaschinen normalerweise an URL-Fragmenten (also #...) interessiert sind.

Vielleicht helfen die beiden Antworten von Thomas Hey'l weiter, auch wenn die ursprüngliche Frage anders gelagert ist: https://productforums.google.com/forum/ ... tD89709yxo

Das sind auf jeden Fall interessante Informationen. Allerdings erklären sie nur einen Teil meiner eigentliche Frage. Nicht klar ist mir weiterhin, ob sich Suchmaschinen für den Inhalt des Hashtags (alias URI-Fragments) interessieren? Anders ausgedrückt: spielt es eine Rolle, ob dort etwas sinnvolles steht, oder einfach nur eine Zahl. Immerhin wird aber von Thomas Heyl bestätigt, dass Hashtags sinnvoll sind, und diese sich im Laufe der Zeit nicht beliebig ändern sollten.

Sehr interessant finde ich auch den Hinweis auf die pushState() Technik. Ich kannte bisher nur die Hash-Bang-Konvention. Jedenfalls ist das durchaus etwas, was auch für CMSimple interessant sein könnte -- vermutlich sogar als Plugin realisierbar.

[meltemi]

ob sich Suchmaschinen für den Inhalt des Hashtags (alias URI-Fragments) interessieren? Anders ausgedrückt: spielt es eine Rolle, ob dort etwas sinnvolles steht, oder einfach nur eine Zahl.

Aus eigener Erfahrung weiß ich, daß es egal ist, was da steht. Da kann also auch eine Zahl oder eine geheimnisvolle Kombination mehrerer Buchstaben stehen. Aber im Hinblick auf Google muß da immer das gleiche stehen.

Unter manchen Suchergebnissen zeigt(e?) Google gelegentlich seiteninterne Zu ... springen-Links an. Das kann man erreichen, wenn man oben auf der Seite in einer Liste Links platziert und die gleichen Linktexte verwendet, die weiter unten auf der Seite in den den jeweiligen Sprungmarken zugeordneten Überschriften vorkommen. Für solche zusätzlichen Links gibt's aber keine Garantie. Das hängt von den Suchbegriffen ab, vom insgesamt semantisch richtigen Aufbau der Seite und natürlich auch davon, daß Google oft und gerne mal was Neues ausprobiert. (Nicht zu verwechseln mit den sogenannten sitelinks.)

Ein Beispiel kann ich gerade nicht reproduzieren. Vielleicht hat Google das auch wieder abgeschafft.

[cmb]

ob sich Suchmaschinen für den Inhalt des Hashtags (alias URI-Fragments) interessieren? Anders ausgedrückt: spielt es eine Rolle, ob dort etwas sinnvolles steht, oder einfach nur eine Zahl.

Aus eigener Erfahrung weiß ich, daß es egal ist, was da steht. Da kann also auch eine Zahl oder eine geheimnisvolle Kombination mehrerer Buchstaben stehen. Aber im Hinblick auf Google muß da immer das gleiche stehen.

Danke für die Info.

Ein Beispiel kann ich gerade nicht reproduzieren. Vielleicht hat Google das auch wieder abgeschafft.

Du meinst vermutlich so was wie das "Weiter zu Cast" beim englischen Wikipedia-Artikel unter https://www.google.de/webhp#q=deep+space+nine+cast. Das scheint aber bei der Suche nach "cmsimple_xh installation plugins" nicht zu klappen -- vielleicht muss man doch noch mehr beachten?

[meltemi]

Du meinst vermutlich so was wie das "Weiter zu Cast" beim englischen Wikipedia-Artikel unter https://www.google.de/webhp#q=deep+space+nine+cast.

Ja, so was wie.

Ich sehe hier kein Weiter zu Cast, sondern Cast - See also - Notes - Footnotes. Aber wie schon gesagt, Google ändert gerne und oft.

Bei mir sah das Suchergebnis damals aber anders aus, mit der Beschriftung Zu ... springen. Und ich hatte nur ganz simple <a name="xyz"></a> eingebaut.

Das scheint aber bei der Suche nach "cmsimple_xh installation plugins" nicht zu klappen

Da sehe ich hochgerechnet Ungefähr 12.800 Ergebnisse. Wenn ich bis zum Ende blättere, sehe ich 802 Treffer. Soll ich die wohl alle prüfen ;-(