aus Wikipedia, der freien Enzyklopädie

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite. Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der URL-Zeile deines Browsers (Beispiel: [[MediaWiki Diskussion:Common.css/Archiv 1#Abschnittsüberschrift]]).

Anwendung der Definitionen

Rahmen- und Hintergrundfarben

Die in hier in MediaWiki:Common.css definierten Hintergrund- und Rahmenfarben sollen eine

• skinunabhängige und
• einheitliche

Farbgebung unterstützen. Auch hier gilt: weniger ist mehr.

Beachtet, dass die tatsächliche Farbgebung nicht festgelegt wird, dass eine Warnfarbe in einer anderen Umgebung beispielsweise nicht rot sondern weiß sein könnte und dass die Verwendung dieser Definitionen auch noch bei einer Ausgabe in Graustufen oder für eine Skinanpassung für Personen mit einer Farbsehschwäche Sinn machen soll.

Die hier definierten Farben sind als Beispiele für eine Standardausgabe zu verstehen; die Verwendung und eigentliche Definition sollte der angegebenen Beschreibung folgen und findet bei Bedarf in anderen CSS-Dateien statt.

Übersicht

Definiert sind rahmenfarbe1 bis rahmenfarbe5 und hintergrundfarbe1 bis hintergrundfarbe9.

Beispiele

Diese Farben sind zur Verwendung für Textkästen und Tabellen gedacht. Sie werden als CSS-Klasse eingebunden. Dabei definieren die Rahmenfarben zusätzlich eine Strichstärke von 1px, so dass für einen dünnen Rahmen nur noch die Strichart festgelegt werden muss.

Diskussion

Änderungen mitteilen

Änderungen am CSS sollte mitgeteilt werden, zB per sitenotice, damit die Nutzer Gelegenheit bekommen, ihren Cache zu leeren. Danke --WikiWichtel Cappuccino? 10:25, 19. Dez 2005 (CET)

Übersicht Rahmen- und Hintergrundfarben

Hier mal zur Verdeutlichung der Ergänzungen am 18.12.2005 eine Übersicht, weil schon mehrfach danach gefragt wurde:

Eine sehr gute Idee, das hier festzulegen, war schon länger überfällig ... aber das hg3-Gelb ist schon arg fies, ich hoffe nicht, dass das einem bald ständig irgendwo ins Auge springt ;-) Sinnvoll fände ich eine Ergänzung für alle bildbezogenen Hinweise um das Commonsblau bzw. die Metafarben. Das könnte im Hinblick auf zukünftige Auf-einen-Blick-Zuordnung von Bildern bei vielen Vorlagen zweckdienlich sein. Die Benennungsreihenfolge (momentan 1-5) sollte natürlich intuitiv sein/bleiben. --:Bdk: 12:45, 19. Dez 2005 (CET)

Wirklich eine längst überfällige Aktion. Also erstmal Danke für die Initiative! Ich wäre allerdings dafür, das hg3-Gelb etwas abzuschwächen ... Auch Bdks Vorschlag, noch ein Blau dazuzunehmen, ist gut, auch sonst würden eine oder 2 "leichte", Dann sollte diese Neuerung auf jeden Fall noch im Handbuch beworben werden, werde ich bei Gelegenheit mal tun.. --SwEEper 18:12, 23. Dez 2005 (CET)

Farbdefinitionen

Sinn und Zweck der Farbdefinitionen ist es, eine „geräteunabhängige“ (hier: nicht-skingebundene) Möglichkeit zur grafischen Gestaltung zu haben. Gleichzeitig geht es darum, die vordefinierten Farben auf ein Minimum zu reduzieren, um die Dateigröße nicht ausufern zu lassen und die Übersicht zu behalten, denn die Verwendung von CSS-Definitionen ist nicht mehr mit einfachen Mitteln wie „Links auf diese Seite“ zu kontrollieren.

Die „indirekte“ Definition von Farben über CSS-Dateien gewährleistet, dass die gewünschten Texthervorhebungen jedem zur Verfügung stehen. Solange die Amethyst-Skin noch läuft kann man dazu mal dies mit jenem vergleichen. Hat sich wohl gerade eben erledigt.

Ich habe mit den jetzigen Definitionen, wie ich hoffe, einen Großteil der in den Standardformatierungen abgedeckt, mit Ausnahme der als „Highlight“ 1 bis 3 definierten Vorlagen, bei denen ich noch überprüfen muß, ob es Ausnahmen bei deren jetzigen Einbindung als „bgcolor“ gibt. Diese, wie auch weitere Farben sind auch eher als „variabel“ zu verstehen, da sie außer zur Unterscheidung untereinander keinen besonderen Zweck verfolgen.

Bei den jetzt definierten Hintergrund- und Rahmenfarben bin ich bei der Ersetzung mit drei Ausnahmen genau den vorgefundenen, explizit vorgegebenen Farben gefolgt:

• die ab und zu angetroffene Hintergrundfarbe #f7f8ff (ganz leicht bläuliches, sehr helles Grau) habe ich Hintergrundfarbe 1 zugeschlagen (sehr helles Grau ohne ganz leicht bläulich)
• einige vereinzelte Varianten eines anderen Hellgrau habe ich mit Hintergrundfarbe 5 vereint
• das blasse Gelb in den Kästen auf Wikipedia:Verschieben (und ich meine irgendwo anders noch Kästen mit rosa Hintergrund) ist bei der kräftigeren Hintergrundfarbe 3 gelandet

Was im Moment an Hintergrundfarben noch fehlt, sind

1. die oben erwähnten „Highlight“-Farben. Zusätzlich wird manchmal eine Reihe von Graustufen zur Hervorhebung in Tabellen benutzt (beispielsweise in Vorlage:Links für Kalender und Zeit).
2. Individualfarben, die nur vereinzelt vorkommen, wie auf den Portalseiten.

Mehr Rahmenfarben brauchts im Moment glaube ich nicht.

Eine Handvoll Farben zur Hervorhebung, beispielsweise in Tabellen, ist zwar nicht zwingend notwendig, wird aber gerne verwendet. Die Frage ist nur, wie viele es sein sollen. „Schmuckfarben“ wie für die Portale müssen auch sein, sollten aber nicht gleich zu einer Vervielfachung der Definitionen führen. Die „Sparversion“ einer universellen Farbdefinition ist, bei einer Definition einer Hintergrundfarbe auch eine Text- (Vordergrund-) farbe (schwarz für die meisten) zu definieren, so dass ein entsprechender Textkontrast gewährleistet ist, da man nicht davon ausgehen kann, dass andere Skins Schwarz als Textfarbe benutzen. Das funktioniert allerdings nicht mehr, wenn Links im Text stehen, weil die wieder andere Farben haben können.

Wenn die Grundversorgung an Farben in den CSS-Dateien vorhanden ist schlage ich vor, weitere Definitionen nur nach vorheriger Diskussion aufzunehmen, um einen Wildwuchs zu vermeiden. Ein schlechtes Beispiel ist die neue, derzeitige Definition einer „palaeobox“, die außer ein paar unnötigen Trivialdefinitionen und bis auf einen Farbunterschied nur sämtliche Definitionen der Taxobox unter einem anderen Namen wiederholt und damit nur das System verlangsamt.

-- Schnargel 07:04, 23. Dez 2005 (CET)

Fortsetzung, Hintergrundfarben zur allgemeinen Hervorhebung

Zur Zeit sammle ich weitere häufig oder in Vorlagen verwendete Farbdefinitionen. Weitere Rahmenfarben sind wohl bis auf weiteres nicht nötig, aber ein paar unterschiedliche Hintergrundfarben sind vor allem für Hervorhebungen in Tabellen beliebt und dann ist da noch die Frage, ob eine Grautreppe sinnvoll ist und wenn ja mit wieviel Stufen. Zum Glück ist es ja kein Problem, das schnell gelöst werden muss, so dass genug Zeit zur Überlegung ist.

Im Sinne der „farbunabhängigen Farbgebung“ ist auch für diese Hervorhebungsfarben die genaue Farbe weniger interessant, als dass die einzelnen Farben voneinander leicht unterschieden werden können und dass es möglich ist, entsprechende Farbsets auch für beispielsweise weiße Schrift zu definieren. -- Schnargel 04:21, 3. Jan 2006 (CET)

Bei einer Grautreppe ist es nur wichtig, dass die etsprechenden „Farben“ unter sich eine gleichmäßige Reihenfolge bilden. Eine Beziehung zu anderen definierten Grautönen oder Farben gibt es nicht.

Es gibt sowohl Gründe, die Töne solch einer Farbreihe so zu benennen wie die anderen (hintergrundfarbeXX), als auch Gründe, einen anderen Namen zu wählen (hintergrundreiheX). Der verlockende Name „hintergrundgrau“ ist leider nicht farbneutral.

Die Frage bleibt (neben der benötigten Anzahl), ob man diese nur selten angewendeten Grautöne wirklich braucht, also ob beispielsweise Vorlage:Links für Kalender und Zeit dadurch übersichtlicher wird oder ob die abwechselnden Graus in der unteren Tabelle in Vendémiaire tatsächlich das richtige Mittel sind, die Lesbarkeit zu erhöhen. -- Schnargel 17:42, 8. Jan 2006 (CET)

Ein paar Blautöne, vielleicht ein kräftiges Orange/Gelb sollen von vielen Menschen als angenehme Farbkombinationen wahrgenommen werden. Als Grün würde ich ein satteres nehmen. Ist es sinnvoll, dass die Definitionen in anderen Namensräumen nicht angezeigt werden? (important etc.) --ChristianErtl 23:19, 8. Jan 2006 (CET)

Ein kräftiges Gelb und Orange gibt es oben schon als hintergrundfarbe3 und 4. Diese Hervorhebungsfarben ab Nummer 6 sollten für einfache Hervorhebungen in Tabellen besser nicht zu auffällig sein denke ich. Zudem soll auf ihnen auch noch Text mit (farbigen) Links angenehm lesbar sein, deswegen die etwas weniger satte Farbgebung. Und da sie in mehrfarbigen Tabellen auch nebeneinander stehen, sollten sie in der Auffälligkeit etwa gleich sein.

Zu viele Farben verderben das Layout und zu viele Farbdefinitionen verführen vermutlich auch zu unnötigem Farbgebrauch. Da die CSS-Dateien für jeden Artikel mitgeschleppt und interpretiert werden, sollten dort nicht notwendige Definitionen vermieden werden.

Die Definitionen sollen allgemeingültige Namen für die verwendeten Farben vorgeben und für alle Namensräume gültig sein. Durch die zentrale Definition können die Farbschemata einfach angepasst werden, zum Beispiel für Skins, die dunkle oder farbige Hintergründe und andersfarbige Schriftfarben verwenden in dem entsprechenden Stylesheet oder für Personen mit einer Farbenfehlsichtigkeit in einem Benutzerstylesheet. -- Schnargel 19:59, 15. Jan 2006 (CET)

Ich verstehe das durchaus. Allerdings wird das einige an Überzeugungsarbeit, nur die CSS-Klassen zu verwenden und sonst keine (so ist es doch gedacht, oder?). --ChristianErtl 20:36, 15. Jan 2006 (CET)

Welchen Browser benutzt du denn? Schau mal Wikipedia:Fragen zur Wikipedia im IE und im Firefox an. Im IE schaut es generell nicht so besonders gut aus, dafür ist die Farbe in anderen Namensräumen außer dem Artikelnamensraum richtig. --ChristianErtl 21:04, 15. Jan 2006 (CET)

Die Verwendung von CSS-Definitionen für eine geräteunabhängige Formatierung von Web-Inhalten ist allgemein ein langfristiges Ziel für den Entwurf von Webseiten überall. Davon ist eine unabhängige Farbdefinition zwar ein einfacher aber auch großer Teil des Gesamtkonzeptes (und halbwegs leicht verständlich zu machen). Dass diejenigen, die „ganz tolle Tricks“ mit <br>-Tags und Farbdefinitionen kennen sich ein wenig umgewöhnen müssen gehört dann dazu. Dass die Zeiten, in denen Webseiten entweder für Netscape oder Internet-Explorer „optimiert“ wurden zum Glück vorbei sind hat sich ja schon ein wenig herumgesprochen; die Erkenntnis, dass Webseiten auch mit anderen Schriftarten- und größen dargestellt werden, dass es Webbrowser für PDAs und Mobiltelefone gibt (und dass es in der Wikipedia auch Skins mit anderer Seitenaufteilung und Hintergrundfarben als Monobook gibt) ist davon nicht mehr weit entfernt. Der erste Schritt ist auf jeden Fall, eine barrierefreie Formatierung zu ermöglichen. Die Überzeugungsarbeit die danach kommt, nämlich diese Möglichkeiten anzuwenden, hängt auch von guter Vorarbeit ab. Wenn die nächsten paar Farben fertig sind und ich Zeit habe, werde ich die Anwendung auf einer geeigneten Seite erläutern und versuchen, sie schmackhaft zu machen.

Der Darstellungsunterschied, den Du in Fragen zur Wikipedia meinst, ist der Hintergrund von dem großen Kasten? Der Internet-Explorer ist leider der Browser mit den meisten Überraschungen wenn es um normgerechte Darstellung geht, das betrifft oft Hintergrundfarben und die Positionierung von Tabellen oder Textkästen zueinander. Interessanterweise scheint er die Vorlage alleine hier wieder richtig darzustellen.

Ich bin nicht sicher, ob ich richtig verstehe, was Du mit richtiger (oder falscher) Darstellung in den Namensräumen meinst. Dir ist aber auch klar, dass andere Skins auch andere Hintergrundfarben benutzen? Es ist zwar ohne weiteres möglich, für jede Skin und jeden Namensraum einzelne Farben zu definieren, so dass beispielsweise „hintergrundfarbewikipediaseite“ oder „hintergrundfarbediskussionsseite“ immer die „passende“ Farbe liefert, aber ich denke, das würde das ganze System jetzt zu unübersichtlich machen. Ich bevorzuge erst mal Definitionen, die nicht an Skins oder Namensräume angepasst werden müssen. Gruß -- Schnargel 00:28, 17. Jan 2006 (CET)

Gegen den ersten Abschnitt habe ich auch gar nichts einzuwenden, wenn der Eindruck entstanden sein sollte. Was mir an der IE-Darstellung nicht passt, ist der dicke Rahmen. Das mag deutlicher sein, ist aber auch sehr hässlich. Der Rest verwirrt mich etwas: Du spricht hier teilweise von der Firefox-Darstellung, oder? Der IE zeigt es bei mir bei beiden gleich an. Ich meine, dass die Hintergrundfarbe des Namensraums bei Monobook statt der in hintergrundfarbe1 definierten gewählt wird. Bei den Skins Klassik, Nostalgie und Kölnisch Blau scheint es zu funktionieren. --ChristianErtl 20:38, 17. Jan 2006 (CET)

Ach so, du meintest den Rahmen. Dann haben wir uns gegenseitig verwirrt. Ich hatte eine Standard-Breite von „thin“ statt „1px“ vorgegeben und IE ist wohl der einzige Browser, der das etwas dicker macht. Prinzipiell machen Pixel-Angaben nur für Bildschirmausgabe in Normalgröße Sinn, schon bem Vergrößern einer Seite oder erst recht für andere Ausgabegeräte (beim Drucken einer Seite) ist „ein Pixel“ schon nicht mehr ein Pixel. Aber wenn es dadurch hässlich aussieht, ändere ich die Angabe in Kürze in 1px. -- Schnargel 19:09, 18. Jan 2006 (CET)

Ich bin mir nicht sicher, aber ich denke, dass Folgendes der Grund ist, dass Firefox die Hintetgrundfarben in den Klassen ignoriert, wenn es sich um eine Tabelle handelt: (Aus MediaWiki:Monobook.css. (Schreibs doch das nächste Mal gleich dazu.) -- Schnargel 01:53, 29. Jan 2006 (CET))

.ns--1 table,
.ns-2 table,
.ns-4 table,
.ns--1 form {
        background: inherit;
}

Deswegen habe ich es bei mir so abgeändert. --ChristianErtl 16:18, 24. Jan 2006 (CET)

Wenn das stimmt, wären Monobook-Nutzer auf Benutzer- und Wikipediaseiten betroffen. Komisch bloß, dass dann bis jetzt noch niemand sonst was gesagt hat. Ich frage mich auch, was diese von Dir zitierten Zeilen bezwecken sollen und bin in Versuchung, die dort einfach zu entfernen, das sieht allerdings ein bisschen nach einem Bugfix für IE aus, wenn ich mich richtig erinnere, sollten Hintergrundfarben in Tabellen sowieso „ererbt“ werden (da zeigt sich mal, dass Kommentare in solchen Texten doch helfen können), der vielleicht doch seinen Grund hat. Ich würde gerne ohne die Hilfe von !important auskommen. Vielleicht meldet sich ja noch mal jemand anderes. Ich ändere jetzt erst mal für selbigen Browser die Rahmenbreite auf 1px. -- Schnargel 01:53, 29. Jan 2006 (CET)

Da ich es auf mehreren Rechnern bei verschiedensten Firefox-Installationen (1.5) falsch sehe, gehe ich davon aus, dass es mehrere Benutzer betrifft. Dass sich niemand meldet, ist meiner Meinungn nach kein Wunder: Man geht wohl davon aus, dass es so sein soll. Es ist auch nicht richtig, dass sich niemand meldet, ich wurde schon gefragt, warum das bei der Vorbereitung eines Artikels im Benutzernamensraum nicht angezeigt wird, im Artikelnamensraum aber schon. Ich kann Firefox und IE schon auseinander halten. Du kannst dir das bei allen Skins außer Klassik, Nostalgie und Kölnisch Blau bei Wikipedia:Fragen zur Wikipedia anschauen. --ChristianErtl 12:22, 29. Jan 2006 (CET)

Ich nehme die Definition mal aus MediaWiki:Monobook.css heraus in der Hoffnung, dass was immer die Leute dann sehen dann auch als „es soll so sein“ gesehen wird. Die Darstellung von Tabellen auf Seiten mit Hintergrundfarben soll für alle Namensräume und Skins gleich und nachvollziehbar sein. -- Schnargel 00:48, 30. Jan 2006 (CET)

{{prettytable}} vs. class="wikitable"

In der Diskussion zu monobook.css ist Ende des letzten Jahres schon einmal ergebnislos angesprochen worden – die Diskussionsteilnehmer verloren sich in Nebensächlichkeiten – was eigentlich hierher gehört: Die Vorlage:Prettytable sollte durch einen Eintrag im de.wikipedia.org-weiten und skinübergreifenden Stylesheet common.css ersetzt werden. In der englischen Wikipedia hat man sich letztendlich für den Klassennamen „wikitable“ entschieden und der Einheitlichkeit wegen sollten wir den wohl übernehmen. Die englische Diskussion wurde inzwischen archiviert (Abschnitte 6 und 8). Es wurden dort m.M.n. alle relevanten (und einige irrelevante) Argumente ausgetauscht und die vernünftige Lösung gewählt. Könnten wir dem also bitte folgen? Christoph Päper 15:10, 24. Feb 2006 (CET)

Ich kann mich dem nur anschließen. Die Vorlage wird so oft verwendet, daß scheinbar wirklich Bedarf besteht. Kann da ein Verantwortlicher etwas einpflegen? --chrislb 问题 14:38, 18. Apr 2006 (CEST)

Ich halte das für eine sehr nützliche Erweiterung. Die Commons.css wird sowieso bei jeder Seite mitgeladen und ist zudem vor Vandalismus geschützt. --CyRoXX ^(?) 13:45, 30. Apr 2006 (CEST)

Bin auch für class="prettytable", hat ihre Prüfzeit (Testlauf) wohl mit Erfolg bestanden um sie statisch ins CSS zu geben. -- Ολλίμίνατορέ ^•Ω• 14:00, 30. Apr 2006 (CEST)

Ein weiterer Vorteil (für die Flexibilität) wäre, dass man zusätzliche CSS-Angaben machen könnte, was mit Vorlage nur über einen zusätzlichen Parameter funktionieren würde (den es auch Momentan nicht gibt). -- Ολλίμίνατορέ 10:59, 21. Mai 2006 (CEST)

Ein mögliches gewichtiges Gegenargument wäre, dass die ersten Angaben kein CSS sind und auch nicht einheitlich zu selbigen konvertiert werden können. -- Ολλίμίνατορέ 09:54, 22. Mai 2006 (CEST)

Ich habe mir mal die Disskusion in en: darüber durchgelesen, die folgenden Angaben sind das Ergebnis einer langen (älteren) Diskussion und für de: ebenfalls als unbedenklich zu übernehmen. Überdies wird diese Methode vom Mediawiki sogar empfohlen w:Meta-templates_considered_harmful, Template:Prettytable, und ist seit 2005 mehr als bewehrt im Einsatz. -- Ολλίμίνατορέ 20:46, 7. Jun 2006 (CEST)

Bin auch dafür das ins CSS aufzunehmen, aber das mit den ersten vier Nicht-CSS-Atrributen (border="2" cellspacing="0" cellpadding="4" rules="all") muss dann noch geklärt werden. -- San Jose 21:54, 7. Jun 2006 (CEST)

Das Problem wurde gelöst (durch die differenzierten mehrzeiligen Angaben). -- Ολλίμίνατορέ 22:06, 7. Jun 2006 (CEST)

Ja dann, ab in den Probelauf -- San Jose 09:23, 8. Jun 2006 (CEST)

Ολλίμίνατορέ: Du schreibst, diese Methode werde „vom Mediawiki“ sogar empfohlen und gibst als Beleg (leicht fehlerbehaftet) einen Link an, der korrigiert wohl en:Wikipedia:Meta-templates considered harmful ist. Ich finde oben auf jener Seite einen Textkasten, der mit den fettgedruckten Worten „This proposal was rejected by the community“, auf deutsch: „Dieser Vorschlag wurde von der Gemeinschaft abgelehnt“ beginnt. Aus er zugehörigen Diskussionsseite geht hervor, dass es sich um Einzelmeinungen eines oder weniger Mitglieder der englischen Wikipedia handelte. „Der Mediawiki“ ist übrigens die MediaWiki-Software und spricht selbst keine Empfehlungen aus. Die wären auch ehestens auf http://www.mediawiki.org/ zu erwarten.

CyRoXX (und andere): Die Commons.css wird hoffentlich vom Webbrowser nicht jedesmal neu geladen sondern zwischengespeichert, aber je mehr da drin steht, desto träger wird das System, und Commons.css wird auch für alle Seiten ausgewertet, die keine „prettytable“ enthalten und das dürften die allermeisten sein. (Unsinnigerweise werden zwar seit einiger Zeit auch Definitionen, die ausschließlich für die Hauptseite bestimmt sind für 435.000 andere Seiten mitgeschleppt, aber man soll ja nicht von schlechten Beispielen lernen.) Wenn Vandalismus ein Problem sein sollte, kann man die Vorlage ganz einfach schützen.

chrislb (und andere): Vorlagen und Stylesheets sind verschiedene Dinge. Und aus der Häufigkeit der Verwendung kann man keine Präferenz für das eine oder andere ableiten oder gar schließen, dass die Aufgabe mit dem einen oder andren besser gelöst werden könnte.

Welchen Vorteil eine entsprechende Definition hier haben würde wird weder aus dieser Diskussion, noch aus Vorlage Diskussion:Prettytable, noch aus den Diskussionen in der englischen Wikipedia deutlich. Die vage Argumentation mit der Serverlast ist nirgendwo mit konkreten Zahlen belegt, wird aber offensichtlich gerne abgeschrieben. Andere Vorlagen werden weitaus häufiger verwendet. Ansonsten erkenne ich viel Halbwissen und Aktionismus, aber beides ist nicht geeignet um hier einen (vermeintlichen) Fortschritt zu bringen. Viele wissen auch nicht oder nicht genau, wofür CSS-Stylesheets geeignet sind und wofür nicht.

Ich zitiere hier eine Antwort von mir, die ich auf meiner Diskussionsseite zu diesem Thema gegeben habe:

Möglich ist vieles, aber ob es wirklich sinnvoll ist, ist eine andere Frage. Und dass, was andere machen automatisch gut ist, stimmt auch nicht immer. Schön wäre es, wenn man damit auf einen Schlag alle Tabellenprobleme lösen könnte, was aber nicht der Fall ist. Es würde sich in der Anwendung nichts ändern, vereinfachen oder „verbessern“. Mit der Definition in der Vorlage ist alles (außer den Farbdefinitionen, die wirklich in die Stylesheets gehören) übersichtlich an einem Ort zusammengefasst. Was ich auf MediaWiki Diskussion:Common.css lese ist auch kein Diskussionsergebnis sondern sind ein paar Einzelmeinungen, und wenn ich Vorlage Diskussion:Prettytable dazunehme, sind die Meinungen, wie auch Anforderungen an Tabellen so unterschiedlich, dass mir einzelne Vorlagen – wenn überhaupt – als die bessere Lösung erscheinen. (Dass sich jemand die Mühe machte, die erwarteten Vorteile einer solchen CSS-Definition irgendwo aufzuzählen sehe ich auch nicht.)

Was dagegen sinnvoll wäre, wäre das Problem an der Wurzel zu packen und eine neue Tabellensyntax zu entwickeln, die sich im Gegensatz zur momentanen nicht an der HTML-Syntax sondern an den Bedürfnissen der Autoren orientiert und diese dann in die MediaWiki-Software einbauen. Dann hätte man eine einfache Möglichkeit, Zelleninhalte einzeln oder zeilen- oder spaltenweise links, rechts, mittig oder sonstwie auszurichten, beispielsweise jede zweite Spalte einzufärben anstatt mit Linien voneinander zu trennen und vieles mehr. Dann kann man auch guten Gewissens CSS-Stile benutzen und anstreben, sämtliche Tabellen in der Wikipedia entsprechend zu definieren.

Zur Fortsetzung dieser Diskussion wäre es also sinnvoll, erst einmal stichhaltige Argumente anzubringen („wird soundso oft verwendet“ und „andere machen es auch so“ gehören nicht dazu). Sinnvoller wäre aber, wie ich oben geschrieben habe, eine Lösung zu erarbeiten, die gleich alle Probleme, die mit der Anwendung von Tabellen auftauchen, auf einmal lösen würde. – Schnargel 03:53, 24. Jul 2006 (CEST)

Die Vorteile einer CSS-Lösung sind m.E. eigentlich so offensichtlich, dass "stichhaltige Argumenet" nicht nötig wären. Aber hier mal eine Auflistung von Vorteilen, die eine CSS-Lösung bringen würde:

• Wenn {{Prettytable}} benutzt wird, ist eine weitere Angabe von styles für Tabellen nicht möglich, da Prettytable selbst schon ein style-Attribut mitbringt. Das heißt, sollte man als Artikelschreiber an einer Tabelle mit Prettytable-Attribute mit zusätzlichen eigenen Attributen interessiert sein, muss der Inhalt von Prettytable händisch eingefügt und dann das style-Attribute angepasst werden. Der Nachteil ist konsequenterweise, dass eine Änderung in der Vorlage bei solchen Tabellen keine Wirkung haben wird.
• Änderungen der Vorlage haben einen kaskadierenden Effekt auf alle Seiten, die die Vorlage verwenden. Die Serverlast ist also bei solchen Änderungen enorm, da die Caches für alle die Vorlage einbindenden Seiten invalidiert werden. Veränderungen in Common.css haben keinerlei Nachteil für den Server.
• CSS erlaubt es, Prettytable-Tabellen den verschiedenen Skins anzupassen. Dadurch, dass die Tabelle eine CSS-Klasse zugewiesen bekommt, ist es möglich, die Darstellung in den einzelnen und auch in der eigenen Skin anzupassen. Die Vorlage verlangt andererseits, dass Prettytable-Tabellen in allen Skins gleich aussehen, unabhängig davon, wie sehr sie in das Design der Skin passen.
• Weiterhin ist es mit einer CSS-Klasse möglich, Attribute für daring enthaltene Elemente festzulegen. So legt beispielsweise w:Mediawiki:Common.css fest, dass die Kopfzellen alle hellgrau unterlegt sind. Auf ähnliche Weise wäre es dann auch möglich, unter Benutzung entsprechender CSS-Selektoren Zeilen abwechselnd mit verschiedenen Farbtönen zu unterlegen, um die Lesbarkeit gerade in längeren Tabellen zu erhöhen. Die Vorlage erlaubt so etwas nur händisch - sprich, es muss für jede Zeile einzeln angegeben werden.
• CSS spart Bandbreite, da die Styledefinition nur einmal heruntergeladen werden muss und dann im Browsercache gespeichert wird. Bei der Vorlage andererseits wird der gleiche Code für jede Seite, die solche Tabellen beinhaltet, neu heruntergeladen.

Mir ist auch nicht ganz klar, was du mit dem Satz "je mehr da drin steht, desto träger wird das System" meinst. Die Wikimedia-Server werden deswegen auf jeden Fall nicht träger, im Gegenteil: selbst wenn der Cache erneuert werden muss, ist die Einbindung der Vorlage langsamer, als wenn nur ein Verweis auf eine CSS-Klasse steht. Auch für den Leser gibt es am Ende eine Verbesserung, da sich der Bandbreitenverbrauch minimal verringert.

Schließlich: das Argument, dass es so in einer anderen Wikipedia gemacht wird (insbesondere wenn es sich um die en-WP handelt), hat durchaus einigen Wert. Da man wohl davon ausgehen kann, dass sich auch in der en-WP Experten mit diesem Thema behandelt haben und aus der Tatsache heraus, dass die gleiche Diskussion dort zu dieser Lösung geführt hat, könnte man durchaus darauf vertrauen, dass sie vielleicht doch wissen wovon sie reden. Ma'am 08:20, 24. Jul 2006 (CEST)

Was offensichtlich ist und was nicht ist nun auch eine Sache der persönlichen Betrachtung. Eine Diskussion ohne den Austausch von Argumenten ist nicht möglich und eine Darstellung der eigenen Argumente als Selbstverständlichkeit (oder als „offensichtlich“) hilft auch nicht.

1. Vorlagen (und ähnliche Konstrukte) dienen hier nicht nur dazu, den Autoren die Arbeit zu vereinfachen, sondern sollen auch zu einem einheitlichen Aussehen verhelfen. Die Möglichkeit zusätzlicher Attribute kann unerfahrene Autoren verwirren und würde das Aussehen eher veruneinheitlichen.
2. Die Serverlast ist bei anderen Vorlagenänderungen auch da und es ist die Aufgabe der Server, solche Dinge zu erledigen. Es wird auch keiner vorschlagen, auf Vorlagen, Kategorien oder Spezialseiten ganz zu verzichten. Außerdem ist das vermutlich keine „enorme“ Last sondern nur 0,06 %. Die „Kaskade“ tritt auch nicht auf einmal auf und die Vorlage wird auch nicht täglich geändert.
3. Natürlich erwartet der Autor, dass die Tabellen in den verschiedenen Skins nicht nur passend sondern auch etwa gleich aussehen. Die skinabhängigen Bestandteile sind im Moment die Farbmöglichkeiten und die sind bereits in den Stylesheets definiert. Dass für die vorhandenen Skins andere Attribute wie Liniendicke (oder was sonst) separat behandelt werden müssten sehe ich nicht und das würde mit vorhandenen Tabellen, wo eben solches vom Autor bereits explizit geändert wurde, kollidieren.
4. Besondere Attribute können nach wie vor in der Wiki-Syntax für alle Tabellenzeilen und -zellen angegeben werden. Eine globale Änderung der Hintergrundfarbe der Tabellenköpfe wäre allerdings eine skinabhängige Sache und würde ähnlich wie die Hintergrund- und Rahmenfarbe realisiert werden. Ich denke aber nicht, dass es sinnvoll ist hier etwas zu verändern, da die Vorlage bereits sehr häufig verwendet wird und es vermutlich bereits viele individuelle Farbanpassungen bei der Verwendung gibt die mit einer solchen Änderung nicht unbedingt harmonieren würden. Außerdem ist eine Vorlage um so universeller verwendbar, je neutraler sie ist.
5. Auch für ganz kurze Artikel werden bereits 10 kByte HTML gesendet. Artikel die Tabellen enthalten dürften regelmäßig noch weit größer sein. Eine Einsparung von vielleicht 180 Byte wäre da ein sehr marginaler Unterschied. Wenn das Sparen von Bandbreite nötig ist, gibt es weitaus bessere Ansatzpunkte.
6. Zum System gehört auch Dein Webbrowser und der wird träger, je mehr unbenutzte Definitionen er für jede Seite mit herumschleppt und der überwiegende Teil der Wikipedia-Seiten hat keine dieser Tabellen. Und wenn es für Dich keinen Unterschied macht, denke daran, dass Wikipedia den Anspruch hat, auch auf PDA- und Mobiltelefonbrowsern dargestellt werden zu können und diese Geräte haben eine deutlich geringere Rechenleistung und Speicherausstattung. Darüberhinaus bieten solche Browser oft nur eingeschränkte oder keine CSS-Möglichkeiten, so dass die aktuelle Vorlage auch kompatibler ist.
7. Nein, man kann nicht davon ausgehen, dass sich in der englischen Wikipedia nur Experten mit dem Thema befassen, wie beispielsweise für diese Sache unter anderem die Definition von Rahmen- und Hintergrundfarben ohne die zugehörige Definition der Textfarbe zeigt. Auch dort glauben wie hier viele Leute, dass sie plötzlich in vielen Bereichen ein Expertenwissen haben, weil sie vielleicht unwidersprochen, „erfolgreich“ ein paar Artikel geschrieben und einige sonstige Änderungen vorgenommen haben. Das ist aber ein Trugschluß.

– Schnargel 21:23, 26. Jul 2006 (CEST)

nicht mitdrucken (erl)

Wie wäre eine 2. class (man könnte auch BoxenVerschmelzen, wie schon erwähnt per js ablösen) für Navigationsleisten im Hilfe & Wikipedia Namensraum? Da die jetzige .NavFrame diese Angaben: text-align: center; font-size: 95%; zuviel hat. (Bsp.) -- Ολλίμίνατορέ 10:59, 21. Mai 2006 (CEST)

Hätt ja mal jemand sagen könne, dass die Druckansicht in der commonPrint.css definiert wird :-p. Dort gibt es z.B auch die class.noprint. -- Ολλίμίνατορέ 17:07, 28. Mai 2006 (CEST)

Taxobox/Townbox/Paläobox

Könnten wir mal analog der englischen Wikipedia dieses Chaos an einzelnen Boxen beseitigen und einige wenigere generischere Klassen einführen, etwa eine allgemeine Infobox-Class? (Siehe englische MediaWiki:Commons.css). Die Sidebox ist schon nicht schlecht, aber leider überdefiniert, Werte wie width sollten eher in die Vorlage. Hawkes 15:57, 16. Jun 2006 (CEST)

Ich wäre ebenfalls dafür, hier für Ordnung zu sorgen. Zum Beispiel können die Townbox-Angaben meines Wissens ersatzlos gelöscht werden. Ehe man hier etwas ändert, wäre es jedoch wichtig, zuerst ein wichtiges Detail zu besprechen: Die Einleitung soll im Quelltext vor der jeweiligen Infobox stehen, so dass zum Beispiel Screenreader zuerst die Einleitung vorlesen. Das taucht als Frage regelmäßig bei WP:FZW und in anderen Diskussionen auf. --TM 00:09, 8. Aug. 2007 (CEST)

Ich habe mich detailliert mit diesem Problem beschäftigt und festgestellt, dass das mit reinem CSS unmöglich ist. Die Infobox muss im Artikelquelltext zwingend am Anfang stehen. Es existieren allerdings Wege, dieses Problem per JavaScript zu umgehen. Was den Wunsch nach weniger generischen Klassen angeht, denke ich, dass wir mit prettytable alias wikitable und float-right schon gut ausgestattet sind. --TM 10:29, 23. Aug. 2007 (CEST)

Eine eigene CSS-Klasse infobox für Infoboxen hätte gegenüber prettytable den Vorteil, dass die Probleme von prettytable mit den vererbten Eigenschaften auf td und th weggelassen werden könnten. Die infobox-Klasse von en:MediaWiki:Common.css sieht sinnvoll aus. --Fomafix 12:37, 23. Aug. 2007 (CEST)

.NavPic (Bild in Navigationleiste)

Warum ist der Hintergrund weiß? Das sieht komisch aus --MarianSigler {bla} {+-} 19:45, 7. Jul 2006 (CEST)

chrislb hat meine diesbezügliche Frage auf WP:FZW so beantwortet:

div.NavPic {
   background-color: #ffffff;
   margin: 0px;
   padding: 2px;
   float: left;
}

in MediaWiki:Common.css. Damit wird der Hintergrund des Bildes auf weiß gesetzt.

--Leyo 19:23, 29. Mär. 2007 (CEST)

Abstand vor Navigationsleisten

Es werden immer wieder doppelte Leerzeilen vor Navigationsleisten eingefügt, um durch ein hässliches <p><br /></p> einen Abstand zu erzeugen. Diese mehrfachen Leerzeilen werden manchmal in die Navigationsleistenvorlage selbst und manchmal in die Artikel gesetzt.

Eine saubere Lösung dagegen wurde hier Vorgeschlagen. Ich bin unabhängig davon auf die gleiche Lösung gekommen und habe dieses mit mehreren Browsern ausprobiert.

Bitte folgenden Code aufnehmen/integrieren:

/* Abstand vor Navigationsleisten */
div.BoxenVerschmelzen,
div.NavFrame {
  margin-top: 1.5em;
}
div.BoxenVerschmelzen div.NavFrame {
  margin-top: 0;
}
div.NavFrame + div.NavFrame {
  margin-top: 0;
}

Durch diesen Abstand wird so manches ständiges Hin und Her von zusätzlichen Leerzeilen beendet. --Fomafix 11:55, 13. Jul 2006 (CEST)

Sehr dafür! Die am Fließtext klebenden Navileisten sind ein Krampf (und die dafür eingefügten Leerzeilen ebenso). — ^PDD — 12:33, 13. Jul 2006 (CEST)

 Pro Ich habe diese Idee hier schon einmal ausführlich begründet und würde mich sehr freuen, wenn man sie zentral umsetzen könnte. --TM 15:19, 13. Jul 2006 (CEST)

So, ich war mal mutig und habe den Vorschlag eingebaut. Bei mir im FF 2.0 beta 1 sieht es gut aus. --Raymond ^Disk. 18:36, 13. Jul 2006 (CEST)

Ich hatte das wie gesagt schon einmal ausführlich mit etlichen Webbrowsern getestet und kann auch jetzt kein Problem erkennen. Ausnahmen: 1. Dort, wo doppelte Leerzeilen oder andere Platzhalter-Konstrukte eingefügt wurden, sind jetzt sehr große Abstände entstanden. Lösung: Die überzählige Leerzeile aus dem Artikeln entfernen. 2. IE-Nutzer sehen bei nicht verschmolzenen mehrfachen Navigationsleisten einen Abstand zwischen den Leisten. Lösung: Die Boxen verschmelzen. Des weiteren möchte ich vorschlagen, die neuen CSS-Anweisungen in die bereits vorhandenen einzubauen, wie hier schon dargestellt. Das spart ein paar Bytes, die bei einer solchen Datei, die jeder herunterlädt, wirklich von Bedeutung sein können. --TM 23:29, 14. Jul 2006 (CEST)

Wenn ich nun aber den Hintergrund der NLeiste ändern möchte, z. B. über

<div style="background:white;">
{{Navigationsleiste|TITEL=Titel|INHALT=Inhalt}}
</div>

ist auch der Hintergrund oberhalb des Rahmens weiß. Gibt es hierfür dann eine Lösung? -- @xqt 14:24, 13. Okt. 2007 (CEST)

Aus welchem Grund sollte die Hintergrundfarbe geändert werden? Kannst Du ein Beispiel nennen? Die normale Hintergrundfarbe von Artikeln ist bereits weiß. --Fomafix 15:12, 13. Okt. 2007 (CEST)

Wenn ich diese z.B. in meiner Diskussionsseite einbauen will -- @xqt 15:37, 13. Okt. 2007 (CEST)

Probiere folgendes:

<div class="NavFrame" style="background-color:white; float:right; width:10em;">
<div class="NavHead">Titel</div>
<div class="NavContent">
Inhalt
</div>
<div class="NavEnd"> </div>
</div>

Dabei kannst Du Dir auch den Abstand vor der Navigationsleiste überschreiben und damit entfernen. --Fomafix 16:09, 13. Okt. 2007 (CEST)

Wäre halt schön gewesen man hätte die vorhandene Vorlage verwenden können. So muß ich's halt einzeln aufdröseln. Hat aber gegenüber einer starren Tabelle immerhin das goodie, daß der Klappmechanismus funktioniert. Also danke freundlichst für den Tip. -- @xqt 16:17, 13. Okt. 2007 (CEST)

Gallery

Hallo,
die einzelnen Bilder in den Galerien werden außen mit einem weißen Rahmen umrandet. Ich würde es schöner finden wenn diese Umrandung die gleiche Farbe hätte wie die Hintergrundfarbe der Gallery. Ich habe dazu in meiner monobook.css folgenden Code ergänzt:

table.gallery {
  background-color: #F9F9F9;
}
table.gallery td {
  border-color: #F9F9F9;
}

Meinungen dazu? -- San Jose 13:50, 15. Jul 2006 (CEST)

Vielleicht sollte das auf MediaWiki Diskussion:Monobook.css diskutiert werden. Änderungen hier müssen auch für Skins die blaue Schrift auf gelbem Hintergrund darstellen gültig sein. – Schnargel 23:55, 22. Jul 2006 (CEST)

Ohh Stimmt, Monobook.css ist der bessere Diskussionsort. -- San Jose 13:55, 23. Jul 2006 (CEST)

Absolute Positionierungen

Wer weiterhin solchen Spielkram wie absolute Positionierungen von Vorlagen oder anderen Seitenelementen einbauen oder aufrechterhalten will beachte bitte, dass

• um sie allgemein und für jeden sichtbar zu machen solche Dinge für jede Skin separat definiert werden müssen (was spätestens für benutzerdefinierte Skins unmöglich ist)
• aus diesem Grunde die Grundeinstellung für solche Elemente „display: none“ sein muss, was in der Vorlage im umgebenden div- oder span-Tag oder in Common.css erfolgen kann
• die Sichtbarkeit dieser Elemente in den entsprechenden Skin-Dateien dort wo die Positionierung stattfindet dann mit „display: block“ bzw. „display: inline“ wieder hergestellt wird.

Wer nicht weiß, wovon hier die Rede ist möge bitte die Finger davon lassen. – Schnargel 20:40, 22. Jul 2006 (CEST)

Neue Klassen!

Ich bin der Meinung, man sollte noch zumindest 2 neue Klassen einfügen: Infoboxen und Kalendernavigation. Momentan sehen nämlich sehr viele Infoboxen sehr uneinheitlich aus und auch die Anpassung ist aufgrund der Anzahl sehr kompliziert und so könnte man Änderungen direkt übernehmen. Ausserdem werden momentan in alle reformierten Kalendernavigationsvorlagen eine Vorlage namens Kalenderstil eingebaut, die man doch direkt in das Stylesheet integrieren könnte, im Stil von Navigationsleisten...
Eiragorn ^{Let's talk about... Veni, Vidi, Vomui} 16:39, 9. Aug 2006 (CEST)

... für Infoboxen

Zur Zeit gibt es neben einer SideBox Definitionen für Taxoboxen und (völlig unsinnigerweise) die fast gleichen Definitionen noch einmal für Paläoboxen. Diese Definitionen können selbstverständlich von jeder anderen Infobox mitbenutzt werden. Das Problem der Uneinheitlichkeit liegt aber zunächst im Fehlen einer einheitlichen Box-Vorlage, die von den einzelnen Vorlagen verwendet werden müsste, um ein gleichmäßigeres Erscheinungsbild zu erzielen. Die Lösung ist, ähnlich der Vorlage:Navigationsleiste eine universelle Infobox-Vorlage zu erstellen, die dann von den einzelnen Boxen benutzt wird. Dass sich für die Navigationsleistenvorlage Definitionen hier in Common.css befinden liegt mehr daran, dass dadurch das „Verschmelzen“ aufeinanderfolgender Navigationsleisten möglich ist, als dass es nötig wäre, Definitionen, die die Farben, Schriftstile oder ähnliches betreffen nicht gleich direkt in der Vorlage zu definieren.

Für ein einheitliches Aussehen der Infoboxen wäre es also zunächst nötig, etwas wie eine Unibox zu entwerfen, die entsprechend eingebunden wird. Danach kann man sehen, wo es Sinn macht und nötig wäre, hier entsprechende Definitionen einzubauen. Trivialdefinitionen wie „table.taxobox td.taxo-bild { text-align:center; }“ legt man besser in der Vorlage fest. – Schnargel 05:40, 11. Aug 2006 (CEST)

... für Kalendernavigation

Die Kalenderstil-Definitionen sind in Vorlage:Kalenderstil gut aufgehoben. Sie werden in einer Handvoll sich ähnlicher Vorlagen verwendet und sind auf diese Weise bequem und einfach zusammengefasst. Eine Denkweise, dass man solche Dinge „doch direkt in das Stylesheet integrieren könnte“ ergibt sich vielleicht daraus, dass man Stylesheets für das letzte und höchste Maß aller Dinge hält, das sind sie aber nicht. Definitionen für tausende und gut abgegrenzte Kalenderseiten für hunderttausende Wikipedia-Seiten mitzuschleppen ist nicht effizient. Im Gegenteil: Sachen wie „align="center"“, die sich in hundert Jahren nicht ändern werden, sind besser in den einzelnen Kalenderleistenvorlagen aufgehoben und in der Vorlage:Kalenderstil sollte man die existierenden CSS-Definitionen für die Farben benutzen und etwas wie „class="hintergrundfarbe1 rahmenfarbe1"“ anstatt der direkten Farbangaben schreiben, denn das ist, wo Stylesheets Sinn machen, und nicht um einen Absatz über drei Ecken zentriert darzustellen. – Schnargel 05:40, 11. Aug 2006 (CEST)

Grafikfehler: Überschriften ragen in float-Elemente rein

Siehe: http://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&oldid=20990412

Beheben lässt sich dieses Problem, in dem man

clear: right;

in die Style-Definition der Überschriften hinzufügt.

--Martin von Wittich 23:38, 2. Sep 2006 (CEST)

Es ist durchaus gewollt, dass floatende Elemente über nächsten die Überschrift hinausragen. Wenn h2 ein clear: right; bekommt, dann ist so etwas wie bei Bundesautobahn 7 nicht mehr möglich. --Fomafix 17:24, 4. Sep 2006 (CEST)

Sollte so etwas mal unterbunden werden, so kann das mit {{Absatz}} erreicht werden. --Fomafix 17:29, 4. Sep 2006 (CEST)

OK, das hatte ich natürlich nicht bedacht. Danke für den Hinweis! --Martin von Wittich 17:18, 7. Sep 2006 (CEST)

Test

Bla Bla Bla

Test

Bla Bla Bla

Fonts

Da man dem IE6 nachhelfen muss, Fonts zu finden, gibt es im enwiki Stylesheet Support dafür (Abschnitt: Support for Template:IPA, Template:Unicode and Template:Polytonic. The inherit declaration resets the font for all browsers except MSIE6).

Können wir dies nicht übernehmen?

Man sollte das m.E. nicht direkt ins Template zu schreiben, da dann die Fontlisten für alle Browser gelten.

Pjacobi 13:09, 2. Okt 2006 (CEST)

Dadurch können auch die Templates, die z.Zt. Font-Listen beinhalten, z.B. Vorlage:IPA (vergl en:Template:IPA) von diesen befreit werden. --Pjacobi 19:27, 4. Okt 2006 (CEST)

Genau, ich bin sehr dafür. Christoph Päper 13:15, 5. Okt 2006 (CEST)

Ich auch! -- marilyn.hanson 23:26, 13. Okt. 2006 (CEST)

Das verschlimmert aber eher das Bild bei Benutzern vernünftiger Browser mit deren installierten Zeichensätzen. Annahmen über das vorhandensein von Nicht-Standard-Zeichensätzen sind im allgemeinen schlecht und wer einen standardkonformen Browser benutzt sollte nicht durch solche workarounds negativ belastet werden. – Wenn überhaupt, sollte so eine „Anpassung“ mit einer dieser unglücklichen Browser-Weichen eingabaut werden, wie die IExxFixes.css-Reparaturen. – Schnargel 13:58, 19. Okt. 2006 (CEST)

Wenn ich Pjacobi richtig verstehe, dann plädiert er nur für das Verschieben in die common.css, da die Fontangaben bisher in den Vorlagen stehen. Sollte dies der Fall sein, dann stimme ich zu, da mE Style-Angaben nichts in einzelnen Bausteinen zu suchen haben. Dies hat die Wikipedia bisher aber nicht begriffen hat und somit herrscht ein sylistischer Wildwuchs, der das Corporate Design der Wikipedia untergräbt.

Das Sammeln der IE-spezifischen Fonts hier macht das spätere Entfernen einfacher. Siehe auch mein Kommentar auf Vorlage Diskussion:Polytonisch#Kennzeichnung dieser Vorlage als veraltet.. Der Vorlage IPA wird wohl auch nach der Verbesserung des IE eine meta-Aufgabe zukommen. Die Vorlage Unicode kann allerdings irgendwann entfallen. --chrislb 问题 15:08, 19. Okt. 2006 (CEST)

Ich würds ja lieber sehen, dass IE-Benutzer das bei sich (meinetwegen auch in einem kleinen Stylesheet) entsprechend einstellen, da eine feste Vorgabe einer Fontreihenfolge wahrscheinlich meine (und aller) Reihenfolge durcheinanderbringt, möglicherweise meine Standardfonts nach hinten schiebt und (für mich) weniger ansehnlichen den Vorzug gibt. Denn mit einer solchen Vorgabe wird ja nicht nur eine Auswahlmöglichkeit sondern auch eine Reihenfolge vorgegeben. – Ich würde auch darauf wetten, dass die Mehrzahl der IE-Benutzer mit Problemen auch gar keinen entsprechenden Zeichensatz installiert hat, denen würde dann eine Vorgabe hier auch nichts nützen und dass viele, die die entsprechende Zeichensätze installiert haben, ihren Browser auch bereits entsprechend eingerichtet haben und dann hier keine Vorgabe mehr brauchen.

Ich vermute also, dass der Anteil der IE-Benutzer mit passendem Font und unvollkommener Browsereinrichtung sehr klein ist und denke, dass da Hilfe zur Selbsthilfe eher angebracht ist als eine Vorgabe, die weitaus mehr gut funktionierende Systeme beeinflusst. Klagen über nicht richtig dargestellte Zeichen sind auch sehr selten geworden. – Schnargel 17:15, 19. Okt. 2006 (CEST)

Nachtrag:

Ich sehe erst jetzt, dass „font-family /**/:inherit;“ den Effekt für andere Browser zurücksetzen soll. Das wäre dann natürlich etwas anderes, auch wenn es nach einem unsauberen Trick aussieht. Dennoch vermute ich, dass ein Nutzen nur für wenige entstehen würde. – Schnargel 17:24, 19. Okt. 2006 (CEST)

Um jetzt diese Diskussion nicht in den Sand zu setzen, müsstest du sie auf die einzelnen Vorlagen ausdehnen, damit auch andere mitlesen. Wir sollen so oder so einen Kompromiss finden und wenn wir diese Schriftdefinitionen behalten, dann sollten sie hierhin. --chrislb 问题 19:36, 19. Okt. 2006 (CEST)

Eine gute Lösung statt einen Kompromiss zu finden wäre mir ja lieber ;-) – Aber weitere Meinungen könnten jetzt in der Tat nützlich sein und hanz so eilig ist’s ja zum Glück nicht. Wenn ich das richtig sehe, sind das jetzt die Vorlagen Lang, Polytonisch und Unicode. Am schnellsten bekäme man die Leute zusammen, wenn man die Vorlagen ausschaltet und einen entsprechenden Hinweis auf die Diskussionsseite setzt. Aber vielleicht merkts so schnell auch keiner. Interessant wären für mich realistische Schätzungen, wie viele „Betroffene“ es gibt, denen eine solche Vorgabe wirklich als Workaround dient (s. o.) denn warum sollte, wer sich schon damit abgibt so einen Font herunterzuladen, nicht auch gleich den Browser damit einrichten ... – Schnargel 00:36, 20. Okt. 2006 (CEST)

Ich finde, dass ein größerer Test eigentlich unnötig ist, da die vorgeschlagene Änderung auf en: schon längere Zeit im Einsatz ist. Aufgefallen ist der Unterschied Parvati bei der Herübernahme der Vorlage:IAST aus Template:IAST.

Ich befürchte wirklich, dass es für den MSIE6 keine andere Lösung gibt als explizite Font-Vorgaben, wenn auf einer Seite Zeichen aus verschiedenen Schriftsystemen vorkommen. Und damit darunter die anderen Browser nicht leiden, muss das in der Common.css passieren, mit dem CSS-Trick „font-family /**/:inherit;“. --Pjacobi 19:50, 20. Okt. 2006 (CEST)

Ab Anfang November soll der IE7 automatisch verteilt werden. Otto-Normaluser wird ihn auf jeden Fall erhalten, bevor groß was geändert wird, sollte das vorher noch mit dem IE7 ausprobiert werden. Entweder hat sich das Problem dann erledigt oder muss angepasst werden. --Raymond ^{Disk. Bew.} 20:52, 20. Okt. 2006 (CEST)

Noch besser fände ich es, wenn standardmäßig eine Schrift eingestellt wäre, die Vorlagen wie die schon erwähnte Vorlage:IAST überflüssig machen würden. Das Einfügen von Vorlagen bei jedem einzelnen Wort in bereits erstellte Artikel ist sehr viel Arbeit. Warum als Standardschrift nicht gleich Arial Unicode MS einstellen? Dann gäbe es das Problem nicht. --Parvati 22:41, 20. Okt. 2006 (CEST)

Gegen die AUMS als Standardschriftart spricht einiges: sie belegt viel Speicher, es gibt sie nur in einem Schnitt und sie ist nicht besonders ansehnlich/leserlich. Christoph Päper 23:39, 21. Okt. 2006 (CEST)

Nach dem, was in der aktuellen c’t (Heft 22) steht, funktioniert der /**/-Trick im IE 7 nicht mehr. Vielleicht kann ein IE-Liebhaber mal ausprobieren, wie es jetzt mit der Zeichensatzauswahl steht und hier berichten. – Schnargel 20:38, 22. Okt. 2006 (CEST)

Fonts vorschreiben

Es kommen immer wieder Einwände erfahrener Mitarbeiter, die dem Festlegen von Schriften wiedersprechen. Zur Zeit schreiben wir für einige Vorlagen Schriften vor, was evtl in absehbarer Zeit geändert werden soll, und MediaWiki selbst scheint eine Schriftart zu definieren. Letzteres kann ich nicht exakt nachprüfen, nur finde ich einerseits keine Einträge dazu in common.css und Monobook.css, kann dafür aber meine Schriftarten für meinen Browser ändern wie ich will, doch bleibt hier immer die gleiche Schrift eingestellt.

Diese Vorbetrachtung ist nötig für folgende Frage: a) Wenn wir fest Schriftarten vorgeben, bleibt eine Möglichkeit für angemeldete Benutzer diese Einstellungen im eigene Style zu überschreiben? b) Kann man sogar auf die von mir postulierte MediaWiki-Schrift zurückfallen? Die Beantwortungen dieser Fragen ist wichtig im Bezug auf Änderungen die ich demnächst für einige dieser Vorlagen plane, ich hoffe mir kann hier jemand weiterhelfen. --chrislb 问题 14:51, 23. Okt. 2006 (CEST)

