MediaWiki Diskussion:Common.css
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) |
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> Text im Kasten
| ||||
<div class="hintergrundfarbe1 rahmenfarbe4" style="border-style: solid; border-width: 3px; width: 200px; text-align: center;">Text im Kasten</div> Text im Kasten
| ||||
{| width="280" border="1" cellpadding="2" cellspacing="0" class="hintergrundfarbe2"
|
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)
- 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)
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)
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)
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)
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)
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)
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)
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)
- Danke für die schnelle Reaktion. Sieht jetzt schon viiiiieeeel besser aus ;) --Bodo Thiesen 00:05, 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;"
durchclass="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:
- Ich finde von Cäsium137, den rechten Rand nur bei
{| |- valign="top" | {| class="prettytable" | linke prettytable |} | {| class="prettytable" | rechte prettytable |} |}
sieht derzeit so aus:
|
|
sah bisher so aus:
|
|
und wird mit dem Vorschlag von Cäsium137 so aussehen:
|
|
- 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)
- Ich kann mich mit dieser Darstellung anfreunden. Die derzeitige Darstellung mit
- 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;
- ohne
Tabellenkörper |
- mit
margin-left: inherit; margin-right: inherit;
- mit
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 Fallcentered
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 Tabellenkörper |
- Mit
margin-left:inherit; margin-right:inherit;
ist die Beschriftung nur so breit wie die Tabelle und die Mitte bleibt die Mitte:
- Mit
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 mitclass="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
undcentered
sind aber alle universell einsetzbar und sollten weiterhin für alle Elemente zur Verfügung stehen. - Die gleichwerten CSS-Klassen
prettytable
undwikitable
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 Tabellenkörper |
---|
Bzw. mit expandierter CSS-Klasse prettytable so:
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 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)
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)
- Genau genommen werden die Angaben im
- 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)
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)
class="wikitable"
mehr verwendet. --Fomafix 17:20, 17. Apr. 2008 (CEST)
Pro, sofern wirklich kein Artikel - 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. Wennwikitable
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)
- In der französischen Common.css gibt es nur die CSS-Klasse
- 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)
- 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
- 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)
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.)
"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)
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)
- Erledigt. — Raymond Disk. Bew. 17:03, 17. Mai 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)
- Moin, ist jetzt drin. Sorry, hat wohl vorher einfach niemand gesehen. :( Viele Grüße, —mnh·∇· 14:01, 16. Jun. 2008 (CEST)
".reference, .references sup" könnte "white-space:nowrap" gut vertragen (erl.)
<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"/>
<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)
- Vielen Dank
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 mitprettytable
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überliegendentd
-Elements. Allerdings könnte mit diesen Trick die CSS-Definition vonprettytable
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)
- Beim Internet Explorer funktioniert es leider nicht, da das
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)
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)
.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 einpadding: 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)