Vorlage Diskussion:Navigationsleiste/mit Bild1

---

• Ist id=toc vs id="toc" relevant? Wobei genau hilft eignetlich diese id-Angabe?
• Ich glaube, dass in einer zukünftigen MediaWiki-Version erzwunge wird, daß jedes Template zu einem XHTML Fragment expandiert, die Idde eine table-Definition über mehrere Templates zu verteilen, dürfte dann auf Grund laufen.

Pjacobi 17:17, 13. Sep 2004 (CEST)

• id dient der Zuordnung von CSS-Definitionen und die "" sind optional.
• Abwarten und später ist immer noch Zeit um 'ne Lösung für mehrere zusammenhängende Navigationsleisten zu finden. Evtl. geht's dann halt nicht mehr (wie neuerdings bei der Wiki-Tabellensyntax).

--24-online 17:26, 13. Sep 2004 (CEST)

Hallo Paddy,
mit einigem Unverständnis habe ich Deine nächtlichen Änderungen zu den Navigationsleisten gesehen. Unabhängig von der Frage der angeblichen Nicht-Konformität mit w3c-Regeln gibt es zwei Aspekte, die mich sehr ärgern:

• Die Umstellung auf die Wiki-Tabellensyntax und das Hinzufügen des schließenden Table-Tags beschädigen die Funktion der Navigationsleisten. Nach verschiedenen Tests zeigte sich, dass nur bei der Verwendung von HTML-Tags inkl. des fehlenden Table-Tags der erwünschte Effekt erzielt wird, dass die Leisten miteinander Verschmelzen (vgl. Hans-Jochen Vogel). Auf diese Funktion ist explizit innerhalb des zentralen Templates hingewiesen. Ausdrücklich sei darauf hingewiesen, dass die Wikisoftware durchaus darauf ausgerichtet ist und korrekte Syntax erzeugt.
• Zum anderen versuchen Benutzer:24-online und ich gerade, den Einsatz von Navigationsleisten weiterzuentwickeln. Wir haben dazu zentrale Templates entwickelt, die es künftig ermöglichen werden, das Erscheinungsbild der Navigationsleisten bestmöglich zu vereinheitlichen. Dazu gibt es bereits ausführliche Diskussionen. Daher ist es schon reichlich ärgerlich, dass Du (mal wieder) in einer Nacht- und Nebelaktion versuchst, hier Lösungen einzuführen, ohne Dich mit den Leuten abzustimmen, die daran arbeiten.

Da Dein Argument der Nicht-Konformität mit w3c-Regeln nicht besonders stichhaltig ist - wir verwenden an sehr vielen Stellen innerhalb der Stylesheets ID-Tags - hätte ich eigentlich gute Lust, überall den Rollback-Button zu klicken. Da wir aber sowieso nach und nach auf die zentrale Vorlage umstellen wollen, spar ich mir die Zeit. Ich würde mir aber wünschen, wenn Du bei technischen Aspekten, die die Navigationsleisten betreffen, künftig mehr Abstimmung suchen würdest. -- Triebtäter 11:55, 21. Sep 2004 (CEST)

Hallo Paddy, ich kann mich der obigen Aussage nur anschließen.
Wie ich sehe, hast Du über Nacht einen Bot eingesetzt, um die Navigationsleisten zu bearbeiten. Kannst Du mal kurz erläutern, wo das Problem lag und wie ein CSS-taugliche Version der Navigationsleisten machbar wäre? Könntest Du mir außerdem mal das Botskript zukommen lassen und eine kurze Erläuterung geben, wie man diesen Bot einsetzt? Gruß --24-online 11:58, 21. Sep 2004 (CEST)

Da gibt es absolut nichts zu sagen wenn es W3C konfom ist wird es auch richtig dargestellt. Die fehler ligen an anderer Stelle! Da brauchen wir nicht zu dislutieren. Das haben wir gestern lange und breit mit den Entwicklern geklärt. --Paddy 15:34, 21. Sep 2004 (CEST)

Na, dann erzählt doch mal, wo die Zusammenfassung der Diskussion zu finden ist. --24-online 15:36, 21. Sep 2004 (CEST)

