MediaWiki Diskussion:Common.css/Archiv/1

Dieses Diskussionsarchiv hat die empfohlene Seitengröße erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen 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 Adresszeile deines Browsers, beispielsweise [[MediaWiki Diskussion:Common.css/Archiv/1#Abschnittsüberschrift]] oder als Weblink zur Verlinkung außerhalb der Wikipedia https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Common.css/Archiv/1#Abschnittsüberschrift

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

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)

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:

Titel

Inhalt

 

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

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:

Mehrzeile
Überschrift

hier steht ein wegklappbarer Inhalt

 

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

Mehrzeile
Überschrift

hier steht ein wegklappbarer Inhalt

 

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:

Schmales Display eines PDA mit einer Breite von 320 Pixel.

---

mit height: 1.6em; sieht das so aus:

Navigationsleiste mit height:1.6em und langem Titel

hier steht ein wegklappbarer Inhalt

 

ohne height: 1.6em; sieht das so aus:

Navigationsleiste ohne height:1.6em und langem Titel

hier steht ein wegklappbarer Inhalt

 

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:

Mehrzeile
Überschrift

hier steht ein wegklappbarer Inhalt

 

ohne height: 1.6em; sieht das so aus:

Mehrzeile
Überschrift

hier steht ein wegklappbarer Inhalt

 

Schmales Display eines PDA mit einer Breite von 320 Pixel.

---

mit height: 1.6em; sieht das so aus:

Navigationsleiste mit height:1.6em und langem Titel

hier steht ein wegklappbarer Inhalt

 

ohne height: 1.6em; sieht das so aus:

Navigationsleiste ohne height:1.6em und langem Titel

hier steht ein wegklappbarer Inhalt

 

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:

Vorlage:Navigationsleiste Hansestädte

Mitgliedstaaten des Deutschen Bundes (1815–1866)

Nicht verschmolzene Navigationsleiste:

Mitgliedstaaten des Deutschen Bundes (1815–1866)

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)

Klassen, um Linkfarben anzupassen und Unterstreichung zu unterdrücken

span.linkcolor a:link, span.linkcolor a:visited { color:inherit; }
span.no_underline a:link, span.no_underline a:visited { text-decoration:none; }

Für die Vorlage:R-Sätze (12​‐​34​‐​56) wäre es praktisch, wenn man die automatische Unterstreichung und die blaue Linkfarbe unterdrücken könnte. Dann wäre ein ordentlicher Link auf den Artikel#Abschnitt möglich, und trotzdem wären Links orange (derzeit: orange, der Tooltip funktioniert aber nicht wie gewollt) und (nur) unterpunktet. Das wäre bestimmt auch bei anderen Erklärungen praktisch. Ich sehe keine Nachteil, wenn man die Definitionen einfügen würde. Im Gegenteil: Man könnte die Zeile ".IPA a:link" entfernen und die Vorlage:IPA entsprechend anpassen. Meinungen? --Revolus Echo der Stille 01:07, 7. Aug. 2008 (CEST)

Kleine Ergänzung: Vorlage:S-Sätze (12​‐​34​‐​56) würde davon auch profitieren. Die Links habe ich hier noch nicht aktiviert, so dass das gewünschte Erscheinungsbild sichtbar ist (bis auf die fehlenden Links natürlich). --Leyo 01:14, 7. Aug. 2008 (CEST)

Gibt es einen Grund für diese Farbgebung? Die Schriftfarbe ist nur schwer lesbar und sieht unnötig bunt im Gesamtbild aus. Code·is·poetry 12:47, 7. Aug. 2008 (CEST)

Ausgesprochen schlecht lesbar, die Farbe, gerade auf weißem Hintergrund. Bitte nochmal gründlich Gedanken machen, ob eine von Blau/Schwarz verschiedene Farbe notwendig ist. --Gnu1742 13:30, 7. Aug. 2008 (CEST)

Im wesentliche stimme dem Gnu zu, zumal ich keinen Grund erkennen kann. Zu bedenken geben möchte ich noch, dass die Unterstreichung eine Option in den Benutzereinstellungen ist. Wenn jemand lieber alle Links unterstrichen mag, sollte man ihm dies nicht für einzelne Links wegnehmen. Insgesamt plädiere ich für einheitliche Linkgestaltung. — Raymond ^{Disk. Bew.} 13:52, 7. Aug. 2008 (CEST)

Zur Farbgebung: Bei den R- und S-Sätzen handelt es sich um Warnhinweise, die in den meisten Fällen innerhalb der verschiedenen chemischen Infoboxen angezeigt werden (siehe beispielsweise Aldrin). Daher wurde (vor langer Zeit und als Resultat von langen Diskussionen um die Chemobox) diese orange Farbe gewählt. Im Übrigen ist die Farbe in der vorgeschlagenen Ergänzung ja nicht enthalten.

Vorher waren da keine Links. Diese sind nur als alternative Möglichkeit zu den Tooltips gedacht, weil dort teilweise nicht der gesamte Text angezeigt wird. Daher entfällt IMHO hier das Argument der einheitlichen Linkgestaltung. --Leyo 14:04, 7. Aug. 2008 (CEST)

OK, daß es vorher dort war hab ich jetzt übersehen. Dennoch bleibt meine Kritik an der Färbung der Zeichen: Bei großflächigen Warnzeichen funktioniert die Warnung, weil durch die große Fläche einer grellen Farbe generell Aufmerksamkeit erzeugt wird ('Oha, da is irgendwas gefählich!') um die Gefahr dann durch das immer noch große, leicht zu erfassende Icon näher zu spezifizieren. Buchstaben hingegen sind an und für sich kleinteiliger und bestehen aus dünnen Strichen, die man eher übersieht, insbesondere bei dieser zum weißen sehr kontrastarmen Farbe. Auf einem realen Chemikalien-Etikett stehen diese Warnziffern doch auch Schwarz auf weißem Grund (afaik), oder? Ich weiß, das gehört eher in die Vorlagendiskussion, aber vllt. könnt ihr das als Anregung dorthin mit übernehmen. Grüßle, --Gnu1742 14:55, 7. Aug. 2008 (CEST)

Beim letzten Punkt stimme ich dir zu: Falls du die Farbe zur Diskussion stellen willst, bitte in der Redaktion Chemie. --Leyo 15:52, 7. Aug. 2008 (CEST)

Zur Diskussion gestellt: WP:RC#Schriftfarbe von R/S-Sätzen. --Revolus Echo der Stille 14:40, 8. Aug. 2008 (CEST)

Nachdem es hier nun ja nicht mehr um spezifische Farben geht, sondern um die vorgeschlagene Ergänzung: Gibt es Einwände dazu? Dass damit nicht an Linkfarben und Unterstreichungen im Artikeltext „herumgepfuscht“ werden soll, versteht sich natürlich von selbst. Es wäre nur für spezifische Anwendungen einzusetzen, wie bei den erwähnten Vorlagen für die R- und S-Sätze. --Leyo 16:45, 8. Aug. 2008 (CEST)

Ja, es gibt Einwände. Das Aussehen von Links zu verändern gilt generell als schlechte Usability. Wikipedia hat eh schon zig unterschiedliche Linkfarben, je nachdem ob extern oder intern, existierender Artikel oder leere Seite, kurzer oder langer Artikel. Jetzt wollt ihr noch orange Links einführen: dagegen. Macht die Dinger blau, dann sieht der Leser sofort, dass er da noch auf einen weiterführenden Artikel kommt. --Elian Φ 13:07, 9. Aug. 2008 (CEST)

Nicht ganz richtig: Die „Dinger“ sind schon lange orange und haben Tooltips. Die Links sind für die wenigen Fälle da, wo nicht der gesamte Text im Tooltip angezeigt wird. Dies ist beispielsweise in Uranylnitrat der Fall. --Leyo 13:44, 9. Aug. 2008 (CEST)

"Gesichtet"-Kästchen (erl.)

Mit #mw-revisiontoggle { float:right; margin-left:1ex; } würde das (+/-) nach dem Anklicken an seinem Platz bleiben. Wenn man nur kurz gucken will, was sich dahinter verbirgt, ist es für einen Moment verwirrend, wenn der "Link" verschwunden zu sein scheint. Er ist zwar nur nach links verrutscht, aber es ginge auch besser :-) --Revolus Echo der Stille 02:38, 7. Mai 2008 (CEST)

gute Idee. -- San Jose 14:11, 7. Mai 2008 (CEST)

Da hatte noch einer die Idee. --Revolus Echo der Stille 22:09, 7. Mai 2008 (CEST)

Archivierung dieses Abschnittes wurde am 22:09, 7. Mai 2008 (CEST) gewünscht von Revolus Echo der Stille

Fehler bei .Unicode

Bei den Klassen .Unicode, .Unicode1 sowie .Unicode2 sind Code2000, Code2001 und Code2002 jeweils getrennt geschrieben (also Code 2000, Code 2001 und Code 2002). Die Schriftnamen müssen aber zusammengeschrieben werden. -- Prince Kassad 19:35, 27. Mär. 2008 (CET)

Repariert. — Raymond ^{Disk. Bew.} 19:41, 27. Mär. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:24, 6. Okt. 2008 (CEST)

Anpassungen für Taxoboxen und Paläoboxen

Ich möchte bitten, das die tabellen von den beiden Boxen zusätzlich ein clear: right; erhalten. Mein hier erzeugter Diff ist nicht gut gelungen, da es irgendwie Probleme bei den leeren Absätzen gibt, aber vielleicht kann man doch etwas damit anfangen. Da dadurch wird erreicht, das die boxen nach unten wandern und nicht zuseite, sofern beispielsweise die "gesichtet" box wieder am artikelanfang steht, ähnlich der class "float-right". Eine schnelle Umsetzung wäre nett. Ich komme auch gerne für entstandene unannehmlichkeiten auf. Der Umherirrende 13:43, 17. Mai 2008 (CEST)

Ausführlich:

 /* Stylesheet-Ergänzung zu [[Wikipedia:Taxoboxen|Taxoboxen]] */

 table.taxobox {
        border-collapse: collapse;
        border: 1px solid gray;
        float: right;
        margin-left: 0.5em;
        background-color:white;
 }

wird zu

 /* Stylesheet-Ergänzung zu [[Wikipedia:Taxoboxen|Taxoboxen]] */

 table.taxobox {
        border-collapse: collapse;
        border: 1px solid gray;
        float: right;
        clear: right;
        margin-left: 0.5em;
        background-color:white;
 }

und

 /* Stylesheet-Ergänzung zu [[Wikipedia:Paläoboxen|Paläoboxen]] */

 table.palaeobox {
       border-collapse: collapse;
       border: 1px solid gray;
       float: right;
       margin-left: 0.5em;
       background-color:white;
 }

wird zu

/* Stylesheet-Ergänzung zu [[Wikipedia:Paläoboxen|Paläoboxen]] */

 table.palaeobox {
       border-collapse: collapse;
       border: 1px solid gray;
       float: right;
       clear: right;
       margin-left: 0.5em;
       background-color:white;
 }

Vielen Dank. Der Umherirrende 13:48, 17. Mai 2008 (CEST)

Erledigt. — Raymond ^{Disk. Bew.} 17:03, 17. Mai 2008 (CEST)

Danke, so sehen die Artikel schon viel besser aus. Der Umherirrende 18:04, 17. Mai 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:24, 6. Okt. 2008 (CEST)

padding der Hieroglyphen

Hai, Könnte jemand die css-class .mw-hierotable und die erweiterung .mw-hierotable th, .mw-hierotable td no zusätzlich ein padding:0px; hinzufügen? Das Problem ohne diese Definition ist, dass die Hieroglyphen (ohne das "padding:0px;") in einer Tabelle mit der Klasse prettytable einen grösseren Abstand aufweisen. So ist es nicht mehr möglich eine schöne Hieroglyphenkartusche oder ein Serech drum zu bauen.

Also neu:

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

Dies Änderungen habe ich mit meinem monobook.css getestet. danke&gruss--kajk ✉ 12:02, 4. Jun. 2008 (CEST)

Hallo? Aus welchen Gründen werden diese Änderungen nicht eingefügt? gruss--kajk ✉ 13:56, 16. Jun. 2008 (CEST)

Moin, ist jetzt drin. Sorry, hat wohl vorher einfach niemand gesehen. :( Viele Grüße, —mnh·∇· 14:01, 16. Jun. 2008 (CEST)

np, danke viel mals :-) gruss--kajk ✉ 13:21, 17. Jun. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:24, 6. Okt. 2008 (CEST)

".reference, .references sup" könnte "white-space:nowrap" gut vertragen (erl.)

Schon bei ganz simplen Gruppen-Refs wie <ref group="a"> entstehen allzu leicht „hässliche“ Zeilenumbrüche innerhalb ^{„[a 1]“}. Da aber das Verwenden von <span style="white-space:nowrap;"><ref group="a">...</ref></span> manche Gemüter sehr stark zu irritieren scheint (EditWar und Vandalismusmeldung), halte ich es für empfehlenswert MediaWiki:Common.css mit "white-space:nowrap" an der entsprechenden Stelle zu ergänzen.

• <references group="a"/>

Beispiel <ref group="a">

--ParaDox 17:56, 23. Jun. 2008 (CEST)

Done. Dafür ist die Common.css da. —mnh·∇· 18:41, 23. Jun. 2008 (CEST)

Vielen Dank :-)  Bin froh dass der Zwist ein so schnelles und einfaches Ende finden konnte. Die <span>s habe ich selbst entfernt (A B).Gruß, --ParaDox 18:50, 23. Jun. 2008 (CEST)

Dito und danke für's Entfernen. Viele Grüße, —mnh·∇· 19:06, 23. Jun. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:24, 6. Okt. 2008 (CEST)

CommonsTicker

Ich glaube nicht, dass dieses Zeug von allgemeinem Interesse ist. Ich wäre für eine Auslagerung in ein Gadget. Meinungen? Gruß, Code·is·poetry 15:28, 1. Jul. 2008 (CEST)

da hast Du sicherlich recht - das braucht keinesfalls für jeden benutzer geladen zu werden --W!B: 01:31, 8. Jul. 2008 (CEST)

Ich habe es erstmal komplett rausgenommen, der Ticker läuft im Moment sowieso nicht. Code·is·poetry 10:27, 18. Jul. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:24, 6. Okt. 2008 (CEST)

height bei NavHead entfernen

Vor einem knappen Jahr habe ich bereits das störende height bei der CSS-Klasse NavHead angesprochen: MediaWiki Diskussion:Common.css/Archiv/1#height bei NavHead. Die Vorlagenwerkstatt ist auf das gleiche Problem gestoßen und hat mich angesprochen: Benutzer Diskussion:Fomafix#WP:WVW#Vorlage:Kopfzeile Kategoriesystem Planen und Bauen. height:1.6em sollte entfernt werden, da die Höhenangabe nicht benötigt wird und nur für Darstellungsfehler sorgt.

Das Problem ist aber der Internet Explorer bis zur Version 6. Dort bewirkt height:1.6em zwar keine unnötige Höhenangabe, aber behebt einen anderen Darstellungsfehler. Folgende Navigationsleiste

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

sieht derzeit mit height: 1.6em; so aus:

Mehrzeile
Überschrift

hier steht ein wegklappbarer Inhalt

 

Ohne height: 1.6em; würde sie so aussehen und hat beim Internet Explorer 6 Darstellungsprobleme:

Mehrzeile
Überschrift

hier steht ein wegklappbarer Inhalt

 

Als Workaround hatte ich damals .NavFrame { width:100% } vorgeschlagen, was aber geringe Nebeneffekte hat. Eine bessere Methode ist daher .NavFrame, .NavToggle, .NavPic { position:relative }.

Klappen

Mehrzeile
Überschrift

hier steht ein wegklappbarer Inhalt

 

Bitte height:1.6em entfernen und .NavFrame, .NavToggle, .NavPic { position:relative } als Workaround für den Internet Explorer 6 einbauen. --Fomafix 17:29, 25. Aug. 2008 (CEST)

Ich unterstützte diese Bitte vollumfänglich. Gruß --W_I^KImaniac 20:54, 25. Aug. 2008 (CEST)

+1 --Revolus Echo der Stille 21:31, 28. Aug. 2008 (CEST)

