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)

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Archiv

Archiv 1 Archiv 2

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:

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

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)

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)

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

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.[2] --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)

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)

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)

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)

toclimit

Wäre es vielleicht möglich, aus en:MediaWiki:Common.css die class "toclimit" hier einzufügen? Dann könnte man nämlich auch die Vorlage en:Template:TOClimit hier einbinden, mit der man bestimmte Überschriften-Ebenen im Inhaltsverzeichnis ausblenden kann. Gruß --D.H 12:42, 7. Dez. 2008 (CET)

FirstHeading auf der Hauptseite

durch den Eintrag

 /* Überschrift verbergen */
 body.page-Wikipedia_Hauptseite h1.firstHeading {
  display: none;
 }

wird die Überschrift auf der Hauptseite ausgeblendet, dies finde ich sinnvoll. Nur wird durch die Anweisung auch die Überschrift in der Versionsgeschichte, im Diff und beim Bearbeiten unterdrückt. Dies lässt die Oberfläche dort etwas komisch aussehen. Kennt jemand eine Lösung, wie man mit CSS erreichen kann, das dort keine Ausblendung erfolgt? Der Umherirrende 16:58, 19. Dez. 2008 (CET)

Der Wunsch ist berechtigt. Derzeit kann mit CSS ein solches bedingtes Ausblenden nicht erreicht werden, denn es gibt mit CSS keine Möglichkeit zu wissen, was weiter unten auf der Seite kommt. Einzige Möglichkeit wäre MediaWiki zu erweitern und ein Kenner (CSS-Klassen) am body anbringen zu lassen, der angibt, welche Aktion derzeit angezeigt wird. Dann könnte MediaWiki aber auch selbst die Überschrift ausblenden.

Einen bösen CSS-Hack habe ich aber, der ungefähr das gewünschte bewirkt:

#hauptseite {
  position:relative;
  top:-4em;
  margin-bottom:-4em;
}

--Fomafix 13:35, 19. Jun. 2009 (CEST)

Sun-ExtA

Analyse

Ich möchte anregen, den Gebrauch von Sun-ExtA zu minimieren, da dieser Font -- zumindest für IPA -- zu Darstellungsproblemen führt. Um zu sagen, wo genau er verschwinden soll, und wo stehenbleiben, müsste ich zuerst mal wissen, was Unicode, Unicode1 und Unicode2 machen sollen. Auf jeden Fall würde ich ihn bei IPA rausschmeißen wollen. Eigentlich gehört er doch nur bei CJK berücksichtigt, aber gerade dafür scheint keine zentrale Klasse definiert zu sein.

Siehe auch:

• Benutzer_Diskussion:Prince_Kassad#Sun-ExtA
• Wikipedia:Fragen_zur_Wikipedia#IPA-Template/CSS/Font

--Pjacobi 22:44, 20. Mai 2009 (CEST)

Unicode, Unicode1 und Unicode2 entsprechen den Planes 0, 1 und 2 in der Liste der Unicode-Blöcke. Ich hätte ja am liebsten die Klassen nach Schriftsystem aufgeteilt (so wie es z. B. im Wiktionary praktiziert wird), da damit Schriftprobleme vermieden werden können. -- Prince Kassad 22:57, 20. Mai 2009 (CEST)

Was genau stimmt da nicht ? Welche Zeichen sind betroffen ? Der WP-Editor spinnt hier. Ein Teil der Zeichen wird da nicht gezeigt: ɐɑɒɓɔɕɖɗɘəɚɛɜɝɞɟɠɡɢɣɤɥɦɧɨɩɪɫɬɭɮɯɰɱɲɳɴɵɶɷɸɹɺɻɼɽɾɿʀʁʂʃʄʅʆʇʈʉʊʋʌʍʎʏʐʑʒʓʔʕʖʗʘʙʚʛʜʝʞʟʠʡʢʣʤʥʦʧʨʩʪʫʬʭʮʯ

Der Vorteil der Sun-ExtA ist halt, dass sie eine gute Abdeckung der Unicode-Ebene 0 auch für nichtchinesische Zeichen bietet. Für IPA ist sie allerdings nicht nötig, da gibt es genug anderes. Gismatis 04:12, 21. Mai 2009 (CEST)

Die Reihe oben ist nicht betroffen. Vieleicht werden auch "nur" in IPA-Angaben Zeichen benutzt, die gar nicht IPA sind. Die Stelle, wo es mir deutlich aufgefallen ist: Vergleich: . --Pjacobi 09:32, 21. Mai 2009 (CEST)

Kann es sein, dass die letzten 7 Zeichen des Blocks, welche der Editor nicht richtig zeigt, oft Ersatzzeichen genommen werden ? Cäsium137 (D.) 14:19, 21. Mai 2009 (CEST)