Die ist nirgendwo zu finden. Und beruht auf der Tatasche das Wikipedia:Qualitätsoffensive/Deutschlands Städte und Regionen komplett zeschossen war. Da haben Wir die Entwickler gefragt und der fehler lag daran das es nicht konform war. Das bild davon kann ich gerne wieder herstellen. Jeden falls liegt der fehler wenn wo anders. --Paddy 15:41, 21. Sep 2004 (CEST)

Im Portal Schrift muße ich hinter einige Templazes ein händisches </table> setzen, damit der "Trick" con Benutzer:24-online et al keine bösen Nebenwirkungen hat. Häßlich, hat mir aber nicht wehgetan. -- Pjacobi 15:59, 21. Sep 2004 (CEST)

Übrigens hier ist alles in Ordnung Benutzer:Triebtäter/Überblick --Paddy 15:44, 21. Sep 2004 (CEST)

Ich suche gerade wo der Fehler bei Hans-Jochen_Vogel#Weblinks ist bitte solange die Füße stillhalten ;-) --Paddy 15:47, 21. Sep 2004 (CEST)

Eine Diskussion ober die Vor- und Nachteile von Tabellen, die sich aus mehreren Templates zusammensetzen, findet sich hier: [1] und in den Antworten darauf. -- Pjacobi 15:55, 21. Sep 2004 (CEST)

Ich hab's nur bis Du Deiner letzten Version revertet, damit Du den Fehler finden kannst, wenn denn da einer sein soll. Fraglich ist aber, ob die Elemente der richtige Platz für Benutzer:Anathemas persönliche Angriffe sein sollen. -- Triebtäter 16:08, 21. Sep 2004 (CEST) Vielen Dank. --Paddy 16:10, 21. Sep 2004 (CEST)

Der Rahmen fehlt. Das war ja Ausgangspunkt unserer Überlegungen. Die Navigationsleiste sollte, um sich deutlich vom Artikel abzuheben und einen optischen Abschluss mit dem Kategorien-Kasten zu bilden in eine Box über die gesamte Breite gepackt werden. Der ID-Style toc erfüllt genau diese Aufgabe. Erst als Beschwerden kamen, dass gerade der Artikel Hans-Jochen Vogel ein negatives Beispiel wären, weil dort fünf Kästen untereinander stünden, haben Benutzer:24-online und ich versucht, diesem Problem zu begegnen. Es hat sich gezeigt, dass durch das Weglassen des schließenden HTML-Tags der erwünschte Effekt des Verschmelzens erreicht wurde. Gleichzeitig war sichergestellt, dass die Wikipedia-Software durch die tidy(html)-Funktion genau diese Frage handeln kann, so dass nach dem Parsen der Templates am Ende korrekter HTML-Code ausgegeben wird. Ich erkenne nach wie vor nicht, wo das fehlerhaft sein kann. -- Triebtäter 16:29, 21. Sep 2004 (CEST)

Kann der Rahmen nicht durch ein div erzeugt werden? --Paddy 16:31, 21. Sep 2004 (CEST)

Mach' doch mal einen Versuch. Danke.
Übrigens ist in der Vorlage Vorlage:Navigationsleiste mit Bild der Text <small> {{{INHALT}}} </small> bewußt auf mehrere Zeilen umgebrochen, da ansonsten der Inhalt bei Navigationsleisten, in denen der Inhalt (als Parameter) über mehrere Zeilen eingegeben wurde, nicht korrekt umgebrochen wird. (Siehe Vorlage:Navigationsleiste Bezirke in Hamburg) --24-online 16:36, 21. Sep 2004 (CEST)

Sind jetzt alle zufrieden? An der Farbe könnt Ihr noch drehen, wenn ihr wollt. --Paddy 16:46, 21. Sep 2004 (CEST)

Wo ist der Unterschied zwischen der DIV-Lösung und der Definition innerhalb der Tabelle als style-Eigenschaft der Tabelle? Eine DIV-Lösung müsste alle Navigationsleisten umschließen, das ist aber mit den derzeitigen Mitteln nicht möglich. Es sei denn man fügt Code in die verwendenden Artikel ein. Oder? Sobald es bedingte Parameter in der neuen Software gibt, könnte man aber die Navleisten z.B. mit entsprechenden "Schaltern" versehen. --24-online 16:47, 21. Sep 2004 (CEST)