Die Schriftarten und überhaupt das ganze Aussehen der Skins sind in den Haupt-CSS-Skin-Dateien der Mediawiki Software für jede (existierende und zukünftige) Skin vorgegeben. Alles was in den MediaWiki-CSS- oder persönlichen CSS-Dateien angegeben wird dient nur dazu, diese Vorgaben zu ändern oder zu erweitern.

• Für Änderungen gilt, dass diese möglicherweise weniger kompatibel zu Browsern oder künftigen Versionen der MediaWiki-Software sind; dabei sind auch die Verschiedenheiten der Skins zu betrachten: Beispielsweise kann eine Skin einen serifenlosen Zeichensatz verwenden, eine andere eine Schrift mit Serifen. Wenn eine Änderung in Common.css jetzt für Tabellen eine feste Schrift vorgäbe, könnte die nur entweder Serifen haben oder nicht und damit das Schriftbild in Skins mit anderer Schrift verschlechtern.
• Für Erweiterungen gilt, dass sie, sofern sie unabhängig von existierenden oder zukünftigen Skin-Definitionen sind und nicht das Aussehen der Seite sondern die Formatierung von Seiteninhalten betreffen möglich sind. Das sind beispielsweise die Navigationsleisten mit ihrer Verschmelzung oder die Taxoboxen. Wie man solche Erweiterungen nicht nur syntaktisch sondern auch sinnvoll formuliert ist allerdings nicht immer einfach.

