Besonderheiten
Templates mit fixiertem Header
Da sich das Javascript für das "weiche Scrollen" immer am oberen Ende des Fensters orientiert, stimmen die Scrollpositionen bei oben fix positionierten Elementen nicht mehr.
Hiergegen lässt sich ein benutzerdefiniertes Offset definieren. Je nach Anforderung kann es als feste Pixel-Zahl, oder als Rückgabewert einer Javascript-Funktion direkt im Template realisiert werden.
<script type="text/javascript">
/* <![CDATA[ */
var onepage_customOffset = 80;
/* ]]> */
</script>
Das Skript kann im Template ganz unten, aber vor dem schließenden </body> - Tag,
eingefügt werden.
Das "H1-Problem"
Nur eine H1-Überschrift?
Generell sollte man für ein OnePage-Projekt das CMS auf eine einzige Menüebene konfigurieren:
Einstellungen -> CMS -> Menü -> Ebenen -> 1.
Alle "Seiten" erhalten dann eine einleitende H1-Überschrift, die restlichen Überschriften sind zur Strukturierung der Inhalte verfügbar.
Das Problem dabei:
bis heute hält sich die Regel, dass ein Dokument nur eine einzige H1-Überschrift haben sollte.
Wenn nun im Template, zum Beispiel zur Ausgabe von sitename(), noch keine H1 - Überschrift definiert wird, kann man das leicht mit einem kleinen, gut lesbaren Codeschnipsel ;-) direkt im Template beheben:
Anstatt
<?php echo onepage_content()?>
verwendet man zur Ausgabe der Inhalte im Template
<?php echo
preg_replace('#<h2(.*?)<\/h2>#', '<h1$1</h1>',
preg_replace('#<h1(.*?)<\/h1>#', '<h2$1</h2>',
onepage_content()), 1);
?>
Die erste "OnePage" - Überschrift wird hierdurch mit <h1>...</h1> ausgezeichnet, alle weiteren werden in <h2>...</h2> eingeschlossen.
Muss die erste Inhaltsseite jedoch mit <h2> beginnen, lässt sich das selbe Verfahren analog auch für eine Ebene tiefer anwenden:
<?php echo
preg_replace('#<h3(.*?)<\/h3>#', '<h2$1</h2>',
preg_replace('#<h1(.*?)<\/h1>#', '<h3$1</h3>',
onepage_content()), 1);
?>
Vorteile:
- Semantisch richtige HTML-Struktur
- Der im Browser integrierte Lesemodus sollte funktionieren
Nachteile:
- Bei tieferer Verschachtelung muss der User die richtige Überschrift wählen, was nicht intuitiv ersichtlich ist
- Die "Gewichtung" der einzelnen Abschnitte fällt mit dem Level der Überschrift und muss nicht unbedingt dem jeweiligen Inhalt entsprechen
Oder HTML5 like?
Mit HTML5 gibt es neue Möglichkeiten zur semantischen Strukturierung der Inhalte. Zum Beispiel lässt sich eine "OnePage-Seite" in ein <article> - Tag verpacken. In jedem dieser "Artikel" sind, entsprechend der Standardausgabe des OnePage-Plugins, <h1> - Überschriften erlaubt.
Auch die vorherige Ausgabe des Seitennamens als H1-Überschrift ist, vielleicht auch verpackt in ein <header> - Tag, zu 100% valide unter HTML5:
<header>
<a href="#" title="Home">
<h1><?php echo sitename();?></h1>
</a>
</header>
Zu Demozwecken nutzt diese Seite ein angepasstes Template nach diesem Ansatz. Der OnePage-Container wurde dazu im Template umdefiniert:
<?php $onepage_structure =
'<article>
<div id="%s" class="onepage_page">%s</div>
</article>'
;?>
Das angepasste Template ist auch im Download enthalten.
Ausgabe im HTML-Validator testen...
Vorteile:
- Standard-Struktur muss nicht verändert werden
- Der User kann zur weiteren Strukturierung auf allen "Seiten" gleichmäßig Überschriften ab H2 verwenden
- Alle "Seiten" haben, aus Sicht des Inhaltes, die gleiche "Gewichtung"
Nachteile:
- Der Lesemodus der Browser erkennt die (laut Validator valide) Seitenstruktur in der vorliegenden Fassung nicht sauber. Allerdings gibt es (noch) keinen echten Standard für den Lesemodus, was zu unterschiedlichen Ergebnissen bei verschiedenen Browsern führen kann
- Der IE erkennt die neuen Tags erst ab Version 9. Wer ältere Versionen unterstützen muss, kann dafür html5shiv bemühen.
Mehr Hintergrund-Informationen zu dieser Variante finden sich im Netz zum Beispiel unter "The truth about multiple h1-tags in the html5 era".
Fazit
Welche Variante "richtig" ist, hängt vom Projekt und den Inhalten ab. Bei vielen OnePage-Seiten wird inhaltlich die HTML5-Variante die bessere Wahl sein. Aus SEO-Sicht vermute ich ebenfalls kein Problem. Neben der vielleicht besseren Gewichtung der Inhalte, gibt es aber auch Nachteile: der Lesemodus funktioniert nicht / nicht immer richtig und der Validator warnt z.B. vor Screenreadern, die vielleicht die neue Struktur noch nicht sauber interpretieren können.
Die :hover - Pseudoklasse und Touch-Geräte
... passen nicht zusammen, denn ":hover" gibt es nicht auf Touch-Geräten.
Die Navigation in dieser Demo nutzt aber :hover zur Animation beim Überfahren der Navigations-Links mit der Maus. Auf einem Touchgerät behält solch ein Link nach einem Tap die mittels :hover gestzten Styles. Dasselbe passiert zum Beispiel auch bei einem Button, der ein Formular per Ajax-Request absendet.
Wer auf die Hover-Styles nicht verzichten möchte, muss für Touch-Geräte eine passende Lösung integrieren. Zum Beispiel kann man mit Hilfe von Modernizer die Styles so definieren, dass bei Browsern, die das Touch-Event unterstützen, die :hover - Pseudoklasse nicht zugewiesen wird.
Im Template dieser Demo ist diese Lösung als Beispiel integriert.
Eine 100% - Erkennung von Touch-Geräten ist das allerdings nicht.
Warum, lässt sich hier nachlesen: http://www.stucox.com/blog/you-cant-detect-a-touchscreen/.