Wasbitte wovon redest Du? Ich verstehe nur Bahnhof. id="toc" ist einfach falsch. Ihr nutzt da einen Fehler. So wie ich es jetzt gemacht habe ist es richtig und Konform. --Paddy 16:50, 21. Sep 2004 (CEST)

Der Fehler, den wir ausnutzen, ist der Umstand, dass wir mit broken-HTML gearbeitet haben, um die Navigationsleisten innereinander fließen zu lassen, d.h. ohne trennende Linien zwischen mehreren Leisten.

Die Angabe von id="toc" ist durchaus W3C konform.

Ja, wenn man nur eines pro seite nutzt schon.

Sie bewirkt nur, dass die Styles anhand der Definitionen in der CSS-Datei erfolgen und nicht explizit in der Tabelle erfolgen. Also: Unser Ziel war ein Rahmen um mehrere Navigationsleisten (ohne trennende Linien zwischen den einzelnen Leisten). Hast Du da eine Idee? --24-online 16:55, 21. Sep 2004 (CEST)

So sehen übrigens die entsprechenden Styles zur ID "toc" in monobook.css aus...

#toc { 
   /*border:1px solid #2f6fab;*/
   border:1px solid #aaaaaa;
   background-color:#f9f9f9;
   padding:5px;
   font-size: 95%;
}
#toc .tocindent { margin-left: 2em; }
#toc .tocline { margin-bottom: 0px; }
#toc p { margin: 0 }
#toc .toctoggle { font-size: 94%; }
#toc .editsection { 
   margin-top: 0.7em; 
   font-size: 94%;
}

Wie Du siehst, sind dort die z.B. Rahmendefinitionen border:1px solid #aaaaaa; bereits enthalten. --24-online 17:04, 21. Sep 2004 (CEST)

Ok, dann ist das problem wohl jetzt gelöst? --Paddy 17:22, 21. Sep 2004 (CEST)

Nee, eigentlich nicht. Idealziel: Mehrere Navigationsleisten ohne trennende Linie.
Ein Beispiel mit neuer "Lösung" und alter Lösung: Gerhard Stoltenberg --24-online 17:27, 21. Sep 2004 (CEST)

Das wäre supi und flexi, wenn dass

1. Valides XHTML wäre
2. Bei Wikipedia:Qualitätsoffensive/Deutschlands Städte und Regionen nicht verursachen würde, das Vorlagen zwischen denen eigentlich Text stehen sollte und die nichts miteinander zu tun haben auf einmal miteinander verschmelzen. Warum ich diese Aktion auf Wunsch von Benutzer:Bdk überhaupt erst gestartet habe! --Paddy 17:47, 21. Sep 2004 (CEST)

• Die Lösung mit id="toc" hat nur einen Fehler, der aber zur Zeit wenig Auswirkungen zu haben scheint: Die id-Attribute müssen in XHTML document-unique sein, d.h. ein Seite mit mehr als einer id="toc" ist strenggenomme invalid. -- Pjacobi 17:42, 21. Sep 2004 (CEST)
  • Dann müssten wir uns - streng genommen - ohnehin ganz andere Gedanken machen, da auch die IDs tocline und tocinside zur Definition von Überschriften auf vielen Seiten mehrfach vorkommen. Wäre denn die Definition eines neuen Styles navelement eine Lösung? -- Triebtäter 17:49, 21. Sep 2004 (CEST)
    • Ne, tocline ist eine Klasse und keine ID, ist mit class="tocline" im HTML-View-Source zu sehen. BTW, warum müllen wir eigentlich Paddys Diskussionsseite voll und nicht Vorlage_Diskussion:Navigationsleiste_mit_Bild? -- Pjacobi 17:59, 21. Sep 2004 (CEST)

Falls du gerade Deinen Bot startest, kannst Du darauf achten, dass bei Navigationsleisten, bei denen keine Bilder benutzt werden, sondern stattdessen Texte, diese als BILD-Parameter übergeben werden? Siehe Vorlage:Navigationsleiste Städte und Gemeinden im Landkreis Rastatt. Danke --24-online 17:41, 21. Sep 2004 (CEST)

Danke aber schon gesehen ;-) --Paddy 17:50, 21. Sep 2004 (CEST)