Die Frage, ob angemeldete Benutzer irgendwelche Änderungen in eigenen Style-Dateien wieder rückgängig machen können ist für mich hier alles andere als relevant, da es überhaupt nicht darum geht, den vermutlich weniger als 100 Technikenthusiasten, die mit ihrem monobook.css jonglieren sauber aussehende Seiten anzubieten, sondern der großen Masse der (angemeldeten und unangemeldeten) Benutzer.

Eine halbwegs „saubere“ Vorgabe von Schriftarten für IE-Benutzer wäre nur in den IE-Fix-Dateien der MediaWiki-Software möglich, aber die Antwort der Entwickler auf eine entsprechende Anfrage wäre höchstwahrscheinlich, dass die Auswahl, Einrichtung und Wartung von Software inklusive Webbrowsern immer in der Verantwortung des Endbenutzers liegt. Ich schließe mich dem sehr gerne an und denke, dass Hilfe zur Selbsthilfe mehr bringt, als ein Flicken an Symptomen.

Ich gehe davon aus, dass zumindest in der kommenden Version des IE möglich ist, den Browser so einzustellen, dass eine Darstellung verschiedener Schriften automatisch erfolgt. Daher nochmal:

1. Ich halte die Anzahl der IE-Benutzer, die überhaupt keinen (passenden) Unicode-Zeichesatz installiert haben für groß gegenüber denjenigen die es haben. Diesen nützen diese ganzen Mini-Vorlagen und eine Zeichensatzvorgabe nichts.
2. Bei den IE-Benutzern, die selbst aktiv waren und entsprechenden Zeichensätze installiert haben halte ich es für wahrscheinlich, dass ein großer Anteil den Browser dann auch „richtig“ eingerichtet hat (auch wenn es heißt für jedes Schriftsystem einen passenden Zeichensatz einzustellen).