à (U+00E0) und (á U+00E1) sind tatsächlich keine IPA-Zeichen und sie werden mit Sun-ExtA grundsätzlich falsch dargestellt, nämlich mit der Form ɑ, das einen anderen Laut repräsentiert. Ich habe diese Buchstaben durch die Tonzeichen ˦ (U+02E6) und ˨ (U+02E8) ersetzt. Die sind unproblematischer als die Akzente und verleiten weniger zu Lesefehlern (Die Akzente könnten für steigende bzw. fallende Töne gehalten werden). Das normale a (U+0061) wird auch in Sun-ExtA richtig dargestellt (Hier fehlt leider ein eindeutiges Unicode-Zeichen). Es gibt also auch bei IPA keinen Grund, Sun-ExtA nicht zu verwenden. Die mysteriösen Punktwolken müssen auf jeden Fall im Auge behalten werden. Gismatis 16:58, 21. Mai 2009 (CEST)

Es sind aber tatsächlich auch zwei IPA-Zeichen betroffen: ɑɡ. Zwar gibt es keine Punktwolken wie bspw. beim ü, aber trotzdem werden sie nicht korrekt dargestellt. -- Prince Kassad 17:21, 21. Mai 2009 (CEST)

Bei mir werden diese Zeichen richtig dargestellt. Hast du vielleicht eine ältere Version? Gismatis 18:23, 21. Mai 2009 (CEST)

Man könnte noch 'Sun-ExtA' mit 'DejaVu Sans' tauschen, aber die Vollständigkeit hat Vorrang vor den dahinter gelisteten Fonts mit nur 89 von 96 Zeichen. Cäsium137 (D.) 14:26, 21. Mai 2009 (CEST)

Du musst eine veraltete Version von DejaVu Sans haben. Meine Kopie weist alle 96 Zeichen auf. -- Prince Kassad 16:53, 21. Mai 2009 (CEST)

Du hast mich missverstanden: Ich meinte, 'DejaVu Sans' kann vor 'Sun-ExtA' weil es ebenfalls auch alle 96 Zeichen hat. die nachfolgenden aber nicht mehr. Cäsium137 (D.) 00:28, 22. Mai 2009 (CEST)

OK, jetzt habe ich zusätzlich zum IPA- ein Verständnisproblem.

• ˦ und ˨ sind rot!
• Laut unserem IPA-Artikel sind ˦ und ˨ gleichbedeutend mit den composing characters " ́" und " ̀". Letztere sind aber m.E. im Erscheinungsbild vorzuziehen. Ist es wirklich nötig, wegen des Defekts von Sun-ExtA überall von Letzteren auf Erstere umzustellen?
• Übrigens sind auch bei Internationales_Phonetisches_Alphabet#Töne_und_Intonation die Sun-ExtA-Fehler zu sehen.

Aber mal ganz pragmatisch gefragt: Warum schmeißen wir nicht einfach Sun-ExtA bei der CSS class IPA raus? --Pjacobi 17:35, 21. Mai 2009 (CEST)

Ich finde die Stabzeichen besser, aber die anderen gehen natürlich auch. Was läuft denn da bei IPA bloß schief? Tauchen diese Probleme noch bei anderen Schriften auf? Wie gesagt, Sun-ExtA ist bei IPA nicht nötig. Gismatis 18:23, 21. Mai 2009 (CEST)

Wenn du eine der davor gelisteten Schriften auf deinem System hast, dann kommt SunExtA gar nicht zur Wirkung. Nur, wenn weder 'Quivira' noch Code2000' und, nach der von mir vorgeschlagenen Vertauschung, auch nicht 'DejaVu Sans' auf seinem Rechner hat, der bekommt IPA mit SunExtA gezeigt. Cäsium137 (D.) 00:28, 22. Mai 2009 (CEST)

Völlig korrekt, aber was hat das mit der Frage zu tun, ob der (für diesen Bereich fehlerhafte) Font SunExtA aus der Liste entfernt werden soll? --Pjacobi 00:30, 22. Mai 2009 (CEST)

Die Schrift ist drin, da die anderen dahinter nicht komplett sind. Einfach als "letzte Möglichkeit vor der Unvollständigkeit". Besser Sun-ExtA als nur einen Teil der Zeichen und "Kästchen" sehen. Cäsium137 (D.) 00:38, 22. Mai 2009 (CEST)

Das überzeugt nicht, insbesondere wegen der Beobachtung, dass die enwiki-Einstellungen bei mir noch nie zu Problemen mit IPA geführt haben. ("Charis SIL", "Doulos SIL", Gentium, GentiumAlt, "DejaVu Sans", Code2000, "TITUS Cyberbit Basic", "Arial Unicode MS", "Lucida Sans Unicode", "Chrysanthi Unicode") --Pjacobi 00:55, 22. Mai 2009 (CEST)

Ohne Nummern kann ich das nicht nachvollziehen. Welche Zeichen genau (Hex-Nummern) werden von Sun-ExtA wie falsch dargestellt ? Cäsium137 (D.) 00:43, 22. Mai 2009 (CEST)