Für Navigationsleisten ganz ohne "Bild" gibt es übrigens die Vorlage Vorlage:Navigationsleiste ohne Bild (da es momentan noch keine bedingten Parameter gibt). Später soll es nur noch eine Vorlage geben, dann kann hoffentlich der Parameter "BILD" auf einen Wert überprüft werden. Siehe auch: meta:Extended_template_syntax --24-online 18:01, 21. Sep 2004 (CEST)

Spricht etwas dagegen die Vorlage als Class zu definieren? Und dann aber auch mehrfach zu verwenden? --24-online 18:46, 21. Sep 2004 (CEST)

Das ist ja nur sinnig, wenn man vorhande Regeln in den Standard-Skins "mitbenutzen" kann. Ein einfaches Umsetzen von id="toc" auf class="toc" bringt ja erstmal nichts außer Verwirrung, denn es gibt nur CSS-Rules für #toc, nicht für .toc. Pjacobi 18:57, 21. Sep 2004 (CEST)

Werden in Wikipedia bei benutzerdefinierten Skins, die fehlenden Regeln aus einer globalen CSS-Datei genommen? Dann könnte man die Regeln dort ergänzen. --24-online 19:02, 21. Sep 2004 (CEST)

MediaWiki:Monobook.css? -- Pjacobi 19:09, 21. Sep 2004 (CEST)

Das war die Frage. Wird z.B. diese Datei verwendet, wenn in der "eigenen" monobook.css eine Regel fehlt? Was ist bei anderen Skins? --24-online 19:12, 21. Sep 2004 (CEST)

An dieser Stelle brauchen wir einen Experten um weiterzukommen. -- Pjacobi 19:21, 21. Sep 2004 (CEST)

Ok, wer ist hier Experte? ;o) --24-online 19:25, 21. Sep 2004 (CEST)

Der Quelltext einer Seite gibt Antwort. Zuerst werden für die Bildschirmansicht die allgemeinen Stylesheets eingelesen (/style/monobook/main.css) und erst dann die benutzerdefinierten Styles. Die benutzerdefinierten Sytles überschreiben nur jene Elemente, für die ein eigener Style definiert wurde. Taucht ein Element oder eine Klasse nicht in der benutzerdefinierten css-Datei auf, erscheint es so, wie in der allgemeinen css-Datei definiert. Daher noch einmal der Vorschlag. Macht es Sinn, in der allgemeinen css-Datei eine neue Klasse navelement zu definieren? Die ID=toc ist im Augenblick auch nur eine Behelfslösung, da wir zahlreiche Definitionen dort (z.B. die Hintergrundfarbe) ja gleich wieder abändern. -- Triebtäter 19:32, 21. Sep 2004 (CEST)

Hatte ich Deinen Vorschlag zuvor überlesen? Bin dafür. Dann aber als Class, z.B. "navbar"?

Kannst Du die /style/monobook/main.css evtl. entsprechend ergänzen (das hat ja dann "noch" keine weiteren Auswirkungen) und diese Navigationsleiste ebenso. Und dann mal ein Test machen? Danke --24-online 20:34, 21. Sep 2004 (CEST)

Kommt /style/monobook/main.css aus MediaWiki:Monobook.css oder muß das ein m:Developer an ganz anderer Stelle hochladen?

Und wenn wir den Aufwand betreiben, sollte es so funktionieren, dass auch Benutzer:Anathemas Wunsch nach größerer Schrift rechnung getragen wird, d.h. das hart-kodierte &ltsmall> durch CSS-Rules für .navbar ersetzen.

Pjacobi 20:51, 21. Sep 2004 (CEST)

Genau, das finde ich ok. Vielleicht kann ja ein Experte auch eine Option (analog den Inhaltsverzeichnissen) bei den Benutzeroptionen hinterlegen, mit denen Navigationselemente abschaltbar sind?! Ich habe es noch nicht ausprobieren können, werden die Navigationsleisten eigentlich mit ausgedruckt? Das fände ich auch unschön. Vielleicht gibt es da auch noch 'ne Möglichkeit, um das zu verhindern. --24-online 21:08, 21. Sep 2004 (CEST)

Übrigens wird in den CSS-Rules für TOC der p-Tag ebenfalls umdefiniert, sodass es nicht zu den ungewollten großen Abständen kam. --24-online 21:17, 21. Sep 2004 (CEST)