Bleiben dann nur noch diejenigen mit einem installierten Unicode-Zeichensatz der nicht gefunden wird, deren Anzahl ich im Vergleich für sehr gering einschätze.

Solche Fontlisten in Vorlagen oder hier in Common.css einzufügen ist schnell getan, aber oft nur weil es machbar ist und auf den ersten Blick funktioniert und dann nicht weiter hinterfragt wird. Aber ob es auch gut so ist, ist eine andere Frage. Auch wenn eine entsprechende Definition in Common.css besser ist als in den Vorlagen, lässt man damit auch die Datei wieder wachsen und auch jeden diese Definitionen in den Browser-Cache nehmen, der nur mal eine von den 99,99 % Wikipedia-Seiten besucht, für die diese Definitionen irrelevant sind. Und wenn es dann dazu kommt, müssen auch alle gut funktionierenden Systeme erst einmal eine Liste von zehn Zeichensätzen einlesen und dann mit der Browserweiche wieder überspringen.

Ich denke auch, dass die Notwendigkeit eines Handlungsbedarfs hier leicht überschätzt wird

1. weil es eben machbar ist und es schick ist, anderen mit computertechnischem Wissen auszuhelfen
2. weil andere (en) es auch machen
3. weil es vorher auch schon so war

Um aus den tausenden von Vorlagen im Text nicht hunderttausende werden zu lassen und um vor allem auch den Benutzern (IE oder nicht) zu helfen, die gar keinen entsprechenden Zeichensatz installiert haben (und das dürften wie gesagt weitaus mehr sein), halte ich es für deutlich sinnvoller, auf diese Vorlagen zu verzichten und den in diesem Sinne problematischen Artikeln einfach einen kleinen Textkasten wie

Dieser Artikel enthält Zeichen, die nicht in allen Schriftarten verfügbar sind. Bei Darstellungsproblemen bitte Hilfe:Zeichendarstellung beachten

voranzustellen. In vielen Artikeln mit „Sonderzeichen“ ging und geht es bis jetzt auch ohne solche Vorlagen und ich warte immer noch darauf, dass jemand mal zeigt, wo denn haufenweise Anfragen wegen irgendwelcher Kästchen im Text sind.

In dem Sinne bin ich dafür, diese Vorlagen langsam abzubauen und, wo notwendig, einen entsprechenden Hinweis zu geben, damit er dann irgendwann einmal überflüssig ist. – Schnargel 03:52, 25. Okt. 2006 (CEST)

Deine Schätzungen und Mutmaßungen in Ehren, aber sie sind durch nichts belegt. Außer http://codestyle.org/css/font-family/sampler-CombinedResults.shtml kenne ich allerdings auch keine Untersuchungen zur Fontverbreitung und dort findet sich zwar Lucida Sans Unicode, aber sonst keine der Allround-Schriftarten (wie AUMS, das AFAIK in jedem MS Office enthalten ist). Die Anzahl derer, die sich die Mühe macht, dem IE vorzugeben, welche Schriftart er für welches Schriftsystem verwenden soll, schätze ich anders als Du als sehr gering ein – sowohl gegenüber der Allgemeinheit als auch gegenüber denen, die bewusst Schriften oder Büropakete (samt Schriften) installieren. Du überschätzt hingegen den Aufwand des CSS-Parsens maßlos, insbesondere von ohnehin ignorierten Anweisungen. Es gab bereits Vorlagen mit Hinweistexten wie Du sie vorschlägst, aber die wurden (zumindest überwiegend) gelöscht (siehe z.B. Wikipedia:Löschkandidaten/25._Mai_2006#Vorlage:Sonderzeichen(Gelöscht)). Christoph Päper 22:13, 25. Okt. 2006 (CEST)

Schön, dann sind da anderer Meinung. Ich glaube nicht, dass ich da etwas „maßlos“ überschätze, das ist wohl Deine persönliche Meinung. Ich erwähne aber für Dich gerne kurz, dass es bei der zweizeiligen, oben angedachten Lösung nicht so ist, wie Du behauptest, dass (eine oder beide) Anweisungen „ohnehin ignoriert“ werden. Es wird vielmehr die erste Zeile von IE und anderen Browsern ausgewertet und dann die zweite gelesen, wobei der IE dort wegen eines Programmierfehlers abbricht und andere die erste Definition überschreiben. – Schnargel 01:30, 26. Okt. 2006 (CEST)

Das wird einmal geparst, aber zigmal angewendet, so dass die Zeit für das Parsen mit steigender Elementzahl gegen bedeutungslos tendiert. (Inwiefern das Parse-Ergebnis eines Stylesheets seitenübergreifend gecacht wird, weiß ich nicht, aber das würde die zeitliche Bedeutung dieser theoretisch unnötigen Anweisungen, die ohnehin im Mikro- und nicht Millisekundenbereich liegt, noch weiter herabsetzen.) Christoph Päper 00:52, 27. Okt. 2006 (CEST)

Ich halte *garnichts* von diesen Hinweisbausteinen. Ich lösche auch diese selbst verfassten Abschnitte aus den Artikel raus, denn sie haben nichts im Artikel zu suchen. Es ist relativ intuitiv dass da irgendwelche Zeichen sind, die der eigene Rechner nicht darstellen kann, wenn man auch vorher noch nicht "fremde" Schriftzeichen zu Gesicht bekommen hat. Es wird in den meisten Artikel hingewiesen, was da folgt. So steht dort meist soetwas wie "chin." und erst dann folgen die Zeichen. Wir haben mehr Artikel in der Wikipedia mit Sonderzeichen, als ich in meinem Leben lesen kann. Da überall einen Baustein reinzuhauen halte ich für sinnlos. Warten wir einfach auf IE7 und hoffen, dass es sich von alleine löst. Ich will nicht für die Ewigkeit Benutzer darauf hinweisen, dass ihr Computer möglicherweise diese Schrift nicht hat, dass sollte der Browser übernehmen, so wie das andere schön können. --chrislb 问题 23:19, 25. Okt. 2006 (CEST)

Einen solchen Baustein finde ich auch nicht schön, aber besser als diesen Wildwuchs von Vorlagen, der nicht kontrollierbar scheint. Eine Einigung auf die alleinige Verwendung eines Generalhinweises hätte den Vorteil, dass die Verwendung überschau- und kontrollierbar wäre. Die Einführung immer weiterer Hilfsvorlagen wie zuletzt Vorlage:IAST vergrößert nur das Chaos. Aber vielleicht hast Du ja eine Idee, wie man das kontrollieren kann. Ansonsten würde ich auch gerne Meinungen anderer kennenlernen.

Auf IE 7 braucht keiner mehr zu warten, er ist bereits erhältlich. – Schnargel 01:30, 26. Okt. 2006 (CEST)