Die Vokale mit Akut, Makron, Gravis, Hatschek oder Zirkumflex. Anscheinend unabhängig davon, ob sie precomposed eingegeben sind oder nicht:

́ (Akut) oder ˦	U+0301 oder U+02E6	hoch	[é]
̄ (Makron) oder ˧	U+0304 oder U+02E7	mittel	[ē]
̀ (Gravis) oder ˨	U+0300 oder U+02E8	niedrig	[è]
̌ (Hatschek)	U+030C	steigend	[ě]
̂ (Zirkumflex)	U+0302	fallend	[ê]

--Pjacobi 00:55, 22. Mai 2009 (CEST)

Wer bitte schön hat das geschrieben? Die Akzente sind nicht in IPA, und werden für verschiedene, teils sogar komplett gegensätzliche Töne benutzt. -- Prince Kassad 19:14, 22. Mai 2009 (CEST)

Das sind doch keine Zeichen vom Block IPA-Extensions. Der geht von U+0250 bis U+02AF = 96 Zeichen. Danach folgen

U-02B0 bis U+02FF "Spacing Modify Letters" und U+0300 bis U+036F der Block "Combining Diacritical Marks". Cäsium137 (D.) 01:03, 22. Mai 2009 (CEST)

Es geht mir nicht um den Unicode Block IPA-Extensions, sondern um IPA. Und in IPA werden, wenn ich nicht völlig falsch liege, ein ganzer Haufen Zeichen verwendet, die nicht im Unicode Block IPA-Extensions liegen. Und wenn ein Font diese völlig falsch darstellt, dann ist er nicht zur Darstellung von IPA geeignet. Die obige Tabelle ist ein Ausschnitt aus Internationales_Phonetisches_Alphabet#Töne_und_Intonation. --Pjacobi 01:08, 22. Mai 2009 (CEST)

Also ich sehe da keine großen Unterschiede. Ich generiere mal ein Vergleichsbild. Cäsium137 (D.) 01:31, 22. Mai 2009 (CEST)

Sun-ExtA und IPA (2)

Hier der Vergleich (groß, damit man was sieht):

Was ist da schlimm ? Cäsium137 (D.) 01:35, 22. Mai 2009 (CEST)

Der Fehler tritt bei großen Schriftgrößen nicht auf! Irgendwo zwischen 14pt und 10pt wechselt die Anzeige bei SunExt auf die "Punktwolken" die Du in meinem Screenshot oben siehst. --Pjacobi 01:38, 22. Mai 2009 (CEST)

Ach so. Ich habe es getestet. Es tritt bei 10, 9 und 8 (nicht bei 11 und nicht bei 7) auf. Aber nur, wenn die Anzeige im Textverarbeitungsprogramm auch auf 100% steht. Stellt sich die Frage nach der generellen Nutzung. Taucht anscheinend nur bei den "Kombizeichen" auf Cäsium137 (D.) 01:47, 22. Mai 2009 (CEST)

P.S. Die SIL-Schriften sind nicht frei. Die würde ich nicht favorisieren. Cäsium137 (D.) 01:57, 22. Mai 2009 (CEST)

SIL Open Font License (OFL). --Pjacobi 09:53, 22. Mai 2009 (CEST)

Dann weis ich nicht, warum ich Spam-Mail mit Bezug auf angebliche Demolizenz und Werbung für Produkte bekommen habe, nachdem ich sie mal heruntergeladen habe. Cäsium137 (D.) 16:08, 22. Mai 2009 (CEST)

Zum Thema: Wer kennt noch andere Zeichen, bei denen das auftritt ? Cäsium137 (D.) 16:12, 22. Mai 2009 (CEST)

Spam-Mails: Das kann ich Dir nicht sagen, ich habe solche Mails nie bekommen.

So oder so, SunExtA muss aus der CSS Class IPA rausfliegen. Die jetzige Lage ist ja, dass für Nicht-MSIE-Benutzer die IPA-Anzeige durch die explizite Fontliste in der CSS Class schlechter und nicht besser wird als ganz ohne explizite Font-Angabe. Und die MSIE-Benutzer wären mit der Liste aus enwiki besser bedient. Sogar Schriftarten ohne U+02AE und U+02AF sind gegenüber SunExtA vorzuziehen, denn diese beiden Zeichen bringen es gerade mal auf je zweimaliges Auftreten im Artikelnamensraum, wohingegen die Kombinationen mit U+030? (die von SunExtA falsch dargestellt werden) wesentlich häufiger sind.

--Pjacobi 16:17, 22. Mai 2009 (CEST)

Ich bin nicht drauf angewiesen. von mir aus kann sie weg. Weshalb soll die Klasse sonst schlechter sein ? Code2000 und Quivira sind doch recht gute Schriften.Cäsium137 (D.) 18:07, 22. Mai 2009 (CEST)