Ich finde die Nav.leisten ähneln jetzt den Traueranzeigen in meiner Tageszeitung. Könnte man nicht eine etwas dezentere Rahmenfarbe wählen, etwa so, wie um die Kategorie. --W 22:53, 21. Sep 2004 (CEST)

Auf Benutzer:Pjacobi/Scratchpad#Navi habe ich ausprobiert, wie man es mit div statt table machen kann. Um "B" richtig zu sehen muß man class Rules in sein monobook.css stecken, siehe Benutzer:Pjacobi/monobook.css. Als Kompromiß zwischen zusammenwachsenden und getrennten Navi-Boxen, wird eine 1px Border zwischen den Boxen dargestellt. -- Pjacobi 21:45, 22. Sep 2004 (CEST)

Argh, habs gerade angeschaut ... bitte kein 80%-Schriftgrade (also gar keine %-Angaben bei Schriften) verwenden. Durch das Runterrechnen werden die Buchstaben nicht nur klein, sondern bei vielen Nutzern auch verschwommen und wirklich wintzigst. Das Problem hatten wir schon mal. <small> ist im Gegensatz dazu ok, da es feste Systemschriftgrößen nutzt. Eine manuelle Vergrößerung der Ansicht sollten wir insbesondere den vielen Nur-Lesern der WP nicht zumuten. Ob small grundsätzlich genutzt wird, ist mir egal, ich hab nichts gegen kleine Schriftgrößen, nur wenn, dann bitte vernünftig darstellbar. :Bdk: 22:27, 22. Sep 2004 (CEST)

Ja die %-Angabe ist knifflig, es gibt auf CSS-Sites die einen oder anderen Kochrezepte, welche Werte bei einem reüräsentativen Mix von Browsern zum gewünschten Resultat führt. Kann meinetwegen auch gerne mit small gemacht werden, nur addressierte es den Wunsch nach "Normaler Schriftgröße" als CSS-Einstellmöglichkeit. -- Pjacobi 23:04, 22. Sep 2004 (CEST)

Also, als wissbegierige Beobachterin finde ich es schon recht ärgerlich, wenn ich mir die Versionsgeschichte dieser zentralen Vorlage (und mit der Problembehebung verbundener Seiten) anschaue um nachzuvollziehen, was hier geändert wurde und wird, und da tragen selbst gestandene admins nix aber auch gar nix in die Zusammenfassung ein. Und das bei den (verständlicherweise) zahlreichen (nötigen Test-)Änderungen. Das musste ich mal loswerden, ich hoffe, es kommt bei Euch an. Ansonsten Danke natürlich für die Mühen und ein Lob fürs letztendliche Zusammenraufen zur gemeinschaftlichen Korrektur. Gruß :Bdk: 01:31, 23. Sep 2004 (CEST)

Hmmm .... wenn ich so sehe, wo wir jetzt stehen:

• wir haben mit den DIV-Tags eigentlich jetzt einer weniger störungsfreie Lösung als zuvor
• die erhoffte Lösung mit den ausgeblendeten Zwischenlinien klappt (noch) nicht

Was spricht denn im Moment dafür/dagegen, doch wieder auf Tabellen umzusatteln?

Dann wären wir zwar wieder ein wenig am Anfang, aber hätten zumindest eine störungsfreie Anzeige, die die Benutzer nicht mehr irritiert.

Hatt denn jemand Ahnung vom Parsing der Templates. Vielleicht könnte man hier ansetzen, dass der Parser aus zwei aufeinanderfolgenden Templates einfach eine Tabelle baut. -- Triebtäter 19:43, 23. Sep 2004 (CEST)

Meines Erachtens führt der ursprüngliche "Trick" von Benutzer:24-online, der die einzelnen Tabellen "zusammenwachsen" läßt in die Irre.

1) Die m:Developer haben schon angedroht, dass es in Zukunft nicht mehr funtionieren wird.

2) In manchen Umgebungen muß man hinter das "{{Navi X}}" ein einzelnes "</table>" setzen, um Chaos zu verhindern

3) Längst nicht alle Benutzer finden das "Zusammenwachsen" die ästhetisch überzeugendste Lösung.

