Zum Inhalt springen

MediaWiki Diskussion:Common.css

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 11. Juli 2008 um 17:35 Uhr durch Cäsium137 (Diskussion | Beiträge) (.prettytable-Innenabstand). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 16 Jahren von Cäsium137 in Abschnitt .prettytable-Innenabstand
Diese Common.css-Anweisungen werden gemeinsam von den verschiedenen Stylesheets aller Skins genutzt; siehe auch Wikipedia:Skin.

Bitte Common.css nur für Anweisungen im Textfeldbereich und für 100%ig funktionierende (browser-, auflösungs- und skinunabhängige), zuvor geprüfte Ergänzungen verwenden, also nicht für absolute Positionierungen. --:Bdk: 14:02, 17. Dez 2005 (CET)/13:38, 18. Feb. 2008 (CET)Beantworten

Archiv
Wie wird ein Archiv angelegt?

Anwendung der Definitionen

Rahmen- und Hintergrundfarben

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

  • skinunabhängige und
  • einheitliche

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

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

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

Übersicht

Definiert sind rahmenfarbe1 bis rahmenfarbe5 und hintergrundfarbe1 bis hintergrundfarbe9.

rahmenfarbe1
Wie Inhaltsverzeichnis
rahmenfarbe2
Unauffällig, geringer Kontrast
rahmenfarbe3
„Rot“, auffällig
rahmenfarbe4
Neutrale Farbe, deutlich
rahmenfarbe5
„Schwarz“, hoher Kontrast
 
hintergrundfarbe1
Wie Inhaltsverzeichnis
hintergrundfarbe2
„Weiß“, für Nicht-Artikel-Seiten, neutral
hintergrundfarbe3
„Gelb“, auffällig
hintergrundfarbe4
Sehr auffällig
hintergrundfarbe5
Neutral, abgesetzt
hintergrundfarbe6
Allgemeine Hervorhebung, Unterscheidung
hintergrundfarbe7
Allgemeine Hervorhebung, Unterscheidung
hintergrundfarbe8
Allgemeine Hervorhebung, Unterscheidung
hintergrundfarbe9
Allgemeine Hervorhebung, Unterscheidung

H 1 + R 1 H 2 + R 1 H 3 + R 1 H 4 + R 1 H 5 + R 1 H 6 + R 1 H 7 + R 1 H 8 + R 1 H 9 + R 1
H 1 + R 2 H 2 + R 2 H 3 + R 2 H 4 + R 2 H 5 + R 2 H 6 + R 2 H 7 + R 2 H 8 + R 2 H 9 + R 2
H 1 + R 3 H 2 + R 3 H 3 + R 3 H 4 + R 3 H 5 + R 3 H 6 + R 3 H 7 + R 3 H 8 + R 3 H 9 + R 3
H 1 + R 4 H 2 + R 4 H 3 + R 4 H 4 + R 4 H 5 + R 4 H 6 + R 4 H 7 + R 4 H 8 + R 4 H 9 + R 4
H 1 + R 5 H 2 + R 5 H 3 + R 5 H 4 + R 5 H 5 + R 5 H 6 + R 5 H 7 + R 5 H 8 + R 5 H 9 + R 5

Beispiele

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

<div class="hintergrundfarbe5 rahmenfarbe3" style="border-style: solid; width: 200px; text-align: center;">Text im Kasten</div>
erzeugt

Text im Kasten

<div class="hintergrundfarbe1 rahmenfarbe4" style="border-style: solid; border-width: 3px; width: 200px; text-align: center;">Text im Kasten</div>
erzeugt

Text im Kasten

{| width="280" border="1" cellpadding="2" cellspacing="0" class="hintergrundfarbe2"
|-
! colspan="2" class="hintergrundfarbe8" | Tabelle
|-
| Inhalt || Inhalt
|}
erzeugt

Tabelle
Inhalt Inhalt

Diskussion

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:

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

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

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

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

Hier darf laut Vorlage Diskussion:Hebräisch 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)Beantworten

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

done. --DaB. 23:46, 2. Apr. 2008 (CEST)Beantworten
Danke für die schnelle Reaktion. Sieht jetzt schon viiiiieeeel besser aus ;) --Bodo Thiesen 00:05, 3. Apr. 2008 (CEST)Beantworten
immer noch gut? hab das CSS noch ein klein wenig verkürzt. -- 00:54, 3. Apr. 2008 (CEST)Beantworten

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

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

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

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

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

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

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 [1], 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)Beantworten

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

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

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

Danke für’s zurücksetzen. --Fomafix 08:39, 8. Apr. 2008 (CEST)Beantworten
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)Beantworten

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

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

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

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

Pro, sofern wirklich kein Artikel class="wikitable" mehr verwendet. --Fomafix 17:20, 17. Apr. 2008 (CEST)Beantworten
Die Volltextsuche zeigt keinen mehr auf. Cäsium137 (D.) 17:32, 17. Apr. 2008 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
"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)Beantworten
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)Beantworten

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

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

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

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

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

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

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

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

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

gute Idee. -- San Jose 14:11, 7. Mai 2008 (CEST)Beantworten
Da hatte noch einer die Idee. --Revolus Echo der Stille 22:09, 7. Mai 2008 (CEST)Beantworten
Dieser Abschnitt kann archiviert werden. Revolus Echo der Stille (22:09, 7. Mai 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)Beantworten

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)Beantworten
Erledigt. — Raymond Disk. Bew. 17:03, 17. Mai 2008 (CEST)Beantworten
Danke, so sehen die Artikel schon viel besser aus. Der Umherirrende 18:04, 17. Mai 2008 (CEST)Beantworten

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

Hallo? Aus welchen Gründen werden diese Änderungen nicht eingefügt? gruss--kajk 13:56, 16. Jun. 2008 (CEST)Beantworten
Moin, ist jetzt drin. Sorry, hat wohl vorher einfach niemand gesehen. :( Viele Grüße, —mnh·· 14:01, 16. Jun. 2008 (CEST)Beantworten
np, danke viel mals :-) gruss--kajk 13:21, 17. Jun. 2008 (CEST)Beantworten

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

Schon bei ganz simplen Gruppen-Refs wie <ref group="a">[a 1] 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)Beantworten

    Done. Dafür ist die Common.css da. —mnh·· 18:41, 23. Jun. 2008 (CEST)Beantworten
    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)Beantworten
    Dito und danke für's Entfernen. Viele Grüße, —mnh·· 19:06, 23. Jun. 2008 (CEST)Beantworten

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

    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)Beantworten
    Beim Internet Explorer funktioniert es leider nicht, da das inherit nicht versteht. --Fomafix 12:43, 1. Jul. 2008 (CEST)Beantworten

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

    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)Beantworten
    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)Beantworten
    € wäre auch so ein fall, das wie % immer nicht-umbrechend ist.. --W!B: 18:15, 9. Jul. 2008 (CEST)Beantworten

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

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

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

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

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