Ich habe die Änderung getestet. Ich konnte auch bei anderen Verwendungen des Klappmechanismus wie bei Bundesautobahn 7 keine Nebenwirkungen feststellen. Bitte height:1.6em; entfernen. --Fomafix 18:12, 28. Aug. 2008 (CEST)

Von mir auch +1. Dann benötigen wir noch einen Admin, der das umsetzt. Cäsium137 (D.) 21:35, 28. Aug. 2008 (CEST)

Genau dafür gibt es ja WP:AAF. Erledigt. — ^PDD — 08:46, 29. Aug. 2008 (CEST)

Danke! Gruß --W_I^KImaniac 21:01, 29. Aug. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:24, 6. Okt. 2008 (CEST)

TownBox

Die CSS-Klasse TownBox ist in die MediaWiki:Common.css eingebunden worden. Wird/wurde diese Klasse verwendet? Soll sie verwendet werden? Wikipedia:TownBox ist als Archiv deklariert. Wenn die CSS-Klasse nicht gebraucht wird, könnte entfernt wieder werden. --Fomafix 15:08, 16. Jul. 2008 (CEST)

Das wurde eingebunden, da global entfernt, aber noch einbindungen vorhanden waren. Nach der Aussage hier kann es aber wohl wieder entfernt werden. Der Umherirrende 15:23, 16. Jul. 2008 (CEST)

Auf Basis des Dumps vom 25. Juli habe ich das Wort "TownBox" nicht gefunden, daher sollte dieser Edit rückgängig gemacht werden. Der Umherirrende 17:38, 8. Okt. 2008 (CEST)

Der Name TownBox eignet sich nicht als Universalklasse, auch wenn die CSS-Definition im Prinzip dazu geeignet wäre. .infobox könnte eine passende Universalklasse werden. Da TownBox im Dump nicht verwendet wird sollte die CSS-Definition entfernt werden. --Fomafix 21:33, 8. Okt. 2008 (CEST)

Ist entfernt. Code·is·poetry 11:37, 9. Okt. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:59, 9. Okt. 2008 (CEST)

Abstand vor Inhaltsverzeichnis

Die Box mit dem Inhaltsverzeichnis hat keinen eigenen Rand außen herum, also .toc { margin: 0 }. Die Abstände zur darüber oder darunter liegenden Box werden durch die jeweiligen Boxen definiert. Nach dem Inhaltsverzeichnis kommt üblicherweise die erste Überschrift, die einen angemessenen oberen Rand hat. Vor dem Inhaltsverzeichnis steht normalerweise Fließtext mit dem Abstand p { margin-bottom: 0.5em } aus http://de.wikipedia.org/skins-1.5/monobook/main.css. Steht vor dem Inhaltsverzeichnis eine Aufzählung wie bei Balkentheorie, so gilt ul, ol { margin-bottom: 0 }. Der Abstand vor dem Inhaltsverzeichnis ist hier zu gering und wird häufig mit doppelten Leerzeichen erhöht [6]. Dieser „Fehler“ sollte per CSS korrigiert werden.

Ein Ändern des Rands von ul oder ol verbietet sich. Ein generelles .toc { margin-top: 0.5em } funktioniert und teste ich auch schon seit fast einem Jahr [7]. Diese Methode hat aber den Nachteil, dass in den seltenen Fällen, bei denen das Inhaltsverzeichnis in einer Box verwendet wird, wie bei St. Leonhard (Graz), ein zu großer Abstand oben zum Außenrahmen der Box ist. Die Wirkung könnte aber auf ul oder ol eingeschränkt werden:

ul + .toc, ol + .toc { margin-top: 0.5em }

Wäre das eine geeignete und sinnvolle Definition für MediaWiki:Common.css? --Fomafix 12:55, 8. Okt. 2008 (CEST)

Ja, ich halte eine solche definition für sinnvoll, da es ein einheitlicheres aussehen verspricht und auch keine anderen Nebenwirkungen erkennbar sind. Ob allerdings ein Inhaltsverzeichnis in einer Box verwendet werden muss, stellt ich mal dahin, aber das ist eine andere Frage.  Pro Der Umherirrende 17:35, 8. Okt. 2008 (CEST)

Die Infobox in der Box war vermutlich ausversehen, ich fixe das gerade. Der von dir vorgeschlagene Code ändert nur das Aussehen direkt nach Listen, oder verwendet MediaWiki ul/ol noch in einem anderen Kontext? So weit sehe ich jedenfalls nichts, was dagegen spricht. Code·is·poetry 19:08, 8. Okt. 2008 (CEST)

Inhaltsverzeichnisse in Infoboxen hatte ich im Artikelnamensraum bisher nur bei den Stadtbezirken von Graz gesehen. In Portalen oder Benutzerseiten werden solche Spielereien auch ab und zu gemacht. Mein Vorschlag ändert nur den Abstand vor dem Inhaltsverzeichnis, wenn direkt darüber eine Aufzählung kommt. Die Abstände um ul/ol wird mit dieser Definition nicht geändert, so dass die Darstellung von anderen ul/ol in MediaWiki nicht beeinflusst wird. --Fomafix 08:58, 9. Okt. 2008 (CEST)

Ist eingefügt. Code·is·poetry 11:37, 9. Okt. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:59, 9. Okt. 2008 (CEST)

Wunsch

Hallo! Ich bitte um das Hinzufügen folgender Zeilen:

.nnbsp{font-size:50%;}

@media print {
	.nnbsp{margin-left:0.167em;}
	.IfNotPrinted{display:none;}
}

Der Hintergrund dazu findet sich hier (ziemlich weit unten). --Quilbert 問 16:19, 28. Jun. 2008 (CEST)

Ich hoffe mal, dass die Vorlage bald gelöscht wird und damit die Sache hier erledigt ist. Jedenfalls nicht vor Ende der Löschdiskussion umsetzen. Code·is·poetry 16:34, 28. Jun. 2008 (CEST)

bleibt - als workaround für gut befunden - das eintragen wär also toll, damit wir den code der vorlage straffen können - insbesondere könnte man es mit dem workaround für den nbsp; vor % (wo auch immer der steht) zusammenlegen: vor % stünde korrekt auch ein schmales leerzeichen.. --W!B: 01:30, 8. Jul. 2008 (CEST)

€ wäre auch so ein fall, das wie % immer nicht-umbrechend ist.. --W!B: 18:15, 9. Jul. 2008 (CEST)

Vorlage:\ ist gelöscht, damit ist diese Anfrage hinfällig. Ab ins Archiv. --Fomafix 15:30, 15. Dez. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 15:30, 15. Dez. 2008 (CET)

add request

#geo-microformat {display:none;}

→ Hintergrund

Danke -- visi-on 22:46, 21. Nov. 2008 (CET)

Im Projekt WP:GEO benutzt die Vorlage:Coordinate das «geo-microformat» zur semantischen Auszeichnung des Texts. Der Inhalt dieses Tags ist nicht für den Leser bestimmt. Daher wäre es wünschenswert diese Einstellung

.geo {display:none;}

hier global vorzunehmen.-- visi-on 10:31, 25. Nov. 2008 (CET) erledigtErledigt Danke -- visi-on 18:32, 25. Nov. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 15:30, 15. Dez. 2008 (CET)

.spanAr

sollte geändert werden von

span.spanAr
{
 font-family:
 'Arial Unicode MS',
 'Code2000',
 'MPH 2B Damase',
 'DejaVu Sans',
 sans-serif;
}

in

span.spanAr
{
 font-family:
 'Arial Unicode MS',
 'Scheherazade',
 'Code2000',
 'DejaVu Sans',
 sans-serif;
}

Hintergrund: MPH 2B Damase unterstüzt überhaupt kein Arabisch, daher hat es in der CSS-Klasse nichts zu suchen. Da allerdings auch die anderen Schriften nicht besonders gut in der Darstellung des Arabischen sind, sollte die freie Scheherazade-Schrift hinzugefügt werden. -- Prince Kassad 16:33, 11. Nov. 2008 (CET)

1. MPH 2B Damase enthält 198 Zeichen im Block Arabisch Standard. Wieso sollen da deiner Meinung nach keine drin sein ?
2. Wo kann man "Scheherazade" downloaden ? Das sollten sich alle Wikipedianer anschauen können, bevor etwas geändert wird.

Cäsium137 (D.) 23:34, 11. Nov. 2008 (CET)

1. Arabisch ist allerdings eine Schrift, die OpenType-Layoutinformationen braucht, um die kontextabhängigen Formen korrekt darstellen zu können. Die fehlen in MPH 2B Damase.
2. [8] -- Prince Kassad 08:06, 12. Nov. 2008 (CET)

Was ist mit "Arabic Presentation Forms" A und B ? Die werden auf der Downloadseite als fehlend deklariert. Cäsium137 (D.) 13:39, 12. Nov. 2008 (CET)

Es ist nicht sehr tragisch, wenn die fehlen - auf der de.wp fällt mir außer den Unicode-Tabellen keine Seite ein, die diese Zeichen benutzt. -- Prince Kassad 18:10, 12. Nov. 2008 (CET)

Dann stelle auf WP:AAF eine Anfrage zur Änderung. Cäsium137 (D.) 19:54, 12. Nov. 2008 (CET)

Übernommen: [9]. --32X 20:21, 17. Dez. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:56, 19. Dez. 2008 (CET)

Änderungen in Klassik-Skin

Seit kurzem fehlen mir in der Klassik-Skin die "Letzten Änderungen", die früher oben verlinkt waren, und in der Seitenleiste fehlen die "Links auf diese Seite". Wer ändert sowas, und warum? Wie kann ich das wiederherstellen? -- Nina 23:39, 24. Dez. 2008 (CET)

Hallo Nina, ich glaube, da musst du mal auf MediaWiki:Sidebar schauen. Gruß, --Revolus Echo der Stille 23:54, 24. Dez. 2008 (CET)

Danke, dann versuch ich es da mal. -- Nina 00:00, 25. Dez. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:16, 20. Mär. 2009 (CET)

Zentrierte Tabellen und Galerien

HTML 4 bietet bei dem Element table das Attribut align="center" an. Es bewirkt eine horizontale Zentrierung der Tabelle und ist von der Wirkung her gleich wie die CSS-Definition margin-left:auto; margin-right:auto. Das Attribut align ist bei Tabellen zwar als deprecated markiert, aber weiterhin erlaubt und wird von MediaWiki auch durchgereicht. Auch alle Browser verstehen das Attribut, haben aber bei einer gleichzeitigen CSS-Definition der Ränder eine unterschiedliche Interpretationen der Priorität. Die Tabelle

<table align="center" style="margin-left:0; margin-right:0">

Tabelle

wird beim Firefox und Konqueror linkbündig dargestellt, während sie beim Internet Explorer und Opera zentriert wird. Beim Firefox und beim Konqueror haben demnach CSS-Definitionen immer Vorrang vor HTML-Attributen.

Für eine normale Tabelle spielt dieses Verhalten keine Rolle, weil niemand beide Angaben gleichzeitig explizit angibt. Bei der CSS-Klasse wikitable und bei Galerien, die auch Tabellen sind, werden aber mit margin Ränder definiert. Somit werden folgende Stilelemente von den Browsern unterschiedlich dargestellt:

{| class="wikitable" align="center"
| Tabelle
|}

Tabelle

<gallery align="center">
Bild:Feather 150 transparent.png
</gallery>

• 

Für wikitable gibt es daher die CSS-Klasse .centered { margin-left: auto; margin-right: auto; }, mit der sich Tabellen zentrieren lassen.

{| class="centered wikitable"
| Tabelle
|}

Tabelle

Bei Galerien wirkt class="centered" nicht, weil .centered eine geringere Priorität hat als table.gallery aus http://de.wikipedia.org/skins-1.5/monobook/main.css.

<gallery class="centered">
Bild:Feather 150 transparent.png
</gallery>

• 

Die Probleme der unterschiedlichen Darstellung und die fehlende Zentrierung bei Galerien lassen sich per CSS korrigieren. Mit folgender CSS-Definition würde align="center" auch bei einer CSS-Randangabe funktionieren:

table[align=center] { margin-left: auto; margin-right: auto; }

Mit folgender Erweiterung wirkt centered auch bei Galerien:

.centered, table.centered { margin-left: auto; margin-right: auto; }

Diese CSS-Definitionen würde die Darstellung in den Browsern vereinheitlichen. Sollten sie in MediaWiki:Common.css übernommen werden? --Fomafix 00:24, 22. Okt. 2008 (CEST)

Durch diese Änderung werden können nun Galerien folgendermaßen zentriert werden: --Fomafix 12:58, 15. Jun. 2009 (CEST)

<gallery class="centered">
Bild:Feather 150 transparent.png
</gallery>

• 

Cache neu laden nicht vergessen. --Fomafix 12:58, 15. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 12:58, 15. Jun. 2009 (CEST)

float-right geht nicht mehr durch Änderung in MediaWiki

Die CSS-Klasse wikitable für Tabellen ist in http://de.wikipedia.org/skins-1.5/common/shared.css aufgenommen worden:

/* wikitable class for skinning normal tables */
table.wikitable {
    margin: 1em 1em 1em 0;
    background: #f9f9f9;
    border: 1px #aaa solid;
    border-collapse: collapse;
}
.wikitable th, .wikitable td {
    border: 1px #aaa solid;
    padding: 0.2em;
}
.wikitable th {
    background: #f2f2f2;
    text-align: center;
}
.wikitable caption {
    font-weight: bold;
}

Sie ist aber etwas anders als unsere bisherige Definition in MediaWiki:Common.css:

/* aus Vorlage zur Entlastung, skinabhängigen Darstellung und Kombinierbarkeit hierher ausgelagert */
 .wikitable,
 .prettytable {
  margin: 1em 1em 1em 0;
  background: #f9f9f9;
  border: 1px #AAA solid;
  border-collapse: collapse;
  empty-cells:show;
 }
 
 .wikitable th, .wikitable td,
 .prettytable th, .prettytable td {
  border: 1px #AAA solid;
  padding: 0.3em;
 }
 
 .wikitable caption,
 .prettytable caption {
  margin-left: inherit;
  margin-right: inherit;
  font-weight: bold;
 }

Das durch das zusätzliche table.wikitable lässt sich der margin nicht mehr durch eine Klasse .float-right überschreiben. Daher sind beim üblichen

{| class="wikitable float-right"

falsche Seitenabstände. Bitte folgendes

 .float-left { float: left; clear: left; }
 .float-right { float: right; clear: right; margin: 1em 0 1em 1em; }
 .centered { margin-left: auto; margin-right: auto; }

ersetzten durch

 div.float-left, table.float-left, .float-left { float: left; clear: left; }
 div.float-right, table.float-right, .float-right { float: right; clear: right; margin: 1em 0 1em 1em; }
 div.centered, table.centered, .centered { margin-left: auto; margin-right: auto; }

--Fomafix 12:15, 15. Jun. 2009 (CEST) Ich habs mal umgesetzt. --Taxman^¿Disk? 12:46, 15. Jun. 2009 (CEST)

Danke. Die Tabellen sind nun wieder am rechten Rand.

Wichtig: Cache neu laden!

--Fomafix 12:55, 15. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 12:55, 15. Jun. 2009 (CEST)

Sichtungskästchen auf der Hauptseite

Kann jemand bitte das Sichtungskästchen auf der Hauptseite bitte abstellen? Dort ist es doch unnötig.

body.page-Hauptseite #mw-revisiontag {
	display: none;
}

--V·R·S (☣|☢) 16:48, 6. Mai 2008 (CEST)

Allgemein sollte es keine Texte/Bilder überlappen. (von 87.78.33.29, nachgetragen von V.R.S.)

Das Problem tritt nicht auf. Außerdem ist body.page-Wikipedia_Hauptseite #contentSub inzwischen ausgeblendet und damit auch ein eventuelles Sichtungskästchen auf der Hauptseite. --Fomafix 13:08, 19. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 13:08, 19. Jun. 2009 (CEST)

falsche Darstellung in Klassik-Skin