• Davon abgesehen, ist Table vs. Div relativ egal, ältere grafische Browser kommen bei Div schlechter weg, weil die "gracefull degradation" eine zwar funktionsfähige, aber unschöne Navi-Leiste erzeugt. Dagegen dürften Lynx und Sonderschnitz, wie Braille-Zeilen, mit der Div Lösung besser wegkommen.
• Der einzige Unterschied bei aktuellen grafischen Browsern, ist das Umfließen des Bilds bei großen Navi-Leisten (oder niedrigen Bildern), siehe z.B: Vorlage:Navigationsleiste Landkreise und kreisfreie Städte in Niedersachsen. Ich finde das gut, andere mögen es wiederum schlecht finden.
• Das "Zusammenwachsen" ließe sich auch erreichen, indem ein die Leisten in ein "<div class="NavMerge">...<div>" packt, soll ich daran basteln?

Pjacobi 20:01, 23. Sep 2004 (CEST)

Das scheint mir die beste Lösung zu sein. Ein Beispiel gibt es unter Benutzer:Hendrik_Brummermann/Artikel/Hans-Jochen_Vogel, wobei Ihr zum Testen diese Regel in euere monobook.css übernehmen müsst: Benutzer:Hendrik_Brummermann/monobook.css. Als dauerhafte Lösung können sie von einem Admin in Mediawiki:monobook.css kopiert werden, so dass sie für alle Benutzer gelten. --Hendrik Brummermann 20:55, 23. Sep 2004 (CEST) - Damit spielt jemand rum. Soll jetzt zwischen den Navigationsboxen eine Trennline angezeigt werden, oder nicht? --130.75.182.247 22:00, 23. Sep 2004 (CEST)

Na ja, die als Wischi-Waschi-Lösung beschriebene Idee, auf das schließende Table-tag zu verzichten, hat nur an ganz wenig Stellen nicht funktioniert. Die Lösung mit den DIVs macht mir daher ein wenig Sorge, weil ich den Eindruck habe, dass sie sehr viel mehr hakt.
Ich bin sehr neugierig auf Deinen Vorschlag mit dem NavMerge-Style.
Dennoch sollten wir vielleicht trotzdem überlegen ob es vernünftig ist, bis auf weiteres wieder Tabellen (mit schließendem Tag) zu verwenden und dann noch einmal von Grund auf sich Gedanken an Anforderungen und techn. Lösungen zu machen, die dann vielleicht sogar die künftigen Features der Software gleich berücksichtigtigt.
Dann hätten wir als Resultat aus der Diskussion zwar keinen eigentlichen Fortschritt, aber wenigstens individualisierbare, und gegebenenfalls ausblendbare Leisten. -- Triebtäter 20:15, 23. Sep 2004 (CEST)

Die NavMerge Lösung ist auf Benutzer:Pjacobi/Scratchpad#Navi und Benutzer:Pjacobi/monobook.css zu sehen. B1 ist ohne, B2 mit dem zusätzlichem Merge-Div.

Zurückumstellung auf Tabellen: Falls tatsächlich gewünscht den NavFrame div beibehalten, und statt der anderen divs eine Tabelle reinbauen.

Pjacobi 21:04, 23. Sep 2004 (CEST)

OK. Langsam nähern wir uns einer Lösung. Glaub ich wenigstens.
Um das Problem der nur gelegentlich angezeigten Tabellenhintergründe und der ebenfalls nur teilweise angezeigten Rahmen in den Griff zu bekommen, wäre vielleicht eine Kombination aus DIV-Tags und offensichtlich stabiler laufenden Tabellen sinnvoll.
Zweites Problem, für das ich noch keine Antwort habe, ist ein logisches: das Nav-Merge-DIV ist quasi als Rahmen um beide Leisten gelegt, mit beginnendem und schließendem Tag. Wie geht das aber praktisch? Das zentrale Template weiß gar nicht, ob zwei, drei oder vier Leisten eingebunden werden sollen. Dort wird ja eigentlich nur Template für Template abgearbeitet. Dann müsste das umschließende Div-Tag im Artikel selbst stehen. -- Triebtäter 21:30, 23. Sep 2004 (CEST)

Die NavMerge Lösung arbeitet zwar zuverlässig aber sie ist manuell! Man muß das NavMerge-Div oder eine entsprechendes Template händisch einsetzen. Zum Dank für diese Methode, hat ein Artikelbearbeiter die Wahl, ob er einzelne oder zusammengepappte Navis vorzieht. Pjacobi 22:16, 23. Sep 2004 (CEST)

