::::Ich habe allerdings ein Problem mit der Entkopplung. Bitte entweder <code>border-bottom:none</code> wieder rein, oder mit der angemessenen Unterpunktelung leben (oder CSS-Gadget anbieten), dann würde ich gerne [//de.wikipedia.org/w/index.php?diff=98095371&oldid=93548937 diese Änderung] revertieren. @Fomafix: Ich kann dich ja verstehen und finde die Unterpunktelung ebenfalls sinnvoll, aber die „sichtbare Änderung“ führt leider zu unsinnigen Edits. -- [[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]] <small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 21:26, 8. Jan. 2012 (CET)
::::Ich habe allerdings ein Problem mit der Entkopplung. Bitte entweder <code>border-bottom:none</code> wieder rein, oder mit der angemessenen Unterpunktelung leben (oder CSS-Gadget anbieten), dann würde ich gerne [//de.wikipedia.org/w/index.php?diff=98095371&oldid=93548937 diese Änderung] revertieren. @Fomafix: Ich kann dich ja verstehen und finde die Unterpunktelung ebenfalls sinnvoll, aber die „sichtbare Änderung“ führt leider zu unsinnigen Edits. -- [[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]] <small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 21:26, 8. Jan. 2012 (CET)
::::: Wenn die Unterpunktelung für Ärger sorgt und dadurch unsinnige Bearbeitungen gemacht werden, dann kann von mir aus auch die Ausblendung wieder rein. Hier ist sowieso nicht der richtige Ort um so etwas zu diskutieren. --[[Benutzer:Fomafix|Fomafix]] 01:55, 9. Jan. 2012 (CET)
::::: Wenn die Unterpunktelung für Ärger sorgt und dadurch unsinnige Bearbeitungen gemacht werden, dann kann von mir aus auch die Ausblendung wieder rein. Hier ist sowieso nicht der richtige Ort um so etwas zu diskutieren. --[[Benutzer:Fomafix|Fomafix]] 01:55, 9. Jan. 2012 (CET)
:::::: Wo wäre sonst der richtige Ort? Oder meinst du bloß, hier ist zu wenig Publikum und du würdest die Thematik lieber in einer Umfrage oder auf FzW klären? -- [[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]] <small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 19:24, 9. Jan. 2012 (CET)
Einen Kompromissvorschlag habe ich aber noch. Beim Drüberfahren kann die Unterpunktelung angezeigt werden:
Einen Kompromissvorschlag habe ich aber noch. Beim Drüberfahren kann die Unterpunktelung angezeigt werden:
Zeile 1.991:
Zeile 1.992:
Wenn der Code in [[MediaWiki:Common.css]] eingefügt wird, sollte er mit einem entsprechenden Kommentar versehen sein. --[[Benutzer:Fomafix|Fomafix]] 01:55, 9. Jan. 2012 (CET)
Wenn der Code in [[MediaWiki:Common.css]] eingefügt wird, sollte er mit einem entsprechenden Kommentar versehen sein. --[[Benutzer:Fomafix|Fomafix]] 01:55, 9. Jan. 2012 (CET)
:Mir ist eigentlich egal, ob keine Unterpunktelung, eine beim Drüberfahren oder Hervorheben der Unterpunktelung beim Drüberfahren verwendet wird. Wichtig wäre mir das Verwenden von semantischen Tags und keine Notwendigkeit von inline-CSS (damit sie auch in "normaler Darstellung" außerhalb von Vorlagen eingesetzt werden können). Persönlich reicht mir der <code>cursor:help</code> (fehlt derzeit leider) ohne Unterpunktelung, das hellgrau finde ich aber ebenfalls elegant. Bitte stelle aber möglichst schnell den Zustand wie vor deiner Änderung wieder oder einen deiner beiden Kompromissvorschläge her. -- [[Benutzer:✓|<big title="Benutzer:Bergi">✓</big>]] <small><sup>[[Benutzer Diskussion:✓|Bergi]]</sup></small> 19:24, 9. Jan. 2012 (CET)
== Unicode-Fonts? ==
== Unicode-Fonts? ==
Version vom 9. Januar 2012, 19:24 Uhr
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 16 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 17 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 17 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 17 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 17 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 17 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
FirstHeading auf der Hauptseite
Letzter Kommentar: vor 14 Jahren10 Kommentare5 Personen sind 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.
Testfall für den IE-6-Bug (an welchem Element die Klassen stehen, ist egal, der Bug betrifft alle Elemente mit multiplen Klassen):
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Multiple class testcase</title>
<style>
.green { background: lime }
.red.green { background: red }
</style>
</head>
<body>
<p class="green">This should be green, not red.</p>
</body>
</html>
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
Ab sofort hat der body die Klasse action-view, wenn die Seite betrachtet wird, der Vorschlag kann also mit obigem Code umgesetzt werden. --Schnark10:31, 6. Okt. 2011 (CEST)Beantworten
Die CSS-Klasse action-view ist auch einem Versionsvergleich aktiv (Beispiel). Dort würde trotz der obigen Änderung weiterhin die Überschrift ausgeblendet werden. Zumindest wird die Überschrift bei allen anderen Aktionen ausgeblendet. Daher sollte die Änderung umgesetzt werden.
Manchmal wird bei Versionsvergleichen zusätzlich die Aktion historysubmit angegeben (Beispiel). Diese Aktion entsteht, wenn in der Versionsgeschichte auf Gewählte Versionen vergleichen geklickt wird. Mit rev:108341 wird die Aktion dort entfernt und es gilt dann bei Versionvergleichen überall die Aktion view.
Dieser Abschnitt kann archiviert werden. --32X 12:42, 8. Jan. 2012 (CET)
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
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 15 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 15 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 15 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 15 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 15 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 15 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 15 Jahren2 Kommentare2 Personen sind 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
Letzter Kommentar: vor 15 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 Jahren14 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
Mit Bug 33445 habe ich eine Reduzierung der Abstände von wikitable vorgeschlagen. In dem Zuge oder auch unabhängig davon könnten die Abstände für float-right und float-left reduziert werden. Vielleicht sollten diese CSS-Klassen auch in MediaWiki direkt aufgenommen werden, denn schließlich sind fließende Tabellen ein allgemeines Problem. --Fomafix02:14, 9. Jan. 2012 (CET)Beantworten
Schlichte Buch-Tabellen?
Letzter Kommentar: vor 15 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 Jahren4 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
Dieser Abschnitt kann archiviert werden. --32X 21:52, 8. Jan. 2012 (CET)
Listen in Tabellen
Letzter Kommentar: vor 15 Jahren2 Kommentare1 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;}
Dieser Abschnitt kann archiviert werden. --32X 21:52, 8. Jan. 2012 (CET)
weitere Projekt-URL
Letzter Kommentar: vor 14 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo, könnte bitte jemand zu den entsprechenden Abschnitt mit /media ergänzen (zu Folgendem):
/* Bei URLs, die auf unser Projekt und verwandte Projekte verweisen, den Pfeil ausblenden * Dieser Pfeil dient nur dazu, auf externe Ziele hinzuweisen * Auf den Einsatz der Klasse "plainlinks" kann dadurch verzichtet werden */div#contenta.external[href^="http://de.wikipedia.org"],div#contenta.external[href^="https://secure.wikimedia.org/wikipedia/de/"],div#contenta.external[href^="http://toolserver.org"],div#contenta.external[href^="/media"],#mw_contenta.external[href^="http://de.wikipedia.org"],#mw_contenta.external[href^="https://secure.wikimedia.org/wikipedia/de/"],#mw_contenta.external[href^="http://toolserver.org"],#mw_contenta.external[href^="/media/"]{background:none;padding-right:0;}
Wo besteht ein Bedarf dafür? In der Regel sollte sowieso auf die Beschreibungsseiten und nicht direkt auf die Dateien verlinkt werden. Special:Linksearch/media listet hauptsächlich Diskussionsseiten und CSS- und JavaScript-Dateien auf (insgesamt 3749 Links). --Entlinkt02:20, 14. Sep. 2010 (CEST)Beantworten
Hm, ich dachte jetzt eigentlich mehr an Beispiele von Seiten, die besonders von dem Vorschlag profitieren würden, damit man sich ein Bild machen kann … Es stimmt zwar, dass Dateibeschreibungsseiten auf upload.wikimedia.org verlinken, die Links auf den Beschreibungsseiten haben aber kein class="external" und deshalb sowieso auch kein Symbol.
Die Rückfrage hat übrigens durchaus einen Grund. Viele Benutzer schalten diese Symbole für sich wieder ein. Bei Direktlinks auf Dateien wäre das Abschalten meiner Meinung nach auch deshalb nochmals unvorteilhafter, weil manche Dateitypen (Audio, Video, PDF) spezielle Symbole haben, die mit dem Vorschlag ebenfalls weg wären. Ich weiß nicht, ob das so gut ankommt. --Entlinkt20:57, 14. Sep. 2010 (CEST)Beantworten
Mit Dateibeschreibung meinte ich so etwas wie hier, die Links zu den Versionen kommen ja von MW und stehen nicht auf der Liste. Ob die Symbole ein- oder ausgeschalten sind, muss jeder selbst entscheiden, jedoch gehört upload auf alle Fälle zu den Projekten, und diese gemeinsam ein oder aus. Wegen der Dateitypen bin ich mir unsicher, doch die normalen Links sollten auf alle Fälle von dem befreit werden (Es auf diese einzuschränken hätte allerdings hässliches CSS zur Folge). -- ✓Bergi17:13, 15. Sep. 2010 (CEST)Beantworten
Weblinks auf upload.wikimedia.org nicht mit einem Symbol zu markieren finde ich unnötig. Es sind nur sehr wenige Links, die von dieser Änderung betroffen sind.
Im Artikel Kaurischnecken werden diese Links als Quellenangaben verwendet. Dort sind Links auf upload.wikimedia.org genauso extern, wie Links auf en.wikipedia.org. Wer interne Links haben will kann die internen Links auf die Dateibeschreibungsseiten verwenden: [[:Datei:…]].
Im Artikel Procol Harum wird /media/wikipedia/commons/1/1e/Air_%28Bach%29.ogg verlinkt. Sinnvoller wäre hier die Schreibweise {{filepath:Air (Bach).ogg}}. Seitdem protokollrelative Links aktiviert sind muss die Ausgabe hier mit […] explizit als Weblink angegeben werden: [5] statt /media/wikipedia/commons/1/1e/Air_%28Bach%29.ogg. Weil die Dateiendung .ogg ist, erzeugt MediaWiki hier ein Lautsprechersymbol statt einem Pfeil. Mit der oben vorgeschlagenen Änderung würde das Symbol fehlen.
Dieser Abschnitt kann archiviert werden. Fomafix 15:22, 8. Jan. 2012 (CET)
Versionsunterschiede in nicht-verkleinerter Schriftgröße
Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ich bitte darum, die Übernahme der Zeile
table.diff * td {font-size:100% !important;}
zu erwägen. Das Anzeigen der Unterschiede zwischen 2 oder mehr Versionen ist ein zentrales Werkzeug, das permanent benutzt und in dem v.a. sehr genau hingesehen wird. Die Verlängerung des jeweiligen Webdokuments ist durch die größere „Augenfreundlichkeit“ mE mehr als ausgeglichen. --Hæggis22:35, 4. Okt. 2010 (CEST)Beantworten
Die Schriftgröße beim Versionsvergleich sollte für alle Benutzer in allen Wikis gleich sein. MediaWiki versucht her einen Kompromiss für alle Benutzer mit kleinem, wie mit großem Bildschirm zu erreichen. Deine persönliche Schriftgröße kannst Du in Deiner Benutzer:Hæggis/common.css oder Benutzer:Hæggis/vector.css selbst einstellen, wie Du bereits gemacht hast.
Es könnte Absicht sein, dass th-Elemente im Hinblick auf vertical-align ausgenommen sind, schließlich sind sie es im Hinblick auf text-align auch. Wenn aber dieser Vorschlag umgesetzt wird, dann bitte die Definition so ersetzen:
.toptextcells td { vertical-align: top }
.toptextcells tbody { vertical-align: top }
Da vertical-align innerhalb von Tabellen ab tbody abwärts vererbt wird (HTML4, HTML5), hat dies denselben Effekt, verhindert aber, dass wir uns dasselbe Problem wie mit den Hintergrundfarben nochmal einhandeln. Gruß --Entlinkt19:33, 10. Okt. 2010 (CEST)Beantworten
Ansonsten würden mich andere Meinungen interessieren. Gerade das Beispiel mit der Vorlage:Infobox Rennstrecke überzeugt mich noch nicht wirklich. Man betrachte diese Infobox mal im IE 8, in dem th { text-align: center } gilt (was übrigens standardkonform ist; in allen anderen Browsern verhält sich text-align auf eine merkwürdige Weise, die man in Standard-CSS gar nicht ausdrücken kann).
Das derzeitige (sinngemäße) th { vertical-align: middle } ist ein IMHO durchaus logisches Gegenstück zu th { text-align: center }. Und die Klasse wird sicherlich hundertfach verwendet; wer hat den Überblick, ob der Vorschlag überall passt? --Entlinkt19:21, 11. Okt. 2010 (CEST)Beantworten
Mit dem Browser meinte ich eigentlich, ob das auch die alten unterstützen. Deine Links richten sich auf „Working Drafts“ für „Spezifikationen“, dass die neueren Browser das schon so machen weiß ich auch. Aber die alten werden auch andere Probleme haben; und so entscheidend ist toptextcells jetzt auch nicht.
Ich denke nicht dass es Designprobleme geben wird, die Klasse wird in der Regel in Infoboxen und in Listen-in-Spalten-Tabellen eingesetzt, da wäre der Effekt durchaus erwünscht. Einen Komplettüberblick wird eh keiner geben könne. Das „logische Gegenstück“ überzeugt mich nicht, denn genau um diese völlige Zentriertheit aufzuheben ist toptextcells doch da. Ich bin für Umsetzen, zurückrudern kann man immer noch. Aus meiner Sicht überwiegen die Vorteile alle eventuell anfallenden Nachteile. meint -- ✓Bergi19:13, 24. Okt. 2010 (CEST)Beantworten
Zu Browsern: Ja, alle Browser unterstützen es (das Vererben von vertical-align von tbody an tr und weiter an td und th) schon seit den 90er-Jahren. Das veraltete valign-Attribut wurde schon in dieser Weise vererbt und sinngemäß in CSS übernommen.
Zum Vorschlag an sich: Siehe die beiden Beispiele oben rechts. Ich meine nicht, dass der Vorschlag den Infoboxen weiterhilft, weil die th-Zellen immer noch horizontal zentriert sind und in Infoboxen weder vertikal noch horizontal zentriert sein sollen, wenn die ganze linke Spalte aus th-Zellen besteht. Eigentlich sollen sich die Spalten in den Infoboxen nur dadurch unterscheiden, dass die Schrift in der linken Spalte fett ist. Ich weiß aber nicht, ob es überhaupt richtig ist, die linke Spalte aus th-Zellen zusammenzubauen und dann alle Formatierungseffekte außer der Fettschrift wieder abzuschalten. Die Entscheidung zwischen th und td ist eigentlich anhand der Semantik zu treffen, nicht anhand der Formatierung; wenn's nur um die Fettschrift geht, kann man auch td nehmen und den Inhalt zellenweise fett formatieren.
Soweit ich das sehe, sind es auch gar nicht so viele Infoboxen, bei denen die linke Spalte aus th-Zellen besteht (Gegenbeispiele sind die 3 meistbenutzten Infoboxen: Infobox Film, Infobox Fußballspieler, Infobox Verwaltungseinheit in Deutschland). Wie es semantisch am sinnvollsten ist, weiß ich leider selbst nicht ganz sicher, die Semantik ist aber bei allen Boxen gleich, insofern sollte eigentlich auch die Verteilung von th und td bei allen Boxen gleich sein. Gruß --Entlinkt16:24, 31. Okt. 2010 (CET)Beantworten
Das W3C verwendet das <th>-Tag auch neben <td>, genannt „Vertical headers“. Semantisch halte also nicht nur ich es für sinnvoll.
Designtechnisch ist es halt schöner, wenn auch die linken Zellen links oben ausgerichtet sind, oben vor allem halt bei mehrzeiliger Info im Feld daneben. Für links gibt es style="text-align:left;, das bei nicht-wikitables auch von der Tabelle an alle (auch th) Zellen vererbt wird, für oben ist die Klasse toptextcells das designierte Werkzeug.
Eventueller Kompromissvorschlag: table.infobox.toptextcellstbody{vertical-align:top;} sollte Auswirkungen auf „normale“ Tabellen beseitigen.
Ach ja: Wenn ich genau darüber nachdenke, müssten Infoboxen nicht semantisch korrekt so aufgebaut werden? :-)
<divclass="infobox"style="display:table;"><dlstyle="display:table-row-group;"><divclass="one-defintion"style="display:table-row;"><!-- kein passendes Element? --><dtstyle="display:table-cell;">Name:</dt><ddstyle="display:table-cell;">Alan Turing</dd></div>
…
</dl>
…
</div>
w3schools gehört nicht zum W3C. Unabhängig davon ist mir schon klar, dass man th und td auch in einer Zeile mischen kann, aber man muss es anscheinend nicht (jedenfalls tun die allermeisten Infoboxen es nicht), und es löst bei der besagten Vorlage:Infobox Rennstrecke auch nicht das Problem, weil text-align im IE 8 (mindestens, evtl. auch 9), wie oben bereits gesagt, eben nicht von tr an th vererbt wird. Siehe auch:en:MediaWiki talk:Common.css/Archive 12#Table header inheritance in IE8.
Ob man das nun als Bug im IE 8 oder als Bug in allen anderen Browsern betrachtet (meiner Meinung nach eher letzteres), ist letztlich müßig, weil es einfach so ist und nicht zu ändern ist. Das Problem mit der Vorlage:Infobox Rennstrecke ist mit diesem Vorschlag nicht zu lösen, und wozu es sonst gut sein soll, sehe ich eben nicht.
Alternativvorschlag: In Vorlage:Infobox Rennstrecke die th durch td ersetzen und die Schrift in der linken Spalte mit der üblichen Wiki-Formatierung fett machen. Dann braucht es weder diese Anpassung noch text-align:left und funktioniert auch im IE 8. Gruß --Entlinkt01:38, 18. Nov. 2010 (CET)Beantworten
Ich bin da gelandet, weil ich eigentlich die vorgeschlagene Änderung gutgeheißen habe. Mein Beispiel ist die Vorlage:Infobox Whisky-Destillerie. Mit dem Beispiel unten bei header in der 1. Zeile bin ich aber unsicher geworden, welche Variante hier die bessere ist:
Vorlage:Infobox Whisky-Destillerie ist wieder was anderes, weil es eine wikitable ist und die th-Elemente deshalb auch farblich abgesetzt und in jedem Browser horizontal (Warum dann nicht auch vertikal?) zentriert sind. In der Vorlage:Infobox Rennstrecke ist offenbar beabsichtigt, dass die th-Elemente nur durch Fettschrift hervorgehoben sein sollen.
Infoboxen finde ich aber eigentlich gar nicht so entscheidend … es ist kein Akt, in einer Infobox ein paarmal style="vertical-align:top" einzufügen, wenn man das haben möchte. Sorgen mache ich mir eher über die unbekannte Zahl von Artikeln, in denen direkt class="wikitable toptextcells" benutzt wird. (Infoboxen wären idealerweise alle gleich aufgebaut und würden dieselben Klassen verwenden; siehe auch Wikipedia:Meinungsbilder/Vereinheitlichung der Infoboxen). --Entlinkt02:17, 18. Nov. 2010 (CET)Beantworten
Auch wenn ich die Zahl der Verwendungen von wikitable toptextcells ziemlich gering einschätze, gibt es immer noch die Möglichkeit auf table.infobox.toptextcells einzuschränken. Natürlich ist immer die Möglichkeit gegeben, das CSS über das style-Attribut überall einzeln einzusetzen. Im Sinne des guten Webdesigns und der Quelltextfereinfachung würde ich dies jedoch gerne über Stylesheets lösen. Statt umständlichen <td style="vertical-align:top;"><b>Text</b>… würde mir eher ein Konstrukt â la table.infobox td:first-child { vertical-align: top; font-weight: bold; } zusagen. Auch wegen diverser Probleme mit first-child wäre die Implementierung in die bereits vorhandene Klasse toptextcells aber imho am einfachsten. Zum IE-Bug: Eine Alternativlösung wäre auch eine eigene, neue Klasse toptextheaders. Wäre das OK? meint -- ✓Bergi18:51, 18. Nov. 2010 (CET)Beantworten
Selektoren mit 2 Klassen an einem Element wie table.infobox.toptextcells funktionieren im IE 6 nicht.
Im Sinne des guten Webdesigns wäre vor allem eine Vereinheitlichung der Infoboxen … Die Boxen müssen nicht alle plötzlich gleich aussehen, aber wenigstens das Markup (also die Verteilung von td und th) sollte meiner Meinung nach gleich sein, weil td und th semantisch nun mal nicht dasselbe sind und das Markup sich nach der Semantik und nicht nach dem Aussehen richten soll. Was nun semantisch sinniger ist, weiß ich nicht sicher, aber die Verwendungshäufigkeit spricht IMHO klar dafür, dass Infoboxen für beide Spalten td verwenden. Was wiederum heißt, dass die th in Vorlage:Infobox Rennstrecke nur dem Erzielen eines optischen Effekts (Fettschrift) dienen und somit der falsche Weg sind … Wenn aber die th in der linken Spalte semantisch sinnvoll wären, dann wären sie das in allen Infoboxen, was wiederum heißen würde, dass wir eine weitere Klasse zum Abschalten der Fettschrift bräuchten, weil sie in den meisten Boxen nicht gewünscht ist.
Alles in Allem kann das .toptextcells tbody { vertical-align: top } natürlich eingefügt werden (so wichtig isses nun auch wieder nicht, ob es irgendwo ein Problem damit gäbe, das wahrscheinlich eh kaum jemandem auffällt), löst aber meiner Meinung nach kein Problem. Das Problem mit der Vorlage:Infobox Rennstrecke löst es jedenfalls nur unvollständig, und denselben optischen Effekt (Zellen, die einfach nur fett, aber ansonsten gleich sind) kann man auch einfacher haben. --Entlinkt21:43, 18. Nov. 2010 (CET)Beantworten
Letzter Kommentar: vor 15 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, ich versuche diese Vorlage in die deutsche WP einzubauen. Diese Vorlage soll helfen aus dem Fließtext heraus auf ein Buch, das unter der Überschrift Literatur steht, zu zeigen und diese Zeile blau färben. Ähnlich wie es eben ein Einzelnachweis macht. Meine Testseiten sind zur Zeit Benutzer:Christian1985/Spielwiese/Vorlage:Referenz und Benutzer:Christian1985/Spielwiese#Testabschnitt. Das das Springen zum Buch klappt soweit, aber damit die entsprechende Zeile farbig hinterlegt wird, brauche ich noch die Zeile
span.ref:target
{
background: #def;
}
CSS-Code. Diese müsste wahrscheinlich auf dieser Seite eingefügt werden. Aber ich gehe davon aus, dass es nicht gerne gesehen wird, wenn jeder an dieser Datei rumbastelt. Kann mir jemand weiterhelfen? --Christian1985(Diskussion)03:07, 4. Feb. 2011 (CET)Beantworten
Letzter Kommentar: vor 14 Jahren11 Kommentare3 Personen sind an der Diskussion beteiligt
In der en:WP ist der Hintergrund von Thumbnails mit transparentem Hintergrund auf weiß eingestellt, so dass er sich von dem hellgrauen Rahmen abhebt:
/* Makes the background of a framed image white instead of gray. */
/* Only visible with transparent images. */
div.thumb img.thumbimage {
background-color: #fff;
}
Bei uns fehlt diese Einstellung, dadurch ist der Grafikhintergrund im gleichen Grau wie der Rahmen: [7]
Ich fänds schön wenn wir das hier so machen könnten wie die en:WP. Wenn man auf die Miniatur klickt, erhält man ja auch eine Grafik mit weißem Hintergrund. --PM300:05, 10. Mai 2011 (CEST)Beantworten
Ich finde das ist annehmbar und dafür (spart auch die Streitereien bei diversen Bildern ob der Hintergrund weiß oder transparent sein muss) -- Perhelion00:10, 10. Mai 2011 (CEST)Beantworten
Kontra Es gibt Bilder, bei denen zwischen transparent und weiß unterschieden wird. Bei dem Bild rechts aus dem Artikel Mäander (Heraldik) ist die Spitze des Wappens bei weißem Hintergrund schlecht erkennbar. Außerdem hätten durch die obige Definition Galerien und Miniaturbilder nicht die gleiche Hintergrundfarbe. --Fomafix08:59, 15. Mai 2011 (CEST)Beantworten
Im Moment haben Miniaturen und Vollgrafiken (klick mal auf die Minatur rechts!) nicht die gleiche Hintegrundfarbe. Natürlich ist das Ziel, dass die Anzeige überall gleich ist. Die Referenz kann aber doch nur die "Großanzeige" der Grafik sein, und Miniaturen und Galerien sollten das dann identisch wiedergeben.
Nunja, da das hier wohl auf die Schnelle nix wird, bekommen meine selbstgemachten Grafiken nun halt alle weiße Hintergründe. --PM309:39, 15. Mai 2011 (CEST)Beantworten
... und sowas zwingt einen dann halt dazu, weiße Hintergründe in Grafiken einzufügen, bei denen es eigentlich nicht nötig wäre. Wenn man die dann auf einer Seite mit nicht-weißem Basishintergrund anzeigt, sieht es Scheiße aus.
Es bräuchte wohl eine andere technische Lösung. Zum Beispiel einen zusätzlichen Paramter für Miniaturen, mit dem man festlegt ob transparente Hintergründe in der Farbe des Minatur-Rahmens oder des Text-Hintergrunds angezeigt werden sollen. --PM310:26, 15. Mai 2011 (CEST)Beantworten
Mit MediaWiki 1.19 werden alle Projekte in der Dateibeschreibungsseite ein gemustertes Hintergrundbild beim drüberfahren haben: „(Softwareneuheit) Bei PNGs mit transparentem Hintergrund wird auf der Dateibeischreibungsseite der gemusterte Hintergrund in den transparenten Bildteilen erst angezeigt, wenn die Maus über dem Bild schwebt (Beispiel im Translatewiki, Bug 26470, rev:96270).“ --Fomafix13:00, 6. Okt. 2011 (CEST)Beantworten
Ein Bild mit einem transparenten Hintergrund zu versehen, dann aber eine weißen Hintergrundfarbe zu fordern, ist nicht ganz konsistent. Die Hintergrundfarbe von Miniaturbildern ist ein helles Grau und ist daher meiner Meinung nach als neutraler Hintergrund geeignet – auch für das oben aufgeführte Diagramm. Eine generelle weiße Hintergrundfarbe für Miniaturbilder verhindert die Möglichkeit bei Bildern zwischen weiß und transparent zu unterscheiden, wie es bei dem oben aufgeführten Wappen zu sehen ist. Vielleicht bietet MediaWiki irgendwann mal die Möglichkeit bei Miniaturbildern die Hintergrundfarbe explizit individuell anzugeben. --Fomafix14:29, 8. Jan. 2012 (CET)Beantworten
Dieser Abschnitt kann archiviert werden. Fomafix 14:29, 8. Jan. 2012 (CET)
Formatierung der tags abbr, acronym
Letzter Kommentar: vor 14 Jahren17 Kommentare6 Personen sind an der Diskussion beteiligt
Diese Änderung hat relativ viel Staub aufgewirbelt, da sie bei allen Höhen zu gepunkteten Unterstreichungen führt, etwa 100 m ü. A. Diskussionen hier, und dort. Bis auf den Verursacher, der sich bisher nicht geäußert hat, gibt es eigentlich keine Stimme für eine Beibehaltung der Formatierung. Inzwischen wurde auch die zentrale css lt. Bug 28979 angepasst, allerdings noch nicht freigeschalten. Folgende css-Einträge machen die Formatierung wieder rückgängig, lassen aber das aus Sicht der Barrierefreiheit sinnvolle tag <abbr> bestehen:
Das ist der Zustand von zuvor. Mouseover zeigt die Abkürzung an. Der Hinweis auf den Mouseover war früher auch nicht da. Insoferne keine Verschlimmbesserung. Und ich hoffe, das ist ein Zustand, in dem in Ruhe weiterdiskutiert werden kann, lg --Herzi Pinki21:55, 28. Mai 2011 (CEST)Beantworten
Kann es sein, dass Du Bug 28979 missverstanden hast? Dort geht es nicht darum, die Unterstreichung global zu entfernen, sondern lediglich darum, den vormals skinabhängigen Code zu kürzen und zu zentralisieren. In rev:88118 ist vielleicht besser zu sehen, was wirklich gemacht wurde. Insofern ist dies keine Vorwegnahme. Die oben genannten Diskussionen geben es meiner Meinung nach auch nicht wirklich her, die Unterstreichung überall zu entfernen, sondern beziehen sich alle nur auf die Vorlage:Höhe, wo entsprechendes Inline-CSS verwendet werden kann. --Entlinkt18:32, 8. Jun. 2011 (CEST)Beantworten
Als ich diesen Bug eröffnet habe wollte ich durchaus eigentlich die Unterstreichung mitentfernt haben. Sobald ich aber den erzeugenden CSS-Code gesehen hatte, habe ich den Request auf die Entfernung des sinnlosen Codes gekürzt.
Die Verwendung des abbr-Tags ist semantisch korrekt und nur sinnvoll. In den meisten Browsern geht damit die Unterpunktelung - die im MediaWiki-CSS zusätzlich fest verankert ist - einher, was manche Benuter stört. Eine Entscheidung, wie als Abkürzung oder Erklärung gekennzeichnete Stellen formatiert werden, sollte jeder Benutzer (per User- oder Browser-CSS) selbst treffen können. Inline-CSS in Wikipedia-Seiten kommt dabei nicht infrage!!!
Die Einfügung einer de.WP-weiten, einheitlichen Formatierung ins common.css ist nur richtig, allerdings fehlt die Klasse .explain. Der Vorgriff auf den Bug ist dabei nur color:inherit, die Nicht-Unterpunktelung wurde aufgrund mehrfachen Wunsches eingefügt. Um den Benutzer/Leser-Wunsch zu manifestieren, sollte vielleicht eine Umfrage stattfinden, die die Rezeption klärt.
Die "merkwürdige Formatierung" bzw. "Quelltextverunstaltung im Artikel Geschichte der niederländischen Rechtschreibung ist natürlich Unsinn, sie sollte genauso wie Abkürzungen behandelt werden und daher mit class="explain"versehen werden, um dem User/der Gemeinschaft die genannten Möglichkeiten zu eröffnen.
„Als ich diesen Bug eröffnet habe wollte ich durchaus eigentlich die Unterstreichung mitentfernt haben. Sobald ich aber den erzeugenden CSS-Code gesehen hatte, habe ich den Request auf die Entfernung des sinnlosen Codes gekürzt.“ Das ist auch ganz gut so, weil man für globale Änderungen auch eine Begründung braucht und ich bisher (außer „hat in der Vorlage:Höhe Staub aufgewirbelt“) keine sehe.
<abbr>-Elemente kommen aber nicht nur in der Vorlage:Höhe vor, sondern seit August 2009 zum Beispiel auch auf den Seiten Spezial:Letzte Änderungen und Spezial:Beobachtungsliste (vgl. rev:54242; der Aussage„diese Vorlage scheint die einzige nennenswerte Stelle in der WP zu sein, wo das abbr-tag überhaupt vorkommt“ ist also unbedingt zu widersprechen). Dort haben wir jetzt neuerdings rote Ausrufezeichen ohne jedweden Hinweis auf den erklärenden Tooltip.
„Eine Entscheidung, wie als Abkürzung oder Erklärung gekennzeichnete Stellen formatiert werden, sollte jeder Benutzer (per User- oder Browser-CSS) selbst treffen können.“ Kann man so sehen, wobei ich es dann aber immer am logischsten finde, gar nichts ins CSS zu schreiben, sondern es einfach beim Browserstandard zu belassen, zu dem bei allen mir bekannten Browsern die Unterstreichung gehört (Test). Das machen die Browser nicht zum Spaß so, sondern damit der Tooltip, der beim <abbr>-Elemente eine besondere Bedeutung hat, auch gefunden wird.
„Inline-CSS in Wikipedia-Seiten kommt dabei nicht infrage!!!“ Kann man so sehen, ich finde Inline-CSS aber immer ganz praktisch, wenn eine einzelne Vorlage sich von allgemeinen Formatierungsweisen abkoppeln will. Es wird in der Wikipedia eh großflächig verwendet. „Die Einfügung einer de.WP-weiten, einheitlichen Formatierung ins common.css ist nur richtig, [...]“ Warum? Wir haben doch eine globale (wikimediaweit einheitliche) Formatierung. Der Code hier macht es nicht einheitlicher, sondern weniger einheitlich. „[...] allerdings fehlt die Klasse .explain.“ Und dafür haben wir aber ein überflüssiges <acronym>-Element, das in MediaWiki noch nie verwendet und mit HTML5 komplett abgeschafft wurde. --Entlinkt13:01, 9. Jun. 2011 (CEST)Beantworten
Volle Zustimmung. Inline-CSS ist imho immer suboptimal, da es den eigentlichen Sinn von CSS-Files mit Selektoren untergräbt. In der WP ist es aber leider oft der einzige Weg (und über Vorlagen leicht einsetzbar, ohne Tagsuppe im Artikel), eine Gruppe von Elementen (z.B. Infoboxen) abweichend zu formatieren, da über das common.css die pöhsen konservativen Admins wachen. Ich persönlich hätte gerne viel mehr einsetzbare Klassen, für Klassen gleichartiger Elemente ließen sich private Skinänderungen viel einfacher durchführen (statt overrulen der inline-Attribute). Gerade die „Abkopplung von allgemeinen Formatierungsweisen“ halte ich aber für falsch (stell dir per inline-style linksfloatende Infoboxen vor, das halte ich für mit einzeln von der Norm abweichenden Unterpunktelungen vergleichbar). Bei der Höhen-Vorlage haben wir jetzt natürlich den Sonderfall, dass das bislang die einzige häufige Verwendung (in Artikeln) der Abkürzungsauszeichnung ist und deren inline-style die Norm darstellt. Vergleichbares, wie mein Beispiel oben, sollte durch semantische Auszeichnung und CSS-Files statt (artikel-)spezifische inline-styles formatiert werden, die bei einer Normänderung (und sei es User-CSS) nicht eingschlossen werden.
Davon unabhängig ist es mein Vorschlag, die Community (und die Leser) zu befragen, ob sie die Unterpunktelung denn wollen oder nicht. Daraus soll dann erstmal die allgemeine Formatierungsnorm entstehen, nach der sich (Vorlagen)Bastler zu richten haben. Noch betrifft dies nur eine Vorlage, weitere Anwendungen könnten aber folgen. Dann will ich aufgrund der genannten Argumente nicht lauter (vielleicht doch voneinander abweichende) style-Attribute, sondern eine einheitliche (und leicht personalisierbare) Formatdefinition. Die „Veruneinheitlichung“ ist aber nur der technikaversen Community geschuldet, deren Urteil umgesetzt wird (meinen Bugrequest hätte ich als Frage an die globale Community verstanden oder deren bugzilla-nutzenden Teil, was somit wieder Unsinn ist). Auch ich wäre lieber beim Browserstandard geblieben. --✓Bergi15:53, 9. Jun. 2011 (CEST)Beantworten
rev:88118 und rev:88498 von Bug 28979 sind live. Diese Änderung kann damit teilweise entfallen. color:inherit ist nun wirkungslos und kann entfernt werden. border-bottom:none überschreibt allerdings das border-bottom: 1px dotted black von skins/common/shared.css, was auch Browser-Standard ist. --Fomafix13:07, 7. Okt. 2011 (CEST)Beantworten
Ich habe der Einfachheit halber beides entfernt, wenn es dagegen Widerstand gibt, kann die von den anderen Wikis abweichende Formatierung ggf. wieder eingefügt werden. --32X14:43, 8. Jan. 2012 (CET)Beantworten
Ich habe allerdings ein Problem mit der Entkopplung. Bitte entweder border-bottom:none wieder rein, oder mit der angemessenen Unterpunktelung leben (oder CSS-Gadget anbieten), dann würde ich gerne diese Änderung revertieren. @Fomafix: Ich kann dich ja verstehen und finde die Unterpunktelung ebenfalls sinnvoll, aber die „sichtbare Änderung“ führt leider zu unsinnigen Edits. -- ✓Bergi21:26, 8. Jan. 2012 (CET)Beantworten
Wenn die Unterpunktelung für Ärger sorgt und dadurch unsinnige Bearbeitungen gemacht werden, dann kann von mir aus auch die Ausblendung wieder rein. Hier ist sowieso nicht der richtige Ort um so etwas zu diskutieren. --Fomafix01:55, 9. Jan. 2012 (CET)Beantworten
Wo wäre sonst der richtige Ort? Oder meinst du bloß, hier ist zu wenig Publikum und du würdest die Thematik lieber in einer Umfrage oder auf FzW klären? -- ✓Bergi19:24, 9. Jan. 2012 (CET)Beantworten
Einen Kompromissvorschlag habe ich aber noch. Beim Drüberfahren kann die Unterpunktelung angezeigt werden:
Vielleicht wäre es für Unterpunktelungsgegner auch akzeptabel, wenn die Unterpunktelung statt schwarz in einem dezentem hellgrau gemacht wird nur beim darüberfahren schwarz hervorgehoben wird:
Mir ist eigentlich egal, ob keine Unterpunktelung, eine beim Drüberfahren oder Hervorheben der Unterpunktelung beim Drüberfahren verwendet wird. Wichtig wäre mir das Verwenden von semantischen Tags und keine Notwendigkeit von inline-CSS (damit sie auch in "normaler Darstellung" außerhalb von Vorlagen eingesetzt werden können). Persönlich reicht mir der cursor:help (fehlt derzeit leider) ohne Unterpunktelung, das hellgrau finde ich aber ebenfalls elegant. Bitte stelle aber möglichst schnell den Zustand wie vor deiner Änderung wieder oder einen deiner beiden Kompromissvorschläge her. -- ✓Bergi19:24, 9. Jan. 2012 (CET)Beantworten
Unicode-Fonts?
Letzter Kommentar: vor 14 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
Bei mir werden alle Classes mit dem Pip "* " vor dem html nicht dargestellt. Getestet mit FF4 Windows7 und IE9, keine Ahnung was das für ein Workaround sein soll. -- Perhelion04:25, 9. Jun. 2011 (CEST)Beantworten
Aja habe ich auch ebend gelesen "Browserweiche <= 6 und IE 7". Dann machen doch alle diese Vorlagen keinen wirklichen Sinn mehr. Ich frage mich wie ein Browser die richtige Schrift für ein bestimmtes Schriftbild, wie oben erwähnt #Fontvorgaben für IPA, IAST usw.. finden soll. Somit ist der ganze Abschnitt für den Restmüll. Die Vorlagen sind meines Wissen nicht nur für Sprachnotationen und Unicode. -- Perhelion04:41, 9. Jun. 2011 (CEST)Beantworten
Die IE-Versionen 6 und 7 verwenden je nach Statistik noch ungefähr 3 bis 14 Prozent.
Der Workaround ist nur für IE6 und IE7 aktiv und wird nur dort gebraucht. Für moderne Browser sind diese Definitionen hier unwirksam. Solange IE6 und IE7 von MediaWiki unterstützt werden (mw:Supported browsers), sollten diese Definitionen hier erhalten bleiben. Sobald die Unterstützung eingestellt wird, können diese Definitionen und alle anderen Workarounds entfernt werden. --Fomafix13:54, 8. Jan. 2012 (CET)Beantworten
Dieser Abschnitt kann archiviert werden. Fomafix 13:54, 8. Jan. 2012 (CET)
Urls auf verwandte Projekte
Letzter Kommentar: vor 14 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo! könnte man die Urls auf verwandte Projekte um commons erweitern? Hintergrund: Wir wollen im Zuge von WLM Links auf commons mit Parameterübergabe machen (etwa uselang), da das ganze nur als logo in den Listen erscheinen soll stört der Pfeil. LG --AleXXw •שלום!•disk 22:35, 23. Jul. 2011 (CEST)
+1 Es würden damit externe Links und die damit unnötige Zeichenfolgen wegfallen, siehe Benutzer:AleXXw/Test/2 --K@rl (Verbessern ist besser als löschen) 16:29, 24. Jul. 2011 (CEST)Beantworten
Dieser Abschnitt kann archiviert werden. Fomafix 13:39, 8. Jan. 2012 (CET)
Hervorhebung der angeklickten Fußnoten
Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ist es Absicht, das dies nicht im Internet Explorer funktioniert oder ist auch dies technischen Einschränkungen zu zuschreiben? Vielen Dank für eine Erklärung. Der Umherirrende21:53, 1. Sep. 2011 (CEST)Beantworten
/* Fettformatierung von Admin-Spezialseiten in [[Special:Specialpages]] abschalten */.mw-specialpagerestrictedstrong{font-weight:normal;}/* Legende auf [[Special:Specialpages]] ebenfalls abschalten */div.mw-specialpages-notes{display:none;}
Zugriffsbeschränkte Spezialseiten
Die erste Definition soll Spezialseiten für Benutzer mit erweiterten Rechten nicht fett darstellen. Neben Seiten für Administratoren betrifft das für Sichter die Seite Spezial:Ungesichtete Seiten. Die Definition ist aber nicht mehr wirksam, denn das strong ist nicht mehr vorhanden:
Die Definition kann daher entfallen. Wer als Admin oder als Sichter sich über die fette Zeilen stört, kann sie sich selbst in seiner eigenen common.css ausblenden. Eine CSS-Definition in MediaWiki:Common.css wird für alle Benutzer für allen Seiten übertragen, obwohl sie nur für bestimmte Benutzer auf einer Seite wirksam ist. --Fomafix17:43, 8. Jan. 2012 (CET)Beantworten
Gecachte Spezialseiten (Deren Inhalt ist möglicherweise veraltet.)
Auf der Legende werden Gecachte Spezialseiten gleich formatiert wie normale Spezialseiten. Eine Unterscheidung ist daher nicht möglich. Zugriffsbeschränkte Spezialseiten werden fett formatiert. Das Fett ist hier nicht zu sehen, weil die CSS-Definition von MediaWiki nur bei Spezialseiten geladen wird. Normale Benutzer sehen aber keine zugriffsbeschränkten Spezialseiten. Für normale Benutzer ist die Legende daher nicht sehr hilfreich.
. --Pjacobi 09:32, 21. Mai 2009 (CEST)
11:33, 4. Jan. 2010 (CET)
.jpg)
.jpg)
befreit werden (Es auf diese einzuschränken hätte allerdings hässliches CSS zur Folge). -- ✓ Bergi 17:13, 15. Sep. 2010 (CEST)
![[6]](http://imageshack.us/photo/my-images/17/16756728.png/){kind=link}
![[7]](http://imageshack.us/photo/my-images/593/48921746.png/){kind=link}
--Herzi Pinki 19:10, 24. Jul. 2011 (CEST)