Seit kurzem fehlt in der Klassik-Skin bei Tabellen die linke Begrenzungslinie (sowohl bei class="wikitable" als auch bei class="prettytable". Wurde da irgendwas geändert, und wenn ja, was? Wie kann man die Tabellen reparieren? -- Nina 23:19, 25. Dez. 2008 (CET)

Nicht nachvollziehbar. Darstellung ist korrekt: http://de.wikipedia.org/w/index.php?title=Hilfe:Tabellen&useskin=standard --Fomafix 13:00, 19. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 13:00, 19. Jun. 2009 (CEST)

Außenrahmen in prettytable

Bitte den LINKEN Außenrahmen auch auf 1em setzen. Derzeit fließt der Text pixelgenau bis an die prettytable dran. --Bodo Thiesen 22:54, 2. Apr. 2008 (CEST)

done. --DaB. 23:46, 2. Apr. 2008 (CEST)

Danke für die schnelle Reaktion. Sieht jetzt schon viiiiieeeel besser aus ;) --Bodo Thiesen 00:05, 3. Apr. 2008 (CEST)

immer noch gut? hab das CSS noch ein klein wenig verkürzt. -- ∂ 00:54, 3. Apr. 2008 (CEST)

Was soll denn diese Änderung? Der linke Rand von Tabellen ist nun nicht mehr übereinstimmend mit dem linken Rand des Fließtextes. Die Tabellen erscheinen eingerückt. Von Links kommt normalerweise nie Text an die Tabelle ran, es sei denn sie ist mit style="float:right" ein Fließobjekt am rechten Rand. Laut Hilfe:Tabellen soll aber da die CSS-Klasse float-right verwendet werden, die einen Abstand am linken Rand definiert:

.float-right { float: right; clear: right; margin: 1em 0 1em 1em; }

Gibt es noch eine andere Situation, bei der der Fließtext an den linken Rand kommen kann? --Fomafix 15:58, 3. Apr. 2008 (CEST)

Haben nebeneinander stehende Tabellen seit der Änderung einen größeren Abstand oder kommt mir das nur so vor? Grüße, -- Zef 18:43, 3. Apr. 2008 (CEST)

Hallo, ich sehe das wie Fomafix. Deshalb bitte ich auch darum, die Änderung rückgängig zu machen. Mit der CSS-Klasse prettytable formatierte Tabellen stehen normalerweise links oder rechts von anderen Elementen, die ihrerseits Abstand nach rechts erzwingen, wenn sie selber nicht anders positioniert werden. Idealerweise geschieht dies mit den zusätzlichen CSS-Klassen float-right oder centered, um sie rechts auszurichten beziehungsweise zu zentrieren. Im ersten Fall wird gleichzeitig ein Abstand nach links festgelegt, im anderen Fall fließt kein Text um die Tabelle. Ein anderer Effekt der Änderung ist tatsächlich, dass zwei nebeneinander stehende prettytable-Tabellen (die erste zusätzlich mit der CSS-Klasse float-left versehen) jetzt den doppelten Abstand voneinander haben. --Wiegels „…“ 21:01, 3. Apr. 2008 (CEST)

"prettytable" darf keinerlei Seitenabstand haben. Bei einer Breite von 100% steht die Tabelle sonst über. Der Seitenabstand muss bei float-right und float-left eingestellt werden. Also bitte folgenden Standard herstellen:

 .wikitable,
 .prettytable {
    margin: 1em 0em;
    background: #f9f9f9;
    border: 1px #AAA solid;
    border-collapse: collapse;
    empty-cells:show;
 }

 .wikitable th, .wikitable td,
 .prettytable th, .prettytable td {
    border: 1px #AAA solid;
    padding: 0.3em;
 }

 .wikitable caption,
 .prettytable caption {
    font-weight: bold;
 }

 .nogrid th, .nogrid td {
    border: none;
 }

 .float-left {
    float: left;
    clear: left;
    margin: 1em 1em 1em 0em;
 }

 .float-right {
    float: right;
    clear: right;
    margin: 1em 0em 1em 1em;
 }

 .centered {
    margin-left: auto;
    margin-right: auto;
 }

Die beiden Zeilen:

 margin-left: inherit;
 margin-right: inherit;

gehören auch nicht hinein. Sie sind nicht CSS-Standard, sondern spezifisch für Netscape 4.0 . die Verwendung zerstört die Browserunabhängigkeit der Commons.css ! Cäsium137 (D.) 00:21, 4. Apr. 2008 (CEST)

Das klingt überzeugend. Den Fall der 100-%-Streckung hatte ich nicht bedacht, weil ich ihn nicht verwende. Sollte es danach Beschwerden geben, ist in Einzelfällen wahrscheinlich class="prettytable" style="float:left;" durch class="prettytable float-left" zu ersetzen, analog im Fall des Antragstellers auf der anderen Seite. --Wiegels „…“ 03:23, 4. Apr. 2008 (CEST)

Ich finde von Cäsium137, den rechten Rand nur bei float-left zu setzen, konsequent und gut. Es gibt ein Problem: Bei folgender häufigen Verwendung fehlt dann aber der bisher gewohnte Abstand zwischen den Tabellen:

{|
|- valign="top"
|
{| class="prettytable"
| linke prettytable
|}
|
{| class="prettytable"
| rechte prettytable
|}
|}

sieht derzeit so aus:

linke prettytable

rechte prettytable

sah bisher so aus:

linke prettytable

rechte prettytable

und wird mit dem Vorschlag von Cäsium137 so aussehen:

linke prettytable

rechte prettytable

Ich kann mich mit dieser Darstellung anfreunden. Die derzeitige Darstellung mit margin-left:1em geht aber überhaupt nicht.

Eine weitere Bitte habe ich noch: Die Tabellenzellen bekommen mit .prettytable td { padding: 0.3em; } einen angemessenen Abstand. Bei der Tabellenbeschriftung fehlt das noch. Ich schlage daher folgendes vor: .prettytable caption { padding: 0.3em; }. Ich teste das schon seit vier Monaten. --Fomafix 09:47, 4. Apr. 2008 (CEST)

Das beiden Zeilen

.wikitable caption,
.prettytable caption {
  margin-left: inherit;
  margin-right: inherit;
}

werden für den aktuellen Firefox 2 benötigt, sonst kommt es zu einer Falschdarstellung bei:

{| class="prettytable centered"
|+ Beschriftung der Tabelle
|-
| Tabellenkörper
|}

ohne margin-left: inherit; margin-right: inherit;

Beschriftung der Tabelle

Tabellenkörper

mit margin-left: inherit; margin-right: inherit;

Beschriftung der Tabelle

Tabellenkörper

margin-left: inherit; ist nach CSS 2.1 normalerweise nicht notwendig, aber trotzdem erlaubt. Der Firefox verhält sich bei <caption> leider noch nach CSS 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=297676 --Fomafix 11:12, 4. Apr. 2008 (CEST)

Das margin-left:inherit; margin-right:inherit; war beim Firefox bisher nicht nur bei dem selteneren Fall centered notwendig, sondern auch bei einer normalen Tabelle mit Beschriftung. Bei folgender Tabelle sind viele „l“s hintereinander und ein einzelnes „l“ sowohl in der Beschriftung, als auch im Tabellenkörper. Beide „l“s sollten exakt übereinander sein.

l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l
l

l Tabellenkörper

Mit margin-left:inherit; margin-right:inherit; ist die Beschriftung nur so breit wie die Tabelle und die Mitte bleibt die Mitte:

l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l
l

l Tabellenkörper

Hoffentlich wird der Fehler im Firefox mit der Version 3 behoben. Bitte voten, vielleicht hilf’s. --Fomafix 14:02, 4. Apr. 2008 (CEST)

Hier ist nochmal die Zusammenfassung der CSS-Definition:

.wikitable,
.prettytable {
   margin: 1em 0em;
   background: #f9f9f9;
   border: 1px #aaa solid;
   border-collapse: collapse;
   empty-cells: show;
}

.wikitable th, .wikitable td,
.prettytable th, .prettytable td {
   border: 1px #aaa solid;
   padding: 0.3em;
}

.wikitable caption,
.prettytable caption {
   font-weight: bold;
   padding: 0.3em;
   margin-left: inherit;
   margin-right: inherit;
}

.nogrid th, .nogrid td {
   border: none;
}

.float-left {
   float: left;
   clear: left;
   margin: 1em 1em 1em 0em;
}
.float-right {
   float: right;
   clear: right;
   margin: 1em 0em 1em 1em;
}
.centered {
   margin-left: auto;
   margin-right: auto;
}

Bitte übernehmen. --Fomafix 14:02, 4. Apr. 2008 (CEST)

Ohne mich in die Diskussion einzumischen, was besser oder schlechter wäre, möchte ich doch drauf hinweisen, dass es in der CSS-Datei ausgesprochen sinnvoll ist, die Selektoren _mit_ dem Element-Typ zu qualifizieren, d.h. an Stelle von bspw.

.wikitable { your css goes here }

doch bittebittebitte

table.wikitable { your css goes here }

zu schreiben, um Nebeneffekte auszuschliessen. In einem System wie der Wikipedia wird GARANTIERT jemand mal jemand aus Versehen irgendwo einen Klassennamen setzen, der mit einem der hier besprochenen übereinstimmt, und sich dann wundern, warum es 'so komisch' aussieht'. Grüssle, --Gnu1742 14:46, 4. Apr. 2008 (CEST)

Hmm, warum? Die CSS-Klassen existieren seit über einem Jahr in der derzeitigen Form ohne Typ-Selektoren. Am 25. März 2007 wurden die Typ-Selektoren entfernt. Ich denke nicht, dass die Klassen seither unerwünscht aufgefallen sind. prettytable ist natürlich nur bei Tabellen wirklich sinnvoll. Bei einem DIV schadet es aber auch nicht:

div mit class="prettytable"

Außerdem ändert sich durch ein zusätzlichen Typ-Selektor die Gewichtung der Selektoren [10], dessen Auswirkung ich nicht abschätzen kann.

Die CSS-Klassen float-left, float-right und centered sind aber alle universell einsetzbar und sollten weiterhin für alle Elemente zur Verfügung stehen.

Die gleichwerten CSS-Klassen prettytable und wikitable finde ich hingegen als unnötige Doppelung. Meiner Meinung nach könnte eine Klasse entfallen. Dazu müsste aber zuvor per Bot alle Vorkommen der anderen Klassen ersetzt werden.

Erst mal muss aber unbedingt der Rand auf der linken Seite entfernt werden, damit

prettytable mit width:100%

wieder so aussieht

prettytable mit margin-left:0; width:100%

Die Änderung ist zu übernommen worden, ohne die Auswirkung richtig abzuschätzen. --Fomafix 12:18, 5. Apr. 2008 (CEST)

Bei verschachtelten Tabellen ist der Abstand mehrerer innerer Tabellen sinnvollerweise mit dem Attribut padding der obertabelle zu erreichen. Cäsium137 (D.) 17:42, 4. Apr. 2008 (CEST)

Das ist natürlich richtig. So würde ich den Abstand auch erzeugen. Ich will hier nur darauf hinweisen, dass wir hier bei mehreren zigtausend Artikeln die Abstände zwischen mehrspaltigen Tabellen verringern. Meiner Meinung nach ist das aber vertretbar. --Fomafix 12:18, 5. Apr. 2008 (CEST)

Sehe ich auch so. Das Bessere ist der Feind des Guten. Dies ist ja auch ein Effekt, der auf unpräzisen Quelltext zurückzuführen ist. Das ganze wird teilweise auch durch veraltete Angaben (deprecated) wie z. B. "cellpadding" verschärft. Cäsium137 (D.) 16:17, 5. Apr. 2008 (CEST)

cellpadding ist nicht deprecated. Weder bei HTML 4, noch bei XHTML 1.1. Allerdings ist es in HTML 5 nicht enthalten. Natürlich sehe ich es genauso, und verwende besser CSS-padding statt HTML-cellpadding. --Fomafix 13:02, 6. Apr. 2008 (CEST)

Langsam muss ich hier aber Vorwürfe erheben. Unnötige Vorschläge werden binnen weniger als einer Stunde aktiviert, aber trotz ausführlicher Begründung nach vier Tagen nicht zurückgekommen. --Fomafix 13:02, 6. Apr. 2008 (CEST)

Danke für’s zurücksetzen. --Fomafix 08:39, 8. Apr. 2008 (CEST)

Sorry, aber ich sehe auf dieser Seite nur sporadisch vorbei. Es war eben Zufall, das ich die Änderung innerhalb einer Stunde gesehen hatte. Wir haben über 200 Admins, da muss man nicht auf mich warten (oder man kann mir einen kurze Nachricht hinterlassen, wenn es unbedingt ich sein muss). --DaB. 17:42, 8. Apr. 2008 (CEST)

Firefox 3

Der Firefox 3 ist nun freigegeben. Einige Darstellungsfehler wurden behoben, aber nicht vollständig. Der Workaround für den Firefox bis zur Version 2 für Abstände bei den Tabellenbeschriftungen ist nicht mehr notwendig und sorgt nun für Darstellungsfehler beim Firefox 3:

.wikitable caption,
.prettytable caption {
   margin-left: inherit;
   margin-right: inherit;
}

Folgende einfache Tabelle mit Beschriftung

{| class="prettytable"
|+ l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l<br />l
|-
! l<br />Tabellenkörper
|}

wird so dargestellt:

l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l
l

l Tabellenkörper

Bzw. mit expandierter CSS-Klasse prettytable so:

l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l
l

l Tabellenkörper

Beim Firefox 3 und beim Opera ist die Beschriftungsbox ist auf der rechten Seite um 1em zu schmal. Beim Internet Explorer 6 und beim Firefox 2 ist die Beschriftungsbox korrekt gleich breit wie die Tabelle. Der Grund für die zu schmale Beschriftungsbox liegt in dem margin-right:inherit;. Die Beschriftungsbox übernimmt den rechten Rand von dem übergeordneten Objekt, der Tabelle. Der Internet Explorer interpretiert das margin-right:inherit; überhaupt nicht und ist daher nie betroffen. Der Firefox bis zur Version 2 benötigt das margin-right:inherit; für die Beschriftungsbox zwingend, denn sonst macht er die Beschriftungsbox so breit wie die Tabelle mit Rand. In CSS 2.0 war das mal ein korrektes Verhalten, aber beim aktuellen CSS 2.1 ist das falsch. Ohne margin-right:inherit; sieht die obige Tabelle so aus:

l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l
l

l Tabellenkörper

Wie Cäsium137 oben bereits erwähnte muss das margin-left:inherit; margin-right:inherit; aus der Common.css raus, da es bei CSS-2.1-konformen Browsern zu Darstellungsfehler sorgt und nur ein Workaround für den Firefox bis zur Version 2 ist. --Fomafix 22:04, 18. Jun. 2008 (CEST)

Bitte diesen Workaround für den Firefox 2 hier entfernen und ggf. in http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/monobook/FF2Fixes.css integrieren. Beim Firefox 3 und einigen anderen Browsern verursacht dieser Workaround die oben beschriebenen Darstellungsfehler. --Fomafix 10:29, 19. Jun. 2009 (CEST)

Firefox 3.5 ist nun freigegeben. Das Verhalten bezüglich caption ist gleich wie beim Firefox 3.0. Bug 478614 ist in Firefox 3.5 nicht behoben, wurde aber am 28. Juni 2009 im Trunk behoben.

Hier nochmal meine Bitte, die beiden Zeilen

.wikitable caption,
.prettytable caption {
  margin-left: inherit;
  margin-right: inherit;
}

zu entfernen, da sie nur ein Workaround für den Firefox bis zur Version 2 waren. In wikitable aus http://de.wikipedia.org/skins-1.5/common/shared.css sind sie schließlich auch nicht definiert. --Fomafix 12:51, 1. Jul. 2009 (CEST)

Entfernt. — Raymond ^{Disk. Bew.} 13:03, 1. Jul. 2009 (CEST)

Danke. --Fomafix 13:53, 1. Jul. 2009 (CEST)

Workarounds für Firefox 2.0 und älter sind nun aus der Datei entfernt. Die daraus resultierenden Darstellungsprobleme bei manchen aktuellen Browsern treten nun nicht mehr auf. Beim Firefox 2 und älter kann es nun zu verschobenen Tabellenüberschriften kommen, wenn die Tabelle zentriert ist. Das wäre eventuell ein Thema für http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/monobook/FF2Fixes.css, ist aber für hier erledigt.

Das vorgeschlagene .wikitable { margin-right:0 } halte ich zwar prinzipiell für gut, aber nicht für umsetzbar, da die Auwirkungen weitreichend wären. Vorallem ist in http://de.wikipedia.org/skins-1.5/common/shared.css auch table.wikitable { margin-right:1em } definiert.