Aber noch als Beta, oder? Dann würde mich mal interessieren was der kann, bin aber zu faul jetzt zu googlen. IAST ist von der Grundidee krank, aber ich habe sie etwas erweitert, so dass sie jetzt zumindest auch einen semantischen Grund hat. Ich hoffe noch, dass die ISO 15924 irgendwann mal eine Auszeichnung für Romanisierungen bekommt (andere als nur -Latn), und so kann ich mit der IAST darauf warten. --chrislb 问题 10:13, 27. Okt. 2006 (CEST)

Immerhin als RC1, also keine Änderungen mehr. Ich wünsche mir als erstes, dass sich solche Vorlagen nicht noch weiter verbreiten. – Schnargel 01:02, 28. Okt. 2006 (CEST)

Und ich wünsche mir, dass solche Vorlagen überflüssig wären. Es macht nämlich keinen Spaß das überall nachträglich einzufügen. Das ist nämlich eine Heidenarbeit. --Parvati 16:22, 28. Okt. 2006 (CEST)

Sind sie ja auch. – Schnargel 02:41, 31. Okt. 2006 (CET)

Übrigens ist es keine Lösung, ganz auf Firefox zu setzen. Firefox stellt bei dem gegenwärtig verwendeten Font die indische Schrift Devanagari als Fragezeichen dar. Siehe: Dasahra. Die IAST-Vorlage (die ich hier probeweise mal bei einem Wort eingefügt habe) würde auch hier die Funktion erfüllen, die Schrift korrekt darzustellen (vorausgesetzt man hat den erforderlichen Font installiert). Aber anscheinend ist es den erfahrenen Usern völlig egal, was der Normaluser sieht.--Parvati 15:08, 29. Okt. 2006 (CET)

Deine kurzzeitig eingefügte Vorlage hat bei mir ganz unleserliche Fonts kreiert. Bitte seinlassen und Jeden, der die Zeichen sehen will, eine eigene Möglichkeit suchen lassen, anstatt bereits bestehende Einstellungen bei interessierten Nutzern unkontrollierbar zu manipulieren.--Xquenda 10:00, 30. Okt. 2006 (CET)

Mein Firefox (1.8.0.7) stellt es ohne IAST richtig dar. Ich habe deinen Test dann wieder revertiert. Wer ihn noch braucht, kann in die Versionsgeschichte gehen (die Vorlage:IAST ist nur für die Romanisierung IAST gedacht). --chrislb 问题 16:33, 29. Okt. 2006 (CET)

Mein Firefox (2.0.) eben leider nicht. Könnte es vom Betriebssystem abhängen? (in meinem Fall Windows ME). Bevor man eine neue Vorlage kreiiert, die auch nur dasselbe macht wie die IAST-Vorlage könnte man die ja auch für Devanagari einsetzen. --Parvati 16:52, 29. Okt. 2006 (CET)

Die Vorlage hat aber auch einen anderen Sinn, nicht nur die Schriftdarstellung! --chrislb 问题 22:38, 29. Okt. 2006 (CET)

Wie ich bereits sagte: Die Leute brauchen Hilfe, ihre Browser richtig einzurichten und keine Flickvorlagen. Der Durchschnittsbenutzer macht auch den Browser verantwortlich wenn Fonts fehlen und die Integration dieses ganzen Halbwissens verschlimmert höchstens die Sache für diejenigen mit richtig funktionierenden/konfigurierten Zeichensätzen/Browsern/Betriebssystemen. – Schnargel 02:41, 31. Okt. 2006 (CET)

Noch einmal:

• Die Lösung ist auf en: seit Monaten bewährt
• Es sollen keine neuen expliziten Fontangaben erzeugt werden, sondern bisher in Templates existierende auf die technisch bessere Lösung migriert werden.

Pjacobi 21:10, 6. Nov. 2006 (CET)

Noch einmal:

• Der Trick mit „font-family /**/:inherit;“ funktioniert für IE 7 nicht.
• Es ist nicht fürchterlich Sinnvoll die technisch bessere Lösung gerade jetzt einzuführen, da sie dann in Kürze für noch weniger Leute funktioniert, wenn IE 7 jetzt als Auto-Update verteilt wird.

Schnargel 22:11, 6. Nov. 2006 (CET)

Was ist denn das IE7-Verhalten? Das ist mir aus der obigen Diskusssion nicht klar geworden? --Pjacobi 22:48, 6. Nov. 2006 (CET)

Außer dem Hinweis, dass obiger Trick nicht mehr geht hat hier noch niemand direkt über das Verhalten bezüglich der Zeichensatzauswahl berichtet. Ich hielte eine Lösung in common.css auch für besser (aber lange nicht für gut), als die Vorgaben in den Vorlagen, aber der Zeitpunkt, wo Milliarden Wikipedia-Leser ihren Browser updaten ist kein guter Moment für eine Änderung. – Schnargel 01:40, 7. Nov. 2006 (CET)

Dann will ich die Diskussion mal wieder wachrütteln. Laut en:Internet_Explorer_7#Release_history scheint es beim IE7 in Sachen Sonderzeichen nur Verbesserungen in Hinsicht auf URLs zu geben. (Dafür aber Tabbed Browsing, womit der technische Stand von 1996 erreicht wäre, Wahnsinn!) Kann das jemand bestätigen? Und wie sieht es mit dem Funktionieren der erwähnten oder einer anderen Pseudo-Weiche aus? Falls eine solche existiert, könnte man sie wenigstens in die Vorlagen einbinden? Ich habe mich in letzter Zeit ein wenig mit der Vorlage:Unicode beschäftigt. Bis vor kurzem war dort Titus Cyberbit als erste Schriftart eingestellt, die zwar für die Vorlage:Zeichen (die die Vorlage:Unicode verwendete) eine gute Lösung ist, aber auf der Schriftgröße, auf der zumindest ich normalen Text habe, praktisch unlesbar war. Dann habe ich einige lesbare, aber weniger umfassendere Schriftarten nach vorne gestellt, was dann Probleme zumindest beim IE6 verursachte. Und mal abgesehen davon sollten ja überhaupt keine Schriften vorgeschrieben werden. Soll man die alte Lösung weiterbetreiben, eine neue einführen oder die IE-Benutzer selber sehen lassen, dass Microsoft mit dem Problem fertig wird? Achja, es gab hier einen Vermittlungsausschuss zu einem verwandten Thema.--Wrzlprmft 14:56, 16. Mär. 2007 (CET)

Darstellung der Fußnoten

Folgende Ergänzung von Benutzer:Threedots letzer Änderung bezüglich der Reference-Formatierungen führte bei mir zu gleichmäßigem Zeilenabstand unabhängig davon, ob eine Fußnote dargestellt wird oder nicht. Gleichzeitig wurde die Fußnotenziffer leicht hochgestellt:

sup.reference { font-size:0.8em; }
sup.reference { vertical-align:top; }

Getestete Browser

• Internet Explorer 6.0
• Opera 9.02

Falls es auch für andere Browser funktioniert schlage ich die Einarbeitung in commons.css vor. (Vergleiche auch die Erörterungen unter [1]) --Hei_ber 22:04, 11. Okt. 2006 (CEST)

Im Safari und FF führt {line-height:100%;} zum gewünschten Ergebnis. die Änderung von heute (nur vertical-align:top;) führte in Safari und Opera (PC) zu Fußnoten, die auf der Mittellinie lagen, also weder hoch- noch tiefgestellt waren, ziemlich unschön. --elya 22:15, 11. Okt. 2006 (CEST)

P.S. OK, jetzt hab ich auch die verlinkte Disk gesehen ,-) - ich würd's einfach mal einbauen, viel kann ja nicht passieren. --elya 22:17, 11. Okt. 2006 (CEST)

(BK) Danke für die Antwort! Ich vermute, dass durch das Verkleinern der Fußnotenziffer Platz zum Nach-oben-schieben geschaffen wird. Dann kann es ja jetzt mal ausprobiert werden... Gruß --Hei_ber 22:28, 11. Okt. 2006 (CEST)

font-size:0.8em; habe ich jetzt hinzugefügt. Und dann wieder revertet. Der IE bringts nicht auf die Reihe :-( --Raymond ^{Disk. Bew.} 23:05, 11. Okt. 2006 (CEST)

Die jetzige Lösung mit line-height:100% sieht schon fast perfekt aus. Mit font-size:0.8em und vertical-align:top schien es mir - allerdings erst nach der Änderung von line-height:100% im commons.css - perfekt zu sein (IE6.0). Ich werde es mit den genannten Einstellungen im monobook.css weiter testen. Danke für das Ausprobieren in der commons.css! --Hei_ber 23:15, 11. Okt. 2006 (CEST)

Ich hoffe

.reference, .references sup {
    font-size: smaller;
    vertical-align: text-top;
    position: relative;
    top: -0.3em;
}

ist eine möglichst kompatible Lösung. Denkt daran, dass Hochstellung auch im <references />-Abschnitt vorkommen kann. Beachtet bei Tests auch andere Skins, andere Schriftgrößen (und -arten), PDAs und Mobiltelefone. – Schnargel 14:44, 19. Okt. 2006 (CEST)

Erste Testergebnisse

Browser	common.css line-height:100%	common.css line-height:100% + monobook.css:font-size:0.8em ; vertical-align:top	Schnargel, monobook	Schnargel, Klassik	Schnargel, My skin	Schnargel, Kölnisch Blau	Schnargel, Küken	Schnargel, Nostalgie	Schnargel, Simple
PC Internet Explorer 6.0	geringfügig erhöhter Abstand	OK	OK? Zifferndarstellung auf einmal zu klein...	OK	OK	OK	OK	OK	OK
PC Opera 9.02	sehr geringfügig erhöhter Abstand	OK	Zeilenabstand OK, Zahl nur geringfügig hochgestellt	OK	OK	OK	nachfolgender Zeilenabstand erhöht	OK	OK
PC Firefox 1.5.0.7	OK	OK	OK	OK	OK	OK	OK	OK	OK
Linux Konqueror	sehr geringfügig erhöhter Abstand	OK

OK bedeutet hier, dass die Darstellung einer Fußnote nicht zu einer Veränderung von Zeilenabständen führt. Erhöhter Abstand ohne weitere Angabe bezieht sich auf den Abstand zur vorhergehenden Zeile.

Zahlen nur geringfügig hochgestellt bei Opera ist in meinen Augen typographisch noch tragbar. --Hei_ber 19:38, 19. Okt. 2006 (CEST)

Danke für die schnelle Reaktion. Die Unterschiede bei Opera 9 kann ich hier in der Mac-OS-X-Version nicht sehen. Mir fällt auf, dass bei Dir die Hochstellung mit Opera und gerade MonoBook anders ist als bei den anderen Skins. Vielleicht war da noch Dein Monobook.css in irgendeinem Cache, denn der Betrag der Hochstellung sollte in den Skins untereinander nicht so unterschiedlich sein. (Du weißt Du kannst so direkt sehen, was da geladen wird.)

Was mich verblüfft ist, dass sich der Zeilenabstand bei Dir im IE ändert, da ein position: relative; nicht so exotisch ist und das betreffende Element aus der Berechnung der Zeilenhöhe herausnehmen sollte, welche dann vor allem auch nicht kleiner werden dürfte als ohne Fußnote. – Schnargel 01:33, 20. Okt. 2006 (CEST)

Ich hatte bei IE tatsächlich noch meine alte Monobook im cache (Trotz Ctrl-F5), nach Temporäre Internet-Dateien löschen und Neustart sind die bemängelten Skins auch OK. (Generell scheint es bei meinem IE aber immer wieder Cache-Probleme zu geben - jetzt sind auf einmal bei Monobook die Ziffern zu klein...) --Hei_ber 19:23, 20. Okt. 2006 (CEST)

Am besten warten wir mal ein paar Tage, bis sich die Änderung richtig bis in die letzten Ecken der Technik verteilt hat und hoffen das Beste. ;-) – Schnargel 09:59, 21. Okt. 2006 (CEST)

Probleme mit der Darstellung von hochgestellten Fußnotenziffern im IE-Explorer mit monobook

Ich jetzt immer noch bei meinem IE 6.0 (s. o.) bei Monobook das Problem, dass die Fußnotenziffern zu klein und damit unleserlich dargestellt werden. Unter Ansicht -> Schriftgrad ist dabei Mittel gewählt. Ähnliche Probleme berichten nun auch andere Benutzer

• " (...) Unter „Ansicht/Schriftgrad“ die Schrift etwas vergrößern, dann lassen sich die Fußnoten-Ziffern bequem lesen (...)"
• Entweder sind meine Augen zu schlecht, oder aber die Fußnotenziffern sind zu klein. Viel zu klein.

Ich bin nun wahrlich kein monobook-Experte: kann Abhilfe geschaffen werden, indem man den Ziffern eine geringfügig größere Größe verpasst? --Hei_ber 13:05, 4. Nov. 2006 (CET)

Da spielt wohl die Zeichensatz- und Skalierungsvorgabe der Browser für serifenlose Fonts eine tragende Rolle (Außerdem natürlich die Bildschirmauflösung). Generell ist die Vorgabe, dass ein „smaller“ (oder „larger“) die Größe um den Faktor 1,2 verändern sollte. Ich sehe dann beispielsweise die normale Schrift in 12px Größe und die Fußnotenziffern in 10px, was für mich noch lesbar ist. Es scheint aber, dass gerade bei Microsofts Arial (von dem ich vermute, dass es die Standardeinstellung des IE ist) die Verkleinerungen besonders klein aussehen. Ich ändere die Verkleinerung mal auf 91 % (Cache leeren), was dann 11 px entsprechen sollte, und hoffe, dass der Größenunterschied für andere Browser und Skins nicht zu klein wird. – Schnargel 23:15, 6. Nov. 2006 (CET)

Die Schrift in <small>-Tags müsste eigentlich auch dieselbe „zu kleine“, Größe haben, aber das hat wohl noch niemanden gestört. – Schnargel 23:28, 6. Nov. 2006 (CET)

Erfolg! Jetzt sind die Fußnotenziffern im Explorer deutlich zu lesen und hochgestellt. Im Firefox sind die Fußnotenziffern immer noch gut als hochgestellte ausmachbar, sie erscheinen ca. 1/4 Zeile über der Grundlinie. In Opera werden die Ziffern jetzt nur noch 1 Pixel über der Grundlinie dargestellt, das "obere Ende" ist aber deutlich über dem Fließtext. Ich finde diese Einstellung immer noch aesthetisch. (Alle Tests mit monobook)

Dein Hinweis mit der Bildschirmauflöstung könnte stimmen. Bei einem anderen Rechner mit 19"-Monitor waren die Ziffern im Internet-Explorer gut lesbar, im Gegensatz zum 17" Monitor. Mit vielem Dank für's Suchen & Einstellen --Hei_ber 00:31, 7. Nov. 2006 (CET)

Bitte gerne und Dir Danke für die schnelle Rückmeldung (Ich selbst habe im Moment nicht jeden Tag hier Zeit). Der Mac-Opera stellt die Ziffern etwa ähnlich wie andere Browser dar, benutzt aber auch eine andere Schriftart. Mag sein, dass das „text-top“ bei Opera etwas anders interpretiert wird. Aber wenns jetzt immer noch ästhetisch ist, lassen wir es doch so. – Schnargel 01:40, 7. Nov. 2006 (CET)

References - Hervorhebung aufgerufene Quellenangabe

Hallo!

Mir ist in der englischen Wikipedia aufgefallen, dass bei Anklicken eines Verweises auf eine Fußnote im Artikeltext in den entsprechenden Bereich der Referenzen gesprungen wird, und die betreffende Referenz farblich hervorgehoben wird. Dies ist ein tolles Feature für Artikel mit vielen einzelnen Quellenangaben. In der deutschen Wikipedia gibt es anscheinend diese Funktion im Moment nicht. Warum ist hier diese Funktion im Customizing nicht aktiviert worden oder ist eine MediaWiki Software im Einsatz die diese Funktion nicht bietet? Video2005 23:37, 12. Mai 2007 (CEST)

Stimmt, sollte man hier auch einführen.--Τιλλα 2501 ^± 00:20, 13. Mai 2007 (CEST)

Ist sicher eine Javascriptspielerei. Ich kann's aber auf en: nicht finde, fragt mal jemand auf der Dorpuppe nach? --DaB. 03:58, 13. Mai 2007 (CEST)

Ich hab die Änderung aus der en.WP gefunden, ganz einfaches CSS in MediaWiki:Common.css (hier die Diskussion dazu). --Dapeteばか 14:04, 13. Mai 2007 (CEST)