Vorher evtl. Nachschauen, ob es keine neue Version mit Bugfix gibt. Cäsium137 (D.) 18:50, 22. Mai 2009 (CEST)

Artikelkoordinaten bei neuen Skins

 #coordinates_3_ObenRechts, #issnlink, #editcount, #shortcut, #artikelstadium {
    display: none;
 }

muss ergänzt werden um

 #coordinates {
    display: none;
 }

{{Coordinate}} verwendet nicht nur #coordinates_3_ObenRechts, sondern auch direkt #coordinates. Mit display:none hier wird gewährleistet, dass bei neuen Skins ohne Unterstützung für Vorlage:Coordinate die Artikelkoordinaten nicht im Fließtext angezeigt werden. Die Skins überschreiben den Wert dann mit display:inline. --Fomafix 13:18, 31. Aug. 2009 (CEST)

Benutzer:Euku hat die Änderung übernommen. --Fomafix 17:29, 3. Apr. 2010 (CEST)

Dieser Abschnitt kann archiviert werden. Fomafix 17:29, 3. Apr. 2010 (CEST)

Vorlage für arabische Schriften bzw. "spanAr"

Servus!

Nachdem Wikipedia:Fragen_zur_Wikipedia/Archiv/2009/Woche_37#Umstellung_der_Darstellung_arabischer_Schrift.3F FZW nicht gefruchtet hat, frag ich mal hier, weil ich glaube, selbst auch ein bisschen klüger geworden zu sein.

Kurz worum's geht: Seit ca. 12.9. werden auf meinem PC arabische Schriften anders dargestellt als früher, und zwar in einer anderen Schriftart, wenn folgende Bedingungen erfüllt sind:

• das arabische Zeichen ist nicht "exotisch" (vgl Liste arabisch-basierter Alphabete, d.h. i.d.R. es kommt im Farsi oder Arabischen)
• die Vorlage {{Arabische Schrift}} wird verwendet, z.B. per {{Ar}} u.s.w.

Soweit kein Problem bzw. Geschmackssache. Das Problem ist nun, dass, wenn in einem Wort sowohl Buchstaben verwendet werden, die den erstgenannten Punkt erfüllen, als auch solche, die dies nicht tun, erhalte ich über die Vorlagen von Punkt 2 am Bildschirm einen Darstellungsmischmasch. Die exotischeren Zeichen werden "alt" dargestellt, die gängigen "neu". Grenzen ein solches und ein solches Zeichen innerhalb eines Wortes aneinander, werden sie nicht verbunden.

Außerdem, wenn ich schon beim Meckern bin, gibt es ein ähnliches Darstellungsproblem im Editierfenster, nämlich werden exotische Zeichen nicht "dazuverbunden".

Zum Illustrieren folgende Tabelle (Beispiel: "Sindhi" auf Sindhi) mit Screenshot von mir:

Screenshot

Darstellung ohne Vorlage	‏سنڌي‎
Darstellung mit Vorlage	سنڌي
Darstellung im Editierfenster	‏سنڌي‎
Darstellungssoll: vgl. File:Wikinews-logo-sd.png rechts unten

Meine bloße Vermutung ist, dass das erstgenannte Problem mit spanAr zusammenhängt, mehr Hoffnung gibt mir die Vorlage arabische Schrift nicht. Im zweiten Fall scheint die Schriftart im Editierfenster mit exotischen Schriften einfach überfordert zu sein, was schlicht und ergreifend lästig ist.

Für jegliche Hilfe und/oder Info dankend, → «« Man77 »» 18:09, 28. Sep. 2009 (CEST)

Bei mir ist die Darstellung stets gleich, das heißt unverbunden, ob angemeldet oder nicht. Das Zeichen ڌ muss ja sehr exotisch sei, da von meinen Schriftarten nur MPH 2B Damase und Sun-ExtA über eine Glyphe verfügen. Und selbst, wenn ich diese Schriftarten für alle Zeichen verwende, wird nichts verbunden, wobei man das von Multischriftenfonts vielleicht auch nicht erwarten darf. Aber welche Schriftart ist das denn bei dir ohne Vorlage, wenn es verbunden wird? Dann könntest du mit der Angabe .spanAr {font-family: "Name der Schriftart" !important;} in deinen persönlichen CSS-Einstellungen die Verwendung dieser Schriftart erzwingen. Gismatis 22:27, 28. Sep. 2009 (CEST)

1. Text (ohne Vorlage) verwendet Arial. 2. Text (mit Vorlage) verwendet DejaVu Sans, welcher kein Sindhi unterstützt.
Ich bin mir nicht sicher, wie in diesem Fall vorzugehen ist. Durch die eigene Monobook kann man zwar die Deklarationen überschreiben, aber hier triffts ja anonyme Benutzer.
Vielleicht sollten wir hier von unserer neuen Möglichkeit gebrauch machen, Schriftarten in Webseiten einzubinden. -- Prince Kassad 22:57, 28. Sep. 2009 (CEST)

