Diese Common.css-Anweisungen werden gemeinsam von den verschiedenen Stylesheets aller Skins genutzt; siehe auch Wikipedia:Skin.
Bitte Common.css nur für Anweisungen im Textfeldbereich und für 100%ig funktionierende (browser-, auflösungs- und skinunabhängige), zuvor geprüfte Ergänzungen verwenden, also nicht für absolute Positionierungen. --:Bdk: 14:02, 17. Dez 2005 (CET)/13:38, 18. Feb. 2008 (CET)Beantworten
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
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.
Letzter Kommentar: vor 15 Jahren23 Kommentare6 Personen sind an der Diskussion beteiligt
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 Studt15:54, 2. Mär. 2008 (CET)Beantworten
Jetzt hab' ich's: Das liegt an dem komischen „font-family /**/:inherit;“, mit dem die Definition für normale Browser unwirksam gemacht wird! Bei IPA treten die Zwiebelfische ja nur bei den Ostasien-Fans auf, aber bei Altgriechisch (vgl. Vorlage Diskussion:Polytonisch) haben sie alle Win-XP-Standardbenutzer, da dürfte „font-family /**/:inherit;“ kontraproduktiv sein. -- Olaf Studt16:44, 2. Mär. 2008 (CET)Beantworten
Das Problem besteht wohl schon länger: Die in MediaWiki:Common.css für die Klasse IAST angegebene Schriftart Lucida Sans Unicode enthält keine vorgefertigten unterpunkteten und unterstrichenen Buchstaben, sondern die müssen aus Buchstabe + Unterpunkt bzw. Unterstrich zusammengesetzt werden; solche Kombinationen werden aber (sofern man nicht mit entities rumtrickst) beim Speichern von der Wiki-Software duch vorgefertigte Zeichen ersetzt. Deshalb erzeugen Firefox und IE 7 dort Tahoma-Zwiebelfische; bei älteren IE-Versionen steht dort wahrscheinlich trotz IAST-Baustein „K□□□a“ statt Kṛṣṇa. -- Olaf Studt16:44, 2. Mär. 2008 (CET)Beantworten
Wenn man keine der anderen Schriften, die vor l_10646 kommen, besitzt, und dann noch versucht, IAST darzustellen, hat man sowieo keine Chance. Mein Firefox verwendet auch ganz normal Arial. Trotzdem wäre ich für eine eigene Klasse IAST ohne l_10646. -- Prince Kassad17:07, 2. Mär. 2008 (CET)Beantworten
Vielleicht sollte man für die Alt-IEler Tahoma als letztes vor sans-serif aufführen. Aber dann bitte mit Zauberspruch: An der kurdischen WP sieht man, wie hässlich die Schrift ist. Stimmt es überhaupt, dass der Zauberspruch bei IE 7 nicht mehr funktioniert? -- Olaf Studt09:41, 5. Mär. 2008 (CET)Beantworten
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 Studt18:24, 2. Mär. 2008 (CET)Beantworten
MMn Quatsch. 99,8 % der WP-User wissen nix von CSS-Einstellungen und selbst ich, der davon schon was gehört hat, lasse da im allgemeinen die Finger weg. Das sollte zurück in die Vorlage. Arial Unicode MS ist übrigens insbesondere für Hebräisch, aber auch für japanische Zeichen die allerschlechteste Wahl. (siehe en:Help:Multilingual support (East Asian) und die diversen verlinkten Seiten. Irgendwo auf den MS-Supportseiten geben die übrigens zu, daß ihr Kram verschiedene japanische Zeichen falsch anzeigt - ich habe mich vor einigen Wochen mal dahin durchgeklickt, werde diese Suche nicht wieder machen –, einen Fix gibt es dazu angeblich nicht. --Matthiasb17:32, 3. Mär. 2008 (CET)Beantworten
Wenn für einzelne Schriften bestimmte Fonts besser als Arial Unicode MS sind, dann sollte das hier glaubhaft (!) dargelegt werden. Am besten von mehreren Usern, welche sich mit dem Thema umfangreich beschäftigen. wenn es eindeutig ist, dann kann die Einstellung geändert werden. Cäsium137(D.)19:29, 3. Mär. 2008 (CET)Beantworten
Noch mal was Grundsätzliches: Die WP wird für die Leser gemacht, und die haben kein user/Monobook.css (allerdings kann man Hebräisch [im Gegensatz zu IPA und Altitalisch] auch im Browser konfigurieren). -- Olaf Studt09:33, 5. Mär. 2008 (CET)Beantworten
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.
--WolfgangRieger00:38, 11. Jun. 2009 (CEST)Beantworten
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)Beantworten
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.
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:
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. --WolfgangRieger00:25, 4. Jul. 2009 (CEST)Beantworten
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. --32X09:23, 5. Jul. 2009 (CEST)Beantworten
"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.
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 Kassad17:11, 2. Mär. 2008 (CET)Beantworten
Letzter Kommentar: vor 16 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
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.
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 Kassad19:52, 19. Mär. 2008 (CET)Beantworten
Quivira hat auch alle 87 Zeichen, daher kann man die Schrift ruhig nach vorne schieben. Aber meinem Vorschlag, die Schrift Musical Symbols zu den Musikschriften hinzuzufügen, stimmst du zu, oder? -- Prince Kassad20:13, 19. Mär. 2008 (CET)Beantworten
Ok. Ich lade sie mir gerade aus dem Web herunter. Hast du von 'TITUS Cyberbit Basic' eine von Babelmap Generierte Liste der Zeichen ? Ich möchte mich nicht gerne an dieser Uni namentlich anmelden, nur um die Schrift zu bekommen. Cäsium137(D.)20:22, 19. Mär. 2008 (CET)Beantworten
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ß).
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
.prettytabletd{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:
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. --Fomafix15:47, 30. Jul. 2009 (CEST)Beantworten
Infobox
Letzter Kommentar: vor 16 Jahren37 Kommentare9 Personen sind an der Diskussion beteiligt
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 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
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 Umherirrende00:45, 17. Jul. 2008 (CEST)Beantworten
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. --Fomafix01:26, 17. Jul. 2008 (CEST)Beantworten
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:
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 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
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. --Fomafix02:02, 17. Jul. 2008 (CEST)Beantworten
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)Beantworten
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.
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? --Fomafix15:10, 17. Jul. 2008 (CEST)Beantworten
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.
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 200804:03, 21. Jul. 2008 (CEST)Beantworten
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)Beantworten
Version 5
Um das Ganze nochmal zu beleben, jetzt die Version 5:
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? --RevolusEcho der Stille02:38, 7. Aug. 2008 (CEST)Beantworten
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)Beantworten
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·poetry12:44, 7. Aug. 2008 (CEST)Beantworten
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, --Gnu174214:06, 7. Aug. 2008 (CEST)Beantworten
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)Beantworten
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·poetry17:31, 7. Aug. 2008 (CEST)Beantworten
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)Beantworten
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 :) — RaymondDisk.Bew.21:48, 7. Aug. 2008 (CEST)Beantworten
@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. — RaymondDisk.Bew.21:52, 7. Aug. 2008 (CEST)Beantworten
Das muss ein Wiki sein, wo alle gemeinsam arbeiten können.
Viele User hier halten eine Klasse für sinnvoll.
Einige weitere haben sich an einer Initiative beteiligt.
Einer hat es - meinem Eindruck nach- zwar nicht verstanden (Zitat: "Bitte Was ?") revertiert aber trotzdem einfach. ;-)
Viele schreiben zwar, was sie nicht wollen, aber nicht, was stattdessen definiert werden soll.
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·poetry09:54, 8. Aug. 2008 (CEST)Beantworten
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)Beantworten
Zellrahmen
Letzter Kommentar: vor 16 Jahren22 Kommentare3 Personen sind an der Diskussion beteiligt
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.hrulesth,table.hrulestd,tr.hrulesth,tr.hrulestd,th.hrules,td.hrules{border-width:1px0;/* 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. — ChristophPäper17:18, 31. Aug. 2008 (CEST)Beantworten
Wir haben schon "nogrid" für kein Gitter. Nehmen wir also ruhig
"horgrid" für alle horizontalen Linien (nur innen)
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. — ChristophPäper14:06, 11. Sep. 2008 (CEST)Beantworten
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:
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. --RevoLusEcho der Stille18:42, 11. Sep. 2008 (CEST)Beantworten
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
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. — ChristophPäper11:21, 15. Sep. 2008 (CEST)Beantworten
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.
Letzter Kommentar: vor 16 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
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:
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. — ChristophPäper11:21, 15. Sep. 2008 (CEST)Beantworten
Dyn. Fonts sind wegen der schlechten Browserunterstützung nicht verwendbar.
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.
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. Ä.
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.
Wenn du bestimmte Fonts bevorzugst, dann schreibe das in deine eigene CSS. Das ist der Grund für die Klassen.
Da sie optional sind, sind sie natürlich verwendbar. Mein „(stattdessen)“ war quatsch, da Webfonts problemlos als erste Alternative angegeben werden können.
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. — ChristophPäper11:46, 17. Sep. 2008 (CEST)Beantworten
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)Beantworten
Klasse für ähnliches Layout wie Navigationsleisten
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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 Umherirrende17:29, 10. Okt. 2008 (CEST)Beantworten
toclimit
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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 Umherirrende16:58, 19. Dez. 2008 (CET)Beantworten
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:
Notiz für den Fall, dass die Sache irgendwann einmal durch Einführung einer Klasse action-view am body-Element angegangen wird: Der IE 6 unterstützt keine Selektoren mit mehreren Klassen an einem Element bzw. wertet dann nur die letzte Klasse aus. Man darf also nicht body.page-Wikipedia_Hauptseite.action-view schreiben (das würde die Überschrift überall ausblenden), sondern body.action-view.page-Wikipedia_Hauptseite (dann bleibt es im IE 6 beim jetzigen Verhalten; anderen Browsern ist die Reihenfolge egal). --Entlinkt00:27, 27. Aug. 2010 (CEST)Beantworten
Ja, aber die DTDs von HTML4 und XHTML1 erlauben kein class-Attribut am html-Element. Funktionieren tut es trotzdem in allen Browsern, weshalb es in HTML5 erlaubt ist. Ich habe allerdings in Bug 24915 angeregt, dann gleich alle Klassen von body nach html zu verschieben. Folglich würde es im IE 6 dann wieder nicht gehen.
Wie auch immer: Das Problem ist zurzeit mit CSS nicht lösbar, weil die verschiedenen „Ansichten“ einer Seite (URL-Parameter action) in CSS nicht unterscheidbar sind. Mit JavaScript ginge es aber, weil die „Ansicht“ dort als wgAction verfügbar ist. Gruß --Entlinkt06:29, 27. Aug. 2010 (CEST)Beantworten
Sun-ExtA
Letzter Kommentar: vor 16 Jahren33 Kommentare4 Personen sind an der Diskussion beteiligt
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.
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 Kassad22:57, 20. Mai 2009 (CEST)Beantworten
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. Gismatis04:12, 21. Mai 2009 (CEST)Beantworten
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: . --Pjacobi09:32, 21. Mai 2009 (CEST)Beantworten
à (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. Gismatis16:58, 21. Mai 2009 (CEST)Beantworten
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 Kassad17:21, 21. Mai 2009 (CEST)Beantworten
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)Beantworten
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)Beantworten
OK, jetzt habe ich zusätzlich zum IPA- ein Verständnisproblem.
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?
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. Gismatis18:23, 21. Mai 2009 (CEST)Beantworten
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)Beantworten
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? --Pjacobi00:30, 22. Mai 2009 (CEST)Beantworten
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)Beantworten
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") --Pjacobi00:55, 22. Mai 2009 (CEST)Beantworten
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 Kassad19:14, 22. Mai 2009 (CEST)Beantworten
Das sind doch keine Zeichen vom Block IPA-Extensions. Der geht von U+0250 bis U+02AF = 96 Zeichen. Danach folgen
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. --Pjacobi01:08, 22. Mai 2009 (CEST)Beantworten
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. --Pjacobi01:38, 22. Mai 2009 (CEST)Beantworten
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)Beantworten
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)Beantworten
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.
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)Beantworten
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:
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:
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.
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. Gismatis22:27, 28. Sep. 2009 (CEST)Beantworten
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 Kassad22:57, 28. Sep. 2009 (CEST)Beantworten
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 ;)
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 Kassad18:06, 29. Sep. 2009 (CEST)Beantworten
id "artikelstadium"
Letzter Kommentar: vor 15 Jahren15 Kommentare4 Personen sind an der Diskussion beteiligt
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 Umherirrende20:12, 22. Nov. 2009 (CET)Beantworten
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? --Fomafix10:06, 24. Nov. 2009 (CET)Beantworten
Es gibt zurzeit 6 einschlägige IDs (#artikelstadium, #coordinates, #coordinates_3_ObenRechts, #editcount, #issnlink, #shortcut) und eine Kategorie mit 20 Vorlagen und einer MediaWiki-Systemnachricht.
Bei den IDs außer #artikelstadium sehe ich keinen aktuen Handlungsbedarf, sie werden zwar teils in mehreren Vorlagen verwendet, was vielleicht nicht ganz sauber ist, aber es sind Vorlagen, die sich dem Sinn nach ausschließen.
Bei der ID #artikelstadium, verwendet in den Vorlagen Baustelle, Exzellent, Exzellentes Bild, Gesprochene Version, Informativ, Kandidat, Lesenswert, Listenreview, Review und der Systemnachricht MediaWiki:Sharedupload-desc-here, gibt es jedoch jede Menge potenzielle und reale Konflikte: Artikel, die schon eine Auszeichnung haben und für eine andere kandidieren oder als gesprochene Version vorliegen, ausgezeichnete Bilder, die auf Commons liegen usw. All den vorgenannten Vorlagen ist gemein, dass sie oben rechts nur ein Icon, keinen Text anzeigen und an anderer Stelle auf der Seite, wo sie eingebunden sind, einen Baustein erzeugen.
Ich würde deshalb nun doch auch eine Klasse für diese Icons befürworten, unter der Voraussetzung, dass sie wirklich nur für Icons, nicht wie die anderen IDs für irgendwelchen Text verwendet wird. topicon, das in en:MediaWiki:Monobook.css und en:MediaWiki:Vector.css (Fomafix, du meinst doch sicher auch :en?) verwendet wird, halte ich für den geeignetsten Namen, der bisher ins Gespräch gebracht wurde. Gruß --Entlinkt20:40, 19. Mai 2010 (CEST)Beantworten
Ja, ich habe :en gemeint. Dort wird display:block mit !important verstärkt, weil das display:none nicht in Common.css sondern im style="…" steht. Das hat den Vorteil, dass bei der mobilen Variante die absolut positionierten Elemente nicht angezeigt werden, weil dort Common.css nicht eingebunden wird. Eigentlich wäre es besser, wenn es dafür eine MediaWiki:Mobile.css geben würde, oder gibt es das bereits? --Fomafix21:10, 19. Mai 2010 (CEST)Beantworten
Ach wie schön, gerade heute erst habe ich die Option „Inline-CSS in der Vorlage“ aus der Kategoriebeschreibung entfernt, weil es bei uns, obwohl die Möglichkeit seit 2006 bekannt ist, nirgendwo so gemacht wird. Warum eigentlich nicht? Ja, die Idee ist interessant, vor allem für diese Bapperlbegleiticons, weil sie keinerlei Inhalt transportieren und ohne CSS nutzlos vor dem eigentlichen Bapperl stehen. Für die anderen absolut positionierten Elemente, die auch Text enthalten, der nirgendwo sonst angezeigt wird, vielleicht weniger (im Einzelfall zu überlegen). Ich persönlich würde die Klasse aber erstmal wie die IDs hier in Common.css ausblenden und für Vector implementieren (darum ging es ja ursprünglich in der FzW-Diskussion, für die Mobile-Variante wird dadurch nichts schlechter), es sei denn, wir könnten hier kurzfristig klären, ob !important in Vector.css & Co. unbedenklich ist. Können Benutzer es denn dann noch ohne Weiteres für sich überschreiben? Spielen alle Browser dabei mit? Gruß --Entlinkt21:55, 19. Mai 2010 (CEST)Beantworten
Okay, ich zögere bloß, weil ich nicht weiß, warum es bisher nicht so gemacht wurde. Weil niemand darauf kam oder weil es doch keine so tolle Idee ist? Allzu viel Zeit sollten wir uns damit wegen der bekannten 31 Tage aber auch nicht lassen. Wenn sonst niemand zeitnah Stellung nehmen mag, würde ich dazu tendieren, es der Einfachheit halber wie gehabt in Common.css auszublenden, dann können die Deklarationen von #artikelstadium in den Skins, in denen sie vorhanden sind (Monobook, Modern, Klassik) 1:1 auf div.topicon ausgeweitet werden. Ändern kann man das später immer noch. Nochmal angefasst werden sollten die CSS-Dateien sowieso, um irgendwann nach den 31 Tagen #artikelstadium zu entfernen. --Entlinkt06:28, 20. Mai 2010 (CEST)Beantworten
Keine Resonanz zu !important? Dann würde ich das für den Moment zurückstellen. Aber mal was anderes: Es gibt ja insgesamt 10 Vorlagen mit Icons. 8 davon beziehen sich im weitesten Sinne auf ein „Artikelstadium“ (Baustelle, Exzellent, Exzellentes Bild, Informativ, Kandidat, Lesenswert, Listenreview, Review). Von denen soll immer nur eines sichtbar sein, notfalls durch Übereinanderlegen. Und es gibt zwei „Ausreißer“: Vorlage:Gesprochene Version und MediaWiki:Sharedupload-desc-here. Ausreißer insofern, als die beiden mit den anderen 8 kombinierbar sein sollen. Ich sehe zwei saubere Lösungen:
Alle 10 Icons bekommen dieselbe Klasse (Namensvorschlag: .topicon). Die beiden „Ausreißer“ bekommen zusätzlich IDs (Namensvorschläge: #spoken-icon und #commons-icon zwecks Konsistenz mit der englischen Wikipedia). In den einzelnen Skins wird div.topicon so definiert, wie bisher #artikelstadium definiert war. Auch in den einzelnen Skins werden die „Ausreißer“ davon abgeleitet, indem nur die einschlägigen Deklarationen (margin-right: oder margin-top:, je nachdem, ob sie horizontal oder vertikal versetzt sein sollen) überschrieben werden.
Nur die 8 Icons, die sich auf ein „Artikelstadium“ beziehen, bekommen dieselbe Klasse (Namensvorschlag: .artikelstadium zwecks Kontinuität). Die beiden „Ausreißer“ werden über IDs völlig unabhängig davon positioniert.
Der erste Vorschlag ist insofern eleganter, als er mit weniger Code auskommt und sich leichter auf zukünftige Iconwünsche erweitern lässt (aber, schon aus Platzgründen, auch nicht grenzenlos, das sollte den Iconwünschern gleich klar sein). Dafür wäre der zweite Vorschlag näher am jetzigen Zustand und ließe sich auf Umwegen auch kompakt schreiben: div.artikelstadium, #spoken-icon, #commons-icon { /* Grundposition */ }, darunter #spoken-icon, #commons-icon { /* abweichende Position */ }. Meinungen dazu? --Entlinkt19:56, 23. Mai 2010 (CEST)Beantworten
Mangels anderslautendem Feedback setze ich jetzt folgendes um:
Ich definiere eine neue Klasse div.topicon, hier in Common.css mit dem Inhalt display:none und in den drei Skins, in denen bisher die ID #artikelstadium definiert war, nämlich Monobook, Klassik und Modern, mit demselben Inhalt wie #artikelstadium. Diese Klasse legt in Zukunft die „Grundposition“ für alle absolut positionierten Icons fest – auch diejenigen, die nicht an der Grundposition stehen können oder sollen. Aber auch nur für Icons, nicht für andere absolut positionierte Elemente, die es bereits gibt oder in Zukunft gewünscht werden.
Aus den betroffenen Vorlagen und der Systemnachricht entferne ich alle positionierungsrelevanten CSS-Anweisungen – insbesondere auch top:23px aus Vorlage:Gesprochene Version und right:30px aus MediaWiki:Sharedupload-desc-here. Alle Icons werden also standardmäßig an derselben Stelle („übereinander“) positioniert. Das liegt daran, dass meiner Meinung nach nicht skinunabhängig entscheidbar ist, ob zwei Icons neben- oder übereinander stehen sollen bzw. überhaupt Platz haben.
In den drei betroffenen Skins – Monobook, Klassik und Modern – definiere ich IDs #spoken-icon und #commons-icon, mit denen das Icon aus Vorlage:Gesprochene Version gegenüber der Grundposition nach unten und das Icon aus MediaWiki:Sharedupload-desc-here nach links verschoben werden. Dies entspricht dem Verhalten der bis jetzt in den Vorlagen stehenden, von mir so vorgefundenen CSS-Anweisungen. Dass dieses Verhalten suboptimal ist, ist mir bewusst (ich würde empfehlen, #spoken-icon und #commons-icon an dieselbe Stelle zu setzen), aber ich habe ja nicht das Ziel, alle Skins zu verbessern, sondern falsches HTML zu korrigieren und die Umsetzung für Vector zu erleichtern. Wer es in „seinem“ Skin anders haben möchte, möge es dann also gern ändern.
Ich begrenze die Größenangaben der Icons in den betroffenen Vorlagen und der Systemnachricht in Breite und Höhe, damit die Skins den notwendigen Platz zuverlässig reservieren können. Bislang haben die meisten Icons nur eine Breitenbegrenzung auf 15 Pixel und sind quadratisch. Zwei Ausnahmen gibt es: Das im März 2010 unsauber eingebaute Commons-Logo hat nur eine Breitenbegrenzung auf 14 Pixel und ist stark hochformatig (1376/1024 * 14 Pixel = 19 Pixel). Das Icon der Vorlage:Baustelle hat nur eine Breitenbegrenzung auf 20 Pixel, ist aber meiner Meinung nach eine völlig unnötige Spielerei, schließlich ist diese Vorlage in der Regel eh am Seitenanfang eingebunden (der Sprung vom Icon zum Baustein hat übrigens auch nie funktioniert, weil das Linkziel des Icons nicht mit der ID des Bausteins übereinstimmt), ich entferne es. Um dem Commons-Logo etwas entgegenzukommen, aber zugleich die Änderung für die viel länger bestehenden Auszeichnungsicons gering zu halten, wähle ich 16 Pixel.
Wer irgendwelche Probleme bemerkt, möge bitte vor allem anderen den Hinweis aus MediaWiki:Clearyourcache versuchen. Aus demselben Grund sollte #artikelstadium sowohl in den CSS-Dateien als auch in den Vorlagen noch 31 Tage stehen bleiben.
Letzter Kommentar: vor 15 Jahren12 Kommentare5 Personen sind an der Diskussion beteiligt
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.
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)Beantworten
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 Stille11:33, 4. Jan. 2010 (CET)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
»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. |Memex16:39, 29. Mär. 2010 (CEST)Beantworten
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 --Fomafix16:54, 29. Mär. 2010 (CEST)Beantworten
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? |Memex18:09, 29. Mär. 2010 (CEST)Beantworten
font-family /**/: inherit;
Letzter Kommentar: vor 15 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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:
Wiedereinfügen von font-family /**/: inherit;. Dadurch ist eine korrekte Darstellung bis IE6 gewährleistet, ohne dass standardkonforme Browser beeinträchtigt würden.
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")
{
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)Beantworten
Nochmal Vorlage:Polytonisch
Letzter Kommentar: vor 15 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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)Beantworten
Mein Glück
Letzter Kommentar: vor 15 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
soll ich hier versuchen. Weiß jemand von den Web-Ingenieuren Rat? Auch für Verweise auf Seiten oder Mitarbeiter, die etvl. weiterhelfen können, bin ich sehr dankbar. Gruß, Hæggis14:32, 19. Apr. 2010 (CEST)Beantworten
Hallo Hæggis, brauchst du das für dich oder möchtest du, dass eine solche Einstellung für alle Benutzer gilt? Im ersten Fall kannst du folgendes in deine persönliche CSS-Datei schreiben:
Hallo Wiegels, genau da liegt ja das problem: Es wird als Seitencode für alle Benutzer in Form einer __NONUMTOC__-Zeile gebraucht, evtl. auch einer Vorlage (IV soll rechts eingebunden werden). Konkret ist es für eine Neustrukturierung der Überschriften in der AdT-Disk gedacht: Wenn fortan nur noch die Kalendertage ohne „(2./3./…) Alternativvorschlag“ vornan stehen, verwirren die Gliederungsziffern nur, die zusätzliche Übersicht wäre dahin. Ohne Gliederungsziffern wärs das non plus ultra, schöner (soweit ein IV „schön“ sein kann ;) gehts kaum. -- Hæggis17:29, 19. Apr. 2010 (CEST)Beantworten
Um das zu erzielen, könnte man auf der Vorderseite folgenden Code einsetzen:
Es ließe sich auch erreichen, dass nur die Nummerierung ab oder auf der zweiten Ebene entfällt, aber ich glaube, das könnte Leser eher wieder verwirren. --Wiegels„…“17:47, 19. Apr. 2010 (CEST)Beantworten
Mit Vorderseite meinte ich MediaWiki:Common.css, die wir beide nicht bearbeiten können. Zum Testen fügst du bitte in deine persönliche CSS-Datei, in der ich nicht schreiben darf, folgendes ein und besuchst anschießend die Testseite. Mit dem hierüber genannten Code kannst du aber auch die originale Artikel-des-Tages-Diskussion testen.
Modern und #mw_content (war: Externe-Links-Pfeil in Nicht-Monobook-Skins)
Letzter Kommentar: vor 14 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
class="plainlinks" hat sich in letzter Zeit wieder weiter verbreitet, obwohl es bei Links auf de.wikipedia.org, toolserver.org und stable.toolserver.org nicht nötig sein sollte. Liegt wohl daran, dass der Code
Sorry, vielleicht habe ich da irgendwas beim Testen mit Vector durcheinandergebracht, aber bei Modern bleibt der Pfeil wirklich erhalten (Beispiel). Und zwar in demselben Browser, in dem es bei Monobook und Vector funktioniert (Firefox 3.6.3). Gruß --Entlinkt23:55, 23. Apr. 2010 (CEST)Beantworten
Und das heißt …? Dass es gar nicht nach Common.css gehört, da nicht „100%ig funktionierend (browser-, auflösungs- und skinunabhängig)“? Ich frage deshalb nach, weil mir in letzter Zeit mehrfach aufgefallen ist, dass plainlinks wieder gesetzt wurde, wo es nicht nötig sein sollte (Beispiel). Gruß --Entlinkt00:12, 24. Apr. 2010 (CEST)Beantworten
stable.toolserver.org existiert übrigens nicht mehr.
Ich habe bei mir lokal ausprobiert, dass man in die skin.css/js auch Vorlagen einbinden kann. So könnte man eine Unterseite machen, die in monobook/vector eingebunden wird um Redundanzen zu vermeiden. War aber bisher zu ängstlich das hier einfach umzusetzen. Müsste man erstmal im Testwiki ausprobieren. Merlissimo 00:57, 24. Apr. 2010 (CEST)
Überall wird in letzter Zeit das plainlinks entfernt, mit der Begründung "da in Commons.css" und ich (=modern-Nutzer) seh' immer mehr Pfeile. Gibt es bald eine Lösung? Merlissimo 05:34, 9. Jun. 2010 (CEST)
Die ordentliche Lösung steht in Bug 14954, Kommentar 4: Würde Modern dieselben IDs und Klassen wie der Rest der Welt verwenden, gäbe es das Problem gar nicht.
Eine nicht so ordentliche, aber funktionierende Lösung wäre, für Modern eben auch #mw_content hinzuzufügen. Ich frage mich aber eh, wozu die Einschränkung auf #content überhaupt gut sein soll. Zwar haben alle Skins außer Modern #content, aber es bedeutet nicht immer dasselbe:
Chick, Monobook, Myskin, Simple, Vector: #content geht von der Sitenotice bis zu den Kategorien (also quasi wirklich nur „Inhalt“)
Cologneblue, Standard: #content ist ein direktes Kindelement von body und umfasst alles außer der Seitenleiste (insbesondere auch Kopf- und Fußleiste); die Entsprechung zu #content in neueren Skins ist #article
Nostalgia: #content ist ein direktes und (abgesehen von einem Skript) das einzige Kindelement von body; die Entsprechung zu #content in neueren Skins ist #article
Es zu entfernen, würde das Problem auch lösen. Diese Sache mit den Pfeilen ist übrigens auch nicht das Einzige, das in Modern nicht funktioniert. Offensichtlich natürlich alles mit #content, aber es gibt auch subtileres (zum Beispiel funktioniert die Ausblendung der Überschrift auf der Hauptseite nicht, weil Modern nur eine ID, aber nicht wie die anderen neueren Skins auch eine Klasse "firstHeading" hat und die Ausblendung über die Klasse erfolgt). --Entlinkt09:56, 9. Jun. 2010 (CEST)Beantworten
Mal so allgemein zum ID-Konzept: Um Redundanz in den Skins zu vermeiden könnte man eine js/css anlegen, die dann in monobook und vector als Vorlage eingebunden wird (was auch funktioniert). Dann wäre es aus common raus. Merlissimo 12:47, 10. Jun. 2010 (CEST)
Ich meine, das konkrete Problemchen mit den Linksymbolen nun gelöst zu haben (die Dopplung mit #content und #mw_content ist zwar nicht so schön, aber harmlos; es funktioniert in allen Skins). Das Problem ist aber wesentlich allgemeiner. Vorhin ist mir zum Beispiel aufgefallen, dass die Regel mit dem Kommentar Expand URLs for printing aus commonPrint.css in Modern nicht funktioniert, weil sie nur von #content ausgeht. Deshalb werden in Modern sämliche Links ohne die URL in Klammern ausgedruckt. Solche Fehler können im Prinzip überall stecken. --Entlinkt05:19, 7. Jul. 2010 (CEST)Beantworten
Änderungen an zentralen StyleSheets
Letzter Kommentar: vor 14 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Mit rev:66646 (und ein paar weiteren) wurden zentrale StyleSheets-Definitionen verfeinert. Mir ist (auf dem translatewiki) aufgefallen, das die Einfärbung der verschiedenen Namensräumen mit CSS nicht mehr funktioniert. Daher sollte eine Prüfung alle lokalen StyleSheets der deutschsprachigen Wikipedia durchgeführt werden, um keine bösen Überraschungen zu erfahren. In MediaWiki:Monobook.css muss auf jeden Fall etwas geändert werden (rev:66670/Beispielfix). Vielen Dank. Der Umherirrende20:42, 20. Mai 2010 (CEST)Beantworten
Diese Problematik bringt mich auf die Idee unsere CSS-ID-Definitionen zu untersuchen. In MediaWiki:Common.css werden einige CSS-IDs definiert, die nicht auf bestimmte HTML-Elemente beschränkt sind. Es sind daher manche Überschriften nicht möglich. Beispiel:
Wobei sich bei "gelesen" die Frage, stellt, wo das noch verwendet wird. Das Verbergen der Sitenotice scheint heutzutage anders zu laufen. Daher ist ein entfernen hilfreicher, oder habe ich was übersehen? Der Umherirrende15:35, 6. Jun. 2010 (CEST)Beantworten
Es gibt noch weitere CSS-ID-Definitionen ohne Einschränkung auf ein Element. Beispielsweise hat die Überschrift
=== editpage-copywarn ===
hat einen lustigen roten Kasten. Verhindert werden kann das, indem div#editpage-copywarn statt #editpage-copywarn definiert wird. --Fomafix12:21, 9. Jun. 2010 (CEST)Beantworten
Ausblendung der Flagged-Revisions-Backlog-Sitenotice
Letzter Kommentar: vor 14 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
… mittels #mw-oldreviewed-notice { display: none; } funktioniert nicht, weil es nur ein div in einer Tabellenzelle ausblendet. Die Tabelle an sich und vor allem der [Verbergen]-Link in der anderen Zelle bleiben und hängen ohne Bezug zu irgendwas herum. (Zum Glück betrifft das nur Sichter und anscheinend auch die nur auf Spezial:Beobachtungsliste und Spezial:Letzte Änderungen). --Entlinkt05:11, 12. Jun. 2010 (CEST)Beantworten
Das wurde schon an mehreren Stellen angemerkt, aber kein Admin hat sich getraut, das Ausblenden zu entfernen. Seit rev:67414 dürfte sich das ganze aber sowieso erledigt haben (Ist nur noch nicht live). Meinetwegen kann die Definition sofort raus.Der Umherirrende12:36, 12. Jun. 2010 (CEST)Beantworten
In rev:67414 ist aber nur die Sitenotice entfernt worden, die es bei einem generellen Rückstand gibt, es gibt aber auch noch eine andere Sitenotice, die sich auf ungesichtete Seiten auf der Beobachtungsliste bezieht und nicht entfernt wurde. Deren ID wurde in rev:60676 von mw-oldreviewed-notice nach mw-fr-oldreviewed-notice und in rev:67414 nochmals nach mw-fr-watchlist-pending-notice geändert, so dass die Ausblendung gar nicht mehr funktionieren wird. Das Ding sieht übrigens so aus:
Es sind aktuell ungesichtete Bearbeitungen von gesichteten Seiten auf deiner Beobachtungsliste. Deine Aufmerksamkeit ist nötig!
Schuldige, du schriebst von Backlog, da habe ich nur an die eine Sitenotice gedacht (Früher gabe es nur eine, und die andere hat man zwischenzeitlich ja nie gesehen). Ich denke aber trotzdem, dass das ausblenden standardmäßig entfernt werden kann, da es ja [Verbergen] gibt und man es heutzutage ja eh schon klickt, auch wenn man nicht sieht was dann verborgen wird. Der Umherirrende14:39, 13. Jun. 2010 (CEST)Beantworten
gesichtete Versionen, Teil 2
Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
verbrochen. Erreicht wird damit, dass in der Versionsgeschichte die ungesichteten Versionen durch einen deutlichen Abstand von der ersten markierten abgehoben werden. Zusammen mit der gelben Hinterlegeung ist das aber völlig überflüssig, und selbst wenn es als sinnvoll gesehen wird ist der Abstand viel zu groß. Bitte als Bug melden oder hier lokal rückgängig machen. meint -- ✓Bergi20:06, 21. Jun. 2010 (CEST)Beantworten
Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Dieses Ding, das in allen Seiten mit ungesichteten Versionen prangt, hat (von Anfang an übrigens, also seit Mai 2008) drei extrem schwerwiegende Bugs:
Es nutzt float:right, aber viele Artikel enthalten als allererstes Tabellen, die ebenfalls float:right, aber nicht clear:right benutzen, weil sie nicht damit rechnen, dass von oben etwas hereinfloatet. (Streng genommen kein Bug der FlaggedRevs, aber zumindest überraschendes Verhalten.) Wirkung: Die Tabellen rutschen nach links, rechts davon entstehen riesige Leerräume.
Es hat einen ausklappbaren Teil, der aus dem #contentSub-Bereich heraus nach unten absolut positioniert ist, ohne auch nur zu versuchen, sich irgendwie gegen Vorlagen am Artikelanfang, die – warum auch immer – position:relative nutzen, zu schützen. (Diesen Bug habe ich gerade mit Müh und Not so umgangen, dass es in allen Browsern einschließlich der fehlerhaften funktionieren sollte).
Wenn JavaScript deaktiviert ist, ist der ausklappbare Teil immer ausgeklappt und verdeckt Artikelinhalte.
Letztes ist völlig inakzeptabel. Für Monobook wurde das umgangen, indem die ganze Box mit position:relative nach oben verschoben wurde, was das Problem aber nur verlagert. Dort oben steht sie nämlich im Bereich, der eigentlich für lange Lemmata reserviert ist, direkt unterhalb der Koordinaten und überschneidet sich mit dem Icon der Vorlage:Gesprochene Version, weshalb die Box auch noch ein wenig nach links verschoben werden musste. In den anderen Skins war das Problem zu keinem Zeitpunkt in irgendeiner Form „gelöst“.
Unter „Spezial:Einstellungen → Bearbeitungsberechtigung“ gibt es eine Option „Verwende die detaillierte Übersicht, um den Markierungstatus von Seiten anzuzeigen“. Aktiviert man sie, verhält sich die Box völlig anders: Sie hat die drei oben aufgeführten Probleme nicht und nimmt zwar etwas mehr Raum ein, ragt aber auf der anderen Seite nicht in die Artikel hinein.
Meiner Meinung nach sollte zumindest den Benutzern, die JavaScript aktiviert haben, diese Variante standardmäßig angeboten werden; wegen der anderen, nicht ganz so schlimmen Probleme vielleicht sogar allen Benutzern. Dass ohne JavaScript Inhalte überdeckt werden, kann überhaupt nicht angehen. Bis eine bessere Lösung verfügbar ist, würde ich vorschlagen, den ausklappbaren Teil mitsamt des Pfeilsymbols standardmäßig für alle aus- und nur mit JavaScript wieder einzublenden, denn der ausklappbare Teil enthält keine lebensnotwendigen Informationen. Diejenigen, die JavaScript deaktiviert haben und die Zusatzinfos brauchen, können dann zur sogenannten „detaillierten Übersicht“ wechseln. --Entlinkt06:40, 24. Jun. 2010 (CEST)Beantworten
CSS-Filter für IE <= 6 und IE 7
Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
In normalen Browsern ist html das root-Element von HTML-Dokumenten:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><htmlxmlns="http://www.w3.org/1999/xhtml"lang="de"dir="ltr"><head>...</head><body>...</body></html>
Im Internet Explorer haben HTML-Dokumente ein zusätzliches Element, hier „msieroot“ genannt, das bis zum IE 7 nachweisbar ist:
<msieroot><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><!-- Kommentar ohne tieferen Sinn, nur um den IE zu ärgern --><htmlxmlns="http://www.w3.org/1999/xhtml"lang="de"dir="ltr"><head>...</head><body>...</body></html></msieroot>
Bis zum IE 6 kann man von „msieroot“ ausgehend * html selektieren. Im IE 7 wurde das oberflächlich unterbunden, aber :first-child ~ html funktioniert. Dabei selektiert :first-child die DOCTYPE-Deklaration (die auch in manchen anderen Browsern selektiert werden kann, jedoch nicht mit :first-child, weil sie in normalen Browsern kein Kind von irgendetwas ist), ~ überspringt etwaige Kommentare und html selektiert das eigentliche root-Element. Das vielerorts empfohlene :first-child + html funktioniert meist auch, würde aber fehlschlagen, wenn zwischen DOCTYPE und html ein Kommentar steht, weil der IE 7 nicht nur DOCTYPE-Deklarationen, sondern sogar Kommentare selektieren kann.
Andere CSS-Filter setzen auf Parserbugs, indem sie syntaktisch ungültiges oder unsinniges CSS einsetzen und hoffen, dass bestimmte Browser es nicht oder eben doch akzeptieren (was sich von Version zu Version ändern kann), oder auf Selektoren, die bestimmte Browser nicht unterstützen (aber in Zukunft unterstützen können). Dieser hier ist insofern „eleganter“, als er an einem völlig absurden Designfehler ansetzt, der bei keinem anderen Browser nachgewiesen wurde, und leicht nachvollziehbar ist, was im Hintergrund passiert. Microsoft hat eine Policy, solche Bugs in alten Versionen nicht zu fixen (und wäre dazu wohl auch gar nicht in der Lage, ohne das Design zu ändern). Normale Browser können die Regel normal parsen und werden bloß kein passendes Element finden; für sie muss nichts zurückgesetzt werden.
Natürlich dürfen solche Filter nur sparsam eingesetzt werden. Genutzt werden diese zurzeit bei den Schriftartenlisten. Dort ist es m. E. alternativlos, auf bestimmte Browserversionen abzuzielen, weil die Listen einen Mangel bestimmter Browserversionen (die Unfähigkeit, passende Schriftarten zu finden) zu kompensieren versuchen, der wenig mit CSS zu tun hat. In anderen Fällen gibt es oft bessere Alternativen oder keine echte Notwendigkeit für eine Browserweiche. Zu beachten ist außerdem, dass der IE 8 sich in der sogenannten „Kompatibilitätsansicht“ (aus der die Wikimedia-Domains zum Glück gestrichen wurden) wie ein IE 7 verhält und auch der IE 9 einen IE-7-Modus enthalten wird. --Entlinkt01:32, 30. Jun. 2010 (CEST)Beantworten
hintergrundfarbe2
Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo, nachdem in sämtlichen nicht-monobook-Skins (und auch dem neuen Vector) die Standardhintergrundfarbe #FFF ist, lohnt sich diese Definition doch überhaupt nicht. Ich würde daher vorschlagen, diese Hintergrundfarbe auf ca. #E8E8E8 zu ändern. Gleichzeitig wird in der Monobook.css für nicht-ANR-Seiten wieder #FFF definiert. Darauf gekommen bin ich wegen dieser Anfrage. Was haltet ihr davon? Wird diese Klasse oft verwendet, um irgendwo reines Weiß zu bekommen anstatt etwas abzuheben? fragt -- ✓Bergi12:49, 3. Jul. 2010 (CEST)Beantworten
imagemap-inline: inline-block möglich?
Letzter Kommentar: vor 14 Jahren6 Kommentare1 Person ist an der Diskussion beteiligt
Kennt jemand Nebenwirkungen, wenn man die display-Eigenschaft der Klasse von inline auf inline-block ändern würde?
Ich habe gerade Probleme bei
wo sich das (i) wegen inline nicht mehr auf dem Bild befindet. Würde die Einführung einer neuen Klasse gerne vermeiden. Merlissimo 20:26, 21. Jul. 2010 (CEST)
In der jetzigen Form funktioniert die Klasse vor allem auch deshalb nicht, weil Imagemaps aus zwei verschachelten divs bestehen und .imagemap-inline div beide selektiert. Korrekterweise sollte nur das äußere selektiert werden. Meinen Tests zufolge würde in den aktuellsten Versionen von Firefox, IE, Google Chrome und Opera folgendes funktionieren:
Ältere Browser (IE 6/7, Firefox 2) unterstützen inline-block nicht, es kann aber u. U. durch Ausnutzung proprietärer Eigenschaften (hasLayout für IE und irgendwas mit -moz- für Firefox) emuliert werden;
Die Selektion mit .imagemap-inline > div ist auch nicht ganz zuverlässig (sie würde fehlschlagen, wenn zwischen dem Element, auf das die Klasse angewendet wird, und der Imagemap noch irgendein Wrapper ist), aber alternativlos, weil das äußere div, das wir erwischen wollen, keine Klasse oder dergleichen hat.
Mist. Ich hatte bei CSS 2 nachgeschaut und gerade erst gemerkt, das w3c dort inzwischen unter http://www.w3.org/TR/CSS2/ das 2.1 Dokument anzeigt, weil ich nicht mehr auf die Überschrift geachtet habe. Ich bin aber gerade auch zu blöd die letzte 2.0 Spezifikation zu finden. Unter http://www.w3.org/TR/#tr_CSS ist sie nicht aufgeführt. Merlissimo 22:58, 21. Jul. 2010 (CEST)
Im ursprünglichen CSS 2 von 1998 gibt es kein display: inline-block und auch kein Äquivalent dazu, das ist eine Neuerung von CSS 2.1.
Die jetzige Definition ist m. E. ziemlich nutzlos, weil sie nur in Verbindung mit desc none mehr oder weniger funktioniert (dann und nur dann gibt es das störende innere div nicht, und die Dokumentation unter Hilfe:Bilder#Bilder im Fließtext („inline“) behauptet auch gar nicht, dass es mit etwas anderem als desc none funktioniert) und man dann aber auch einfach Bildlinksyntax wie in [[Datei:...|link=...]] verwenden kann.
Im IE 6/7 kann man display: inline-block emulieren, indem man display: inline verwendet und dem Element zugleich Layout gibt, was wegen der vorhandenen Breiten- und Höhenangaben eh schon der Fall ist. In alten Firefox-Versionen verhält sich display: -moz-inline-box ähnlich wie display: inline-block.
Das Hauptproblem ist aber die Selektion: Wie erwischt man das äußere div und lässt das innere in Ruhe. .imagemap-inline > div wäre eine meistens (fast immer) passende Annäherung, aber im IE 6 geht selbst das nicht, weil er den E > F-Combinator nicht versteht. Das wäre nur zu umgehen, indem das äußere div softwareseitig mit einer Klasse versehen wird. --Entlinkt23:22, 21. Jul. 2010 (CEST)Beantworten
Dies hier wäre ein ziemlich übler, aber validierender Hack, der in allen nennenswerten Browsern außer Firefox 2 funktioniert:
/* Jetzige Definition aufheben */.imagemap-inlinediv{display:block;}/* Bessere Definition für Browser, die inline-block unterstützten (IE >= 8, Firefox >= 3, WebKit, Opera), dient im IE 7 nur als hasLayout-Auslöser */.imagemap-inline>div{display:inline-block;}/* IE 7 */:first-child~html.imagemap-inline>div{display:inline;}/* IE 6 */*html.imagemap-inlinediv{display:inline-block;/* hasLayout-Auslöser */}*html.imagemap-inlinediv{display:inline;}*html.imagemap-inlinedivdiv{display:block;}
Ich sehe keine Möglichkeit, Firefox 2 mit validem CSS voll zu unterstützen. Da müsste man sich zwischen drei Optionen entscheiden:
Auf proprietäre -moz-Eigenschaften zurückgreifen;
inline als Fallback, damit wenigstens der Fall desc none weiterhin funktioniert (wobei die Kombination desc none und imagemap-inline aber eh unsinnig ist, seit man bei normalen Bildeinbindungen das Linkziel ändern kann);
kein expliziter Fallback, gleichbedeutend mit block als Fallback.
Die Wiki-Klammer-Link-Syntax kann ich wegen der Lizenz nicht verwenden, weil die Bilder nicht PD sind.
Problem ist, dass es keine Möglichkeit gibt ".imagemap-inline div" als inline zu belassen und man mit block-Fallback sämtliche alt-Kompatibilität zerstört.
Ich glaube wir sollten dem imagemap-div mal eine Klasse verpassen lassen.
Ansonsten sehe ich derzeit keinen sinnvollen Anwendungsfall von imagemap-inline, weil die einzige Möglichkeit mit desc none per Klammersyntax mit leerem link-Parameter ersetzt werden sollte. Müsste man den Syntaxkorrekturleuten mal sagen, damit das langfristig eliminiert wird. Merlissimo 02:11, 22. Jul. 2010 (CEST)
Statt -moz-inline-block sollte es -moz-inline-box oder -moz-inline-stack heißen. Mit den proprietären Eigenschaften kenne ich mich aber auch nicht besonders gut aus, weil ich sie normalerweise nicht benutze. Was mit -moz beginnt, unterstützen jedenfalls nur Gecko-Browser. Es würde in diesem Fall nur dazu dienen, eine standardisierte Eigenschaft für ältere Browserversionen zu emulieren, in denen etwas ähnliches wie das Gewünschte proprietär implementiert war.
Ein Fallback mit inline wäre m. E. durchaus möglich, indem man ganz am Anfang entweder
Ja ich meine -box, hab mich verschrieben, die Linkadresse war aber korrekt. Deine beiden Varianten funktionieren aber bei mir nicht. Da hatte ich natürlich schon alles - was mir einfiel - ausprobiert, aber die Bilder erscheinen damit immer untereinander und nicht in einer Zeile.
Sorry, mit Dokumentation zu -moz-* kann ich nicht wirklich dienen. Hier steht ein bisschen was (und am Ende invalides CSS, wobei man den IE-6/7-Teil leicht valide machen kann, aber bei -moz-* keine Chance), gefunden mit den Suchbegriffen "Cross-Browser Inline-Block".
Welche Varianten funktionieren wann nicht? Die beiden inline-Fallback-Varianten funktionieren dann nicht, wenn Firefox 2 benutzt wird und desc ≠ none ist; in dieser Konstellation funktioniert das Bisherige aber auch nicht. desc = none funktioniert damit weiterhin, insofern wäre es für Firefox 2 (Marktanteil irgendwo bei 0,5 bis 1 %) zumindest keine Verschlechterung und für die anderen eine Verbesserung. Gruß --Entlinkt03:13, 22. Jul. 2010 (CEST)Beantworten
Letzter Kommentar: vor 14 Jahren13 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, derzeit werden alle rechtsfließenden Elemente mit margin-top ausgerüstet. Das sieht aber nach Überschriften nicht gut aus. Daher schlage ich vor, folgenden Code zu ergänzen:
Die zweite Regel ist schlecht. Wenn schon per style-Attribut float:right angegeben wird, dann sollte dort auch ein passender Abstand eingestellt werden können. Kannst Du ein paar Artikel nennen, um das Darstellungsproblem besser beurteilen zu können? --Fomafix14:07, 29. Jul. 2010 (CEST)Beantworten
Ja, die zweite Regel sollten wir wirklich besser weglassen. Allerdings muss dann auch wirklich überall die Klasse float-right verwendet werden, was noch nicht wirklich Standard ist. ALs Beispielartikel könnte man S-Bahn Berlin#Geschichte nennen. Sollte man die Selektoren auch noch über divs und tables hinaus ausweiten? meint -- ✓Bergi15:23, 29. Jul. 2010 (CEST)Beantworten
Den Abstand oberhalb von Tabellen mit float-right finde ich auch etwas groß. Es liegt vorallem daran, dass der Abstand von Fließobjekten nicht mit anderen Abständen zusammenfällt (http://www.w3.org/TR/CSS2/box.html#collapsing-margins). Eine solche spezielle Regel, die nur Überschriften im Artikel betrifft, finde ich allerdings etwas problematisch. Die obige Regel trifft beispielsweise nicht bei den häufigen Infoboxen und Tabellen am Artikelanfang ein. --Fomafix13:30, 30. Jul. 2010 (CEST)Beantworten
Stimmt. Man könnte noch ein #jump-to-nav+.float-right,#contentSub2+.float-right,div.previewnote+.float-right,#shortcut+.float-right einfügen. Wahrscheinlich hab ich viel vergessen, das im Quelltext vor dem eigentlichen Artikelanfang kommt. Wie wäre es denn mit
Das dürfte doch der ursprünglich erwünschte Effekt sein. Imho deutlich leichter (kürzer), wenn man soherum an die Sache herangeht. Bloß hab ich hier vermutlich auch noch jede Menge mögliche Elemente vergessen. meint -- ✓Bergi14:51, 30. Jul. 2010 (CEST)Beantworten
Es ist ganz problematisch, so komplizierte Fallunterscheidungen zu machen, weil die Regel dann im Prinzip beliebig lang werden kann und man immer etwas übersieht, so dass Inkonsistenzen eintreten. Der Teil .float-right + .float-right ist auch problematisch, weil Float-Objekte aufeinanderfolgend gerendert werden können, auch wenn sie im Quelltext gar nicht unmittelbar aufeinanderfolgen. Wir sollten versuchen, die Regeln einfach zu halten.
Ich frage mich aber, ob Float-Objekte überhaupt einen so großen oberen Außenabstand brauchen. Da die Außenabstände von Float-Objekten nicht mit anderen Außenabständen zusammenfallen und andere Blockelemente außer Listen schon untere Außenabstände haben, erscheint mir 1em etwas exzessiv. Gruß --Entlinkt19:31, 30. Jul. 2010 (CEST)Beantworten
ich weiß, und das sollte eben nicht nötig sein. Zudem ist es eben auch nur bei manchen so. Bei der Vorlage wird aber auch nur davon ausgegangen, dass sie oben im Artikel eingesetzt wird, wenn nicht wäre vielleicht ein größeres margin-top besser. Den Abstand von 1em finde ich ganz OK, .float-right + .float-right kann man auch problemlos weglassen, das finde ich auch nicht so sinnvoll. Könntest du die Änderung bitte durchführen? meint -- ✓Bergi12:11, 7. Aug. 2010 (CEST)Beantworten
Mit Adjacent sibling selectors die Abstände von Fließobjekten zu beeinflussen ist generell schlecht, denn die Positionierung hängt von den anderen Fließobjekten ab. Nur eine generelle Verringerung von margin-top kommt daher in Frage. Thumbnails am rechten Rand verwenden beispielsweise margin: 0.5em 0 0.8em 1.4em. Firefox hat übrigens Probleme mit Textüberlappung, wenn breitere Fließobjekte durch ein schmaleres Fließobjekt nach unten verschoben wird, wie das Bild der Brooklyn Bridge im Artikel New York City. --Fomafix14:38, 7. Aug. 2010 (CEST)Beantworten
Benutzer:✓, ich kann die Änderung nicht durchführen, weil ich nicht weiß, welche.
Ich stimme Fomafix zu, dass wir andersherum vorgehen sollten (wenn überhaupt), also für alle Floats margin-top verringern und dann sehen, wo der Abstand durch zu geringe margin-bottom an anderer Stelle zu klein wird.
Floatierte Nicht-Thumbnails ([[Datei:Beispiel.jpg|right]]) haben sogar margin-top: 0, was ich u. U. auch interessant fände.
Der Firefox-Bug ist bekannt (https://bugzilla.mozilla.org/show_bug.cgi?id=25888, Testfall), ich sehe aber ehrlich gesagt den Zusammenhang zu margins nicht. Der Firefox-Bug tritt übrigens oft in Zusammenhang mit der Sichtungsbox auf (jedoch nicht in Monobook, weil die Sichtungsbox in Monobook anders positioniert ist), und hiermit hätten wir schon auch das erste Beispiel für einen Float, dem ein margin-bottom fehlt (nämlich die Sichtungsbox).
@Fomafix: Stimmt, es gibt wahrscheinlich Unregelmäßigkeiten bei im Quelltext nicht nacheinander stehenden Objekten, die dennoch aufeinander floaten. Die fände ich allerdings hinnehmbarer als die derzeitigen Probleme.
Mein neuer Vorschlag: margin-top: .4em; für alle float-Objekte – zumindest die mit Rahmen (auch Bilder). Das ist nämlich der margin-top für Absätze laut main.css (Achtung: dl hat .2em!), sodass dann sämtliche Objekte auf Oberkante nach/nebenstehenden Textes rutschen. …wenn sie nicht durch andere float-Objekte weitergerutscht werden. Gefühlt könnten sie auch noch ein bisschen höher stehen, die reale Textoberkante ist nicht unbedingt die wahrgenommene; imho ist von 0 bis 0.4em alles offen. Bei dem größerem Abstand nach Text (p+.float-right,dl+.float-right{margin-top:1em;}) bin ich mir noch unsicher, er würde aufeinander gerutschte Elemente (<div class="float-right" /><p>kurzer Text.</p><div class="float-right" />) trennen, was zwar in einer Reihe merkwürdig aussehen kann, aber da sie ja tatsächlich nicht zusammengehören auch gar nicht so falsch ist. meint -- ✓Bergi12:46, 8. Aug. 2010 (CEST)Beantworten
div.float-right, table.float-right, .float-right { margin-top: 0.4em; } (ohne irgendwelche sonstigen Zusätze) ist ein Vorschlag, den man testen kann. Die Ausführungen zu Absätzen und Definitionlisten verwirren mich aber. Für Floats denselben margin-top wie für Absätze (oder Definitionslisten, oder was auch immer) zu verwenden, hat IMHO keinen Vorteil, weil Floats eigene Block-Formatting-Kontexte sind und Absätze nicht. Ihre margins verhalten sich deshalb völlig anders. (Es kann natürlich gern derselbe Wert genommen werden, falls er passt, aber nicht, weil er derselbe ist). --Entlinkt14:56, 8. Aug. 2010 (CEST)Beantworten
Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Gibt es schon sowas wie ein Format für schlichte Tabellen, wie in gedruckten (wissenschaftlichen) Büchern? Vorschlag ähnliches CSS, wie:
/* Buchtabelle wie in (wissenschaftlichen) Büchern */table.Buchtabelle,table.BuchtabellePunktiert{margin:1em1em1em0;background:#ffffff;border-top:2px#656463solid;border-bottom:2px#656463solid;border-collapse:collapse;}.Buchtabelletd{border:0px;padding:4px;}.BuchtabellePunktierttd{border-bottom:1pxdottedgrey;padding:4px;}.Buchtabelleth,.BuchtabellePunktiertth{vertical-align:bottom;border-bottom:1pxsolid#656463;border-top:1pxsolid#656463;border-left:0px;border-right:0px;padding:4px;}.Buchtabelleth,.BuchtabellePunktiertth{background:#ffffff;text-align:center;}.Buchtabellecaption{/* font-weight: bold; *//* eventuell zu fett */}
Potenzielle Konflikte bei verschachtelten Tabellen
Letzter Kommentar: vor 14 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Alle Regeln, die Selektoren wie table tr oder table td o. ä. nutzen, haben das Problem, dass sie nicht nur auf die aktuelle Tabelle, sondern auch auf etwaige verschachtelte Tabellen zutreffen. Zu beheben wäre das mit table > tbody > tr bzw. table > tbody > tr > td, was aber meist nicht gemacht wird, weil der IE 6 den Kindselektor E > F nicht versteht.
Bei der Definition der Zebra-Tabellen hätten wir allerdings ohne Weiteres die Möglichkeit, den potenziellen Konflikt zu vermeiden, weil die alternierende Selektion mittels Pseudoklasse :nth-child() im IE 6 sowieso nicht funktioniert (sie funktioniert noch nicht mal im IE 8). Wäre es deshalb sinnvoll, die Definition
zu ersetzen? Momentan hätte das keine Nebenwirkungen. Falls in Zukunft irgendwann einmal thead- und tfoot-Elemente unterstützt würden, hätte es die Nebenwirkung, dass diese nicht gestreift wären. Das halte ich allerdings für einen Vorteil, weil sie dann wahrscheinlich anders abgesetzt wären und ein durchgehendes Alternieren über thead, tfoot und tbody hinweg sowieso nicht möglich ist. --Entlinkt05:35, 5. Aug. 2010 (CEST)Beantworten
Weiter habe ich auf Probleme mit Hintergrundfarben der Form |- class="hintergrundfarbex" an geraden Tabellenzeilen hingewiesen. Dieses Problem könnte entweder an der Definition von .hintergrundfarbex mit !important oder mit Erhöhung der Selektor-Spezifität gelöst werden oder mit:
Untertabellen (mit nur einer Zeile) erzeugt zum Beispiel die Vorlage:Positionskarte. Dass es damit keine Probleme gibt, ist der Tatsache geschuldet, dass die Zebra-Definition nur gerade Zeilen einfärbt. Da dies letztlich Zufall ist, sollte es m. E. korrigiert werden.
An individuell gefärbte Zeilen hatte ich jetzt gar nicht gedacht, weil sie sich mit Zebra-Tabellen m. E. ohnehin nicht besonders gut vertragen. Auf !important würde ich in dieser Datei eigentlich ganz gern verzichten, wenn es nicht unbedingt nötig ist, damit es als „letzte Option“ für Benutzerstylesheets erhalten bleibt.
So bleibt es relativ kurz und übersichtlich und löst m. E. alle Probleme. (Ein hypothetisches Problem gäbe es mit Klassen, die die Zeichenkette „hintergrundfarbe“ enthalten und etwas anderes bedeuten, aber das kommt wohl nirgends vor.) Gruß --Entlinkt17:25, 5. Aug. 2010 (CEST)Beantworten
Listen in Tabellen
Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
normal
Liste
Text in <p>
Liste
Text mit CSS
Liste
Hallo, vor allem in Infoboxen gibt es Zeilen, in denen Text und Listen nebeneinanderstehen. Dabei fällt das ungleiche margin-top unangenehm auf; besser wird es wenn man per Zeilenumbruch den Text in einen Absatz zwingt (siehe rechts). Allerdings gibt es immer noch einen Unterschied zwischen .3 und .4em, den es zu beheben gilt. Ob man für beide Elemente 0.3 oder 0.4em macht ist mir egal, dennoch sollte man zum Systemtext so etwas hinzufügen:
tableul,tablep{margin-top:.3em;}/* oder auch etwas spezifischer, selbst wenn nicht alle den >-Selektor verstehen: */td>ul,td>p{margin-top:.4em;}
. --Pjacobi 09:32, 21. Mai 2009 (CEST)
11:33, 4. Jan. 2010 (CET)
.jpg)
.jpg)