des Problems, dass die Navi-Leisten manchmal größer als der Rest sind, und insbesondere des Problems mit mehreren Navi-Leisten im Artikel (Mark Spitz).

Auch nach längerer Forschung gibt es keine Methode, die mit dem MSIE funktioniert und ohne Javascript auskommt. Also kurz zu der ersten Alternative:

• kein Javascript aber keine Navi-Leistem im MSIE

Der MSIE Benutzer sieht nur die Navi-Leisten-Überschrift, oder was man stattdessen haben will, also z.B.

• Olympiasieger über 100 m Freistil

Er hat also die Navigation, die viele an der Diskussion Beteiligten sowieso haben wollen: Auf eine Listenseite wechseln und dort den nächsten Artikel auswählen.

CSS agnostische User Agents (Lynx, Bots, etc) sehen eine ganz normale Linkliste

• Olympiasieger über 100 m Freistil
  • 1896: Alfred Hajós
  • 1904: Zoltán von Halmay
  • 1908: Charles Daniels
  • 1912: Duke Paoa Kahanamouku
  • 1920: Duke Paoa Kahanamouku
  • 1924: Johnny Weissmüller
  • etc

Mozilla (und andere Gecko Browser) und Opera sehen die Überschrift, wenn man mit der Maus daraufgeht, klappt die Navi-Leiste aus.

Demo folgt später.

Pjacobi 23:53, 30. Sep 2004 (CEST)

---

So, proof-of-concept Demo ist online: Benutzer:Pjacobi/navlinks

• Unter Navigation sieht man nur die Hauptlinks, z.B. zu Verwaltungsgliederung der Russischen Föderation.
• Wenn man mit der Maus auf die Zeile geht, passiert nicht besonderes
• Wenn man Opera, Mozilla oder Firefox benutzt und folgende Zeilen seine /monobook.css kopiert:

li:hover small.hiddenStructure {display: block; padding: 5px; margin: 5px; border: 1px solid black}
li:hover small.hiddenStructure a:hover {color: #411; background: #AAA;}
p:hover small.hiddenStructure {display: block; padding: 5px; margin: 5px; border: 1px solid black}
p:hover small.hiddenStructure a:hover {color: #411; background: #AAA;}

• dann öffnen sich die Navileisten, wenn man in die entsprechende Zeile geht.

Es ist noch nichts für die Schönheit getan, wie gesagt, eine reine Funktionsdemo.

Dass die Klasse "hiddenStructure" als "display: none" vordefiniert ist, kann man auch dafür benutzen, um die bisherigen Navi-Leisten als Voreinstellung unsichtbar zu machen. Dann hat man zwar nicht das neckische Ausklappen, was Mark Spitz etwas weniger albern aussehen läßt, aber es würde auch ohne Javascript in MSIE funktionieren.

Pjacobi 14:47, 1. Okt 2004 (CEST)

Probleme/Kommentar:

• es gibt keine Möglichkeit, im Textfenster am Aufklappen vorbeizukommen. D.h. die Navileiste klappt auch dann auf, wenn der Curser rechts vom Hauptlinks steht.
• es ist nicht möglich, das Popup zu öffnen, und anschliessend mit der Scrollleiste nach unten zu scrollen, damit man auch die ganze Navileiste sehen kann.
• in diesem Zusammenhang vielleicht interessant: http://www.bosrup.com/web/overlib/

ich finde deinen Vorschlag gut, denn manche Artikel werden durch x Navileisten verunstaltet --stw ⊗ 18:10, 1. Okt 2004 (CEST)

Nach einigen Tests scheint es mir klar, dass die Vorlage selbst und das für sie bestimmte CSS in monobook.css nicht alleine das Problem auslösen. Das lässt sich leicht reproduzieren, indem man aus diesen Bestandteile eine standalone HTML-Seite bastelt.

Das Zusammenwirkung der Gesamtheit aller CSS-Styles, die inzwischen für jede Seite inkludiert werden, ist das Problem, das MSIE überfordert. Das heißt natürlich, das die weitere Fehlersuche recht aufwändig werden kann.

Ich versuche unter Vorlage:Navigationsleiste mit Bild/temp eine Version zu erstellen, die dieses Problem nicht zeigt.

Pjacobi 12:46, 4. Okt 2004 (CEST)