Super! Ich habe zumindest in meiner monobook.css die Anpassung mit Erfolg vorgenommen. Jetzt stellt sich nur die Frage, ob irgend etwas dagegen spricht diese Funktion für alle in der globalen Common.css zu aktivieren. Muss dann dazu die Anfrage auf der Common.css Diskussionsseite geführt werden oder hier? Video2005 19:40, 13. Mai 2007 (CEST)

IMHO nicht, ich wäre auch für die Einbindung ins CSS. — Pill (Diskussion · Bewertung) 11:29, 19. Mai 2007 (CEST)

Dem kann ich nur zustimmen. Wollte auch gerade den Vorschlag hier einbringen. --M.L 22:41, 26. Mai 2007 (CEST)

Da sich in den zwei Wochen niemand beschwert hat, hab ich's mal umgesetzt. Im IE funktioniert's zwar nicht, aber es sollte auch keine Nachteile für die IE-User mit sich bringen. Grüße -- kh80 •?!• 23:22, 26. Mai 2007 (CEST)

Schaltfläche [Änderungen zeigen]

Hallo, kann bitte ein Admin unverzüglich diese Änderung rückgängig machen? Die Schaltfläche „Änderungen zeigen“ ist ein sehr wichtiges und für mich unverzichtbares Kontrollelement der Bedienoberfläche. Wer sie nicht braucht, kann sie in seinem persönlichen Skin abschalten, aber einem unangemeldeten oder unerfahrenen Benutzer sollte sie doch zur Verfügung stehen. Gibt es überhaupt einen nachvollziehbaren Anlass für diese Änderung, wie zum Beispiel ein Meinungsbild? Bei Fragen zur Wikipedia kann ich keinen Anlass erkennen. --Wiegels „…“ 13:18, 20. Mai 2007 (CEST)

Tabellen-Probleme von class="prettytable"

Probleme bitte unter Vorlage:Prettytable/Bugs melden.

imagemap inlinen

Verschoben nach Wikipedia:Verbesserungsvorschläge#imagemap inlinen --Revolus Δ 15:38, 30. Jul. 2007 (CEST)

CSS-Klasse "error" von Skins hierher verlagern?

Durch eine Änderung an der Vorlage:Infobox Ort in Deutschland bin ich darauf gestoßen, dass die CSS-Klasse error wohl in den Skins wie Monobook drin ist. Wenn ich TM richtig verstehe, muss die Klasse aber in allen Skins vorhanden sein. Wäre sie damit kein Kandidat für Common.css? Aktuell erst mal für de.wikipedia, später wohl allgemein für MediaWiki --S.K. 20:05, 7. Aug. 2007 (CEST)

Die Klasse "error" ist für alle Skins definiert. Gerade noch in meinem Testwiki ausprobiert. Ich sehe daher keinen Handlungsbedarf. --Raymond ^{Disk. Bew.} 22:57, 7. Aug. 2007 (CEST)

Eiverstanden, dass kein akuter Handlungsbedarf besteht. Aber wäre es nicht sinnvoll, dass grundsätzlich zu machen? Die ganzen Definitionen wie hintergrundX, rahmenfarbeX, ... sind ja auch als Default hier einmal drin und können dann, so gewünscht, in den Skins angepasst werden? Ist aber zugegebenermaßen eher eine Frage für MediaWiki. --S.K. 09:19, 9. Aug. 2007 (CEST)

Abstand zwischen TOC-Nummerierung und TOC-Text

Der Abstand zwischen der Nummerierung und dem Text in Inhaltsverzeichnissen ist doch sehr klein. Gerade wenn die einzelnen Abschnitte mit Jahreszahlen betitelt werden, leidet doch die viesuelle Trennbarkeit von Nummer und darauffolgender Zahl (Beispiel). Mitunter werden dann vor den eigentlichen TOC-Text eine Reihe von &nbsps gesetzt (siehe aktuelle Version des verlinkten Artikels und Benutzer_Diskussion:Gnu1742#Chronologie_Styling). Mein Vorschlag: Folgende Zeilen css in der common.css fügen einen kleinen Zwischenraum zwischen der Nummerierung und dem Text ein:

/* Größerer Abstand zwischen TOC-Nummerierung und TOC-Eintrag */
span.tocnumber {margin-right:0.4em;}

Die Lesbarkeit wird erhöht, ohne dass hier radikal das Layout verändert wird und auf oben genannte unschöne Konstrukte können wir dann guten Gewissens verzichten. Meinungen? Alternativen? Kritik? Grüßle, --Gnu1742 12:39, 9. Aug. 2007 (CEST)

Könnte man denen nicht dazu auch eine hellere Farbe zur Abstufung zukommen lassen? Vielleicht #555. --Revolus Δ 12:50, 9. Aug. 2007 (CEST)

Das fänd ich visuell widerum etwas arg unruhig. --Gnu1742 12:53, 9. Aug. 2007 (CEST)

Hm, hast Recht, das könnte den Fokus beim Lesen zu sehr auf die Nummerierung lenken. Vergiss meinen Vorschlag einfach, deiner ist gut. --Revolus Δ 12:58, 9. Aug. 2007 (CEST)

Ach, ich bin mal mutig und probiers... Wenns stört, ists ja fix revertiert... --Gnu1742 21:14, 9. Aug. 2007 (CEST)

Könnte man das mit padding statt margin machen? Ich lasse Links mit Unterstreichung anzeigen. Jetzt gibt es eine merkwürdig zweigeteilte Lücke, die erste Hälfte der Lücke ohne Unterstreichung und die zweite Hälfte mit. --TM 18:35, 13. Aug. 2007 (CEST)

Öhm... bei mir war weder vor- noch nachher eine Lücke: Die beiden Spans, deren Abstand vergrößert wurde, liegen innerhalb des <a>-Tags und sind somit beide komplett unterstrichen... --Gnu1742 18:42, 13. Aug. 2007 (CEST)

Ich verwende Opera. Da sieht das so aus: 2.3 Beispiel. --TM 21:01, 13. Aug. 2007 (CEST)

Also ich finde die Lücke in der Unterstreichung gerade gut. Dadurch wirkt es die ein Index in einem Buch. --Revolus Δ 01:39, 14. Aug. 2007 (CEST)

Wenn es eine richtige Lücke wäre, ja. Aber hier ist die Lücke halb unterstrichen und halb nicht unterstrichen. Auf mich macht das den Eindruck eines Darstellungsfehlers, der sich zudem noch durch sämtliche Artikel zieht, die ein Inhaltsverzeichnis haben. Außerdem sollte das Ziel eine einheitliche Darstellung in allen Webbrowsern sein, und die kann wie schon gesagt mit padding erreicht werden. --TM 09:01, 14. Aug. 2007 (CEST)

Der 'Fehler' liegt an dem Leerzeichen, welches bei Inhaltsverzeichnissen zwischen Nummer und Titel eingefügt wird und nicht an den spans, auf die sich die Style-Rule bezieht. Das dürfte sich auch mit padding anstelle von margin nicht ändern. Zumindest habe ich auf meiner Testseite auch mit Opera keinen Unterschied in der Darstellung gesehen... --Gnu1742 10:45, 14. Aug. 2007 (CEST)

Ich habe mich geirrt. Ob margin oder padding verwendet wird, ergibt keinen Unterschied. Opera zeigt das immer so an. Eine Lösung dafür konnte ich nicht finden, so dass ich das wohl als Opera-Bug akzeptieren muss. Auf das Leerzeichen darf übrigens nicht verzichtet werden, da dann die Darstellung ohne CSS inakzeptabel wäre („2.3Beispiel“), Screenreader würde es falsch vorlesen („Zwei Punkt Dreibeispiel“) usw. --TM 11:56, 14. Aug. 2007 (CEST)

Links auf dunklem Hintergrund

Es ist manchmal grafisch sinnvoll, in Infoboxen mit kräftigen Hintergrundfarben zu arbeiten. So bietet sich bei den Autobahnen naheliegenderweise ein Dunkelblau an. Das hat den Nachteil, dass Links auf diesem Hintergrund unsichtbar werden. Das sieht dann beispielsweise so aus: Die Überschrift ist weiß, Links auf [Referenzen] und zum [Einklappen] sind aber blau auf blau. Ein konkretes Beispiel wäre der Artikel Bundesautobahn 92 (man beachte, dass sich in der Kopfzelle „Anschlussstellen und Bauwerke“ zwei Links befinden). Das kann auch nicht durch zusätzliche style-Angaben im Vorlagenquelltext behoben werden, da solche Links automatisch durch die Software oder durch Skripte erzeugt werden und außerhalb des Einflusses der Vorlage liegen.

Was ich mir vorstelle, ist eine class="dark-background", die etwa wie folgt definiert ist:

#bodyContent .dark-background,
#bodyContent .dark-background a,
#bodyContent .dark-background a:visited {
        color: white;
}

Auf diese Weise könnte man im Vorlagenquelltext beispielsweise class="dark-background" style="background-color: black;" schreiben und das Farbproblem damit aus der Welt schaffen. Habe ich etwas übersehen? Gibt es eine bessere, standardkonformere und barrierefreiere Methode? --TM 10:29, 23. Aug. 2007 (CEST)

Nö, klingt klug. Man sollte aber trotzdem unterschiedliche Farben für Text, Links und besuchte Links definieren (also nicht alles einfach nur weiss wie im Beispiel) --Gnu1742 10:33, 23. Aug. 2007 (CEST)

Ich sehe gerade, dass mir meine Idee im Fall der Vorlage:Infobox Bundesautobahn nur zur Hälfte weiter hilft. Die Vorlage benutzt die selbe Funktion zum Ein- und Ausklappen wie die Navigationsleisten. Der von der Monobook.js erzeugte NavToggle-Link zum Einklappen landet aber außerhalb des dunkelblauen NavHead-Bereichs und entzieht sich damit den vorgeschlagenen CSS-Selektoren. Hat da jemand eine Idee?

Was die Farben betrifft, hast du natürlich Recht. Man sollte die Links auch noch erkennen, wenn sie nicht unterstrichen sind. Da das aber auf allen Hintergründen funktionieren muss (dunkelrot, dunkelgrün, dunkelblau usw.), kommen nur Grautöne in Frage.

Normaler Text, noch nicht besuchter Link, besuchter Link.

Oder man erzwingt einfach die Unterstreichung.

Normaler Text, noch nicht besuchter Link, besuchter Link.

--TM 11:11, 23. Aug. 2007 (CEST)

Ein Vorschlag: Kann man bei den style-Parametern oben in einem div einen hinzufügen, der für die Linkfarbe zuständig ist? Beispielsweise link-color:#FFEEDD? Dann könnte man die Linkfarbe auch an die jeweilige Hintergrundfarbe anpassen. --Versusray | Diskutiere mich | Bewerte Mich 12:46, 23. Aug. 2007 (CEST)

Das Problem ist nicht die CSS-Eigenschaft, mit der man die Farbe ändern kann, sondern der Selektor. Die Textfarbe, die man dem umgebenden Element per style-Parameter zugewiesen hat, wird durch Deklarationen aus der main.css wieder überschrieben (kaskadierend, daher der Name Cascading Stylesheets). Die einzige Möglichkeit, diese Deklaration wiederum zu überschreiben, ist einen neuen Selektor einzuführen, der eine höhere Priorität hat als der bisherige. --TM 13:46, 23. Aug. 2007 (CEST)

Dass das (noch) nicht geht ist mir klar. Meine Frage war nur, ob man sowas nicht vielleicht anderweitig realisieren kann (Für html gibts ja auch die Möglichkeit, eine Linkfarbe zuzuweisen, aber die funktioniert in der WP leider nicht). Möglich, aber aufwändig wäre, so eine Funktion in der Software unterzubringen, aber das lohnt sich wohl nicht.
Ich hab selber schon mal versucht, so eine Linkfarbe in einer Vorlage unterzubringen und bin daran gescheitert. Kleinarbeit wäre
[[Link|<span style="color:#008888">Irgendwas</span>]]: Irgendwas,
aber das wurde wohl auch schon in Erwägung gezogen und ist viel zu frickelig.
Edit: Außerdem ist es ja eben nicht in einer Vorlage verwendbar. --Versusray | Diskutiere mich | Bewerte Mich 14:04, 23. Aug. 2007 (CEST)

Dein Beispielquelltext ist korrekt (das wird zum Beispiel in der Vorlage:BAB-A so gemacht), aber wie ich oben schon schrieb, ist diese Methode nicht auf ref-Links und auf per JavaScript zugeschaltete Ein/Ausklappen-Links anwendbar. Sie schlägt auch fehl, wenn man zum Beispiel mit Bundesland = [[Sachsen]] fertige Links an eine Vorlage übergibt. Da lässt sich nachträglich kein span mehr einschmuggeln. --TM 15:24, 23. Aug. 2007 (CEST)

Dass man in der Vorlage keine Linkfarbe definieren kann ist ja das Problem, das ich auch hatte und von dem ich weiß dass man es normal nicht sauber lösen kann. Bitte halte mich nicht für völlig ahnungslos.
Was nur bisher an mir vorbeigegangen war, dass das Problem auch für solche "Speziallinks" bestand. Das hab ich überlesen. --Versusray | Diskutiere mich | Bewerte Mich 20:02, 23. Aug. 2007 (CEST)

Ich sehe für die blau hinterlegten Spalten in der Infobox keinen Bedarf. Nur weil die BAB-Schilder blau sind, muss es die Infobox nicht sein. Linkfarben extra deswegen anders zu definieren, findet meine Unterstützung nicht. --BLueFiSH ✉ (Langeweile?) 15:28, 23. Aug. 2007 (CEST)

Ich halte das für ein grundsätzliches Problem. Es gibt momentan keine technisch saubere Möglichkeit, dunkle Hintergrundfarben zu verwenden (jetzt einmal unabhängig davon, ob und in welchen Fällen das sinnvoll ist). Die blassen Pastelltöne, die jetzt von der Common.css vorgegeben werden, zeigen das Problem: sie sind alle so ausgelegt, dass sie mit dunklem Text funktionieren. Ich fordere im Grunde nur, konsequent zu sein:

1. Entweder wir erlauben dunkle Hintergrundfarben. Dann sollte es auch eine Möglichkeit geben, Links weiß einzufärben.
2. Oder wir untersagen dunkle Hintergrundfarben. Noch besser: Wir untersagen feste Farbangaben. Das sollte dann aber irgendwo niedergeschrieben sein, damit man sich darauf berufen kann. --TM 18:18, 23. Aug. 2007 (CEST)

Ich würde eigentlich sagen, dass Untersagen fester Farbangaben sollte verboten werden. Dafür gibt es ja die Klassen hintergrundfarbe1..9, auf denen Links gut sichtbar sind. Wobei die Färbung bei den Autobahnartikeln schon schick aussieht. Vielleicht sollten zu rahmenfarbe1..5 und den Hintergrundfarben-Klassen noch ein paar Textfarben-Klassen eingeführt werden, 2-3 (wobei eine für dunkle Hintergründe wäre und eine als Blickfang) hielt ich für angemessen. Diese könnten dann auch die a:links formatieren. Dann würde sich das ganze Problem in Wohlgefallen auflösen. --Revolus Δ 18:43, 23. Aug. 2007 (CEST)

Besser wären Linkfarbenklassen, nicht Textklassen, um Links von normalem Text zu unterscheiden. Schick wäre aber auch sowas anstatt einer Farbhervorhebung für Links. Hier sieht das jedenfalls schon ganz annehmbar aus. --Versusray | Diskutiere mich | Bewerte Mich 20:23, 23. Aug. 2007 (CEST)

Wie wäre es mit den Komplementärfarben zu den bestehenden Linkfarben? Normaler Text, noch nicht besuchter Link, besuchter Link. --Fomafix 00:05, 24. Aug. 2007 (CEST)

Erstmal geht es generell darum, ob eine solche Klasse eingeführt werden sollte. @Fomafix: dieser Gelbton weckt in mir keinerlei Asoziationen zu einem Link. Gelb auf Blau wirkt doch etwas grell. --Revolus Δ 06:14, 24. Aug. 2007 (CEST)

height bei NavHead

Bei der Titelzeile von Navigationsleisten div.NavHead steht ein

height: 1.6em;

Wozu ist diese Höhenangabe notwendig? Diese feste Höhenangabe sorgt für ein Überlaufen des Titels aus dem Rahmen der Überschrift, wenn die Überschrift nicht mehr in eine Zeile passt:

{{Navigationsleiste
|TITEL=Mehrzeile<br />Überschrift
|INHALT=hier steht ein wegklappbarer Inhalt
}}

mit height: 1.6em; sieht das so aus:

ohne height: 1.6em; sieht das so aus (Achtung, fehlerhafte Darstellung im Internet Explorer 6):