Am liebsten wär mir eine Lösung, die das Problem endgültig und für alle löst, momentan mach ich's mal (etwas widerwillig) mit Monobook, damit mir beim Lesen nicht schlecht wird ;)

Wobei hinzuzufügen ist, dass selbst Unicode noch nicht alles berücksichtigt. → «« Man77 »» 14:34, 29. Sep. 2009 (CEST)

joa, es fehlen auch noch Zeichen für die weißrussische arabische Schrift. Aber die sollte für uns nicht so wichtig sein.
Das Einbetten einer eigenen Schriftart sollte das Problem endgültig lösen, wir brauchen nur 1. eine Schriftart und 2. irgendwo Platz, um sie zu hosten. -- Prince Kassad 18:06, 29. Sep. 2009 (CEST)

id "artikelstadium"

Die id "artikelstadium" wird in Bewertungsbausteine verwendet, um die Platzierung am oberen Rechten Rand zu erreichen. Das Problem ist aber, das diese id auch mehrfach auf einer Seite vorhanden sein könnte (Berlin). Das sollte man aber vermeiden um kein invalides XHTML zu erzeugen. Vorschlag: id behalten (für Abwartskompatibilität) und zusätzlich eine Klassendefinition raus machen und die entsprechenden Vorlagen ändern. Es muss dabei nur daran gedacht werden, das in Common.css komplett auszublenden und bei den einzelnen Skins wieder einzublenden. Vielen Dank. Der Umherirrende 20:12, 22. Nov. 2009 (CET)

Mir aufgefallen: Bei einer Abwahl kommen sich die Bildchen zZt in die Quere (zumindest bei mir): http://de.wikipedia.org/w/index.php?title=Mare_Imbrium&oldid=67138478. Ist das so gewünscht oder Beifang der neuen Kandidaturenseite? → «« Man77 »» 23:45, 22. Nov. 2009 (CET)

Das konnte ich beheben, jetzt verdeckt das Kandidatur-Icon das Exzellent. Der Umherirrende 20:33, 23. Nov. 2009 (CET)

Wozu soll dass none gut sein? Es erzeugt ein zusätzliches div ohne Funktion. --Fomafix 10:06, 24. Nov. 2009 (CET)

Ich habe nur Quelltexte verglichen und da war mir der Unterschied aufgefallen. Ein Unterschied ist aber bei mir sichtbar (IE8). Der Umherirrende 21:37, 24. Nov. 2009 (CET)

Ohne das none ist durch den Zeilenumbruch ein störendes p-Element eingefügt worden. Ich’s entfernt. --Fomafix 22:23, 24. Nov. 2009 (CET)

id="artikelstadium" hat als id und nicht als class einen guten Grund, denn ein Artikel kann nur in einem Stadium sein. Allerdings wird diese Kennzeichnung von anderen Vorlagen auch verwendet (missbraucht), vorallem auch für die Ab-/Anwahl des Stadiums. Auch meiner Meinung nach sollte zusätzlich eine CSS-Klasse für alle absolut positionierten Elemente angelegt werden. Diese Klasse sollte in MediaWiki:Common.css mit display:none; ausgeblendet sein und in den Skins mit display:block; position:absolute; right:xem; top:yem; die rechte obere Ecke festgelegt werden. Von dort aus können die einzelnen Bildchen mit margin positioniert werden, so dass sie sich nicht überdecken, bzw. bewusst überdecken und mit z-index in der Reihenfolge festgelegt werden. Diese Definitionen können dann entweder in die Vorlagen oder per id in die Skins. Was wäre ein geeigneter Name für eine solche CSS-Klasse? --Fomafix 10:06, 24. Nov. 2009 (CET)

• ObenRechts
• position_absolute
• bapperlecke

Fußnoten-Darstellung

Hi, ich beziehe mich nochmal auf diese Diskussion. Damals (2006) wurde die Darstellung der Fußnoten-Zahlen geändert, damit die Zeilen nicht unterschiedlich hoch sind. Die Lösung finde ich suboptimal - z.B. weil das extra dafür vorgesehene vertical-align:super nicht benutzt wird und somit auch syntaktisch unklar ist, was das eigentlich ist. Außerdem führt diese Darstellung zu teilweise fehlenden Zahlen bei Opera dank eines sehr absurden Bugs. Bei der Lösung der en.wikipedia gibt es beide Probleme nicht.

Statt

.reference, .references sup 
{ 
font-size: 91%;
vertical-align: text-top;
position: relative;
top: -0.3em;
white-space: nowrap;
}

nutzen die

sup.reference 
{
font-weight: 400;
font-style: normal;
}

sup, sub 
{ 
line-height: 1em;
}

