search1 wrote:Die CSS-Pseudoklassen sind meines Wissens nicht geeignet, den momentan angezeigten Menüpunkt zu markieren?
Nein. Mit diesen Pseudoklassen kann man noch nicht besuchte (:link), bereits besuchte (:visited), mit der Tastatur fokussierte (:focus), mit der Maus überfahrene (:hover) sowie gerade angeklickte (:active) Links (genauer: Elemente, denn in modernen Browsern kann man diese Pseudoklassen durchauch auch auf andere HTML-Elemente anwenden) gestalten.
Ich weiss, :active hört sich an, als sei es das, was Du suchst -- ist es aber nicht.
search1 wrote:und in eigenes_Template/index.php
folgenden Link beim Hauptmenü gestaltet:
Code: Select all
<li><a {if $currpage == $serendipityBaseURL}class="hinterlegt" {/if}href="{$serendipityBaseURL}">Start</a></li>
Dies führt aber zu keinem geänderten Ergebnis: Der Menüpunkt bleibt, wenn geöffnet, in der alten Hintergrundfarbe. Was mache ich falsch?
Zunächst mal funktioniert das so ohnehin nur für genau eine Seite.
Darüber hinaus haben wir hier das Problem, dass in diesem Fall die
gesamte Navigation hart kodiert ist. Die $currpage-Technik funktioniert z.B. im Bulletproof-Template so, dass die URLs, auf welche der jeweilige Link verweist, in einer Variablen abgelegt wird, welche dann mit $currpage und $currpage2 verglichen werden kann.
In Eurem Fall mussten diese URLs jedoch aufgrund der gewünschten Menüstruktur hart einkodiert werden, d.h. es gibt keine Variable, mit der man $currpage(2) vergleichen könnte -- außer eben den paar wenigen, die s9y bereitstellt, die aber nur die wenigsten Seiten abdecken.
Davon abgesehen müsste man den CSS-Selektor auch anders gestalten, aber die Frage stellt sich so noch gar nicht. Es müsste #navi a.hinterlegt sein, damit die Kaskade korrekt funktioniert, aber wie gesagt: Zunächst müsste man einen Weg finden, diese Klasse überhaupt korrekt zuzuweisen.
Ganz generell muss ich mir mal genauer ansehen, wie es mittlerweile funktioniert, Du hast ja doch zwischenzeitlich einiges umgebaut.
search1 wrote:die eigenes_Template/index.php verweist auf eine mainnav.tpl, in der abgefragt wird:
Code: Select all
{if $view == 'start'}
{include file="mainnav_start.tpl"}
in dieser mainnav_start.tpl wird dann der style nur für die Startseite definiert. So benötigt jede Seite eine eigene php-Datei. Außerdem muss neben {if $view == 'start'} auch die {elseif $view == 'entry'}, {elseif $view == 'plugin'}, {elseif $faq_plugin.this_faq.category}, {elseif $faq_plugin.subcategories} und {elseif $view == 'categories'} für alle Seiten abgefragt werden, was die Sache bei einer Änderung ziemlich verkompliziert.
Ah, ich erinnere mich
Die „Modularisierung“ der Navigation (wäre sie nicht modularisiert, wäre das Problem übrigens dasselbe) habe ich in erster Linie eingesetzt, damit diese Navigation für Euch wartbar bleibt -- je kleiner die Teile, in die man sie aufsplittet, umso weniger fehleranfällig wird das Gesamtkonstrukt. Zudem war (und ist) es wie erwähnt unmöglich, die von Euch gewünschte Navigationsstruktur in s9y dynamisch generieren zu lassen, einfach deshalb, weil in beiden Navigationen munter Links auf verschiedene Quellen (Kategorien, statische Seiten usw.) vermischt werden.
s9y bietet z.B. ein Seitenleisten-Plugin, um eine Liste der statischen Seiten auszugeben (mit dem allerdings die currpage-Methode auch nicht funktionieren würde) -- aber keine „eierlegende Wollmilchsau“, die einem eine Navigation „einmal mit allem (und scharf
)“ generiert.
So. Was tun?
Man müsste irgendwie™ das hart einkodierte href-Attribut auslesen, mit der URL der aktuellen Seite vergleichen und bei Übereinstimmung eine CSS-Klasse zuweisen. Für meine Begriffe schreit das nach Javascript (funktioniert dann halt auch nur bei Besucher, die JS aktiviert haben), aber möglicherweise fällt jemand anderem noch eine bessere, serverseitige Lösung ein.
Garvin?
YL
