MediaWiki Diskussion:Common.css/Archiv/1

Bearbeitungshinweise
Diese Common.css-Anweisungen werden gemeinsam von den verschiedenen Stylesheets der Skins genutzt. Bitte Common.css nur für Anweisungen im Textfeldbereich und für 100%ig funktionierende (browser-, auflösungs- und skinunabhängige), zuvor geprüfte Ergänzungen verwenden. --:Bdk: 14:02, 17. Dez 2005 (CET) Alle Skins nutzen Common.css

Ä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:

rahmenfarbe1 Wie Inhaltsverzeichnis #aaaaaa	rahmenfarbe2 Unauffällig, geringer Kontrast #e9e9e9	rahmenfarbe3 Rot, auffällig #c00000	rahmenfarbe4 Neutrale Farbe, deutlich #8888aa	rahmenfarbe5 Schwarz, hoher Kontrast #000000
hintergrundfarbe1 Wie Inhaltsverzeichnis #f9f9f9	hintergrundfarbe2 Weiß, für Nicht-Artikel-Seiten, neutral #ffffff	hintergrundfarbe3 Gelb, auffällig #ffff40	hintergrundfarbe4 Sehr auffällig #ffaa00	hintergrundfarbe5 Neutral, abgesetzt #e0e0e0

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.

Vorhanden:

Vorlage:Highlight1 | Vorlage:Highlight1

Vorlage:Highlight2 | Vorlage:Highlight2

Vorlage:Highlight3 | Vorlage:Highlight3

Überlegung:

hintergrundfarbe6?

hintergrundfarbe7?

hintergrundfarbe8?

hintergrundfarbe9?

Mehr Hervorhebungen?

Mehr Hervorhebungen?

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.

Überlegung:

hintergrund-reihe1?

hintergrund-reihe2?

hintergrund-reihe3?

hintergrund-reihe4?

hintergrund-reihe5?

hintergrund-reihe6?

hintergrund-reihe7?

hintergrund-reihe8?

hintergrund-reihe9?

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)

.NavPic (Bild in Navigationleiste)

Warum ist der Hintergrund weiß? Das sieht komisch aus --MarianSigler {bla} {+-} 19:45, 7. Jul 2006 (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)

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	Bla
Bla	Bla
Bla	Bla
Bla	Bla

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)

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)