Die Verkleinerung der Schrift wird nicht mittels font-size sondern mittels line-height erreicht (die auf 1em statt auf 1.5em gesetzt wird). Dann muss weiter nichts relativ positioniert werden und dank des Standard-vertical-align stellen auch potentielle Browser, die das alles nicht kennen, das ganze halbwegs gut dar. Ich wollte jetzt nicht einfach mutig sein (nachdem ich gesehen habe, was damals für eine Diskussion darüber herrschte *g*) und stelle das daher hier mal zur Debatte. In der en.wikipedia scheint es gut zu funktionieren. --APPER\^☺☹ 02:52, 31. Dez. 2009 (CET)

Wenn’s auf en.wp benutzt wird, muss es ja ordentlich getestet worden sein. Hier sehen die Fußnoten ja wirklich scheußlich aus. Ich würde sagen: Ändern und auf eventuelle Meldungen bei FzW warten. Gruß, --Revo Echo der Stille 11:33, 4. Jan. 2010 (CET)

Ja, vertical-align: text-top; macht Probleme. sup, sub { line-height: 1em; } ist gut. font-weight: 400; verstehe ich nicht. Unter en:MediaWiki:Common.css steht sup.reference { font-weight: normal; font-style: normal; }. --Fomafix 16:36, 4. Jan. 2010 (CET)

font-weigth:400 entspricht etwas dünner als normal: [3]. --Revo Echo der Stille 19:46, 4. Jan. 2010 (CET)

Ah, danke. font-weight: 400; entspricht exakt font-weight: normal; nach CSS 2.1 und CSS3. font-weight: normal; finde ich aber leserlicher. --Fomafix 20:18, 4. Jan. 2010 (CET)

Ich hatte das nicht direkt aus der css genommen, sondern aus Dragonfly, Operas "Entwicklerwerkzeugen" - kann sein, dass Opera die "normal"-Angabe an der Stelle schon in 400 umgerechnet hat. --APPER\^☺☹ 02:11, 6. Jan. 2010 (CET)

Also richtig begeistert bin ich noch nicht; in Google Chrome wirken die Fußnoten im Text jetzt tiefergestellt („wirken“, weil sie in Wirklichkeit ja nur kleiner und exakt auf der Grundlinie sind), während sie im Firefox, Safari und Opera hochgestellt sind. Kann man das nicht irgendwie so machen, dass es zumindest in den State-of-the-art-Browsern gleich aussieht? — ^PDD — 19:24, 5. Jan. 2010 (CET)

Kann ich nicht nachvollziehen. Bei mir sieht das in Chrome genauso aus wie in anderen Browsern (hochgestellt). Caching-Problem? --APPER\^☺☹ 02:11, 6. Jan. 2010 (CET)

Nö. Andere Version? Bei mir Chrome 4.0.266.0. — ^PDD — 02:15, 6. Jan. 2010 (CET)

»Keine Vergrößerung der Zeilenhöhe durch hochgestellte Zahlen der Fußnoten« soll bewirkt werden, aber derzeit ist dort »line-height: 1em« fest voreingestellt. Dadurch wird die Höhe jeder Zeile, die Fußnotenziffern enthält, hässlicherweise um etwa 1 bis 2 Pixel verrutscht (ich verwende die monobook.css mit Verdana unter Firefox 3.6.2 und MacOS 10.5.8). Diese auffallend unregelmäßigen Zeilenabstände nerven beim Lesen enorm und sind absolut unprofessionell. Gleichmäßige, korrekte Zeilenabstände hingegen erzeugt »line-height: 0em« – siehe de.wikipedia.org/wiki/Benutzer:Memex/monobook.css – jedenfalls bei mir. Ich bitte um Stellungnahme bzw. Korrektur. |Memex 16:39, 29. Mär. 2010 (CEST)

Richtig, bei dem derzeitigen sub, sup { line-height: 1em; } werden bei meinem Firefox auch die Zeilenabstände auch um etwa 1 bis 2 Pixel vergrößert. sub, sup { line-height: 0; } vermeidet das Problem bei den Fußnoten im Fließtext, hat erzeugt aber ein Problem mit dem Zeilenabstand, wenn eine ganze Zeile in sup geschrieben ist:
Erste Zeile
sup mit line-height:1
Zweite Zeile
sup mit line-height:0
Dritte Zeile
--Fomafix 16:54, 29. Mär. 2010 (CEST)

Wozu sollte man denn ganze Zeilen in Superskript setzen? Für kleineren Text verwendet man Absatzformate mit entsprechender Schriftgröße usw. Ansonsten muss eben ein spezieller Stil für Fußnotenziffern her, denn so geht das nicht weiter. Habe selbst jedoch keinerlei Erfahrung mit dem hiesigen CSS-Konzept und wohl auch keine Änderungsrechte. Ist der offizielle CSS-Designer ansprechbar? |Memex 18:09, 29. Mär. 2010 (CEST)

"metadata" und Tabellenzeilen