Das war natürlich ein extremes Beispiel mit einem absichtlich umgebrochenen kurzen Titel, das so sicher nicht vorkommen wird. Was aber durchaus vorkommt ist ein langer Titel, der auf einem schmalen Bildschirm, beispielsweise einem PDA:

Die Höhenangabe sorgt für Probleme und sollte demnach entfernt werden. Dass bei mehrzeiligen Titelzeilen die Zentrierung durch den Button zum Ein- bzw. Ausklappen nicht passt ist ein anderes Problem, dass sich nicht so leicht beheben lässt. --Fomafix 22:09, 27. Aug. 2007 (CEST)

Update: für das Problem mit der nicht ganz zentrierten Titelzeile habe ich inzwischen sogar zwei Lösungen. --Fomafix 23:13, 27. Aug. 2007 (CEST)

Bitte keinesfalls zwei Einklapp-Links. Das wäre Unfug. Aufgrund der von dir beschriebenen Probleme ist float die einzige technisch sauber funktionierende Lösung. Dass die Zentrierung sich dann am Rest abzüglich des Einklapp-Links orientiert, ist kein Fehler. Es gibt ja auch Navigationsleisten mit Bildern links an der Seite, da würde sowieso keine deiner beiden vermeintlichen Lösungen funktionieren.

Mit der height-Angabe muss ich dir allerdings Recht geben. Sie wurde im Oktober 2004 mal eingeführt, aber ich kann nicht mehr nachvollziehen, warum. Ich würde sie einfach rauswerfen. --TM 00:51, 28. Aug. 2007 (CEST)

Die Korrektur der Zentrierung ist noch nicht ausgereift, aber das height: 1.6em; sollte entfernt werden. Beim Internet Explorer 6 gibt es allerdings Probleme. Der Internet Explorer ignoriert die Höhenangabe und von height: 1.6em; und zeigt macht den grauen Hintergrund immer so hoch wie der Text von der Titelzeile. Daher ist der Darstellungsfehler mit dem überlaufenden Text auch mit dem Internet Explorer nicht aufgefallen. Wenn allerdings height: 1.6em; komplett entfernt wird, dann nach Einfügen des Ein-/Ausklappbuttons der graue Hintergrund überhaupt nicht mehr angezeigt. In der schmalen div-Box funktioniert es allerdings seltsamerweise. Daher habe ich probiert, dem Internet Explorer etwas zu helfen, ohne dass andere Browser beeinträchtigt werden und bin auf folgende Lösung gekommen. Bei NavFrame muss ein width:100%; ergänzt werden:

mit height: 1.6em; sieht das so aus:

ohne height: 1.6em; sieht das so aus:

Der Internet Explorer verhält sich dann bezüglich Zentrierung wie die anderen Browser. --Fomafix 10:35, 30. Aug. 2007 (CEST)

Es müsste damit folgende CSS-Definiton verwendet werden:

/* Stylesheet-Ergänzung zu Standard-[[Wikipedia:Navigationsleisten]] */
 
div.BoxenVerschmelzen,
div.NavFrame {
        width: 100%;
        margin: 1.5em 0 0 0;
        padding: 2px;
        border: 1px solid #aaa;
        text-align: center;
        font-size: 95%;
        clear: both;
}
div.BoxenVerschmelzen div.NavFrame {
        border-style: none;
        margin-top: 0;
}
div.NavFrame + div.NavFrame {
        border-top-style: none;
        margin-top: 0;
}
div.NavPic {
        background: #fff;
        margin: 0;
        padding: 2px;
        float: left;
}
div.NavHead {
        font-weight: bold;
        font-size: 100%;
        background: #efefef;
}
div.NavFrame p,
div.NavFrame div.NavContent,
div.NavFrame div.NavContent p {
        font-size: 100%;
}
div.NavEnd {
        margin: 0;
        padding: 0;
        line-height: 1px;
        clear: both;
}

Ich habe dabei auch die Regeln für den Abstand vor den Navigationsleisten mit zusammenfasst. --Fomafix 11:07, 30. Aug. 2007 (CEST)

Moment, das width:100%; wirkt sich doch auf andere Browser aus. Beim Firefox ist eine minimal breitere Box zu sehen. Bei gestapelten Navigationsleisten mit BoxenVerschmelzen fällt das noch mehr auf. Das nur für den Internet Explorer notwendige width:100%; muss daher auf den Internet Explorer beschränkt werden. Entweder es wird in die IE*Fixes.css aufgenommen, oder sinnvoller: es wird per CSS-Tricks ausgeblendet:

/* Nur der Internet Explorer benötigt width:100%; für eine korrekte Darstellung. */
/* Der Internet Explorer ignoriert Zeilen mit einem leeren Kommentar vor dem ":", */
/* Daher wird bei allen anderen Browsern das width:100%; durch width:inherit; überschrieben und die Breite geerbt. */
div.NavFrame {
        width: 100%;
        width /**/: inherit;
}

--Fomafix 15:23, 31. Aug. 2007 (CEST)

Invalides CSS: border-style: hidden;

Kann mir übrigens mal jemand sagen, was die beiden border-style: hidden; in dieser Datei zu suchen haben? Das wurde 2004 mal beim wilden Herumexperimentieren eingefügt und seit dem offenbar nie wieder entfernt. Zur Erklärung: Im Zusammenhang mit border gibt es nur das Schlüsselwort none. Das Schlüsselwort hidden gehört zur Eigenschaft visibility und hat hier nichts zu suchen wirkt nur im Zusammenhang mit Tabellen. --TM 23:03, 30. Aug. 2007 (CEST)

hidden ist schon ok: http://de.selfhtml.org/css/eigenschaften/rahmen.htm#hidden --Revolus Δ 23:30, 30. Aug. 2007 (CEST)

Interessant. Trotzdem ist das border-style: hidden; überflüssig, da es zum einen von dem nachfolgenden border-style: none; in jedem Fall überschrieben wird und zum anderen nur bei Tabellen überhaupt eine Wirkung zeigen würde. Aus dem selben Grund ist auch die Angabe border-collapse wirkungslos. Weder border-collapse noch border-style: hidden; haben bei div-Containern eine Wirkung. Ich habe diese Zeile daher ebenfalls entfernt. Des weiteren habe ich einige doppelte CSS-Angaben zusammen gefasst (font-size: 100%; stand dreimal direkt hintereinander) und wenn möglich kürzere Alternativen eingesetzt (die Maßangabe bei 0px war unnötig). Ich würde vorschlagen, das jetzt so zu übernehmen (nicht vergessen, den dann überflüssigen Abschnitt „Abstand vor Navigationsleisten“ zu entfernen). Wenn möglich bitte mit Tabulatoren, um die Datei klein zu halten. --TM 09:58, 31. Aug. 2007 (CEST)

Weitere Vereinfachung der CSS-Klassen für Navigationsleisten

NavHead

NavHead kommt sowieso nur als Unterklasse von NavFrame vor. Diese Einschränkung habe ich oben entfernt. --Fomafix 16:47, 1. Sep. 2007 (CEST)

BoxenVerschmelzen

das padding:2px; und font-size: 95%; in BoxenVerschmelzen und in NavFrame bewirkt, dass verschmolzene Navigationsleisten einen breiteren Abstand zwischen der grauen Titelzeile und dem Rahmen und eine kleinere Schriftgröße haben als nicht verschmolzene Navigationsleisten:

Verschmolzene Navigationsleiste:

Deutsche Hansestädte heute

Anklam | Bremen | Demmin | Gardelegen | Greifswald | Hamburg | Havelberg | Lübeck | Lüneburg | Osterburg (Altmark) | Rostock | Salzwedel | Stendal | Stralsund | Werben (Elbe) | Wismar

 

Mitgliedsstaaten des Deutschen Bundes (1815–1866)

Kaiserreich: Österreich | Königreiche: Preußen | Bayern | Sachsen | Hannover | Württemberg | Kurfürstentümer: Hessen-Kassel | Großherzogtümer: Baden | Hessen-Darmstadt | Luxemburg | Mecklenburg-Schwerin | Mecklenburg-Strelitz | Oldenburg | Sachsen-Weimar-Eisenach | Herzogtümer: Anhalt (ab 1863) | Bernburg (bis 1863) | Dessau (bis 1863) | Köthen (bis 1847) | Braunschweig | Holstein | Lauenburg | Limburg | Nassau | Sachsen-Altenburg (ab 1826) | Sachsen-Coburg-Saalfeld ab 1826 als Sachsen-Coburg-Gotha | Sachsen-Gotha-Altenburg (bis 1826) | Sachsen-Hildburghausen (bis 1826) | Sachsen-Meiningen | Fürstentümer: Hessen-Homburg | Hohenzollern-Hechingen (bis 1850) | Hohenzollern-Sigmaringen (bis 1850) | Liechtenstein | Lippe | Reuß ältere Linie | Reuß jüngere Linie | Schaumburg-Lippe | Schwarzburg-Rudolstadt | Schwarzburg-Sondershausen | Waldeck | Freie Städte: Frankfurt am Main | Hamburg | Lübeck | Bremen

 

Nicht verschmolzene Navigationsleiste:

Mitgliedsstaaten des Deutschen Bundes (1815–1866)

Kaiserreich: Österreich | Königreiche: Preußen | Bayern | Sachsen | Hannover | Württemberg | Kurfürstentümer: Hessen-Kassel | Großherzogtümer: Baden | Hessen-Darmstadt | Luxemburg | Mecklenburg-Schwerin | Mecklenburg-Strelitz | Oldenburg | Sachsen-Weimar-Eisenach | Herzogtümer: Anhalt (ab 1863) | Bernburg (bis 1863) | Dessau (bis 1863) | Köthen (bis 1847) | Braunschweig | Holstein | Lauenburg | Limburg | Nassau | Sachsen-Altenburg (ab 1826) | Sachsen-Coburg-Saalfeld ab 1826 als Sachsen-Coburg-Gotha | Sachsen-Gotha-Altenburg (bis 1826) | Sachsen-Hildburghausen (bis 1826) | Sachsen-Meiningen | Fürstentümer: Hessen-Homburg | Hohenzollern-Hechingen (bis 1850) | Hohenzollern-Sigmaringen (bis 1850) | Liechtenstein | Lippe | Reuß ältere Linie | Reuß jüngere Linie | Schaumburg-Lippe | Schwarzburg-Rudolstadt | Schwarzburg-Sondershausen | Waldeck | Freie Städte: Frankfurt am Main | Hamburg | Lübeck | Bremen

 

Eine Auftrennung nach Wirkungen nach innen und Wirkungen nach außen zwischen BoxenVerschmelzen und NavFrame behebt das Problem.

div.BoxenVerschmelzen,
div.NavFrame {
        margin: 1.5em 0 0 0;
        border: 1px solid #aaa;
        clear: both;
}
div.NavFrame {
        padding: 2px;
        text-align: center;
        font-size: 95%;
}

Diese Änderung bewirkt allerdings eine Vergrößerung der Schriftart von bisher 95% · 95% = 90% auf 95% bei Artikel, die bereits verschmolzene Navigationsleisten verwendet haben. Vielleicht wäre generell eine einheitliche Schriftgröße von 90% sinnvoller. --Fomafix 16:47, 1. Sep. 2007 (CEST)

font-size

Das font-size: 100%; ist meiner Meinung nach wirkungslos, da es die Schriftgröße auf 100 % der geerbten Schriftgröße setzt.[2] Wenn diese Angabe nicht aufgrund von browserspezifischen Verhalten benötigt wird, kann sie entfernt werden. --Fomafix 16:47, 1. Sep. 2007 (CEST)

Automatisches Verschmelzen

Das automatische Verschmelzen von Navigationsleisten, also verschmelzen von zwei oder mehrere Navigationsleisten direkt hintereinander ohne BoxenVerschmelzen, funktioniert auch nicht einheitlich. Der Internet Explorer versteht Adjacent sibling selectors (+) nicht. Seit dem zusätzlichen und notwendigen Abstand vor Navigationsleisten ist der Abstand zwischen unverschmolzenen Navigationsleisten groß geworden. Auch beim Firefox und anderen modernen Browsern ist die Darstellung nicht einheitlich: Bei verschmolzenen Navigationsleisten wird keine Rahmenlinie zwischen den einzelnen Navigationsleisten angezeigt, während beim automatischen Verschmelzen keine Linie mehr dazwischen ist.

Um eine Einheitlichkeit zwischen den Browsern zu schaffen, wäre es denkbar, auf das automatische Verschmelzen zu verzichten und dadurch die derzeitige Darstellung vom Internet Explorer zu übernehmen. Mit der Vorlage:NaviBlock können verschmolzene Navigationsleisten ganz angenehm angelegt werden:

{{NaviBlock
|Navigationsleiste Hansestädte
|Navigationsleiste Mitglieder des Deutschen Bundes
}}

Die hübsche Linie zwischen automatisch verschmolzenen Navigationsleisten lässt sich übrigens durch folgenden CSS-Code auch in per BoxenVerschmelzen verschmolzenen Navigationsleisten einbauen:

div.NavFrame {
        border: 1px solid #aaa;
}
div.BoxenVerschmelzen {
        border-top: 1px solid #aaa;
}
div.BoxenVerschmelzen div.NavFrame {
        border-top: none;
}

Eine Verschmelzung per JavaScript halte ich für nicht sinnvoll, da sich dann die Darstellung und nicht nur Buttons verändern, wenn JavaScript deaktiviert wird. --Fomafix 18:51, 3. Sep. 2007 (CEST)

Neue CSS-Definition für Navigationsleisten

Ich habe hier einen Vorschlag für eine neue CSS-Definition für die Navigationsleisten. Es sind noch nicht alle Vorschläge von oben eingebaut, da diese einzeln diskutiert werden sollten. --Fomafix 18:51, 3. Sep. 2007 (CEST)

/* Stylesheet-Ergänzung zu [[Hilfe:Navigationsleisten]] */
 
div.BoxenVerschmelzen,
div.NavFrame {
        margin: 1.5em 0 0 0;
        clear: both;
}
div.BoxenVerschmelzen {
        border-top: 1px solid #aaa;
}
div.NavFrame {
        width: 100%;
        width /**/: inherit;
        border: 1px solid #aaa;
        padding: 0.2em;
        text-align: center;
        font-size: 95%;
}
div.BoxenVerschmelzen div.NavFrame {
        border-top: none;
        margin-top: 0;
}
div.NavFrame + div.NavFrame {
        border-top: none;
        margin-top: 0;
}
div.NavPic {
        background: #fff;
        margin: 0;
        padding: 0 0.2em 0.2em 0;
        float: left;
}
div.NavHead {
        font-weight: bold;
        background: #efefef;
        padding: 0 0.4em;
}
div.NavEnd {
        margin: 0;
        padding: 0;
        line-height: 1px;
        clear: both;
}

In MediaWiki:Monobook.css sollte für den Ein-/Ausklappbutton noch ein angemessener Abstand zum Rand eingestellt werden: --Fomafix 01:14, 4. Sep. 2007 (CEST)

.NavToggle {
        padding: 0 0.4em;
}

Link FA

Gibt es eigentlich irgendwelche nicht offensichtlichen Gründe, warum für die Vorlage:Link FA das Sternchen ohne transparenten Background verwendet wird und nicht z. B. diese transparente Version? Mit der aktuellen Fassung kriegt man in den Interwikis immer so einen häßlichen weißen Blob drumherum. — ^PDD — 15:49, 2. Sep. 2007 (CEST)

nicht daß ich wüsste. probiert's aus! -- ∂ 16:18, 2. Sep. 2007 (CEST)

Na dann schaunmermal. — ^PDD — 23:52, 2. Sep. 2007 (CEST)

Ich habs jetzt grad nicht an der Hand, aber kann der IE7 mittlerweile transparente pngs darstellen? Wenn nein, ist das Problem des hässlichen weissen Blobs noch nicht gelöst... --Gnu1742 06:39, 3. Sep. 2007 (CEST)

Der IE6 kanns auf jeden Fall nicht, habs gerade ausprobiert. Aber auch dort (und ggf. im IE 5.5, analog zu den restlichen Browser-Fixes) sollte es mMn ansehnlich bleiben. Denn auch wenn das Problem im IE7 vielleicht gelöst sein sollte, nicht jeder hat die aktuellste Browserversion, sondern ist mitunter aus guten Gründen mit einem etwas angestaubten Klassiker unterwegs. – Ich selbst verwende dann aber doch lieber den FF. ;-) Sollte das aber der einzige Grund für das Bild mit weißem Hintergrund sein, so könnte man statt der Wiederherstellung des alten Zustands eventuell eine Browserweiche einbauen. Grüße, --CyRoXX ^(? ±) 11:21, 3. Sep. 2007 (CEST)