Ein weiterer Vorschlag ist .wikitable durch table.wikitable zu ersetzen. Das sollte keine Auswirkung auf die Darstellung haben und bietet keine Vorteile oder Nachteile. Es besteht aber die Gefahr, dass <div class="wikitable"> irgendwo verwendet wird, dass dann nicht mehr funktioniert. Die Umstellung sollte meiner Meinung nach trotzdem erfolgen, da unter http://de.wikipedia.org/skins-1.5/common/shared.css ebenfalls so definiert ist. Die Umstellung geschieht am besten dadurch, dass die gesammte Definition von wikitable hier gelöscht und ausschließlich von http://de.wikipedia.org/skins-1.5/common/shared.css verwendet wird. Vorher muss aber die CSS-Knacknuss #Hintergrundfarbe Titelzellen gelöst werden. --Fomafix 13:53, 1. Jul. 2009 (CEST)

Wer einen "alten Firefox" hat, der sollte einfach die Zeilen in die eigene CSS schreiben. Dazu muss man nicht einmal wissen, wie genau das funktioniert. Cäsium137 (D.) 11:41, 6. Jul. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Cäsium137 (D.) 11:41, 6. Jul. 2009 (CEST)

.prettytable-Innenabstand

Ich würde sagen, man sollte den Innenabstand von pretttable-Tabellen verringern. Auf 0.3ex vielleicht. 0.3em sind doch recht viel und spreizen das Layout sehr. --Revolus Echo der Stille 23:48, 9. Jul. 2008 (CEST)

Das padding empfinde ich mit 0.3em auch recht groß. Der Abstand wurde an das cellpadding=? aus der ehemaligen Vorlage:Prettytable angepasst. Die fr:MediaWiki:Common.css verwendet auch 0.3em. en:MediaWiki:Common.css und viele andere Wikipedias verwenden 0.2em. 0.3ex finde ich aber als viel zu klein. Für normale Tabellen würde mir ein padding: 0.2em 0.3em besser gefallen, bei dem nur der vertikale Abstand verringert wird. Allerdings habe ich bei allen Änderungen die Sorge, dass es irgendwo Probleme geben kann. Die CSS-Klassen haben eigentlich den Vorteil, dass es sich jeder angemeldete Benutzer selbst einstellen kann. --Fomafix 09:10, 10. Jul. 2008 (CEST)

Vorsicht beim Herumändern ! Die Einstellungen müssen vor allem für User ohne eigene CSS passen. Besser nichts mehr ändern, denn da sind bestimmt schon viele Artikel drauf abgestimmt. Cäsium137 (D.) 17:35, 11. Jul. 2008 (CEST)

Seit rev:48842 gibt es eine wikitable-Definition in http://bits.wikimedia.org/skins-1.5/common/shared.css mit 0.2em. Ich halte die globale Definition für ausreichend, sehe keinen Grund, die lokale Variante mit 0.3em aufrecht zu erhalten und habe sie deshalb entfernt und prettytable daran angepasst. Vorlage:Prettytable hatte übrigens cellpadding="4". --Entlinkt 03:06, 11. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 03:06, 11. Jun. 2010 (CEST)

Hintergrundfarbe Titelzellen

Könnte man vielleicht .wikitable th, .prettytable th dieselbe Hintergrundfarbe wie .hintergrundfarbe6 zuweisen? Vielfach machen Leute das händisch, wodurch das Tabellendesign uneinheitlich wird.

Ich würde auch alternative, semantische Namen für die grünliche, gelbliche und rötliche Hintergrundfarbklasse begrüßen, z.B. mit den Wortfeldern positiv/neutral/negativ, gut/egal/schlecht oder hoch/mittel/niedrig. — Christoph Päper 11:57, 8. Apr. 2008 (CEST)

was die semantischen Klassennamen angeht stimme ich dir vollkommen zu. Was die Hintergrundfarbe angeht: Weil es einige machen, muss der Stil hier nicht geändert werden. Wer weiss, vielleicht ist es in ein paar Monaten eine andere Hintergrundfarbe, die 'Hip' ist und dann überall in die Tabellenköpfe eingebaut wird... Leiderleiderleider empfinden hier zu viele MA ihr persönliches Empfinden von Layout als optimal. Ausserdem ist zwecks Überzeugung derselben unglaublich viel Dickbrettbohrerei notwendig, auf die zumindest ich keine Lust mehr habe. --Gnu1742 12:03, 8. Apr. 2008 (CEST)

Hintergrundfarben für Tabellenkopfzellen bei prettytable gibt bei en:MediaWiki:Common.css (permalink):

table.wikitable th,
table.prettytable th {
    background: #f2f2f2;
    text-align: center;
}

Das hebt die Tabellenkopfzellen schön hervor:

Kopf 1	Kopf 2
Körper 1	Körper 2

Diese Eigenschaft war am 31. Mai 2007 war es bei der deutschen Wikipedia auch vorhanden. Wo sie damals definiert war finde ich allerdings im Moment nicht. Diese CSS-Definition sorgt aber für Probleme, wenn für eine Zeile eine andere Farbe gewünscht wird. In der deutschen Wikipedia findet man häufig Tabellen, bei denen eine Zeile farbig hinterlegt ist:

{| class="prettytable"
|- style="background: #fee;"
! Kopf 1 !! Kopf 2
|-
| Körper 1 || Körper 2
|}

Kopf 1	Kopf 2
Körper 1	Körper 2

Die obige CSS-Definition für die Kopfzellen überschreibt aber die Inline-Definion für die Tabellenzeilen. In der englischen Wikipedia erscheint daher bei obigen Beispieltabelle keine farbige Zeile. Bei folgendem Beispiel funktioniert es aber weiterhin:

{| class="prettytable"
|-
! style="background: #fee;" | Kopf 1 !! style="background: #fee;" | Kopf 2
|-
| Körper 1 || Körper 2
|}

Kopf 1	Kopf 2
Körper 1	Körper 2

Ich weiß das daher noch genau, weil ich hier mit diesem Problem zu kämpfen hatte. Inzwischen ist die CSS-Definition für eine Hintergrundfarbe bei prettytable-Kopfzellen nicht mehr vorhanden. Eine Aktivierung in der MediaWiki:Common.css wie bei der englischen Wikipedia würde bei zigtausenden Tabellen die Hintergrundfarbe überschreiben. Eine Aktivierung in der deutschen Wikipedia kann ich daher nicht empfehlen. --Fomafix 13:07, 8. Apr. 2008 (CEST)

Genau genommen werden die Angaben im style-Attribut nicht überschrieben, sondern man sieht sie nur nicht, weil die Hintergrundfarbe der Zellen (th bzw. |) die der Zeile (tr bzw. |-) vollständig verdeckt. .prettytable tr[style] th {background-color: inherit} wäre aber mglw. zu oft falsch-positiv (.prettytable tr[bgcolor] th {background-color: inherit} natürlich nicht).