Spricht eigentlich etwas dagegen, die Klasse "metadata" auch für das Element "tr" zu definieren, so dass Tabellenzeilen ausgeblendet werden können? Bislang ist das nur für ganze Tabellen und Spans möglich.

• Vorteil: Vorlage:Infobox Verwaltungseinheit in Deutschland enthält einen Workaround mit einer Tabelle in der Tabelle, der dann entfernt bzw. ordentlich gelöst werden könnte.
• Nachteil: Es würde möglicherweise großflächig benutzt werden, auch wo es vielleicht nicht angebracht ist (Ausblenden von Infoboxzeilen, die besser nicht ausgeblendet sein sollten; Einführung neuer ausgeblendeter Infoboxparameter, die es besser gar nicht geben sollte etc. pp.)

Meinungen? --Entlinkt 05:36, 21. Jan. 2010 (CET)

font-family /**/: inherit;

Die verschiedenen CSS-Klassen für Schriftarten dienen hauptsächlich dazu, das Unvermögen des Windows/Microsoft Internet Explorers zu beheben, dass er keine passenden Schriftarten auswählen kann. In standardkonformen Browsern, die sehr wohl passende Schriftarten auswählen können, sollten diese CSS-Klassen keinen Effekt haben. Dies ist aber derzeit nicht so. Im Gegenteil: Diese CSS-Klassen können völlig unpassende Schriftarten einfügen, so dass die Typographie der Wikipedia-Artikel empfindlich gestört wird. Dies insbesondere in dem Fall, dass man die (meiner Ansicht nach ziemlich hässliche) Schriftart Code2000 installiert haben sollte.

Der jetzige Lösungsvorschlag unter Vorlage:Unicode#CSS sieht vor, dass man sich bei Wikipedia registrieren und dann die Seite Spezial:mypage/monobook.css anlegen muss. Das dünkt mich eine ziemliche Zumutung, wenn ich doch eigentlich einen standardkonformen Browser verwende, der die richtige Darstellung eigentlich problemlos zu Stande bringt. Wenn irgendjemand die Darstellung manuell verbessern müsste, dann doch ganz bestimmt nicht diejenigen, die einen standardkonformen Browser verwenden.

Unter MediaWiki Diskussion:Common.css/Archiv 1#Fonts steht zu lesen, dass der bis IE6 übliche CSS-Hack, nämlich das Hinzufügen von font-family /**/: inherit;, unter IE7 korrigiert worden ist, ohne dass IE7 die Fähigkeit zum Auswählen von Schriften erhalten hätte. Dieser CSS-Hack ist folglich am 22. März 2008 aus Common.css gelöscht worden: [4]. Seither ist die Darstellung auf standardkonformen Browsern gestört. Ich meinte, wenn man schon unbedingt eine Extra-Behelfslösung für den Internet Explorer ins Common.css aufnimmt, dann doch bitte auf eine Art und Weise, die keine Probleme auf standardkonformen Browsern verursacht.

In der englischen Wikipedia haben sie eine derartige Lösung gefunden: en:Template talk:IPA#Solution for IE6/7 problem. Sie belassen dort die Regel font-family /**/: inherit; in Common.css, gewährleisten aber die Darstellung unter IE7 durch eine Spezialregel in Common.js.

Mein Vorschlag:

1. Wiedereinfügen von font-family /**/: inherit;. Dadurch ist eine korrekte Darstellung bis IE6 gewährleistet, ohne dass standardkonforme Browser beeinträchtigt würden.
2. Einfügen einer speziellen Internet-Explorer-Regel in Common.js, so dass auch IE7 korrekte Schriftarten darstellt, ohne dass standardkonforme Browser beeinträchtigt würden.

Ich habe en:MediaWiki:Common.js mit unserem Common.css verglichen und denke, der zusätzliche Code für Common.js müsste etwa wie folgt aussehen:

if (navigator.appName == "Microsoft Internet Explorer") {

   /**
    * Ergänzung zu Common.css, ohne die Darstellung in standardkonformen Browsern zu stören.
    */
   if (document.createStyleSheet) {
       document.createStyleSheet().addRule('.Unicode', 'font-family: "Code2000","Sun-ExtA","Arial Unicode MS","NSimSun",sans-serif;');
       document.createStyleSheet().addRule('.Unicode1', 'font-family: "Code2001","Quivira","MPH 2B Damase",sans-serif;');
       document.createStyleSheet().addRule('.Unicode2', 'font-family: "Sun-ExtB","Code2002",sans-serif;');
       document.createStyleSheet().addRule('.IPA', 'font-family: "Quivira","Code2000","Sun-ExtA","DejaVu Sans","Gentium","Arial Unicode MS","Lucida Sans Unicode",sans-serif;');
       document.createStyleSheet().addRule('.IAST', 'font-family: "Code2000","SunExtA","Arial Unicode MS",sans-serif;');
       document.createStyleSheet().addRule('.altitalisch', 'font-family: "Quivira","Code2001","MPH 2B Damase",sans-serif;');
       document.createStyleSheet().addRule('.gotisch', 'font-family: "Quivira","Code2001","MPH 2B Damase",sans-serif;');
       document.createStyleSheet().addRule('.hebrew', 'font-family: "Quivira","Sun-ExtA","Arial Unicode MS","SBL Hebrew","Code2000","MPH 2B Damase",  sans-serif;');
       document.createStyleSheet().addRule('.spanAr', 'font-family: "Arial Unicode MS","Scheherazade","Code2000","DejaVu Sans",sans-serif;');
       document.createStyleSheet().addRule('.music-symbol', 'font-family: "Musical Symbols","Euterpe","Code2001",sans-serif;');
   }

}