dann lieber häßliche blobs. browserweichen sind böse. -- ∂ 12:30, 3. Sep. 2007 (CEST)

Die letzte von mir hochgeladene Version von Bild:Monobook-bullet-star.png sieht mit allen Browsern ansehnlich aus. --Revolus Δ 13:28, 3. Sep. 2007 (CEST)

Obwohl ich meine, den gesamten IE-Cache gelöscht zu haben (Temporary Internet Files, Reload mit Strg+F5), erscheint bei mir im IE6 noch immer ein leicht bläulicher Hintergrund. Kann das jemand bestätigen? Grüße, --CyRoXX ^(? ±) 14:23, 3. Sep. 2007 (CEST)

Ja, immernoch da. Es wurde ja noch nichts in der common.css geändert. --Revolus Δ 14:38, 3. Sep. 2007 (CEST)

Ich Dösbaddel... Hier wird ja ein Direktlink zu einer konkreten Bildversion verwendet. Die aktuelle Version sieht tatsächlich makellos aus. Damit man das gegebenenfalls auch bei anderen Bildern anwenden kann: Worin genau lag der "IE6-Fix"? Grüße, --CyRoXX ^(? ±) 14:50, 3. Sep 2007 (CEST)

Ich habe bei der zweiten Version keine indizierten Farben genommen, sondern den kompletten RGBA-Farbraum. Seit irgendeinem Patch scheint der IE das korrekt anzuzeigen; vor einer Weile war die Empfehlung jedenfalls noch, indizierte statt RGBA-Farben zu verwenden. Irgendwie seltsam die Sache ;-) Gruß, --Revolus Δ 15:04, 3. Sep. 2007 (CEST) Nachtrag: Für solche Aufgaben empfehle ich GIMP. Einfache Zeichnungen sind damit schwieriger als mit MS-Paint, aber das Nachbearbeiten geht 1a.

Bin mir nicht hundertprozentig sicher, ob ihr beide vom gleichen Bild redet. Das von mir in die Common.css eingebundene (und daher wohl auch bei CyRoXX angezeigte?) ist dieses hier: [3]. Im IE7 sieht es gut aus, IE6 hab ich nicht mehr hier. Revolus redet von einer anderen Version [4], die er über das ursprüngliche (hier nicht mehr verwendete) Bild drübergeladen hat. Muss da nun noch etwas ersetzt werden? — ^PDD — 15:41, 3. Sep. 2007 (CEST)

Die jetzt eingetragene Variante hat den bläulichen Hintergrund mit IE6 (bei mir zumindest). Glaube, CyRoXX und ich haben über dasselbe Bild geredet :-) --Revolus Δ 17:53, 3. Sep. 2007 (CEST)

Ich warte mal noch auf Aufklärung, was denn dann CyRoXX mit „Die aktuelle Version sieht tatsächlich makellos aus“ gemeint haben könnte... — ^PDD — 18:32, 3. Sep. 2007 (CEST)

Damit war diese Version. Sie hat keinen bläulichen Hintergrund mehr, dafür allerdings einen weißen. Ich habe jetzt eine Version, die sowohl in FF als auch IE6 transparent ist; damit es auf dunklem Grund besser aussieht, habe ich die helleren Pixel auch tranparent gemacht. Der IE6 kann anscheinend nicht mit Farbtiefen größer als 8 Bit umgehen. Sobald das Uploadformular auf Commons wieder richtig funktioniert (es gab einen Crash, das ist wohl auch der Grund dafür, dass ich die alten Bilder nicht überschreiben kann), lade ich die Datei mal hoch. Grüße, --CyRoXX ^(? ±) 19:06, 3. Sep. 2007 (CEST)

Fein, das Hochladen dann bitte gleich als neue Version von Bild:Monobook-bullet-star-transparent.png auf commons erledigen; die Grafik unter dem alten Titel (Bild:Monobook-bullet-star.png) lassen wir jetzt einfach mal in Ruhe, da sie auf zig Projekten verwendet wird und wir keine Gedanken lesen können, welche technischen Lösungen die sich dort überall ausgedacht haben. — ^PDD — 19:15, 3. Sep. 2007 (CEST)

Ich habe das Bild jetzt hochladen können, es befindet sich unter [5]. Ich hoffe, dass das Transparenz-Problem jetzt nicht nur für meine beiden Testbrowser gelöst ist. ;-) Da sich der Link nicht geändert hat, sollten keine weiteren Anpassungen in der Common.css und Common.js nötig sein.

Meine Fehleinschätzung, es gab einen Crash, sodass ich nichts hochladen konnte, war im Übrigen nur Resultat einer Verkettung unglücklicher Zustände: Der Toolserver hat eine kaputte Festplatte, deswegen kann auf einige dort replizierte Datenbanken nicht zugegriffen werden. Ich hatte mich zum Hochladen des Bildes neu angemeldet und durfte als Newbie innerhalb der bekannten vier Tage Wartefrist keine bestehenden Bilder überladen, dazu sah ich eine (nur im deutschen Sprachinterface auf Commons) kaputte MediaWiki-Nachricht, die mich freundlich auf dieses fehlende Recht hinweisen wollte. So kommt eins ins andere... ;-) Grüße, --CyRoXX ^(? ±) 18:52, 7. Sep. 2007 (CEST)

Na wunderbar, vielen Dank! — ^PDD — 00:15, 8. Sep. 2007 (CEST)

Standardschriftart ändern

Immer wieder wird damit argumentiert, Unicode-Zeichen nicht zu verwenden, weil sie im Internet Explorer nicht korrekt angezeigt werden. Es wurde schon die Vorlage:Unicode gegen dieses Problem "erfunden". Bloß wo soll man sie anwenden? Was ist ein Unicode-Zeichen, das man damit anzeigbar machen soll? Meiner Meinung ist die Vorlage nur eine mäßige Behelfslösung, da sie in Lemmata nicht angewendet werden kann und man bei manchen Artikeln quasi den gesamten Quelltext in die Vorlage packen sollte. Die einfachste und eleganteste Lösung wäre es doch, die in der Vorlage:Unicode angegebenen Schriftarten in die commons.css bei #content oder body zu packen. Somit hätte man ein Problem gelöst und viele Argumente gegen Unicode fielen weg. --Revolus Echo der Stille 13:43, 23. Sep. 2007 (CEST)

Huhu? --Revolus Echo der Stille 18:11, 28. Sep. 2007 (CEST)

Druckformate zerschossen

Hallo liebe CSS-Bastler. Schon seit längerem stört mich gewaltig, dass man WP-Artikel nicht vernünftig drucken kann. Weil einem ein besonderes Stylesheet für das Ausdrucken aufgezwungen wird, dieses aber gelinde gesagt untauglich ist. Am schlimmsten ist, dass der Textumfluss um die Bilder nicht funktioniert. Sieht aber auch sonst sehr bescheiden aus. Interessanterweise finde ich heute heraus, dass das mit dem Textumfluss bei en:WP ganz prächtig klappt. Mir scheint also, dass bei den zahlreichen Anpassungen hier in de irgendwann irgendwas zerschossen worden ist. Nun also zwei Fragen:

• Gibt es Aussicht, dass sich einer von den begnadeten CSS-Gurus mal auf die Suche macht und das mit dem Textumfluss behebt?
• Gibt es eine Möglichkeit, wie ich die Anwendung des print-CSS ganz unterdrücken kann, damit ich einen Artikel einfach so ausdrucken kann, wie er auf dem Bildschirm zu sehen ist?

Ich harre in Hoffnung. Grüße --ThePeter 20:18, 27. Sep. 2007 (CEST)

Kannst Du eine Seite nennen, die Probleme bereitet und bei en:WP funktioniert? --Fomafix 22:47, 27. Sep. 2007 (CEST)

Eigentlich nein, weil die Seiten auf de und en nicht identisch sind. Komischerweise stoße ich auch jetzt auf ähnliche Probleme in en. Gestern habe ich zahlreiche Artikel angesehen und überall passte der Umfluss. Komisch. Nun gut. Ich formuliere Frage 1 um: Besteht Aussicht, dass jemand das Umflussproblem behebt, obwohl es auch in en besteht? Frage 2 bleibt unverändert. ;) --ThePeter 12:01, 28. Sep. 2007 (CEST)

Welches Umflussproblem? Ohne Beispielseite lässt sich schlecht über ein Ist-/Soll-Verhalten diskutieren. Auch wird der verwendete Browser eine große Rolle dabei spielen. --Fomafix 12:20, 28. Sep. 2007 (CEST)

Versuche z.B. mal, Finnischer Bürgerkrieg auszudrucken. Der Text fließt, vom Bild in der Einleitung abgesehen, nicht um die Bilder (jedenfalls nicht im Firefox, aber als ich zuletzt geschaut habe, war das Problem im IE das gleiche). --ThePeter 14:15, 28. Sep. 2007 (CEST)

Das Problem hatte ich auch schon. Es ist jedenfalls kein Einzelfall. Im Browser siehts gut aus, aber beim Ausdruck fließt der Text nicht außenrum. (IE6, in meinem Firefox hab ichs noch nicht ausprobiert)--Versusray | Diskutiere mich | Bewerte Mich | Tester gesucht! 14:29, 28. Sep. 2007 (CEST)

Könntet ihr mal einen Screenshot der Druckvorschau machen? Bei Opera 9 sieht alles gut aus. --Revolus Echo der Stille 14:32, 28. Sep. 2007 (CEST)

Ich konnte weder beim Internet Explorer, noch beim Firefox und auch nicht beim Opera Probleme in der Druckvorschau feststellen. Wo ist Dein Problem? --Fomafix 15:18, 28. Sep. 2007 (CEST)

Beim Ausdrucken selber. Im Browser siehts ja auch gut aus. --Versusray | Diskutiere mich | Bewerte Mich | Tester gesucht! 15:24, 28. Sep. 2007 (CEST)

Ich habe in allen Browsern die Druckvorschau angeschaut. Kommt dort ein anderes Ergebnis, wenn ich die angezeigten Seiten physikalisch ausdrucke? --Fomafix 15:31, 28. Sep. 2007 (CEST)

Vielleicht kann du den Druck ja mal einscannen. --Revolus Echo der Stille 15:46, 28. Sep. 2007 (CEST)

hier. --ST ○ 09:12, 29. Sep. 2007 (CEST)

Die PDF kann ich in Acrobat 6 nicht öffnen, ich habe aber das gleiche Problem (FF2, IE7) --RalfR → BIENE braucht Hilfe 13:45, 29. Sep. 2007 (CEST)

Versuchs mal damit: http://upload.wikimedia.org/wikipedia/de/5/53/Finnischer_B%C3%BCrgerkrieg_-_Wikipedia.pdf Du hast nicht zufällig die Bildbeschreibungsseite zu öffnen versucht? --Versusray | Diskutiere mich | Bewerte Mich | Tester gesucht! 13:53, 29. Sep. 2007 (CEST)

Ich kann die Probleme bei mir nicht nachvollziehen. Bei mir werden die Bilder immer korrekt umflossen. Sowohl in der Druckvorschau, als auch beim Ausdruck in ein PDF. Sowohl beim Drucken des Artikels, als auch bei der Druckversion. Angemeldet, als auch unangemeldet. Mit Firefox, Opera und Internet Explorer. --Fomafix 14:04, 29. Sep. 2007 (CEST)

Link FA 2

Mir gefällt diese Version des Sterns besser. Meinungen?--Τιλλα 2501 ^± 14:35, 2. Nov. 2007 (CET)

Hast du den schon mit verschiedenen Browsern angeschaut? --Revolus Echo der Stille 15:40, 2. Nov. 2007 (CET)

Nur mit dem FF und jetzt auch mit dem IE.--Τιλλα 2501 ^± 16:34, 2. Nov. 2007 (CET)

Ja es ging mir hauptsächlich um den IE. Wenn es mit dem gut=transparent aussieht, spricht eigentlich nichts gegen eine Änderung. Mit dem "Glanz" sieht es jedenfalls besser aus. --Revolus Echo der Stille 16:39, 2. Nov. 2007 (CET)

Allerdings nur den 7er, wie der Stern sonst aussieht weiß ich nicht.--Τιλλα 2501 ^± 16:41, 2. Nov. 2007 (CET)

Mit IE6 ist der neue Stern nicht transparent. Allerdings habe ich auch nur mit Ies4Linux getestet, weshalb meine Aussagen nicht so ohne Weiteres nützlich ist. --Revolus Echo der Stille 16:45, 2. Nov. 2007 (CET)

Kann ich bestätigen. Beim IE6 ist der Stern nicht transparent. --Eneas 16:53, 2. Nov. 2007 (CET)

mw-hierotable

Beim move von der Vorlage:Prettytable zu class="prettytable" hat man festgestellt, dass die css-angaben nicht kompatibel mit den tabellen, die vom WikiHiero plugin generiert wird... Am 16. November wurde auf der Projektneuheiten-Seite bekannt gegeben, dass die Tabellen des WikiHiero-Plugins neu mit einem css-class generiert werden. Deswegen: kann jmd. folgende 2 Zeilen hier einfügten? :

.mw-hierotable { border: 0px; }
.mw-hierotable th, .mw-hierotable td { border: 0px; }

Gruss & Danke --kajk ✉ 10:44, 6. Dez. 2007 (CET)

[x] Done. — Raymond ^{Disk. Bew.} 12:35, 6. Dez. 2007 (CET)

Unicode

Hallo. In der Vorlage:Unicode, welche knapp 1000 mal eingebunden ist, wird aus darstellerischen Gründen eine Sequenz an Fonts deklariert. Das verhindert jedoch, dass User, welche einen der Fonts mit schlechter Qualität im System haben, eine andere Schrift einstellen können. Ich möchte daher, dass die Schriften hier deklariert werden. Das erlaubt es Usern, in ihrer monobook.css die Einstellung bei Bedarf zu überschreiben. Der Code wäre:

span.Unicode { 
  font-family: 'Lucida Sans Unicode', 'Arial Unicode MS', 'Bitstream Cyberbit',
  'Bitstream CyberBase', 'DejaVu Sans', 'Bitstream Vera Sans', 'Gentium', 'GentiumAlt',
  'TITUS Cyberbit Basic', 'Doulos SIL', 'Thryomanes', 'Visual Geez Unicode',
  'Microsoft Sans Serif', 'Lucida Grande', 'Sun-ExtA', 'Unicode Symbols', 'Code 2000',
  'Aegean', 'Akkadian', 'Code 2001', 'Sun-ExtB', 'Chrysanthi Unicode';
 }

Wäre das Ok ? Cäsium137 08:55, 5. Feb. 2008 (CET)

Das kann ich nur unterstützen. Allerdings sollte die Angabe die Schriftart auf den Internet Explorer beschränkt werden, indem wie bei en:MediaWiki:Common.css die Definition gleich wieder mit inherit überschrieben wird:

font-family /**/:inherit;

Außerdem sollten in diesem Zuge alle Vorlagen mit Schriftartangaben in die Common.css verlagert werden: Vorlage:IPA, Vorlage:Polytonisch, Vorlage:Musik, … --Fomafix 09:59, 5. Feb. 2008 (CET)

Das muss eigentlich mit allen Vorlagen, welche nichtlateinische Schriften formatieren, gemacht werden.

Es sollte eine möglichst einheitliche Schriftfolge und nicht zu viel Geben. die User können ja selbst einstellen.

Eintragungen

Eine Standardfolge für die meisten Fälle

• Für die Vorlagen "Unicode", "IPA", "Altitalisch" "Musik" und arab. Schrift:

span.Unicode,
 span.IAST,
 span.music-symbol,
 span.spanAr,
 span.altitalisch
 { 
  font-family:
  'Arial Unicode MS',
  'Code 2000',
  'Bitstream Cyberbit',
  'TITUS Cyberbit Basic',
  'Lucida Sans Unicode',
  'DejaVu Sans',
  sans-serif ;
 }

Mehr benötigt man nicht. Reihenfolge nach Dateigröße und Anzahl der Zeichen im Font.

Für Vorlage Hebräisch:

span.hebrew { font-family:
 'SBL Hebrew',
 'Arial Unicode MS',
 'Code 2000',
 'Bitstream Cyberbit',
  'TITUS Cyberbit Basic',
 'Lucida Sans Unicode',
 'DejaVu Sans',
 sans-serif ;
 }

Mehr benötigt man nicht. Cäsium137 00:34, 12. Feb. 2008 (CET)