Das Dunkelgrau der englischen WP (#F2F2F2) finde ich übrigens (zumindest auf meinem Monitor und im Zusammenspiel mit dem leichten Grau der Datenzellen) nicht besonders gelungen, darum kann ich die verstehen, die Kopfzeilen bunt machen wollen. Wenn es aber mal standardmäßig mit einer Farbe hinterlegt ist, gibt es nur in Ausnahmefällen einen guten Grund, diese zu ändern, und für diese kann man immer noch auf die Änderung an einzelnen Zellen zurückgreifen. — Christoph Päper 18:51, 16. Apr. 2008 (CEST)

Mit folgender CSS-Definition werden die oben genannten Probleme umgangen:

table.wikitable tr:not([class^="hintergrundfarbe"]):not([style]):not([bgcolor]) th,
table.prettytable tr:not([class^="hintergrundfarbe"]):not([style]):not([bgcolor]) th {
	background-color: #f2f2f2;
}

Es wird dabei :not(x) aus CSS3 verwendet, das laut [11] von Firefox ab Version 1, Opera ab Version 9.5 und Safari ab Version 1.0 unterstützt wird. Beim Internet Explorer fehlt allerdings die Unterstützung. Eine solche Aktivierung wäre denkbar, würde aber für unterschiedliche Darstellung bei unterschiedlichen Browsern sorgen und die Autoren verwirren. Ich teste diese Definition bereits. --Fomafix 16:32, 15. Dez. 2008 (CET)

Die abgegebenen Regeln reichen noch nicht, um alle Sonderfälle abzudecken. Ich habe noch ein paar weitere Sonderfälle in monobook.css ergänzt, verfolge es aber nicht mehr weiter, da es unnötig komplizierte Regeln erzeugt. --Fomafix 12:47, 15. Jun. 2009 (CEST)

Ich nehme an, es ist gewünscht, das sich jeder seine Tabelle selber gestalten kann, auch wenn es zu uneinheitlichkeit führt, ein wenig Freiraum sollte man lassen. Daher würde ich keine standardmäßige Formatierung vorschlagen. Der Umherirrende 10:44, 18. Jul. 2009 (CEST)

Hintergrundfarben wurden mit rev:48842 in den Core übernommen. Siehe auch #Hintergrundfarben nach Übernahme von wikitable in core-css, somit erledigt. --Der Umherirrende 19:33, 14. Okt. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:33, 14. Okt. 2009 (CEST)

Klasse "wikitable"

Diese Klasse wird in keinem Artikel mehr benutzt. Sie ist nur noch in Archiven des WP-Namensraums und auf ein paar Seiten im Benutzerbereich vorhanden. Weil Redundanz immer auch eine mögliche Fehlerquelle darstellt, schlage ich vor, diese Klasse aus der Commons.css zu löschen. Die Einbindungen kann man bei Bedarf ja ändern. Cäsium137 (D.) 16:55, 17. Apr. 2008 (CEST)

 Pro, sofern wirklich kein Artikel class="wikitable" mehr verwendet. --Fomafix 17:20, 17. Apr. 2008 (CEST)

Die Volltextsuche zeigt keinen mehr auf. Cäsium137 (D.) 17:32, 17. Apr. 2008 (CEST)

Sehe ich nicht so. Die Klasse wird in anderen Wikis verwendet und ist von der Namensgebung passender als prettytable. Dass du selbst für die Löschung des CSS-Namens gesorgt hast, ist auch etwas seltsam. Warum war das nötig? Solche Edits bringen keinen Mehrwert für den Leser, verstecken aber wesentliche Seitenänderungen auf der Beobachtungsliste. sebmol ^{? !} 20:32, 17. Apr. 2008 (CEST)

Für den Leser bringt es einen Nachteil, wenn er alte Versionen betrachtet, die noch Wikitable verwenden.

(deshalb ist und bleibt es heikel, wenn Vorlagen und CSS-Definitionen verändert oder entfernt werden)

-- MichaelFrey 20:38, 17. Apr. 2008 (CEST)

Wenn eine Vorlage oder eine CSS-Definition gelöscht wird, hat das immer einen Nachteil für alte Versionen von Artikeln. Seit dem Löschen der Vorlage:Prettytable werden zigtausende Tabellen in alten Versionen der Artikel nicht mehr richtig dargestellt. Trotzdem war der Schritt notwendig und richtig, um Wildwuchs und Redundanz zu vermeiden. Wenn die CSS-Klasse wikitable nicht mehr definiert ist, dann werden alte Tabellen zumindest weiterhin als Tabellen dargestellt und sind weiterhin lesbar. Wer viel mit betroffenen alten Versionen arbeitet kann sich – anders als bei gelöschten Vorlagen – sogar selbst die CSS-Definition eintragen. Wenn wikitable nicht jetzt gelöscht wird, wann dann? In einem Jahr? In zehn Jahren? --Fomafix 08:46, 18. Apr. 2008 (CEST)

Nie. Ich sehe weiterhin keinen Zweck in der Löschung. wikitable und prettytable sind als CSS-Klassen ein Quasi-Standard über Dutzende Wikimedia-Projekte hinweg. sebmol ^{? !} 09:01, 18. Apr. 2008 (CEST)

In der französischen Common.css gibt es nur die CSS-Klasse wikitable. Warum brauchen wir zwei CSS-Klassen? --Fomafix 09:11, 18. Apr. 2008 (CEST)

Historisch gewachsen. Früher gab es nur prettytable als Vorlage, dann wurde das in eine CSS-Klasse umgewandelt. Als man das tat, wurde aber übersehen, dass man vermutlich die wikitable-Klasse hätte nehmen sollen. Jetzt haben wir zwei Klassen, die dasselbe aussagen, aber sonst eigentlich keine Probleme verursachen. sebmol ^{? !} 22:25, 21. Apr. 2008 (CEST)

Weil wir uns nicht einigen können, eine im ANR ungenutzte und sonst kaum genutzte Klasse zu löschen. Es geht hier einigen Usern vermutlich darum, den Claim neu abzustecken. Cäsium137 (D.) 22:19, 21. Apr. 2008 (CEST)

"den Claim neu abzustecken" - magst du sagen, was das heißen soll? Mir erschließt sich der Inhalt deines Kommentars nicht. sebmol ^{? !} 22:25, 21. Apr. 2008 (CEST)

Ich habe den Eindruck, als ginge es einigen Usern nicht um die Sache, sondern darum, Recht zu behalten. Mir ist es relativ egal, ob in der Common.css diese Klasse steht, solange sie nicht im ANR benutzt wird. Nur um das in Zukunft zu verhindern, möchte ich sie löschen. Cäsium137 (D.) 22:35, 21. Apr. 2008 (CEST)

Die Volltextsuche Spezial:Suche/wikitable findet nicht alle Vorkommen von „wikitable“. So wird der Artikel Top-Level-Domain nicht gefunden, obwohl er mehrfach class="wikitable" verwendet. Die derzeit angezeigten acht Treffer sind also lang nicht alle Verwendungen von „wikitable“. Bei der Umstellung von der Vorlage:Prettytable auf die CSS-Klasse ist der Fehler gemacht worden, dass der Name der CSS-Klasse nicht an die anderen Wikipedias angepasst wurde. Alle anderen verwenden „wikitable“, nur die deutsche Wikipedia hat unnötigerweise zwei identische CSS-Klassen. Aber Fehler kann man korrigieren – it’s a wiki. --Fomafix 14:44, 1. Jul. 2008 (CEST)

Wie wäre es dann, wenn wir lieber langsam in Richtung wikitable konvertieren würden? Code·is·poetry 15:31, 1. Jul. 2008 (CEST)

Das ist genauso gut. Hauptsache keine redundanten CSS-Klassen. Die Umstellen eilt aber nicht und sollte im Rahmen der üblichen Wartungsarbeiten geschehen. Statt zwei Klassen für das gleiche sollte besser eine eigene Klasse für Infoboxen (class="infobox") angelegt werden, wie sie bereits in anderen Wikipedias existiert. --Fomafix 15:41, 1. Jul. 2008 (CEST)

Wie willst du die class="prettytable" finden, wenn das mit "wikitable" nicht funktioniert ? Cäsium137 (D.) 15:37, 1. Jul. 2008 (CEST)

Für class="infobox" würden wir zuerst (!) einen Abschnitt in der Common.css benötigen. Den muss jemand schreiben und eintragen. Cäsium137 (D.) 15:46, 1. Jul. 2008 (CEST)

Was sollte die Klasse infobox für eigenschaften haben? wikitable, float-right … bei der Breite könnte es schon Streitereien geben, obwohl gerade da eine Festlegung wünschenswert wäre. Ich werde ab jetzt jedenfalls bei meinen Edits automatisch von prettytable nach wikitable umstellen. Code·is·poetry 16:22, 1. Jul. 2008 (CEST)

Ich habe mal die Hilfeseiten auf wikitable umgestellt, damit zumindestens nicht mehr so viele neue prettytable hinzukommen. Sollten wir bei WP:AWB und WP:BOT anfragen, ob sie das in die "kosmetischen Änderungen" aufnehmen? Das würde bedeuten, das dies nebenbei gemacht wird, wenn bereits ein edit gemacht wird, das würde ja nicht schaden und bringt viel. Sollten wir für die Infoboxklasse einfach einen neuen Abschnitt hier aufmachen? Der Umherirrende 12:00, 16. Jul. 2008 (CEST)

Bin ich dafür, ich mache das ja auch schon mit jedem Edit. Eine mögliche Infoboxklasse sollten wir bald klären, damit die Vorlagen auf wikitable oder eben die neue Vorlage umgestellt werden können. Gruß, Code·is·poetry 12:13, 16. Jul. 2008 (CEST)

Anfragen für AWB und für Bot. Der Umherirrende 02:25, 17. Jul. 2008 (CEST)

Eine solche Klasse sollte m. E. auf das Standardskin Monobook und seine Standardeinstellungen bei einem Bildschirm 1024 x 768 ( = ca. 800px Hauptfeldbreite) passen. Cäsium137 (D.) 13:56, 16. Jul. 2008 (CEST)

Für die CSS-Klasse infobox werde ich demnächst hier ein neuer Thread aufmachen (#Infobox) und dort Anforderungen und Vorschlage sammeln. --Fomafix 14:42, 16. Jul. 2008 (CEST)

Könnte die Umstellung von prettytable auf wikitable genutzt werden, um oben beschriebenen Probleme in der CSS-Definition zu korrigieren? Ich meine damit folgendes:

.prettytable { margin: 1em 1em 1em 0; }
.wikitable { margin: 1em 0; }

Durch das margin-right:0 stört das caption {margin-right:inherit;} nicht, das beim Firefox bis zur Version 2 notwendig ist und ab Version 3 stört (#Firefox 3). --Fomafix 14:42, 16. Jul. 2008 (CEST)

Das sollte man in einem Extra-Abschnitt ansprechen. Der Rest ist ja erledigt. Der Umherirrende 19:31, 14. Okt. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:31, 14. Okt. 2009 (CEST)

Klasse für ähnliches Layout wie Navigationsleisten

Ich schlage vor, eine Klasse einzufügen, die die gleichen Definitionen wie bei den Navigationsleisten hat, aber nicht vom Skript erkannt wird und daher nicht geklappt werden kann. Man könnte dann das Design der Vorlage:Folgenleiste entsprechend verändern: Vorschlag. Der Vorteil eines veränderten Design der Folgenleiste sehe ich darin, das der untere Abschnitt von Artikeln einheitlicher aussieht. Es kommt öfters vor, das Folgenleiste und Navigationsleisten in einem Artikel stehen: Beispiel. Eine andere Alternative wäre eine Klasse einzufügen, die dem Skript sagt, das es nicht agieren soll, wäre aber etwas für MediaWiki Diskussion:Common.js, wenn sich mehr dafür aussprechen könnte ich auch dort einen Abschnitt ergänzen. Was haltet ihr davon? Der Umherirrende 17:29, 10. Okt. 2008 (CEST)

Inhaltlich gebe ich Dir recht, dass das Layout in CSS-Definitionen gehört. Bei Wikipedia wird aber üblicherweise das Layout über Vorlagen erzeugt, außer es sind grundlegende Dinge wie wikitable. <style scoped="scoped">…<style> kann leider nicht aus dem Wikitext heraus erzeugt werden. Reichen hier Vorlagen aus, oder ist das eine grundlegende allgemeine Formatierung, die in jedem zweiten Artikel benötigt wird? --Fomafix (Diskussion) 19:31, 2. Mär. 2012 (CET)

Da es so alt ist und kein anderer in der Zwischenzeit die Idee hatte, sehe ich das erstmal als erledigt an. Der Umherirrende 19:51, 2. Mär. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:51, 2. Mär. 2012 (CET)

Zellrahmen

Auch wenn es in MS Word und verwandter Software die Voreinstellung ist, sind Tabellen, in denen sämtliche Zellen an allen vier Seiten sichtbar berandet sind, doch schlechter Stil. Häufig genügen horizontale Linien zusammen mit einem vernünftig großem Abstand des Inhalts zum Rand (padding). Manchmal kann man außerdem die horizontalen Linien für die meisten Zeilen weglassen, um die Lesbarkeit nicht nur nicht zu verschlechtern, sondern zu verbessern.

Letzteres funktioniert für wikitable- bzw. prettytable-Tabellen mithilfe der zusätzlich angegebenen Klasse nogrid und entsprechenden border-Angaben im style-Attribut derjenigen Zeilen (|-), die es wirklich brauchen. Es gibt aber ohne die Einführung einer weiteren Klasse m.W. keine Möglichkeit, allen Zeilen einer wikitable-Tabelle auf einmal (nur) horizontale Ränder zuzuweisen, da das HTML-Attribut rules (mit dem Wert rows) vom CSS überschrieben wird.

Darum schlage ich eine neue Klassen vor, hrules:

table.hrules th, table.hrules td,
tr.hrules th, tr.hrules td,
th.hrules, td.hrules {
  border-width: 1px 0;/* oder
  border-style: solid none; */
}

Von mir aus kann man auch gleich vrules miteinführen, wenn die auch deutlich seltener nützlich sein würde. An den Namen hänge ich nicht, falls was deutscheres oder selbsterklärenderes bevorzugt wird. — Christoph Päper 17:18, 31. Aug. 2008 (CEST)

Wir haben schon "nogrid" für kein Gitter. Nehmen wir also ruhig

• "horgrid" für alle horizontalen Linien (nur innen)
• "vergrid" für alle senkrechten Linien (nur innen)
• "grid" für alle Linien (nur innen)
• "bordergrid" für grid plus Außenlinien.

Cäsium137 (D.) 17:52, 31. Aug. 2008 (CEST)

Generell befürworte ich die Idee, aber ich würde es zwecks Verständlichkeit .zeilenrahmen und .spaltenrahmen nennen. Die Variante mit border-style ist die bessere. --Revolus Echo der Stille 21:47, 31. Aug. 2008 (CEST)

Naja, .nogrid existiert bereits (weswegen »grid« besser ist als »rules«) und .wikitable sowie .prettytable sind auch nicht so richtig deutsch. Aber letztlich sind mir die Namen wie gesagt relativ egal, nur machen sollte es jemand.

Zu bedenken ist vielleicht noch, dass »grid« (oder »bordergrid«?) der Standardzustand von .wikitable/ .prettytable ist, während andere Tabellen (ohne HTML-Attribute) eher »nogrid« entsprechen. Das heißt, dass Autoren in den meisten Fällen vertikale Linien wegnehmen wollen, um »horgrid« zu erreichen, was eine kleine kognitive Hürde darstellt. — Christoph Päper 14:06, 11. Sep. 2008 (CEST)

Wer sich in dieses Metier hineinwagt, der kommt gewiss mit engl. Begriffen klar. Ich ändere meinen Vorschlag auch dahingehend ab, dass wir statt "grid" besser "innergrid" und statt "bordergrid" besser "allgrid" nehmen. Ich formuliere mal aus:

  .horgrid { border:none; border-style:hidden; }
  .horgrid th,
  .horgrid td {
    border-top-style:solid;
    border-bottom-style:solid;
    border-left-style:hidden;
    border-right-style:hidden;
  }

  .vergrid {  border:none; border-style:hidden;}
  .vergrid th,
  .vergrid td {
    border-top-style:hidden;
    border-bottom-style:hidden;
    border-left-style:solid;
    border-right-style:solid;
  }

  .innergrid { border:none;  border-style:hidden; }
  .innergrid th,
  .innergrid td {
    border-top-style:solid;
    border-bottom-style:solid;
    border-left-style:solid;
    border-right-style:solid;
  }

  .allgrid { border-style:solid; }
  .allgrid th,
  .allgrid td {
    border-top-style:solid;
    border-bottom-style:solid;
    border-left-style:solid;
    border-right-style:solid;
  }

Sollen wir das umsetzen ? Cäsium137 (D.) 14:39, 11. Sep. 2008 (CEST)

Hast du innergrid schonmal ausprobiert? Ich denke, das müsste hidden heißen, um die Rahmen der Zellen zu verbergen. Ansonsten bin ich dafür. --RevoLus Echo der Stille 17:58, 11. Sep. 2008 (CEST)

Gemäß SelfHTML gibt es (Zitat):

Für Wert einen der folgenden Werte notieren:
none = kein Rahmen (bzw. unsichtbarer Rahmen).
hidden = kein Rahmen (bzw. unsichtbarer Rahmen),
dotted = gepunktet.
dashed = gestrichelt.
solid = durchgezogen.
double = doppelt durchgezogen.
groove = 3D-Effekt.
ridge = 3D-Effekt.
inset = 3D-Effekt.
outset = 3D-Effekt.

offensichtlich ist beides erlaubt. Ein Test läuft gerade. Cäsium137 (D.) 18:21, 11. Sep. 2008 (CEST)

Sie haben einen kleinen Unterschied: none heißt, dass die Box keinen eigenen Rahmen hat; hidden heißt, dass auch bei zusammenfallenden Zellen (border-collapse) die Rahmen entfernt werden. --RevoLus Echo der Stille 18:42, 11. Sep. 2008 (CEST)

Ich habe den Test (mit "hidden") durch. Es funktioniert jetzt. Cäsium137 (D.) 19:58, 11. Sep. 2008 (CEST)

Ich würde wegen der Übersichtlichkeit durchgängig das shorthand property border-style verwenden, also

.horgrid th, .horgrid td {border-style: solid hidden;}
.vergrid th, .vergrid td {border-style: hidden solid;}
.innergrid th, .innergrid td, .allgrid th, .allgrid td {border-style: hidden;}

Ansonsten, make it so! — Christoph Päper 11:07, 12. Sep. 2008 (CEST)

Hast zwei Zeilen vergessen ;-)

.horgrid th, .horgrid td { border-style: solid hidden; }
.vergrid th, .vergrid td { border-style: hidden solid; }

.innergrid { border-style:hidden; }
.allgrid { border-style:solid; }
.innergrid th, .innergrid td, .allgrid th, .allgrid td { border-style: solid; }

horgrid würde mir für Infoboxen gefallen. --RevoLus Echo der Stille 11:24, 12. Sep. 2008 (CEST)

Also border:none muss man zusätzlich nehmen, um die Vererbung des Rahmens der Klasse wikitable auf tr zu deaktivieren. So zumindest in meinem Browser. Wieso soll ich was vergessen haben ? Ist doch oben im Quelltext drin. da stehen die Styles für .horgrid th etc. doch einzeln drin und sowas wie .innergrid { border-style:hidden; } ist u. a. in der Zeile

.innergrid { border:none; 'border-style:hidden; }

enthalten. In meinem Browser funktioniert es fehlerfrei. Natürlich kann man die Styles kürzer schreiben. Cäsium137 (D.) 12:32, 12. Sep. 2008 (CEST)

(BK) War ne Antwort auf Christoph. none gilt für den style. Also eigentlich müsste border-style:hidden das border:none überschreiben. hidden müsste auch alle anderen Eingaben überschreiben. --RevoLus Echo der Stille 12:36, 12. Sep. 2008 (CEST)

Aha. Ich habe es mal kompakter geschrieben.

  .horgrid {
    border:none;
    border-style:hidden;
  }
  .horgrid th,
  .horgrid td {
    border-style: solid hidden;
  }

  .vergrid {
    border:none;
    border-style:hidden;
  }
  .vergrid th,
  .vergrid td {
    border-style: hidden solid;
  }

  .innergrid {
    border:none;
    border-style:hidden;
  }
  .innergrid th,
  .innergrid td {
    border-style: solid;
  }

  .allgrid {
    border-style:solid;
  }
  .allgrid th,
  .allgrid td {
    border-style:solid;
  }

Das ist gestestet und läuft genauso. Sollen wir es übertragen (lassen) ? Cäsium137 (D.) 12:48, 12. Sep. 2008 (CEST)

Ich würde es mit weniger Regelblöcken schreiben, da sich die Regeln wiederholen, aber ansonsten sieht das doch unkritisch aus und sollte alsbald übernommen werden. — Christoph Päper 11:21, 15. Sep. 2008 (CEST)

So ist es übersichtlicher, was in den Klassen definiert wird. Es kommt nicht auf 10 Quelltextzeilen an. Cäsium137 (D.) 16:35, 16. Sep. 2008 (CEST)

Find ich nicht übersichtlicher als

.horgrid th, .horgrid td { border-style: solid hidden; }
.vergrid th, .vergrid td { border-style: hidden solid; }

.innergrid { border-style:hidden; }
.allgrid { border-style:solid; }
.innergrid th, .innergrid td, .allgrid th, .allgrid td { border-style: solid; }

 :-) --Revolus Echo der Stille 16:43, 16. Sep. 2008 (CEST)

Meine letzte Version aus meiner CSS-Datei sieht ähnlich aus. Ich würde die beiden letzten Klassen aber getrennt schreiben, da das mehr Übersicht bewirkt.

  .horgrid th,    .horgrid td   { border-style: solid hidden; }

  .vergrid th,    .vergrid td   { border-style: hidden solid; }

  .innergrid th,  .innergrid td { border-style: solid; }

  .allgrid th,    .allgrid td   { border-style: solid; }

Sollen es so umgesetzt werden ? Cäsium137 (D.) 17:04, 16. Sep. 2008 (CEST)

.innergrid { border-style:hidden; } fehlt noch, damit es auch mit prettytable funktioniert. Ansonst ja; kannst ja mal eine Anfrage auf WP:AAF stellen. --Revolus Echo der Stille 17:08, 16. Sep. 2008 (CEST)

Nehmen wir doch

  .horgrid { border-style: hidden; }
  .horgrid th,  .horgrid td { border-style: solid hidden; }

  .vergrid {  border-style: hidden;}
  .vergrid th,  .vergrid td { border-style: hidden solid; }

  .innergrid { border-style: hidden; }
  .innergrid th,  .innergrid td { border-style: solid; }

  .allgrid { border-style:solid; }
  .allgrid th,  .allgrid td { border-style: solid; }

Dann sind wir auf der sicheren Seite. OK ? Cäsium137 (D.) 17:17, 16. Sep. 2008 (CEST)

Ok. --Revolus Echo der Stille 17:20, 16. Sep. 2008 (CEST)

Gut. Ich stelle die AAF mit Quelltextangabe. Cäsium137 (D.) 17:21, 16. Sep. 2008 (CEST)

---

Neue zusätzliche CSS-Klassen würde ich nach Möglichkeit vermeiden. Zentrale CSS-Klassen müssen bei allen Seiten immer geladen werden, auch wenn sie nicht benötigt werden. Außerdem besteht die Gefahr, dass bei früheren Artikelversionen nicht mehr passende CSS-Definitionen geladen werden. Die zentralen CSS-Definitionen sollten sich daher auf elementar notwendige CSS-Klassen wie wikitable beschränken. Eine bessere Lösung für individuelle Seitengestaltung wäre es, wenn das HTML5-Element source mit dem Attribut scoped im Wikitext ermöglicht werden würde. --Fomafix 16:18, 27. Jan. 2012 (CET)

Mit rev:107669 wurden die Zellrahmen bei wikitable vom Descendant Selector auf den Child Selector umgestellt. Damit haben Subtabellen nicht mehr automatisch Zellrahmen. Die CSS-Klasse nogrid wird derzeit an Subtabellen eingesetzt, um diese Zellrahmen zu unterbinden. Wenn die Änderung von wikitable mit MediaWiki 1.19 live geht, wäre es sinnvoll die CSS-Klasse nogrid hier auch zu entfernen und aus den entsprechenden Artikeln zu entfernen. --Fomafix 16:18, 27. Jan. 2012 (CET)

Nein, das ist ganz sicher nicht der einzige Zweck der Klasse. Da derzeit wikitable die einzige Möglichkeit ist, per CSS für ganze Tabellen ein anständiges padding zu bekommen, wird auch für gepolsterte, rahmenlose Tabellen gerne wikitable nogrid genommen. Solange wir also keine pad-Klassen bekommen, sind modifizierte wikitables oft der einzige Weg. -- ✓ ^Bergi 20:03, 29. Jan. 2012 (CET)

nogrid wurde vor knapp fünf Jahren auf Zuruf zum Thema „Subtabellen bei prettytable“ hinzugefügt. nogrid war also nur ein schneller Workaround für Subtabellen in prettytable bzw. wikitable. Dabei würde es auch andere Lösungen geben: https://translatewiki.net/w/docs/uidesign/child-selector-emu.html. Eine saubere Lösung dieses Themas ist mit rev:107669 endlich vollzogen, wobei der IE6 allerdings angehängt wurde. Damit sollte sich nogrid eigentlich entfernen lassen. Dass nun irgendwo norid mit wikitable kombiniert wird, ist ein typisches Beispiel für das Problem mit solchen CSS-Klassen. Einmal eingeführt können sie nie wieder entfernt werden. Die derzeitige Definition wird aber auf jeden Fall unwirksam, sobald MediaWiki 1.19 ausgerollt wird, weil die Selektorspezifität geringer ist das neue wikitable. Meiner Meinung nach wäre das der richtige Zeitpunkt diese Definition zu entfernen. Um gepolsterte Tabellen ohne Gitter zu erzeugen kann weiterhin cellpadding verwendet werden. Die saubere und universelle Lösung wäre <style scoped="scoped">td, th { padding: 0.5em }<style> zu erlauben. --Fomafix 23:55, 29. Jan. 2012 (CET)

MediaWiki 1.19 ist live.

.nogrid th,
.nogrid td {
	border: none;
}

kann meiner Meinung nach komplett entfallen. Es ist derzeit sowieso unwirksam, da wikitable eine höhere Spezifität hat:

1	2
3	4

{| class="wikitable nogrid"
|-
| 1 || 2
|-
| 3 || 4
|}

--Fomafix (Diskussion) 09:39, 1. Mär. 2012 (CET)

Ich habe die Klasse entfernt, ein Jahr Unwirksamkeit sollte reichen. --Entlinkt (Diskussion) 17:38, 12. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 17:38, 12. Mai 2013 (CEST)

Fontvorgaben für IPA, IAST usw.

Nachdem die Fontangaben aus den Vorlagen {IPA}, {IAST} und {Hebräisch} entfernt wurden, sehe ich (Windows-XP-Standardkonfiguration mit installierten ostasiatischen Schriften) folgende Probleme:

Vorlage:IPA

Das ist wohl das technischste Problem: Nach Entfernung der font-families aus der Vorlage zeigt mein Firefox (meistens, aber nicht immer) Zwiebelfische in der (bei kleinen Schriftgrößen krakelig wirkenden) Serifen-Schriftart MS Mincho. Der IE 7 zeigt statt der Liaisonbögen „Würfelzucker“. -- Olaf Studt 15:54, 2. Mär. 2008 (CET)

Jetzt hab' ich's: Das liegt an dem komischen „font-family /**/:inherit;“, mit dem die Definition für normale Browser unwirksam gemacht wird! Bei IPA treten die Zwiebelfische ja nur bei den Ostasien-Fans auf, aber bei Altgriechisch (vgl. Vorlage Diskussion:Polytonisch) haben sie alle Win-XP-Standardbenutzer, da dürfte „font-family /**/:inherit;“ kontraproduktiv sein. -- Olaf Studt 16:44, 2. Mär. 2008 (CET)

Kann ich nicht bestätigen, bei mir zeigt Firefox IPA problemlos an (ich weiß aber nicht, welche Schrift er verwendet). -- Prince Kassad 17:05, 2. Mär. 2008 (CET)

Vorlage:IAST

Das Problem besteht wohl schon länger: Die in MediaWiki:Common.css für die Klasse IAST angegebene Schriftart Lucida Sans Unicode enthält keine vorgefertigten unterpunkteten und unterstrichenen Buchstaben, sondern die müssen aus Buchstabe + Unterpunkt bzw. Unterstrich zusammengesetzt werden; solche Kombinationen werden aber (sofern man nicht mit entities rumtrickst) beim Speichern von der Wiki-Software duch vorgefertigte Zeichen ersetzt. Deshalb erzeugen Firefox und IE 7 dort Tahoma-Zwiebelfische; bei älteren IE-Versionen steht dort wahrscheinlich trotz IAST-Baustein „K□□□a“ statt Kṛṣṇa. -- Olaf Studt 16:44, 2. Mär. 2008 (CET)

Wenn man keine der anderen Schriften, die vor l_10646 kommen, besitzt, und dann noch versucht, IAST darzustellen, hat man sowieo keine Chance. Mein Firefox verwendet auch ganz normal Arial. Trotzdem wäre ich für eine eigene Klasse IAST ohne l_10646. -- Prince Kassad 17:07, 2. Mär. 2008 (CET)

Vielleicht sollte man für die Alt-IEler Tahoma als letztes vor sans-serif aufführen. Aber dann bitte mit Zauberspruch: An der kurdischen WP sieht man, wie hässlich die Schrift ist. Stimmt es überhaupt, dass der Zauberspruch bei IE 7 nicht mehr funktioniert? -- Olaf Studt 09:41, 5. Mär. 2008 (CET)

Vorlage:He

Hier darf laut Vorlage Diskussion:He in den in MediaWiki:Common.css für die Klasse hebrew vorgegebenen Schriftarten zumindest Arial nicht so weit vorne stehen, am besten werden wohl die bisher in der Vorlage stehenden Schriftarten übernommen. -- Olaf Studt 16:44, 2. Mär. 2008 (CET) P.S. Die Schriftart Narkisim ist übrigens Bestandteil des Microsoft-Sprachpakets Hebräisch. -- Olaf Studt 18:24, 2. Mär. 2008 (CET)

Du kannst die Reihenfolge in deiner CSS überschreiben. Dann ist das Problem für dich behoben. Als Standard ist Arial Unicode MS richtig. Cäsium137 (D.) 21:10, 2. Mär. 2008 (CET)

MMn Quatsch. 99,8 % der WP-User wissen nix von CSS-Einstellungen und selbst ich, der davon schon was gehört hat, lasse da im allgemeinen die Finger weg. Das sollte zurück in die Vorlage. Arial Unicode MS ist übrigens insbesondere für Hebräisch, aber auch für japanische Zeichen die allerschlechteste Wahl. (siehe en:Help:Multilingual support (East Asian) und die diversen verlinkten Seiten. Irgendwo auf den MS-Supportseiten geben die übrigens zu, daß ihr Kram verschiedene japanische Zeichen falsch anzeigt - ich habe mich vor einigen Wochen mal dahin durchgeklickt, werde diese Suche nicht wieder machen –, einen Fix gibt es dazu angeblich nicht. --Matthiasb 17:32, 3. Mär. 2008 (CET)

Wenn für einzelne Schriften bestimmte Fonts besser als Arial Unicode MS sind, dann sollte das hier glaubhaft (!) dargelegt werden. Am besten von mehreren Usern, welche sich mit dem Thema umfangreich beschäftigen. wenn es eindeutig ist, dann kann die Einstellung geändert werden. Cäsium137 (D.) 19:29, 3. Mär. 2008 (CET)

Noch mal was Grundsätzliches: Die WP wird für die Leser gemacht, und die haben kein user/Monobook.css (allerdings kann man Hebräisch [im Gegensatz zu IPA und Altitalisch] auch im Browser konfigurieren). -- Olaf Studt 09:33, 5. Mär. 2008 (CET)

• SBL Hebrew: זֹהַר
• Quivira: זֹהַר
• Sun-ExtA: זֹהַר
• Arial Unicode MS: זֹהַר
• Code2000: זֹהַר
• MPH 2B Damase: זֹהַר
• david: זֹהַר
• narkisim: זֹהַר
• Microsoft Sans Serif: זֹהַר

Noch Fragen? Die erste Fontspec stammt aus der he-Vorlage von en-WP [12], die zweite von hier. Wenn man nur Arial Unicode MS auf dem Rechner hat, wird man keinen großen Unterschied sehen. Dass eine spezialisierte Font den Vorzug gegenüber einer nichtspezialisierten haben sollte, dürfte aber einleuchtend sein. Insbesondere SBL Hebrew ist in Deutschland zumindest verbreitet bei Leuten, die sich für Hebräisch interessieren. Und sie liefert die beste Darstellung. Arial Unicode MS ist noch schlechter als Microsoft Sans Serif, die es auch auf jedem Windows-Rechner gibt, da Arial Unicode MS wie schon von anderer Seite bemerkt bei Interpunktion besonders störende Zwischenräume zeigt. Die Fontspec in en-WP ist

font-family:"SBL Hebrew", david, narkisim, "Microsoft Sans Serif"; font-size:125%;

Ich würde

font-family:"SBL Hebrew", david, narkisim, "Microsoft Sans Serif", sans-serif; font-size:125%;

vorschlagen. Die leichte Vergrößerung ist vor allem bei der Darstellung der Vokalisation hilfreich, außerdem erscheinen hebräische Zeiche gegenüber den vergleichbaren lateinischen Großbuchstaben etwas kleiner, weshalb eine Vergrößerung ein harmonischeres Schriftbild gibt. --WolfgangRieger 00:38, 11. Jun. 2009 (CEST)

Tja. Offenbar nicht nur keine Fragen sondern auch keine Reaktion. --WolfgangRieger 02:35, 19. Jun. 2009 (CEST)

Wenn eine alte D. wieder aufgenommen wird, dann kann das schon mal untergehen. Zum Thema: Erst mal eine größere Darstellung:

SBL Hebrew:	זֹהַר
Quivira:	זֹהַר
Sun-ExtA:	זֹהַר
Arial Unicode MS:	זֹהַר
Code2000:	זֹהַר
MPH 2B Damase:	זֹהַר
david:	זֹהַר
narkisim:	זֹהַר
Microsoft Sans Serif:	זֹהַר

Wenn die Font nicht installiert ist, erscheint monospace.

Es sollte mehrere User geben, welche das mit der Qualität zumindest ungefähr genauso sehen. Du kannst aber auch eine Seite im Web nennen, wo die Zeichen als Grafik (!) garantiert korrekt zu sehen sind. Ansonsten gibt es hier endlose Disk. Cäsium137 (D.) 10:32, 19. Jun. 2009 (CEST)

P.S.: SBL Hebrew hat nur 82 der 87 Zeichen. Das ist gewiss kein Vorteil. MPH 2B Damase deckt sogar nur 51 Zeichen ab. Cäsium137 (D.) 10:38, 19. Jun. 2009 (CEST)

Mit den 87 Zeichen meinst Du vermutlich die Zeichen im Unicode Hebrew Range (0590-05FF). Es gibt außer diesen auch noch die hebräischen Zeichen in Alphabetic Presentation Forms (FB00-FB4F). Es ist aber für eine korrekte Darstellung nicht so wesentlich, ob auch extrem ausgefallene Zeichen vorhanden sind (beispielsweise werden die Zeichen für Kantillation bei uns hier überhaupt nicht benötigt), sondern ob die Kombination von Zeichen (Kerning) richtig funktioniert. Bekanntlich ist Arial Unicode MS in dieser Hinsicht defizitär.

Fontbeispiele finden sich z. B. unter http://www.wazu.jp/gallery/Fonts_Hebrew.html. Vor allem zu beachten die Zahl der Kerning Pairs bei den jeweiligen Fonts.

Interessant ist auch die SBL Website http://www.sbl-site.org/educational/biblicalfonts.aspx und zur Problematik der Darstellung vor allem das User Manual (http://www.sbl-site.org/Fonts/SBLHebrewUserManual1.5x.pdf).

Hoffe das hilft bei der Entscheidungsfindung ;-) --WolfgangRieger 16:46, 19. Jun. 2009 (CEST)

Noch ein paar Schriften zur Ergänzung und zum Vergleich:

SBL Hebrew:	זֹהַר
Cardo:	זֹהַר
TITUS Cyberbit Basic:	זֹהַר
DejaVu Sans:	זֹהַר
Times New Roman:	זֹהַר
Arial Unicode MS:	זֹהַר
serif:	זֹהַר
sans-serif:	זֹהַר

Wenn die Font nicht installiert ist, erscheint monospace.

Brauchbar erscheinen mir für Althebräisch eigentlich nur „SBL Hebrew“, „Cardo“, „Code2000“ und „DejaVu Sans“. Letztere als serifenlose Schrift nicht so schön, aber verbreitet. Code2000 ist zwar keine Freeware, aber das scheint hier sonst auch nicht zu stören. Meinen obigen Vorschlag würde ich daher folgendermaßen modifizieren:

font-family:"SBL Hebrew", Cardo, Code2000, "DejaVu Sans", david, narkisim, "Arial Unicode MS"; font-size:125%;

„david“ und „narkisim“ sind zwar nicht besonders geeignet, aber (glaube ich) in Israel verbreitet. --WolfgangRieger 17:41, 19. Jun. 2009 (CEST)

OK, jetzt habe ich etwa 2 Wochen auf eine Reaktion gewartet. Wenn Seiten vollgesperrt sind, weil nicht jeder daran herumfummeln soll, muss umgekehrt auf Vorschläge, Anforderungen etc. in angemessener Zeit reagiert werden. Wenn ihr überlastet seid, dann lasst halt noch ein paar neue Admins wählen. --WolfgangRieger 00:25, 4. Jul. 2009 (CEST)

Es liegt nicht an der Überlastung, aber diese Seite ist wenig beobachtet. Wenn zudem überhaupt kein Kommentar auf einen Vorschlag kommt, wird ein Admin, der nicht in der Materie steckt, auch nicht tätig. Wenn du die Änderung willst, dann sorg auch dafür, dass andere Nutzer ihr zustimmen oder dass ein versierter Admin darauf aufmerksam wird. Im Übrigen ist die Commons.css nicht vollgesperrt, vielmehr ist der Namensraum durch die serverseitige Softwarekonfiguration auf die Bearbeitung durch Administratoren beschränkt. Der Unterschied mag klein sein, ist jedoch durchaus wichtig. --32X 09:23, 5. Jul. 2009 (CEST)

Vorlage:Polytonisch

Gewissermaßen Fortsetzung von oben

"SBL Greek" ist übrigens bei Altsprachlern auch verbreitet. In Vorlage:Polytonisch ist eine Klasse definiert, die hier allerdings nicht berücksichtigt wird, und was steht in der Vorlage an erster Stelle? Arial Unicode MS! Und auf der dortigen Disk wird hierher verwiesen, das Problem scheint aber nicht angekommen zu sein.

Als Fontvergleich für Altgriechisch siehe z. B. http://www.gottwein.de//unicode/examples/greek_table_1.html und http://www.gottwein.de//unicode/examples/greek_table_2.html (Gottwein nimmt allerdings SBL Greek offenbar nicht zur Kenntniss). Was die Darstellung anbelangt, braucht Arial Unicode u. ä. hier keine Kombination von diakritischen Zeichen, da für praktisch alle Kombinationen Glyphen vorhanden sind. Ob Arial oder andere Fonts mit ähnlicher Funktion (Abdeckung eines möglichst großen Zeichenvorrats) hier ein optisch besonders ansprechendes Ergebnis liefern, bezweifle ich, doch das ist Geschmackssache.

Zumindest sollte hier ein Eintrag für die Klasse stehen und die Vorlage entsprechend geändert werden. --WolfgangRieger 16:46, 19. Jun. 2009 (CEST)

Vorlage:Altitalisch

Für .altitalisch nur Schriften zu deklarieren, die allesamt kein Altitalisch können, kann gar nicht funktionieren. Die Klasse muss unbedingt eine eigene Fontdekaration mit Schriften für Altitalisch bekommen. -- Prince Kassad 17:11, 2. Mär. 2008 (CET)

Das kann bestimmt gemacht werden. Vorher muss aber Einigkeit über die Font und ihre Prioritäten erzielt werden. Cäsium137 (D.) 19:31, 3. Mär. 2008 (CET)

Mein Vorschlag: Aegean, "MPH 2B Damase", Cardo, Code2001, Quivira. -- Prince Kassad 10:35, 4. Mär. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 11:43, 11. Mai 2013 (CEST)

Ermittelte Schriften

Nachfolgend mein angepasster Vorschlag für die Sprachklassen. Damit möglichst viele Leser alle Zeichen sehen, hat die Vollständigkeit im Font den Vorzug vor der Qualität bekommen. Die Vorlagen, welche sie benutzen, sind nicht für lange Fließtexte gedacht.

 span.Unicode
 {
  font-family:
  'Code 2000',
  'Sun-ExtA',
  'Arial Unicode MS',
  'NSimSun',
  sans-serif;
 }

 span.Unicode1
 {
  font-family:
  'Code 2001',
  'Quivira',
  'MPH 2B Damase',
  sans-serif;
 }

 span.Unicode2
 {
  font-family:
  'Sun-ExtB',
  'Code 2002',
  sans-serif;
 }

 span.IPA
 {
  font-family:
   'Quivira',
   'Code2000',
   'Sun-ExtA',
   'DejaVu Sans',
   'Gentium',
   'Arial Unicode MS',
   'Lucida Sans Unicode',
   sans-serif;
 }

 span.IAST
 {
  font-family:
   'Code2000',
   'SunExtA',
   'Arial Unicode MS',
  sans-serif;
 }

 span.altitalisch
 {
  font-family:
   'Quivira',
   'Code2001',
   'MPH 2B Damase',
   sans-serif;
 }

 span.gotisch
 {
  font-family:
   'Quivira',
   'Code2001',
   'MPH 2B Damase',
   sans-serif;
 }

 span.hebrew
 {
  font-family:
  'Quivira',
  'Sun-ExtA',
  'Arial Unicode MS',
  'SBL Hebrew',
  'Code2000,
  'MPH 2B Damase',
  sans-serif;
 }

 span.spanAr
 {
  font-family:
  'Arial Unicode MS',
  'Code2000',
  'MPH 2B Damase',
  'DejaVu Sans',
  sans-serif;
 }

 span.music-symbol
 {
  font-family:
  'Musical Symbols',
  'Euterpe',
  'Code2001',
  sans-serif;
 }

Cäsium137 (D.) 19:14, 19. Mär. 2008 (CET)

Sun-ExtA ist für Hebräisch gar nicht zu empfehlen und sollte nur benutzt werden, wenn wirklich keine einzige andere Schrift verfügbar ist. Außerdem bei span.music-symbol noch Musical Symbols hinzufügen. -- Prince Kassad 19:52, 19. Mär. 2008 (CET)

Sun-ExtA ist aber vollständig (87 Zeichen) und 'SBL Hebrew' hat nur 82 Zeichen. Cäsium137 (D.) 19:56, 19. Mär. 2008 (CET)

Quivira hat auch alle 87 Zeichen, daher kann man die Schrift ruhig nach vorne schieben.
Aber meinem Vorschlag, die Schrift Musical Symbols zu den Musikschriften hinzuzufügen, stimmst du zu, oder? -- Prince Kassad 20:13, 19. Mär. 2008 (CET)

Ok. Ich lade sie mir gerade aus dem Web herunter. Hast du von 'TITUS Cyberbit Basic' eine von Babelmap Generierte Liste der Zeichen ? Ich möchte mich nicht gerne an dieser Uni namentlich anmelden, nur um die Schrift zu bekommen. Cäsium137 (D.) 20:22, 19. Mär. 2008 (CET)

Die Schrift ist leider nicht in meinem Besitz. (Nachtrag: aber hier scheint es diese Zusammenfassung zu geben) -- Prince Kassad 20:43, 19. Mär. 2008 (CET)

Bringt keine weiteren Vorteile. Cäsium137 (D.) 12:41, 22. Mär. 2008 (CET)

Hallo,

auf meiner Diskussionsseite hat sich Benutzer:Ghermezete gemeldet, dass bei ihm der arabische Buchstabe 'ی' mit der Vorlage:fa/Vorlage:faS in der Wortmitte falsch dargestellt wird. Letztendlich werden dabei ja über <span class"spanAr"> die Fontdefinitionen hier aus Common.css verwendet. Ein Durchprobieren der verwendeten Fonts in der Disk zeigte, dass bei ihm nur die Darstellung mit der Font-Family 'Arial Unicode MS' "falsch" ist. Auch bei mir ist das klar die "hässlichste" Variante.

Von daher die Frage: Kann man nicht die Reihenfolge der Font-Families umstellen (mir schon klar, dass da viele Faktoren wie Betriebssystem, Browser, etc. mitspielen)? Z.B. verwendet aber ja die Eingabeleiste für arabische Schriftzeichen zuerst die Font-Family 'Traditional Arabic', die bei mir klar besser aussieht. Die Leiste dürfte ja auch relativ häufig benutzt werden, von daher sollten Probleme damit aufgefallen sein.

Als Hintergrund: Ghermezete verwendet Firefox sowohl unter Windows wie Linux, ich selber habe es mit Firefox 3 und IE6 unter Windows XP SP2 versucht (ohne speziell installierte Fonts, soweit ich weiß).

Viele Grüsse, -- S.K. 00:51, 5. Aug. 2008 (CEST)

Wir hatten heute eine ähnliche Diskussion hier: Diskussion:Allah. --Liberaler Freimaurer (Diskussion) 00:55, 5. Aug. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 11:43, 11. Mai 2013 (CEST)

Infobox

Erster Vorschlag

 div.infobox,
 table.infobox {
   caption-side:top;
   table-layout:auto;
   margin: 0.5em 0em 0.5em 1em;
   border: #000000 2px solid;
   border-collapse:collapse;
   empty-cells:show;
   float:right;
 }

 table.infobox td {
   border: #999999 1px solid;
   padding:0.2em;
   background:#ffffff;
 }

 table.infobox th {
   border: #999999 1px solid;
   padding:0.2em;
   background:#eeeeff;
   text-align:center;
   vertical-align:middle;
 }

Das sieht so aus:

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Kopfzeile Zelle 1	Zentriert	Kopfzeile Zelle 3
Normalzeile Zelle 1	Normalzeile Zelle 2	Links

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Ich bitte um konstruktive Stellungnahmen. Cäsium137 (D.) 23:06, 16. Jul. 2008 (CEST)

Warum eine Unterseite? Ich denke, dass sollte man auch so schaffen, aber egal. Auf jeden Fall muss ein clear: right; hinzu, damit man float-probleme behebt, das die Box zur seite und nicht nach unten ausweicht, wenn beispielsweise die Sichtungsbox ausgeklappt wird. Ich weiß nicht, ob man dort max-width; und min-width einbauen kann? Vielleicht auch eine Standardbreite (width) damit man dies nicht extra deklarieren muss. Das 'margin' würde ich an .float-right anpassen (margin: 1em 0 1em 1em;; kann eine Klasse eine andere nutzen? Wäre hier sinnvoll/praktisch) Der Umherirrende 00:45, 17. Jul. 2008 (CEST)

margin-top sollte auf 0 stehen, denn Infoboxen sind am oberen Rand vom Artikel und sollten oben bündig mit dem Text anfangen. Außerdem sorgt ein margin-top > 0 für unterschiedliche Darstellung der Tabellen-Caption bei unterschiedlichen Browsern, weil der Firefox bis einschließlich Version 3 nicht vollständig konform zu CSS 2.1 ist, sondern zum Teil CSS 2.0 verwendet. --Fomafix 01:26, 17. Jul. 2008 (CEST)

Ok. Ohne U-Seite. Ein em lässt sich gewiss machen. Eine andere Klasse nutzen erreicht man am besten, indem man einfach die Werte kopiert. Min-width ist m.E. wichtig. Max-width passt nur zu table-layout:fixed, was aber generell nicht gewünscht sein dürfte. Neue Version:

Version 2

 div.infobox,
 table.infobox {
   caption-side:top;
   table-layout:auto;
   margin: 1em 0em 1em 1em;
   border: #000000 2px solid;
   border-collapse:collapse;
   empty-cells:show;
   float:right;
   clear:right;
 }

"Td" und "th" wie in Version 1. Das sieht so aus:

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Kopfzeile Zelle 1	Zentriert	Kopfzeile Zelle 3
Normalzeile Zelle 1	Normalzeile Zelle 2	Links

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Cäsium137 (D.) 01:03, 17. Jul. 2008 (CEST)

Die Hintergrundfarbe der Tabelle darf nicht an den Zellen (table.infobox td { background:#ffffff; }) definiert werden, denn dann kann eine Infobox-Vorlage die Hintergrundfarbe nicht mehr für die gesamte Tabelle verstellen: {| class="infobox" style="background: #efe". Eine Hintergrundfarbe ungleich transparent muss für die Tabelle vorgegeben, denn sonst scheinen die Rahmenlinien der Überschriften durch. Also, entweder table.infobox, div.infobox { background:#ffffff; } wie bei normalen Tabellen oder table.infobox, div.infobox { background:#f9f9f9; } wie bei prettytable. Bei Titelzellen ist eine Hintergrundfarbe sinnvoll. Bei prettytable ging das im Nachhinein nicht mehr, siehe #Hintergrundfarbe Titelzellen. --Fomafix 02:02, 17. Jul. 2008 (CEST)

Das müsste man dann bei td und th weglassen. Eine Anlehnung an prettytable ist bei den Maßen aber sinnvoll, da viele Boxen z.Z. "prettytable" verwenden und es sonst zu Layoutstörungen kommen kann. Ich schlage auch 200px als Mindestbreite vor. Cäsium137 (D.) 12:47, 17. Jul. 2008 (CEST)

Es ergibt sich die Version 3:

Version 3

 div.infobox,
 table.infobox {
   caption-side:top;
   table-layout:auto;
   margin: 1em 0em 1em 1em;
   border: #000000 2px solid;
   border-collapse:collapse;
   empty-cells:show;
   float:right;
   clear:right;
 }

 table.infobox td {
   border: #999999 1px solid;
   padding:0.2em;
 }

 table.infobox th {
   border: #999999 1px solid;
   padding:0.2em;
   text-align:center;
   vertical-align:middle;
 }

Das sieht, einmal ohne und dann mit Zeilenfarbe, so aus:

Kopfzeile Zelle 1	Zentriert	Kopfzeile Zelle 3
Normalzeile Zelle 1	Normalzeile Zelle 2	Links

Kopfzeile farbig	Zentriert	Kopfzeile Zelle 3
Normalzeile Zelle 1	Normalzeile Zelle 2	Links

Cäsium137 (D.) 13:21, 17. Jul. 2008 (CEST)

infobox soll eine neue Klasse werden, die für alle Infoboxen anwendbar sein sollte. In der Standardeinstellung sollte sie sinnvolle Vorgaben geben, aber jede Einstellung muss veränderbar sein. infobox darf aber durchaus anders als prettytable float-right sein. Vorallem das margin-top sollte auf 0 stehen.

Eine separate Hintergrundfarbe für Titelzellen finde ich eine prinzipiell eine sinnvolle Vorgabe. Sie kann überschrieben werden mit:

|-
! style="background:#fee" | Kopf

statt mit

|- style="background:#fee"
! Kopf

Für Infoboxen ist das ausreichend, denn Infoboxen haben häufig nur zwei Spalten und die Titelzellen werden für Zwischenüberschriften mit colspan="2" verwendet. Allerdings gibt es auch Vorlagen, wie die Vorlage:Infobox Gemeinde in Deutschland, die Hintergrundfarbe der Tabelle als Hintergrundfarbe für den Rahmen und die Titelzellen verwenden und hingegen jeder normalen Tabellenzeile eine eigene Hintergrundfarbe zuweisen. Wenn infobox für alle Infoboxen verwendbar sein soll, dann darf dort keine Definition gemacht werden, die bei den bestehenden Infoboxen Probleme macht und sondern muss in separate Klassen oder HTML-Attribute ausgelagert werden. Das betrifft vorallem die Descendant-Selectoren, also Hintergrundfarbe und Rahmen(farbe). Allerdings werden Infoboxen üblicherweise im Vorlagen-Namensraum definiert und nicht wie normale (prettytable) Tabellen im Artikel-Namensraum.

Mindestbreiten sind prinzipiell sinnvoll, aber der Internet Explorer 6 versteht min-width nicht.[13] --Fomafix 14:35, 17. Jul. 2008 (CEST)

Für Artikel, die mehrere Infoboxen gleichzeitig brauchen und die Abschnitte nicht mit einem klaren clear:both abtrennen können, sondern die Infoboxen aneinanderhängen, wäre ein umschließender div-Container um die Infoboxen sinnvoll, um solche Probleme zu vermeiden. Besteht da Unterstützungsbedarf mit CSS-Klassen? --Fomafix 15:10, 17. Jul. 2008 (CEST)

• Der IE6 ignoriert es, die Tabelle funktioniert aber noch, wenn auch ggf. schmaler. Ein Grund mehr, dass User den IE upgraden oder gleich einen anderen Browser nehmen...
• Oben kein Rand ist sinnvoll, da die Box fast immer ganz oben steht.
• Wir sollten ausprobieren, ob es mit "BoxenVerschmelzen" passt.
• Ich erbarme mich mal der Situation und probier es in meinem BNR aus.

Cäsium137 (D.) 19:07, 17. Jul. 2008 (CEST)

Nachtrag: Erste Tests zeigen:

1. Auch relative Breiten funktionieren. Hauptfeldbreite = 100%
2. überschreiten eines max-width erzeugt Unbrüche.

Wir können also auch max-width setzen und Prozente angeben.

Ich bin für min-width:25%; max-width:67%;

Cäsium137 (D.) 19:52, 17. Jul. 2008 (CEST) Es Wert für width muss auch hinein, da sonst die Layouts durcheinander geraten. Mein Tipp: 33% Cäsium137 (D.) 07:42, 19. Jul. 2008 (CEST)

Version 4

Zusammenfassung zu einem neuen Vorschlag:

 div.infobox,
 table.infobox {
   caption-side:top;
   table-layout:auto;
   margin: 0em 0em 1em 1em;
   border: #000000 2px solid;
   border-collapse:collapse;
   empty-cells:show;
   min-width:25%;
   width:33%;
   max-width:67%;
   float:right;
   clear:right;
 }

 table.infobox td {
   border: #999999 1px solid;
   padding:0.2em;
 }

 table.infobox th {
   border: #999999 1px solid;
   padding:0.2em;
   text-align:center;
   vertical-align:middle;
 }

Für td auch vertical-align:top; ? Meinungen dazu ? Cäsium137 (D.) 07:32, 19. Jul. 2008 (CEST)

vertical-align:top; vermisse ich schon lange. Nichts spricht dagegen. --Revolus Echo der Stille 02:13, 21. Jul. 2008 (CEST)

Was soll das werden? Das neue Layout für Todesanzeigen in Wikipedia? --Elian Φ 02:25, 21. Jul. 2008 (CEST)

Nein, die bekommen einen schwarzen Hintergrund. --Revolus Echo der Stille 03:06, 21. Jul. 2008 (CEST)

achso, dann is ja gut. Und wofür sind jetzt diese schicken Klötze mit den Trauerrändern? --Elian Φ 03:52, 21. Jul. 2008 (CEST)

Wirklich etwas sehr Holzhammer. Wenn es gray oder silver wäre, ginge es (vielleicht) noch. Besser, außen 1px solid black und innen grau. Noch besser: außen 1px solid gray, innen 1px solid silver. --RalfR → DOG 2008 04:03, 21. Jul. 2008 (CEST)

Warum denn soviel Aufregung ? Ich habe doch lediglich farbneutrale Ränder und keine Hintergrundfarben definiert. Um eine vielseitige Verwendung zu gewähren sind Graustufen notwendig und 2px ist m.E. für den Außenrand auch nicht zu dick. Haben die Kritiker hier es überhaupt mal ausprobiert ? In euren Editlisten ist von einem Test nichts zu sehen. Cäsium137 (D.) 11:13, 22. Jul. 2008 (CEST)

Version 5

Um das Ganze nochmal zu beleben, jetzt die Version 5:

 div.infobox,
 table.infobox {
   caption-side:top;
   table-layout:auto;
   margin: 0em 0em 1em 1em;
   border: #000000 1px solid;
   border-collapse:collapse;
   empty-cells:show;
   min-width:25%;
   width:33%;
   max-width:67%;
   float:right;
   clear:right;
 }

 table.infobox td {
   border: #999999 1px solid;
   vertical-align:top;
   padding:0.2em;
 }

 table.infobox th {
   border: #999999 1px solid;
   padding:0.2em;
   text-align:center;
   vertical-align:middle;
 }

Wenn nichts Wichtiges dagegen spricht, dann sollten wir zu Potte kommen und die Klasse einsetzen. Cäsium137 (D.) 14:04, 2. Aug. 2008 (CEST)

Tilla hat's getan! Sehr schön :-) --Revolus Echo der Stille 02:17, 7. Aug. 2008 (CEST)

Ich habe darum gebeten. Am besten zunächst langsam (= wenige Einbindungen) umsetzen, damit sich die User nicht überrannt fühlen. Cäsium137 (D.) 02:26, 7. Aug. 2008 (CEST)

Ja, habe ich gesehen. Meiner Meinung fehlt da aber irgendwie die Hintergrundfarbe: "background-color: #f9f9f9;". Sieht so "steril" aus. Vielleicht wäre das aber auch etwas für die einzelnen Skins, etwas Individuelles? --Revolus Echo der Stille 02:38, 7. Aug. 2008 (CEST)

Die habe ich weggelassen, weil die Klasse in dem hier definierten Stil ja nur bei Usern ohne eigene CSS-Werte wirkt und dann bei fast allen Skins, z.b. auch Monobook, der Hintergrund weiß ist und das also dann passt. Weniger ist hier besser. Cäsium137 (D.) 09:32, 7. Aug. 2008 (CEST)

Und ich hab’s wieder rausgenommen. Können wir mal eine fertige Infobox mit den Klassen sehen? Selbst mir ist überhaupt nicht klar geworden, was ihr da geredet habt. Wollt ihr ein einheitliches Aussehen für alle Infoboxen? Bräuchte das nicht vielleicht ein etwas größeres Forum als diese Technikseite? Code·is·poetry 12:44, 7. Aug. 2008 (CEST)

Der Revert geht in Ordnung. Wenn auf dieser eher wenig beachteten Diskussionsseite ein Standard für alle Infoboxen beschlossen werden soll, so gebt das zumindest auf WP:FzW bekannt. Und stellt doch hier einfach mal eine Beispielinfobox vor, an Hand man sich dann auch ein Urteil bilden kann. Vielen Dank, --Gnu1742 14:06, 7. Aug. 2008 (CEST)

Und warum revertierst du dann einfach, obwohl du keine ahnung hast ? Wochenlang keine Äußerung von dir zum Thema und dann einfach reverten, nur weil du nicht durchblickst. Dein Revert und die Frage, wie das denn aussieht, zeigt mir: Du hast vom Thema zu wenig Ahnung, um es zu bewerten. Ich erwarte von dir, dass du den Text wieder einfügst, da du das Prinzip von CSS nicht verstanden hast. Überrlasse das doch anderen Admins. Es ist keine Schande, etwas nicht zu verstzehen. Cäsium137 (D.) 14:08, 7. Aug. 2008 (CEST)

Zur Sache: Der Sinn erschließt sich m. E. jedem, der sich mit CSS auskennt. Wer schlauer werden will: http://de.selfhtml.org hat Antwort. Cäsium137 (D.) 14:10, 7. Aug. 2008 (CEST)

Ok. War das so schlecht zu finden ? Ich erstelle ein Beispiel in meinem B-Raum. dauert etwas. Cäsium137 (D.) 14:18, 7. Aug. 2008 (CEST)

Fertig. Das Beispiel steht auf Benutzer:Cäsium137/Infoboxbeispiel Es funktioniert aber nur, wenn die Common.css auf die Version mit der Klasse (erstellt von Tilla) Re-revertet wird ! Cäsium137 (D.) 14:39, 7. Aug. 2008 (CEST)

Ich ignoriere mal dein ganzes PA-Krams, hat hier nun wirklich nix verloren. Ich habe die Änderung rückgängig gemacht, da ich keinen Konsens für die Eigenschaften sehe. Auch die Kompatibilität mit häufig verwendeten Infoboxen wurde wohl noch nicht getestet – mir ist klar, dass das nicht ganz einfach ist. Inhaltlich sehe ich die Klasse durchaus als Fortschritt an, auch wenn die Zusammenwirkung von prozentualer Breite und Bildern noch gut getestet werden muss, meines Wissens nach haben viele Infoboxen absolute Breitenangaben. Code·is·poetry 17:31, 7. Aug. 2008 (CEST)

Gut. Lassen wir PA weg. Zur Sache: Ist doch weitgehend klar: Die Box muss für einen nicht angemeldeten Leser vernünftig aussehen. Das bedeutet, dass sie relativ einfach aussehen sollte. Um zu sehen, was die Version 5 für IPs bewirkt, ist es aber notwendig, dass der CSS-Quelltext in der Common.css aktiv ist. Nur so sieht man im abgemeldeten Zustand die Box so, wie sie auch eine IP sieht. Daher solltest du die Version von Tilla wiederherstellen und wir einigen uns darauf, dass dies vorläufig ist und die Klasse nicht eher in verwendete Vorlagen kommt, bis das Ganze geklärt ist. Die WP-Software funktioniert nun mal so. Cäsium137 (D.) 21:07, 7. Aug. 2008 (CEST)

Da du dich so gut mit der WP-Software auskennst, schlage ich vor, dass das zuerst in einem Testwiki getestet wird. Entweder ein selbst aufgesetztes MediaWiki oder es wird von dir und anderen Interessierten vorab im http://de.labs.wikimedudia.org ausgetestet. Ich mache dich auch gerne zeitweise zum Admin dort, damit du an der Common.css herumspielen kannst. Aktuell wird das de.labs nicht weiter gebraucht. In ca. 2 Monaten allerdings haben wir anderes damit vor, dann solltet ihr fertig sein :) — Raymond ^{Disk. Bew.} 21:48, 7. Aug. 2008 (CEST)

@Cäsium137 Nachtrag: Du solltest noch deutlich ruhiger und gelassener werden und nicht mit „obwohl du keine ahnung hast“ und ähnlichen Ausdrücken um dich werfen. Vor allem wenn du die Person nicht kennst. Sowas kommt gar nicht gut an, überhaupt nicht gut, glaub mir. — Raymond ^{Disk. Bew.} 21:52, 7. Aug. 2008 (CEST)

Das muss ein Wiki sein, wo alle gemeinsam arbeiten können.

1. Viele User hier halten eine Klasse für sinnvoll.
2. Einige weitere haben sich an einer Initiative beteiligt.
3. Einer hat es - meinem Eindruck nach- zwar nicht verstanden (Zitat: "Bitte Was ?") revertiert aber trotzdem einfach. ;-)
4. Viele schreiben zwar, was sie nicht wollen, aber nicht, was stattdessen definiert werden soll.

Ich befürchte daher, dass ich da weitgehend alleine bleibe, obwohl viel sowas für sinnvoll halten. Cäsium137 (D.) 22:01, 7. Aug. 2008 (CEST)

Wie Version 5 aussieht, kann hier betrachtet werden. Cäsium137 (D.) 22:32, 7. Aug. 2008 (CEST)

Ich bin mir ziemlich sicher, dass ich mehr Ahnung von css habe als Tilla, aber gut, genug davon. Ich habe nun schon mal einen inhaltlichen Punkt genannt, auf den nicht eingegangen wurde. Die Vorlage:Infobox Tennisspieler verwendet meinem oberflächlichen Blick nach ganz andere Stile, wäre also bsw. nicht kompatibel – für die typischen EN-Infoboxen dürfte das gleiche gelten. Ich denke ein sinnvoller Ansatz wäre nicht das Erstellen eines kompletten, verwendbaren Designs, sondern das Finden eines Minimalkonsenses, sprich: Welche Eigenschaften braucht jede Infobox. Das ist im Wesentlichen margin und float. Zu einem einheitlichen Design aller Infoboxen werden wir so schnell nicht kommen, das fängt schon bei der Breite an – pixelabsolute, relative und em-absolute Angaben treten häufig auf. Code·is·poetry 09:54, 8. Aug. 2008 (CEST)

Das nicht zuviel hinein soll, habe ich oben schon erwähnt. Eine Breite ist als Defaultwert notwendig. Bei kleinen Abweichungen sind auch zusätzliche Einzelangaben im Tabellenkopf drin und "Tennisspieler" lässt sich mittels der Kombination class="infobox nogrid" erreichen. Wenn es für eine Vorlage mal absolut nicht passt, dann kann man die Klasse auch mal weglassen, auch wenn das nicht optimal ist. Hier kommt dann eine id in Frage. Cäsium137 (D.) 13:01, 8. Aug. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 11:43, 11. Mai 2013 (CEST)

Unicode-Fonts

Die Angabe von sans-serif als letzter Option in den diversen span-Klassen für spezielle Schriftsysteme ist kontraduktiv, da ja nicht ein spezieller Schrifttyp (serifenlos) erreicht werden soll, sondern eine Unterstützung bestimmter Zeichen, die u.U. eher in meiner Serifen-Standardschrift vorhanden sind. Außerdem stört es Skins, die als Textschrift eine mit Serifen verwenden.

Die Klassen altitalisch und gotisch sind (derzeit) identisch festgelegt und sollten daher zusammengefasst werden:

 span.altitalisch,
 span.gotisch
 {
  font-family:
   'Quivira',
   'Code2001',
   'MPH 2B Damase';
 }

Da der Klasse IAST im Vergleich zu Unicode nur „NSimSun“ fehlt, kann man die vielleicht auch zusammenfassen:

 span.Unicode,
 span.IAST
 {
  font-family:
  'Code2000',
  'Sun-ExtA',
  'Arial Unicode MS',
  'NSimSun';
 }

Man sollte darüber nachdenken, (stattdessen) dynamisch runterladbare Webfonts anzubieten, wobei die Unterstützung dafür bisher nur in den aktuellsten Versionen weniger Browser (v.a. Safari) gegeben ist, wenn man nicht EOTs für IE produzieren will. — Christoph Päper 11:21, 15. Sep. 2008 (CEST)

• CSS3 Fonts ED, 2008
• CSS3 Webfonts WD, 2002
• CSS 2.0, 1998

1. Dyn. Fonts sind wegen der schlechten Browserunterstützung nicht verwendbar.
2. Das sans-serif steht drin, weil es sich bei der Auswertung vieler Fonts gezeigt hat, dass diese im Durchschnitt vollständiger sind als die anderen. Die Fonts sind nach Vollständigkeit ausgesucht worden, denn ein grafisch schlechtes Zeichen ist besser als gar kein Zeichen.
3. Für größere Texte, bei denen das Aussehen wichtig wäre, sind diese Klassen auch nicht gedacht, sondern nur für Wortübersetzungen u. Ä.
4. Getrennte Stildefinitionen sind bei Bedarf separat editierbar. Ein Zusammenfassen der Klassen ist unnötig und dahingehend ein Nachteil. Die fünf Zeilen Quelltextersparnis sind kein Grund.
5. Wenn du bestimmte Fonts bevorzugst, dann schreibe das in deine eigene CSS. Das ist der Grund für die Klassen.

Ich sehe keinen Änderungsbedarf. Cäsium137 (D.) 13:52, 16. Sep. 2008 (CEST)

1. Da sie optional sind, sind sie natürlich verwendbar. Mein „(stattdessen)“ war quatsch, da Webfonts problemlos als erste Alternative angegeben werden können.
2. Tut mir leid, das ergibt (so) keinen Sinn, d.h. ohne nähere Spezifizierung von „diese“ und „die anderen“, denn bspw. ist TNR laut en:Unicode typefaces besser ausgebaut als Arial und das sind die Fallback-Schriften für die meisten Surfer. (Mal davon abgesehen, dass beide die Schriftsysteme, für die diese Klassen vorgesehen sind, nicht abdecken.) Außerdem ist die Textschrift des Standard-Skins Monobook, wenn ich mich nicht verguckt habe, ohnehin schon sans-serif. — Christoph Päper 11:46, 17. Sep. 2008 (CEST)

Genauer: "Diese" = serifenfrei, "die anderen" = mit Serifen. Maßgeblich für die Reihenfolge ist die Anzahl der vorhandenen Zeichen im entsprechenden Unicode-Block. erst danach kommt es auf die Qualität an. Cäsium137 (D.) 13:37, 17. Sep. 2008 (CEST)

Der englische Artikel ist hoffnungslos veraltet. TNR enthält genau zwei Zeichen weniger als Arial. -- Prince Kassad 14:54, 17. Sep. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 11:43, 11. Mai 2013 (CEST)

class="prettytable": Kleinen CSS-Ersatz für cellpadding ermöglichen

Weil das <style>-Tag von der MediaWiki-Software anscheinend unterdrückt wird, ist folgendes nicht möglich,

<style type="text/css">
.tablePad2 th td { padding:1.6em }
</style>
{| class="prettytable tablePad2"
...
|}

und somit ist auch kein CSS-Ersatz für cellpadding möglich, was mich heute zum erstellen vom unschönen Abschnitt «Hilfe:Tabellen#Probleme mit der class="prettytable"» (PermaLink) veranlasst hat. Da das <style>-Tag wohl kaum freigegeben wird (warum eigentlich?), schlage ich irgendwie in etwa folgende Ergänzung für die MediaWiki:Common.css vor,

.tablePad0 th td { padding:0     } /* Null */
.tablePad1 th td { padding:0.8em } /* etwa 10 pixel */
.tablePad2 th td { padding:1.6em } /* etwa 20 pixel */
.tablePad3 th td { padding:2.4em } /* etwa 30 pixel */
.tablePad4 th td { padding:3.2em } /* etwa 40 pixel */
/* usw.? */

was beispielsweise irgendwie in etwa folgendes als Ersatz für cellpadding="20" möglich machen könnte:

{| class="prettytable tablePad2"

--ParaDox 20:11, 20:15, 23. Jun. 2008 (CEST)

So halte ich es für nicht gut, denn jeder Abstand muss separat definiert werden. Ich habe mal experimentiert, ob cellpadding auch mit prettytable kombinierbar wäre. Die derzeitige CSS-Definition

.prettytable td { padding: 0.3em; }

überschreibt das HTML-cellpadding. Wenn der Selektor auf das Gegenteil von

.prettytable[cellpadding] td { padding: 0.3em; }

eingeschränkt werden könnte, müsste das cellpadding wirksam sein. Ein zusätzliches

.prettytable[cellpadding] td { padding: inherit; }

oder

.prettytable[cellpadding] td { padding: auto; }

setzt aber leider nicht auf die HTML-Angabe zurück, sondern den padding-Initialwert des darüberliegenden td-Elements. Allerdings könnte mit diesen Trick die CSS-Definition von prettytable geändert werden auf:

.prettytable tr { padding: 0.3em; }
.prettytable td { padding: inherit; }
.prettytable[cellpadding] td { padding: auto; }

Folgende Tabelle mit class="prettytable"

A	B
C	D

sieht gleich aus wie die Tabelle mit dem obigen Trick

A	B
C	D

nur dass hier cellpadding="20" funktioniert:

A	B
C	D

Zuerst muss aber getestet werden, ob das in allen Browsern funktioniert und keine sonstigen Nebenwirkungen hat. --Fomafix 12:36, 1. Jul. 2008 (CEST)

Beim Internet Explorer funktioniert es leider nicht, da das inherit nicht versteht. --Fomafix 12:43, 1. Jul. 2008 (CEST)

Es gibt in CSS3 das Gegenteil von

.prettytable[cellpadding] td { padding: 0.3em; }

und zwar

.prettytable:not([cellpadding]) td { padding: 0.3em; }

Es wäre damit ein ähnlicher Workaround zur Aktivierung der HTML-Attribute, wie bei den zentrierten Tabellen und Galerien. --Fomafix 21:52, 5. Nov. 2008 (CET)

Die eleganteste Lösung wäre:

.prettytable { padding: 0.3em; }
.prettytable tbody,
.prettytable tr,
.prettytable th,
.prettytable td { padding: inherit; }

Dann könnte der Innenabstand direkt per CSS an der Tabelle eingestellt werden:

{| class="prettytable" style="padding: 1em"
|-
| Tabelle mit großem Padding
|}

Tabelle mit großem Padding

Durch das border-collapse:collapse ist eh nur noch das Padding an den Zellen selbst relevant und wird durch inherit von table übernommen. Leider versteht der Internet Explorer inherit nicht, so dass es aus dieser Lösung nichts wird. --Fomafix 15:47, 30. Jul. 2009 (CEST)

cellpadding ist in HTML5 nicht mehr enthalten. Mit rev:94465 wurde begonnen veraltete HTML-Attribute in entsprechendes Inline-CSS zu wandeln. cellpadding ist da allerdings noch nicht dabei, weil es nicht so einfach ist, das abzubilden. Wir sollten hier nicht noch eine Möglichkeit aufmachen, das irgendwie mit projektweiten CSS-Definitionen zu ermöglichen. Die meiner Meinung nach richtige Lösung wäre das style-Element mit dem Attribut scoped von HTML5 mit entsprechender Filterung im Wikitext zu ermöglichen. --Fomafix 13:17, 27. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 13:17, 27. Jan. 2012 (CET)