Ich bin nicht sicher, ob alle diese CSS-Klassen wirklich benötigt werden. Ich hoffe, eine korrekte Darstellung für standardkonforme Browser kann wieder gewährleistet werden. -- machᵗᵃˡᵏ 12:52, 1. Feb. 2010 (CET)

Nochmal Vorlage:Polytonisch

Gibt es eigentlich einen Grund dafür, dass Internet-Explorer-Schriftarten für class="polytonic" noch immer in Vorlage:Polytonisch definiert werden und nicht hier? Es ist schon unschön genug, dass eine Browser-spezifische Problemlösung ins CSS aufgenommen worden ist, aber diese Problemlösung könnte doch wenigstens zentral an einer Stelle (also hier) versammelt werden, anstatt sie über verschiedene Stellen zu verstreuen. -- machᵗᵃˡᵏ 16:31, 21. Feb. 2010 (CET)

wikitable ↔ prettytable

Hallo, hier bin ich darauf gestoßen, dass wiki- und prettytable nicht ganz gleich sind, sondern dass bei der prettytable noch ein text-align: center; aus [5] fehlt. Braucht es das nicht oder wurde das einfach vergessen?
fragt -- ✓ ^Bergi 15:53, 5. Mär. 2010 (CET)

Das wurde vermutlich nachträglich / später in wikitable eingeführt. Da 'prettytable' eh eine "aussterbende Klasse" sein soll, halte ich das auch für weniger tragisch. Im Gegenteil.... --Guandalug 16:18, 5. Mär. 2010 (CET)

Wenn du einige Diskutanten liest, machen die das sicher zu einem Vorteil von prettytable und einem Grund, diese weiter einzusetzen :) Aber dann verhelfen wir einfach so zum Aussterben und löschen irgendwann (oder auch gerne jetzt gleich) die prettytable-Definitionen, dann bleibt den Ignoranten nichts anderes mehr übrig…
meint -- ✓ ^Bergi 18:37, 5. Mär. 2010 (CET)

Nein, das wäre überhaupt nicht gut, da so die ganzen noch nicht umgestellten Tabellen zerschossen werden würden... -- Chaddy · D·B - DÜP 17:35, 10. Apr. 2010 (CEST)

P. S.: Und solange wikitable immer noch nicht richtig mit Farbdefinitionen umgehen kann, ist es eh die schlechtere Alternative... -- Chaddy · D·B - DÜP 17:39, 10. Apr. 2010 (CEST)

Welche Konstellation von Farbdefinitionen fehlen noch, wo sollte man Energie für aufwenden? Siehe auch im Archiv --Der Umherirrende 20:36, 10. Apr. 2010 (CEST)

Ja, die Diskussion kenne ich.

Bei der Formatierung mit ! funktiniert nur class="hintergrundfarbe5", style="background-color:#fedbca;" und bgcolor="#DDEEFF" dagegen nicht (da erscheint dann die Standardfarbe).

Ich verdeutliche das mal mit einem Beispiel:

Mit wikitable:

{| class="wikitable"
|- style="background-color:#fedbca;"
! Test1
| Test2
|- bgcolor="#DDEEFF"
! Test3
| Test4
|- class="hintergrundfarbe5"
! Test5
| Test6
|}

Test1	Test2
Test3	Test4
Test5	Test6

Mit prettytable:

{| class="prettytable"
|- style="background-color:#fedbca;"
! Test1
| Test2
|- bgcolor="#DDEEFF"
! Test3
| Test4
|- class="hintergrundfarbe5"
! Test5
| Test6
|}

Test1	Test2
Test3	Test4
Test5	Test6

Da alle diese Formatierungen sehr weit verbreitet sind, sollte man sie schon auch mit wikitable unterstützen... -- Chaddy · D·B - DÜP 21:01, 10. Apr. 2010 (CEST)

Es scheint mir so, das wir das Problem nicht lokal beheben können. Eine Lösung wäre wünschenswert, wenn es wirklich eine häufige Verwendung ist. Sollte damit an die MediaWiki-Entwickler herangetreten werden? Sollte jemand im verständlichen Englisch verfassen, ich bin dafür nicht geeignet. Der Umherirrende 21:40, 10. Apr. 2010 (CEST)