Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
Letzter Kommentar: vor 11 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt
Das sieht sehr komisch aus. Bitte in den Block mit den Hauptseitenausblendungen auch body.page-Wikipedia_Hauptseite .wbc-editpage als Selektor aufnehmen. --Schnark09:15, 7. Mär. 2013 (CET)
Habe ich mal ergänzt. Wobei ich mich frage, warum bei noexternallanglinks noch ein Bearbeitenlink da ist, aber gut, jetzt ist er weg. Der Umherirrende 18:02, 7. Mär. 2013 (CET)
Danke für den Hinweis, habe das mal vermerkt. Dann wundert man sich später beim drüberschauen nicht und kann es auch getrost entfernen, wenn es gefixed ist. Der Umherirrende 19:48, 8. Mär. 2013 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:02, 7. Mär. 2013 (CET)
Überschrift 5. und 6. Ordnung proportionaler zu Fließtext
Letzter Kommentar: vor 10 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Schon mal als Vormerkung: Mit 1.22wmf4 werden diese Formatierungen überflüssig: gerrit:61548 (h5 bekommt 105 % statt unseren 108 %, aber das sollte keinen groß sichtbaren Unterschied machen.) --Schnark09:20, 2. Mai 2013 (CEST)
Ja, der Unterschied dürfte dann nicht mehr auffallen. Dauert aber noch etwas (22. Mai). Mal schauen, wer dran denkt. Der Umherirrende 09:35, 2. Mai 2013 (CEST)
Irgendwann mal wird das schon jemand sehen, updaten und dann eine Erle hierhinter pflanzen.
Wenn ich das richtig sehe, tut die Klasse in den Vorlagen nichts; und die Vorlagen simulieren den Standardzustand, aber nicht den hier gültigen. Falls ich das richtig sehe, sollte man sie einfach jetzt schon anpassen, sprich die Schriftgrößen auf 105 % und 100 % heraufsetzen. --Schnark11:29, 2. Mai 2013 (CEST)
Die 105% sind relativ witzlos, weil sie sich in Vector und Monobook nicht von 100% unterscheiden:
vector
monobook
modern
108% (≙ h5 lokal)
Teststring (13.824px)
Teststring (13.716px)
Teststring (14.04px)
105% (≙ h5 neu global)
Teststring (13.44px)
Teststring (13.335px)
Teststring (13.65px)
100% (≙ h6 lokal und neu global)
Teststring (12.8px)
Teststring (12.7px)
Teststring (13px)
Die Demonstration gilt bei Standard-Browsereinstellungen, das heißt font-size: medium entspricht 16px und font-size: x-small entspricht 10px (zur Skalierung in den einzelnen Skins siehe hier). --Entlinkt (Diskussion) 10:07, 11. Mai 2013 (CEST)
Letzter Kommentar: vor 10 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Die Anzeige des externen Linkpfeils (div#mw-content-text a.external[href^="domain"]) sollte analog zum Toolserver auch bei Labs für Links auf Tools für folgende Domains (entsprechend http+https) ausgeblendet werden:
Für tools.wmflabs.org habe ich es mal ergänzt, weil jetzt die Koordinaten auf den geohack dort verlinken. Braucht es bots.wmflabs.org auch? Oder gibt es eine Möglichkeit, das ohne Dopplung in CSS abzubilden? Der Umherirrende 21:05, 10. Jun. 2013 (CEST)
In CSS käme allenfalls noch der Teilstring-Selektor in Frage ([att*="val"] erfasst alle Elemente, bei denen das Attribut att den Teilstring val enthält), dies kann aber u. U. zu falschen Treffern führen.
Für eher selten benutzte URLs braucht es die Ergänzung hier m. E. nicht, die Klasse plainlinks kann bei Bedarf weiter genutzt werden. (Für den Toolserver braucht es das m. E. eigentlich auch nicht; soweit ich weiß, ist das damals eingeführt worden, um aus der Koordinatenvorlage die Klasse plainlinks entfernen zu können und damit 11 kritische Bytes in Artikeln mit sehr vielen Koordinateneinbindungen zu sparen). --Entlinkt (Diskussion) 18:30, 11. Jun. 2013 (CEST)
Grund: In den mit <templatedata> generierten Vorlagendokumentationen soll angedeutet werden, welcher Teil der Doku-Seite aus TemplateData stammt; insbesondere die Zusammengehörigkeit der Kurzbeschreibung mit der meist nachfolgenden Tabelle deutlich werden.
Hinsichtlich Blauton, Pixelbreite und Padding bin ich leidenschaftslos; den Farbwert hintergrundfarbe6 habe ich der Vorlage:Dokumentation zwecks Angleichung an .rulerdocumentation entnommen.
Der Bereich soll immer die gesamte Breite des Satzspiegels nutzen (→≈100 %).
Ok Umgesetzt wie gewünscht. Bezüglich Styling etc. bin auch ich leidenschaftslos. Jeder mag ändern wie er/sie will :-) — RaymondDisk.20:01, 8. Jul. 2013 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:13, 19. Jul. 2013 (CEST)
Letzter Kommentar: vor 10 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
3.7 04.07.2013: Femeiche
3.8 05.07.2013: Hennes Weisweiler
3.9 06.07.2013: Tauchmedizin
3.10 07.07.2013: Judentum in Münster
3.11 08.07.2013: Opportunity
3.12 09.07.2013: Kettenschleppschiff
3.13 10.07.2013: Guamkrähe
3.14 11.07.2013: NOCH OFFEN
3.15 12.07.2013: NOCH OFFEN
3.16 13.07.2013: NOCH OFFEN
So sieht ein typtisches Ausschnitt des Inhaltsverzeichnisses von wd:AdT aus. Man erkennt schnell, dass die Tage und Monate eine eigene, übersichtliche Sortierung ergeben, während die vorgeordneten Gliederungspunkte (hier 3.7–3.16) das Gegenteil von dem bewirken, wofür sie da sind: Übersicht.
Ich habe bereits 2010 eine Anfrage zu dem Thema gestartet, damals noch recht indirekt ausgedrückt. Der Umherirrende schloss mit
„Die Commons.css sollte, außer der Hauptseite, keine seitenindividuelle Anpassungen erhalten. Das Thema ist mehrere Jahre alt, sollte daher erledigt sein. Der Umherirrende 19:53, 8. Mär. 2013 (CET)“
Der Sinn ist klar, nur: Kann es nicht eine Ausnahme geben? Der AdT ist integraler Bestandteil der Hauptseite, seine Aktualisierung hatte zuletzt viele Ausetzer (erst nach Mitternacht + Hinweis auf wd:HS). Ich habe mich dem Ganzen letzte Woche angenommen und sehe eine Ursache für die geringe Beteiligung darin, dass die Seite leicht überfordert und als erschlagende Textmenge erscheint. Ein klareres Inhaltsverzeichnis wirkt dem entgegen.
P.S. Nach etwas Recherche fand ich keine einzige weitere Seite im Projektnamensraum, die eine vergleichbare Struktur aufweist. FzW zum Beispiel hat gewiss ebenfalls Tagesabschnitte, die zugehörigen Frage-Überschriften beginnen jedoch mit variablen Buchstaben ohne verlässliches Muster. --Hæggis21:33, 4. Jul. 2013 (CEST)
Was hältst du denn davon, oben auf der Seite einzufügen
NOTOCNUM müsste aber zu einer Extension gehören, die hier vermutlich nicht aktiv ist. Es gibt
Vorlage:TOC limit mit CSS-Unterstützung hier, wäre nicht auch etwas für diesen Problemfall denkbar? Dann hätten wir keine Seitenspezifische Sache und jeder könnte es verwenden. Der Umherirrende 20:41, 9. Jul. 2013 (CEST)
__NOTOCNUM__ ist auf unserer Hilfe:Variablen dokumentiert; deswegen ging ich davon aus, das es hier scharf ist und habe es in <nowiki> gesetzt.
Wie ich feststellen muss, ist es nicht oder nicht mehr aktiv. Sorry für den näselnden Ton oben.
Ich meine aber mich erinnern zu können, dass es vor Jahren hier ging; kann aber Mitte des letzten Jahrzehnts gewesen sein. Müsste man mal herausfinden, wann warum wo das funktioniert oder nicht mehr. mw:Extension:PSINoTocNum nennt dies. Vielleicht war das mal früher irgendwo mit drin; sonst die Hilfeseite aktualisieren.
Wenn __NOTOCNUM__ nicht mehr aktivierbar bleibt, müsste man sich mal diese class=toc* genauer anschauen. Vielleicht geht ein analoges Konstrukt wie in Vorlage:TOC limit.
Eine Einschränkung nur speziell für diese einzelne Seite kommt nicht in Frage, aber eine Klasse .tocnonum könnte man anbieten; hier definieren, irgendwas ähnlich
.tocnonum .tocnumber {display:none;}
und in einer entsprechenden Vorlage einwickeln analog Vorlage:TOC limit.
Gemach. Es gibt ca. zwei Admins, die das regelmäßig umsetzen. Jetzt ist Urlaubszeit und Backofentemperatur, und auch Techies brauchen mal einen Sonnenstrahl und frische Luft. Wenn man übereinkommt, dass die zwangsläufige Ressourcenbelastung für sämtliche Leser aller Seiten verhältnismäßig ist und auch hie und da weitere Anwendungen zu erwarten sind, wird man das umsetzen. Und üblicherweise bekommst du dann sogar eine Info auf die Benutzerdisk.
Vorlage:TOC nonum ist implementiert, wobei die Vorlage auch von jedem anderen hätte erstellt werden können, vorallem hinsichtlich Namen finde ich das immer hilfreich, aber ja, jetzt ist es erledigt. Der Umherirrende 23:05, 28. Jul. 2013 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 23:05, 28. Jul. 2013 (CEST)
Bisher gab es noch keine aufruhrähnliche Nostalgieprotestzüge. Erstaunlich. Und danke! --wiederbeschreibbar 23:40, 4. Aug. 2013 (CEST)
So umgesetzt. Vorlagen bitte in Zukunft immer gleich so gestalten, dass Ergänzungen an dieser Datei möglichst nicht notwendig sind (es ist nicht Sinn dieser Datei, hier speziellen Code für zig Vorlagen mitzuschleppen). --Entlinkt (Diskussion) 17:47, 24. Aug. 2013 (CEST)
Letzter Kommentar: vor 10 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at bugzilla:63725. Regards, Nemo11:45, 10. Apr. 2014 (CEST)
Letzter Kommentar: vor 10 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Im Abschnitt textarea#wpUploadDescription fehlt die Angabe box-sizing:border-box. Aktuell ragt das textarea über die Tabellenzelle hinaus und ist breiter als die Zeichenleiste darunter. --TMg18:56, 5. Nov. 2013 (CET)
Gut erkannt. Damit es im Firefox auch funktioniert, wird folgendes benötigt:
Letzter Kommentar: vor 9 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Der Bug wird zwar in gerrit:164521 nicht genannt, für mich sieht es aber so aus, als ob er dadurch behoben wird. Benutzer:Entlinkt, du verstehst von uns hier vermutlich am besten, was Sache ist, schließt du gegebenenfalls den Bugreport entsprechend und wirst bei uns den Fix raus, sobald die Änderung hier live ist? --Schnark11:06, 6. Okt. 2014 (CEST)
Ja, das ist prinzipiell der richtige Fix.
An der Sache ändert sich ständig irgendwas, und zwar in der Vergangenheit skinabhängig. (Daraus folgt unmittelbar, dass der Fehler in der Vergangenheit aus skinabhängig verschiedenen CSS-Dateien bzw. „Themes“ gekommen sein muss; momentan finde ich aber nur mehr resources/lib/jquery.ui/themes/smoothness/jquery.ui.core.css).
So ganz blicke ich jetzt selbst nicht mehr durch, aber ich werd’s im Auge behalten und den Workaround entfernen, sobald er nicht mehr nötig ist (in der Hoffnung, dass er dann auch unnötig bleibt). Gruß --Entlinkt (Diskussion) 18:57, 6. Okt. 2014 (CEST)
@Entlinkt: Der Change ist gestern abend live gegangen. Vielleicht kannst du es nochmal prüfen und dann entfernen. 30 Tage muss man hier nicht warten, weil die Änderung an Modulen ja schneller gehen sollte. Vielen Dank. Der Umherirrende21:48, 11. Dez. 2014 (CET)
Letzter Kommentar: vor 9 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
... steht noch in der Seite. Die folgenden Zeilen sollten dann mal raus, oder? Bin gemeinsam mit anderen auf der Suche nach dem Grund für Fehlermeldungen wie "Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr." (hat damit aber wohl nichts zu tun). --Sitacuisses (Diskussion) 00:45, 3. Jul. 2014 (CEST)
Der Kommentar hat nichts mit den Fehlermeldungen zu tun. Die besagten Zeilen in der CSS-Datei sind einfach nur dazu da, dass Links auf den Toolserver nicht wie externe Links aussehen und sind durch die Abschaltung unnütz geworden. Fehler können sie aber nicht verursachen.
Ich hatte vor, die entsprechenden Zeilen zu entfernen, damit eventuell noch übrig gebliebene Links auf den Toolserver optisch auffallen. So ganz abgeschaltet ist der Toolserver aber nun wohl doch nicht, siehe Wikipedia:Kurier#Sammelstelle „Vermisste Tools“ vom Toolserver („[…] Ausnahmen: Merlbot, OSM-Projekte“). Deshalb habe ich sie jetzt erst mal noch drin gelassen, bis geklärt ist, welche Links noch aktiv sind.
(Gibt es überhaupt noch aktive verlinkbare Tools auf dem Toolserver oder sind die beiden Ausnahmen nur Bots, die auf dem Toolserver laufen?)
Das ist harmlos. Es verhindert nur, dass ein hinter das Link gemalt wird; reine Dekoration, kann mit dem Problem nichts zu tun haben.
Wir wären ohnehin unschuldig an Problemen auf Commons.
Schau mal nach WP:JS #Fehlermeldungen – das gibt dir ggf. präziseren Aufschluss, was hängt.
Muss man aber möglicherweise tiefer einsteigen, um die richtige Info zu finden und Unwichtiges als solches einschätzen zu können.
Oft hilft auch die totale Cache-Leerung, wenn seit neuer Software-Version noch Benutzerskripte und andere inkompatible Überreste zurückgeblieben sind.
Die eine Meldung, die da wiedergegeben ist, ist nur ein Folgefehler. Mal zusehen, dass man in die fraglichen URL ein debug=true manipuliert bekommt, dann werden die Meldungen zielgenauer.
Die Dekoration kann jetzt übrigens gelegentlich raus, wir haben Juli und das Teil ist nun extern.
Sollte man sogar eher für die nächsten Monate gelb unterlegen, damit auf den Projektseiten die Links gefixt werden können.
~merl hat hinterlassen, er würde die neuen Tools bereitstellen und die Links selbst fixen; 250 URL in Projektseiten hätte er vor sich. Aber vielleicht fragt er einen Botbetreiber.
Manche Toolserver-Links sind mit mehr oder weniger funktionstüchtigen Weiterleitungen ausgestattet; mal mit und mal ohne Weiterreichen der aktuellen Parameter. Der Toolserver selbst wird keine Datenbankabfragen mehr vornehmen können. ~merl und OSM und so haben eine befristete Sonderregelung, weil die Folge-Architektur noch nicht fit ist.
Ich denke, von August bis Dezember 2014 sollte man auf den Projektseiten mal ein wenig drängeln und die Dinger gelb machen; sonst lassen die Leute die Weiterleitungen ewig stehen und bemerken das Problem nicht. Im Juli noch warten, bis weitere neue Tools robust sind.
Letzter Kommentar: vor 9 Jahren3 Kommentare1 Person ist an der Diskussion beteiligt
Mit gerrit:165039 habe ich den Satz wegen translatewiki.net aus der Nachricht MediaWiki:Editinginterface in die neue Nachricht MediaWiki:Translateinterface geschoben. Da die Nachrichten lokal vorhanden waren, habe ich das lokal auch gemacht. Jetzt würde ich gerne den Kasten um beide Texte haben, ohne eine Linie in der Mitte zu haben. Wie mach ich das am besten?
/* Warnmeldung bei der Bearbeitung von Seiten im MediaWiki-Namensraum */.mw-editinginterface{background:#f9f9f9;border:1pxsolid#c00000;padding:2px;}
müsste ersetzt werden. Vorschläg wäre:
/* Warnmeldung bei der Bearbeitung von Seiten im MediaWiki-Namensraum */.mw-editinginterface,.mw-translateinterface{background:#f9f9f9;border:1pxsolid#c00000;padding:2px;}.mw-editinginterface+.mw-translateinterface{border-top:none;margin-top:-8px;}
Die Kästen treten nicht immer zusammen auf, nur dann wenn es auch etwas im translatewiki.net gibt, sonst ist nur der erste Kasten da. Über Kommentare würde ich mich freuen. Der Umherirrende20:45, 31. Okt. 2014 (CET)
Letzter Kommentar: vor 9 Jahren9 Kommentare2 Personen sind an der Diskussion beteiligt
Ich schlage vor, die Farbe für die Unterstrichelung auf Schwarz zu setzen und die 50 Prozent Alphakanal beizubehalten. Gerade auf TFT-Bildschirmen ist die Unterstrichelung in grauen Infoboxen praktisch nicht auszumachen. In en.wikipedia.org erscheint die Unterstrichelung übrigens ganz schwarz. Abkürzungstitel sollen fachlich übliche Abkürzungen für Wikipedia-Leser mit durchschnittlichen Kenntnissen erklären. Dieses Ziel wird nur erreicht, wenn die Linie, die das Vorhandensein eines solchen Titels signalisiert, in den meisten Situationen erkennbar ist. Ich bitte daher um Änderung von 75 % RGB auf 0 %. Aktenstapel (Diskussion) 01:05, 21. Jan. 2015 (CET)
Bei der Vorlage:Infobox Gesetz erscheint die Punktlinie schwach (bei mir je nach Blickwinkel unsichtbar):
BGBl.
Ich möchte meinen Vorschlag revidieren, so dass er auch auf Schwarz sichtbar wäre:
BGBl.
Schwarz auf Weiß scheint mir in der gegenwärtigen Darstellung deutlich benachteiligt gegenüber der seltenen Variante Weiß auf Schwarz.
Ich bin auch offen für andere Vorschläge, nur sollte die Linie bitte irgendwie erkennbar sein, damit das Angebot eines abbr titles von den Betroffenen wahrgenommen wird.
In der alten Diskussion war Wunsch nach einer dezenteren Darstellung, damit die Unterpunktelungen nicht stören und daher die abbr entfernt werden. Mir persönlich ist semantische Auszeichnung mit den Tags wichtig, die Darstellung ist mir nicht so wichtig. Grau ist aber eine problematische Farbe, die bei unterschiedlichen Displays mit unterschiedlichem Kontrast darstellt wird. Mir erscheint der Kontrast auch etwas schwach. Als Kompromissvorschlag kann vielleicht rgba(50%, 50%, 50%, .5) verwendet werden. Das müsste deutlicher zu erkennen sein, als das bisherige rgba(75%, 75%, 75%, .5). --Fomafix (Diskussion) 11:13, 21. Jan. 2015 (CET)
Den Vorschlag finde ich gut. Die neu gefärbte Linie ist immer gerade noch zu erkennen, wo der Blickwinkel eine Unterscheidung der jetzigen Variante nicht mehr zulässt. Aktenstapel (Diskussion) 12:57, 21. Jan. 2015 (CET)
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Seit dieser Änderung werden die roten Ausrufezeichen in der Beobachtungsliste mit
.mw-changeslist.unpatrolled{display:none;}
ausgeblendet. Bei Patrol ersetzt aber anscheinend das Ausrufezeichen ein Leerzeichen gleicher Breite. Durch das ausblenden verrutscht nun die Zeile um ein Zeichen. Statt ausblenden sollte das Ausrufezeichen unsichtbar gemacht werden:
In der Version für Mobilgeräte werden Tabellen ungünstig dargestellt. In Eintracht Braunschweig werden die Tabellen mit den Saisondaten komplett gelb hinterlegt. Das in einzelnen Zeilen verwendete Attribut class="hintergrundfarbe5" wird ignoriert. Ist dies ein Bug (von was?) oder ein Feature? --cwbm 19:55, 31. Mär. 2013 (CEST)
Die Frage wäre wohl eher, was aus Common.css nicht mobil gemacht werden solle.
Möglicherweise einige margin/padding platzsparender, und bei font-size müsste sich jemand zur Lesbarkeit äußern. Vielleicht cwbm als Versuchskarnickel; weitere Anregungen?
Warum nicht klein anfangen und erst einmal nur den Abschnitt mit allen Rahmen- und Hintergrundfarben kopieren. Einfach 1:1. Falsch kann das meiner Ansicht nach nicht sein. Über den Rest kann man immer noch sprechen. --TMg20:44, 1. Apr. 2013 (CEST)
Der Bug steht auf FIXED. Ich kann jetzt nicht sagen, ob es schon live ist, sollte aber ansonsten am 8. Mai dabei sein. Der Umherirrende 09:40, 2. Mai 2013 (CEST)
Letzter Kommentar: vor 8 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, nach einer kurzen Diskussion auf FzW ist die Frage offen geblieben, warum denn nun die Zebra-Klasse ausschließlich an wikitable gebunden ist! Müsste doch auch bei einer einfachen Tabelle möglich sein, oder? Sinn macht Zebra ja vor allem (genau genommen nur) in Kombination mit sortable, und diese Klasse ist ohne wikitable genauso möglich! Ließe sich da etwas anpassen? Gruß, XanonymusX (Diskussion) 11:33, 13. Jun. 2015 (CEST)
Grundprinzip ist, dass sämtliche ernsthaften und sichtbaren Tabellen (von machmal unvermeidlichen Layout-Tabellen abgesehen) auf wikitable basieren sollen.
Wenn im begründeten Fall einzelne Merkmale unterschiedlich sein sollen, dann lassen sich diese immer überschreiben. So ist es üblich, die Kopfzeilen farblich hervorzuheben; überhaupt kein Problem.
Wir haben insbesondere aus den Kinderjahren und Importen fürchterlichen festverdrahteten Schrott in Artikeln und Vorlagen, was nicht zu warten und zu pflegen ist und mühsam nach und nach durch gültige Syntax und ein zeitgemäßes Design ersetzt werden muss.
Deshalb ist es durchaus Absicht, sanften Druck zur Verwendung von wikitable auszuüben, um Weiterentwicklungen bei Skins oder Mobilgeräten und neuere Features von HTML und CSS zentral unterstützen zu können.
Eine Freigabe von zebra außerhalb von wikitable lehne ich deshalb ab, um privaten Wildwuchs nicht auch noch zu fördern.
Verstehe ich durchaus. Die FzW damals war ja auch, wie weit sich Merkmale der wikitable überschreiben lassen; soweit ich weiß, lässt sich bspw. der Zellrahmen nicht vermeiden, oder?--XanonymusX (Diskussion) 14:45, 13. Jun. 2015 (CEST)
Es lässt sich alles überschreiben, weil der individuelle style Vorrang vor den allgemeinen Vorgaben einer class hat.
Nur verbotene, ungültige und sonstwie veraltete Syntax wird möglicherweise blockiert.
Naja, die Farben von .zebra kann man z.B. nicht (bei Beibehaltung des Effekts) überschreiben, weil man dafür mehr an Selektoren braucht als "du, und nur du, und zwar immer". --nenntmichruhigip (Diskussion) 15:05, 13. Jun. 2015 (CEST)
Ich hatte das Überschreiben eigentlich schon erfolglos versucht … Zebra ist schon klar, hatten wir ja erst zwei Abschnitte drüber. Da bleibt nur noch das Problem even–odd; mit unsichtbarer Zusatzzeile bringt man leider die Sortierung durcheinander, was ja genau vermieden werden soll … Ach je. Nun, nach den nächsten Experimenten meld ich mich wieder, danke soweit!--XanonymusX (Diskussion) 15:09, 13. Jun. 2015 (CEST)
Die Links sind gleich formatiert wie bei normalen Beobachtungslisten-Einträgen. Mit Ausnahme des Links auf den Wikipedia-Artikel, führen alle Links auf Wikidata. Ich finde, dass diese sechs Links anders dargestellt werden sollten, so dass dies für OMA direkt ersichtlich ist und nicht erst beim Klicken. --Leyo18:28, 4. Jun. 2013 (CEST)
Für jemand wie dich, der ohnehin jede Menge Links mit besonderen Farben kennzeichnet, mag eine solche Hervorhebung sinnvoll sein. Meiner Ansicht nach muss der unwissende Benutzer, der keine Ahnung von Wikidata hat, auch keine Ahnung davon haben. Da ist eine Änderung, die sich (möglicherweise, und indirekt) auf den Artikel auswirkt, was geändert wurde, kann man sehen, wenn man auf „Unterschied“ klickt, kein Grund das irgendwie hervorzuheben. Zudem ist eine Hervorhebung in keiner Weise selbsterklärend, und ob die Nachfragen lauten „Warum führen manche Links auf der Beobachtungsliste zu einem anderen Wiki?“ oder „Warum sind manche Links auf der Beobachtungsliste blassblau (oder sonstwie) unterlegt?“ spielt keine große Rolle.
Die farbliche Unterscheidung von normaler Links und Links zu anderen Projekten ist ohnehin leicht zu übersehen bzw. nur wahrzunehmen, wenn man davon weiß. --Schnark09:27, 5. Jun. 2013 (CEST)
Es geht ja nicht darum, die Links grün oder orange zu hinterlegen, wie ich dies für wenige ausgewählte Seiten mache. Aber nur schon aus Konsistenzgründen sollten doch alle Links zu anderen Projekten einheitlich sein. Wie du selbst sagst, ist der Unterschied eher klein. Daher würde sich wohl kaum jemand daran stören. Wenn man's weiss, ist's aber eine Hilfe. Beispielsweise sieht man so auch auf einen Blick, wo Popups funktioniert und wo nicht. --Leyo09:52, 5. Jun. 2013 (CEST)
Bereits die Schwesterprojektlinks in Artikeln sind nicht einheitlich, siehe Wikipedia:Textbausteine/Schwesterprojekte. Wenn man's weiss, ist's aber eine Hilfe. – Oben argumentierst du, es solle für OMA direkt ersichtlich sein. Für wen soll diese Änderung denn nun sein? Für den Poweruser, der das ohnehin (evt. mit Hilfe) nach eigenen Vorstellungen in seiner eigenen common.css anpassen kann, oder für den normalen Benutzer, der sich nicht gut auskennt? --Schnark10:12, 5. Jun. 2013 (CEST)
Ich beziehe mich betreffend Einheitlichkeit nur auf die Beobachtungsliste.
Vielleicht für mit guter Beobachtungsgabe ausgestattete OMAs? Es sollte so ausgestaltet sein, dass es nicht stört, aber doch erkennbar ist. Da muss man wohl in Kauf nehmen, dass es auch übersehen werden kann. --Leyo10:21, 5. Jun. 2013 (CEST)
Ich hätte an ein dunkles mittelgrau gedacht; oder kursiv, wenn es das schon für einen gleichartigen Zweck gibt.
Service für alle Benutzer; wobei sich empfiehlt, Wikidata gleich ganz auszublenden, wenn man es überhaupt nicht wissen möchte.
Die Unterscheidung, dass der edit nicht in unserem Artikel vorgenommen wurde und nur sehr indirekt inhaltliche Auswirkungen hätte, ist schon von Bedeutung und auch leicht nachvollziehbar. In aller Regel wird man die Info überlesen wollen, wenn man sich nicht besonders intensiv für dieses einzelne Lemma interessiert.
Auf diesen Standpunkt stelle ich mich tatsächlich. Es sollte IMO in allen Wikipedias gemacht werden. Unter bugzilla:50893 gibt es nun eine Anfrage dazu. Magst du oder sonst jemand diese bezüglich D ergänzen? --Leyo18:25, 18. Jul. 2013 (CEST)
Es gibt zwei Irrtümer deinerseits: Ich bin nicht wirklich an Wikidata interessiert, und Bugzilla-Tickets für Wikidata bewirken nicht wirklich etwas. Der Umherirrende ist der bessere Ansprechpartner, da er es kürzlich überhaupt erst ermöglicht hat, dass weitere Flags wie etwa D verwendet werden können. --Schnark09:17, 19. Jul. 2013 (CEST)
Ja, ich hatte mich letztens mal damit beschäftigt und als Problem gesehen, das man garkeine eigenen Kürzel wie N, K, B und ! ergänzen kann und dafür eine Möglichkeit geschaffen. Dies könnte man für die einfache Beobachtungsliste auch sicher schon aktivieren, auch wenn dann auf der gruppierten Beobachtungliste ein Leerzeichen in dem Bereich der Buchstaben mehr auftaucht.
Ich hatte auch mal versucht, die gruppierte Beobachtungsliste mit WikiData-Einträgen zu versehen, aber der Code in MediaWiki der für die gruppierte Beobachtungsliste vorhanden ist, lässt keine Möglichkeit der Überschreibung. Daher ist das etwas komplizierter. Zusätzlich stellte sich dann die Frage, wie gruppiert man das am besten? Soll der Benutzername, die Seitenänderung von WikiData mit in die erste Zeile? Sollen die WikiData-Einträge garnicht gruppiert werden oder eine eigene Gruppe machen, wenn es mehrere gibt, ansonsten eine einzelne Zeile? Der Umherirrende 16:11, 19. Jul. 2013 (CEST)
Das Change Set gerrit:74636 für das D wurde jetzt angenommen, damit könnte es ab dem 22. August entsprechend gekennzeichnet werden. Der Umherirrende 16:40, 16. Aug. 2013 (CEST)
Vielen Dank! Damit ist die Hälfte meiner Wünsche erfüllt. Die leicht andere Farbe für nicht-lokale Links hätte ich weiterhin gerne… :-) --Leyo17:14, 16. Aug. 2013 (CEST)
Wobei ich eher glaube, das es der 29. August wird. Der Umherirrende 18:18, 20. Aug. 2013 (CEST)
Das D erscheint nun auf der Beobachtungsliste. Der Umherirrende 20:15, 29. Aug. 2013 (CEST)
Toll, danke! Ist es Absicht, dass es im Gegensatz zum K und B nicht fett ist? In der en-WP passt es übrigens etwas weniger ins Schema, weil m und b klein geschrieben werden. --Leyo07:31, 30. Aug. 2013 (CEST)
Im englischen ist es gemischt, Neue Seiten bekommen ein großes N, während bot und minor klein geschrieben werden. Daher würde ich nicht sagen, das ein großes D stört, aber ich kann auch nicht für die en.wp sprechen. Ändern könnten sie es lokal immer.
Das D wird ohne Styles ausgeliefert. Das Fett hatte ich nicht mehr in Erinnerung, weil ich es schon bei mir weggemacht habe (lenkt mich zu sehr ab). Andererseits weiß ich nicht, wie man in einer Extension ein neues ResourceLoader-Modul erstellt, was dann auf der Beobachtungsliste mit dem eigentlichen Modul geladen wird (Ein extra download davon wäre wohl zu viel des guten). Vermutlich ist ein Bug hier zielorientierter. Der Umherirrende 20:13, 5. Sep. 2013 (CEST)
Ich habe doch eine Möglichkeit gefunden: gerrit:74636, mal schauen, ob die Reviewer das auch mögen. Nach der Änderung wird es auch einfacher sein, CSS für die Linkfarbe einzufügen, weil es dann schon ein Modul gibt. Wobei im Bug ja erfragt wird, ob class="external" gesetzt werden kann. Da die Links aber schon plainlinks haben, wäre das irgendwie nicht sinnvoll. Der Umherirrende 21:27, 5. Sep. 2013 (CEST)
Schnarks Einwand halte im übrigen nicht für zutreffend, weil der unwissende Benutzer üblicherweise nicht in seinen Einstellungen herumgebastelt hat, um Wikidata-Links zu sehen. Oder andersrum, wer in Einstellungen | Beobachtungsliste das Häkchen vor Wikidata-Bearbeitungen in der Beobachtungsliste anzeigen gesetzt hat, ist nicht unwissend, sondern ist sich der Dichotomie auf der Beobachtungsliste durchaus bewußt. Mich stört übrigens, daß von der Beobachtungsliste aus Popups Wikidataeinträge nicht anzeigt. --Matthiasb – Vandale am Werk™ (CallMyCenter)02:43, 6. Sep. 2013 (CEST)
Popups funktioniert bei keinen nicht-lokalen Links. Das war früher schon bei Interwikibots-Edits so, wo die betreffenden Interwikis in der Zusammenfassung verlinkt waren. --Leyo10:55, 6. Sep. 2013 (CEST)
Kann freundlicherweise jemand angeben, was in die eigene common.css eingetragen werden muss, damit die Links auf Wikidata die IMO korrekte Farbe erhalten? Reicht ein Einzeiler mit der von PerfektesChaos ganz oben angegebenen Klasse? --Leyo00:16, 16. Okt. 2013 (CEST)
Die Farbe allein bringt wirklich fast gar nichts. Ohne gleichzeitig das Pfeilsymbol hinter alle externen Wikidata-Links zu setzen, sind sie nicht zu unterscheiden. Ich hab mal etwas rumgespielt. Ist nicht ganz ausgereift, aber wer mag, kann das mal in seiner eigenen common.css ausprobieren. --TMg17:13, 16. Okt. 2013 (CEST)
/* Wikidata-Zeilen in der Beobachtungsliste abblenden */li.wikibase-edit{opacity:.6;}/* Korrekte externe Linkfarbe für Wikidata-Links */li.wikibase-edit.plainlinks{color:#36B;}/* Buchstabe "D" durch das Wikidata-Logo ersetzen */abbr.wikibase-edit{background:url(//upload.wikimedia.org/wikipedia/commons/e/e8/Wikidata-favicon.png)050%no-repeat;color:transparent;padding-right:8px;}
Vielen Dank! Ich habe mich mal aufs mittlere beschränkt. Das erste übernehme ich bei Bedarf. À propos Bedarf: Ich sehe noch immer nicht ein, welche relevanten Gründe gegen die Aufnahme in der Common.css sprechen. Ein MB dazu wäre ja wohl ein Overkill… --Leyo01:38, 19. Okt. 2013 (CEST)
Daran hat sich auch fast zwei Jahre später nichts geändert. Falls hier keine Argumente kommen, setze ich's um (mittlere Variante). --Leyo21:19, 22. Jul. 2015 (CEST)
Letzter Kommentar: vor 8 Jahren5 Kommentare4 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 */}
Der Codevorschlag ist in einem veralteten Stil geschrieben (mit descendant combinators statt child combinators). Das hat man wegen dem Internet Explorer 6 früher so gemacht, es führt aber zu unerwünschten Nebenwirkungen bei verschachtelten Tabellen.
Das ließe sich zwar sehr leicht beheben, trotzdem befürworte ich die Aufnahme unter den momentanen Voraussetzungen nicht. Es gibt eine Vielzahl von Gründen, die tendenziell gegen die Etablierung neuer dewiki-spezifischer Formatierungsklassen sprechen und im Einzelfall gegen die Vorteile abzuwägen sind.
Konkret zu diesem Vorschlag ist zu sagen, dass die Wikipedia-Apps für Android und iOS momentan überhaupt kein sitespezifisches CSS auswerten (auch nicht MediaWiki:Mobile.css, wie man durch Betrachten der Seite Hilfe:Farbe leicht verifizieren kann), so dass Tabellen mit dieser Klasse (wenn wir sie denn aufnehmen würden) komplett unformatiert erscheinen würden, ohne dass wir etwas dagegen tun könnten.
Nun könnte man zwar sagen, dass die Schuld bei den Apps liegt, trotzdem sollte uns dies Mahnung genug sein, dass unsere Inhalte in der Praxis unabhängig von unseren CSS-Dateien genutzt werden und meiner Meinung nach auch so nutzbar sein sollten. Das spricht nicht prinzipiell gegen CSS-Ergänzungen, bei denen es kein Problem wäre, wenn sie fehlen. Wenn eine Tabelle, die keine Layouttabelle ist, ohne jede Formatierung erscheint, ist das aber sehr wohl ein Problem.
Letzter Kommentar: vor 8 Jahren21 Kommentare5 Personen sind an der Diskussion beteiligt
toptextcells für th
"wikitable toptextcells" aktuell
th
td
td
th
"wikitable toptextcells" gemäß Vorschlag
th
td
td
th
Hallo, ich hätte gerne eine Ergänzung zur Klasse toptextcells: Kann bitte jemand die Definition auf <th>-Elemente ausweiten? Siehe auch WP:WVW#Vorlage:Infobox Rennstrecke, in Infoboxen wird nämlich oft die linke Zelle als th realisiert, meist ist gerade für sie das toptextcells in Infoboxen nötig. meint -- ✓Bergi16:44, 10. Okt. 2010 (CEST)
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)
Gute Idee, sollte man eventuell (gleich) noch thead und tfoot einbeziehen? Und: unterstützen alle Browser das tbody, es wird im Quelltext ja nicht ausgeliefert? -- ✓Bergi15:34, 11. Okt. 2010 (CEST)
In HTML gibt es immer ein tbody-Element, egal ob es im Quelltext notiert ist:
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)
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)
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)
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)
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)
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)
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)
toptextcells für th zum Zweiten
Beispiel-Infobox
Label 1 mit mehr als einer Zeile
Oben ausgerichtet
Label 2
Im Gegensatz dazu ist diese Zeile nicht oben ausgerichtet
Die Diskussion gab es weiter oben schon mal, aber sie schlief wie es scheint ein. Können wir die Regel bitte erweitern, so dass sie auch für Kopfzellen gilt? Aktuell ist das sehr verwirrend (siehe das Infobox-Beispiel rechts). --TMg17:44, 9. Mai 2013 (CEST)
Wie genau erweitern? Ziemlich risikolos im Hinblick auf unerwartete Effekte, weil analog zum Vorhandenen wäre die Variante
Gefällt mir aber ehrlich gesagt nicht besonders, besser fände ich
table.toptextcells>*{vertical-align:top;}
(ähnlich wie der Vorschlag im Abschnitt weiter oben, aber daran angepasst, dass sortierbare Tabellen mittlerweile auch thead- und tfoot-Elemente haben, vgl. tablesorter.js)
Vorteile der zweiten Variante:
Wirkt sich nicht auf verschachtelte Tabellen aus
Kann nur auf ganze Tabellen angewendet werden (Verwendungen bleiben im Hinblick auf zukünftige Änderungen überschaubar, bisher mögliche Anwendung auf einzelne Zeilen hat eh keinen Mehrwert gegenüber zeilenweisen style-Anweisungen oder valign)
Kann durch Ausnutzen von Vererbung zeilen- oder zellenweise mit style="vertical-align: ..." oder sogar valign="..." überschrieben werden
Nachteile der zweiten Variante:
Wirkt sich nicht auf verschachtelte Tabellen aus (unwahrscheinlich, aber es könnte sein, dass sich irgendwer irgendwo auf die bisherige Wirkung verlassen hat)
Kann nur auf ganze Tabellen angewendet werden (dito)
Funktioniert nicht im IE 6 (tut die wikitable-Klasse aus shared.css mittlerweile allerdings auch nicht mehr)
Hm, damit kann man mehr machen als mit toptextcells, die Klasse wäre dann nicht mehr nötig, müsste aber weiter unterstützt werden wegen der bisherigen Verwendungen, und explizites inherit funktioniert wohl selbst im IE 7 nicht (die automatische Vererbung aber schon, diese ist im IE irgendwie anders implementiert). --Entlinkt (Diskussion) 12:03, 12. Mai 2013 (CEST)
Ich habe jetzt mal was umgesetzt, das verändert natürlich auch bestehende Artikel, sollte aber wohl keine katastrophalen Folgen haben und lässt sich leicht individuell überschreiben (im Gegensatz zum Vorherigen auch zeilenweise und auch mit valign). Falls es sich bewährt, müsste Hilfe:Tabellen#toptextcells noch aktualisiert werden. --Entlinkt (Diskussion) 04:52, 18. Mai 2013 (CEST)
1.
a
b c
d e
f
g
h i
j k
l
2.
a
b c
d e
f
g
h i
j k
l
3.
a
b c
d e
f
g
h i
j k
l
Bei sortierbaren Tabellen ist das Ergebnis hässlich, siehe rechts: Das Pfeilsymbol zum Sortieren ist als Hintergrundbild implementiert und passt sich der obenbündigen Textausrichtung nicht an. Was tun?
So lassen
Nur <thead> von der obenbündigen Ausrichtung ausschließen
<thead> und <tfoot> von der obenbündigen Ausrichtung ausschließen
Da es keine Rückmeldungen gab, archiviere ich das Anliegen ohne Maßnahme. Nochmal die explizite Begründung: Meiner Meinung nach verschlechtert der Vorschlag das Zusammenspiel der Klasse mit sortierbaren Tabellen und es ist nicht klar, wie damit umgegangen werden soll. Unter diesen Umständen ist der Vorschlag keine klare Verbesserung, da er zwar Inkonsistenzen beseitigt, aber auch neue schafft. --Entlinkt (Diskussion) 00:52, 28. Mär. 2016 (CEST)
ist für Anwender ohne das Gadget wirkungslos. Es könnte daher nach MediaWiki:Gadget-Personendaten.css verschoben werden, damit es nicht für alle Benutzer immer geladen wird. Allerdings gibt es noch Benutzer, die sich die Metadaten mit eigenen CSS-Definitionen einblenden und vermutlich nicht das Gadget aktiviert haben. --Fomafix12:22, 23. Feb. 2012 (CET)
Eine Suche nach \.metadata\b über alle JS/CSS-Benutzerseiten ergibt 1587 Seiten. Das ist etwas viel, würde ich sagen, um das zentral auszublenden. Der Umherirrende 17:08, 3. Mär. 2012 (CET)
Ich verstehe Deine Antwort nicht ganz. Ich habe gesagt: „metadata-inline kann entfallen“. Wird das noch irgendwo verwendet? .metadata { display: none; } muss selbstverständlich erhalten bleiben. --Fomafix (Diskussion) 18:43, 3. Mär. 2012 (CET)
Meine Antwort bezog sich auf die mögliche Verschiebung des Layouts und die Anmerkung darin, das es noch Benutzer in der eigenen CSS stehen haben. \.metadata-inline\b gibt Treffer auf 19 Benutzer-JS/CSS-Seiten, weil es so wohl in PDD's monobook.css drin vorkommt. Der Umherirrende 18:50, 3. Mär. 2012 (CET)
Aber eigentlich müsste man dafür ein Scan über Artikel/Vorlagen machen, nur habe ich die gerade nicht im Zugriff. Der Umherirrende 18:59, 3. Mär. 2012 (CET)
Vor einem Jahr habe ich alle metadata-inline auf metadata umgestellt und daraufhin metadata-inline auf MediaWiki:Gadget-Personendaten.css entfernen lassen. Das metadata-inline hier habe ich nur übersehen. Ob jemand noch eine nicht mehr benötigte CSS-Definition in seiner CSS-Datei hat, spielt keine Rolle für die Entfernung von metadata-inline hier. Entscheidend ist nur, ob metadata-inline noch in Artikeln oder Vorlagen verwendet wird. --Fomafix (Diskussion) 22:01, 3. Mär. 2012 (CET)
Da per Gadget sowieso nicht mehr sichtbar gemacht wird, habe ich es entfernt. Das Verschieben des Layouts für die Metadaten in das Gadget geht aufgrund der individuellen Einblendungen nicht, hier ist Abwärtskompatibiltät gefragt (Früher gab es das Gadget ja nicht, sondern nur per skin.css). Der Umherirrende 22:07, 3. Mär. 2012 (CET)
Abwärtskompatibilität ist gut und recht, aber wie lange wollen wir die beiden CSS-Definitionen table.metadata { border: 1px solid #aaa;} .metadata-label { color: #aaa;} hier noch für alle Benutzer laden lassen, statt sie in das Gadget zu übertragen? --Fomafix (Diskussion) 22:39, 3. Mär. 2012 (CET)
Keine Ahnung, da aber möglicherweise 1500 Benutzer betroffen sind, geht es aus meiner Sicht nicht. Muss erst eine Flurbereinigung her. Der Umherirrende 22:45, 3. Mär. 2012 (CET)
Es geht nur um einen grauen Rahmen und eine Schriftfarbe. Zu sehen sind die Informationen auch für die betroffenen Benutzer, die sich die Metadaten ohne Gadget einblenden. --Fomafix (Diskussion) 23:11, 3. Mär. 2012 (CET)
Ich fände es nicht so gut, wenn auf einmal die Personendaten ohne Rand daher kommen, ohne das man mir etwas gesagt hat, daher bin ich gegen die Änderung. Der Umherirrende 23:28, 3. Mär. 2012 (CET)
Oder man nötigt die Benutzer mit selbstaktivierten Metadaten zum Aktivieren des Gadgets, indem in die Vorlage:Personendaten eine auffällige Meldung mit class="metadata nogadget" positioniert wird und blendet diese im Gadget mit .nogadget { display: none } aus. --Fomafix (Diskussion) 23:53, 3. Mär. 2012 (CET)
Ich würde den zuletzt gemachten Vorschlag im Prinzip unterstützen; allerdings nicht als „auffällige Meldung“:
Funktional bleibt für die Benutzer alles gleich; ggf. auch hier in der Common.css unverändert.
In die dadurch ein/ausgeblendete Box wird pfiffig eine Unterzeile/Unterbox eingeblendet, die nur diejenigen sehen können, die irgendetwas mit den fraglichen Elementen angestellt haben (Vorlagenprogrammierung).
In dieser Box befindet sich ein Kurzhinweis „Du verwendest veraltetes CSS – bitte entfernen“, das Linktitel für eine Unterseite von Vorlage:Personendaten ist, in der erklärt wird, dass die Leute
aus ihrer persönlichen CSS das entfernen sollen (Was ist das? Wie geht das? Was für Seiten?)
auf Helferlein ankreuzeln sollen, was sie haben wollen (Was für ein Ding? Wie heißt das? Wo muss ich mein Putin-Kreuz machen?).
Das Info-Link kann hier auf Common.css durch irgendein geniales .metadata #oldCSSMetadata sichtbar/unsichtbar gemacht werden.
6–12 Monate abwarten.
Danach komplett entfernen.
Wir haben Tausende offenkundig inaktiver Benutzer, in deren JS/CSS sonstwelches vergammeltes Zeug herumsteht.
Wir können nicht jeden Mist von 2003 auf ewige Zeiten unterstützen.
Es wäre unfair, es technikunkundigen Leuten unterm Keyboard wegzuziehen, sie stundenlang rätseln und schließlich auf FzW aufschlagen zu lassen.
Wer dann nach einem halben Jahr nicht eingeloggt war, nicht auf Personenartikeln war, nichts getan hat … dem wird das auch nicht auffallen. Zumal es offenbar nur um einen Rahmen geht.
Ich finde das einen gigantischen Aufwand und das nur wegen einem Rahmen und etwas grauer Schrift. Ich vermute mal, dass es trotz eines Hinweistextes in 6–12 Monaten weiterhin über 1000 Treffer auf /\.metadata/ in den Benutzer-CSS-Dateien geben wird.
Meiner Meinung nach sollte die Formatierung einfach in die Vorlage verschoben werden. So wird das schließlich auch bei allen anderen Vorlagen gemacht. --Fomafix (Diskussion) 15:25, 5. Mär. 2012 (CET)
Das ist richtig. Ist id="Personendaten" in Ordnung? Oder gibt das ein Problem, falls mal eine Überschrift == Personendaten == existiert? Ist .metadata-label überhaupt noch notwendig, falls die Formatierung in der Vorlage ist? --Fomafix (Diskussion) 10:41, 6. Mär. 2012 (CET)
Großgeschriebene IDs sehen in meinen Augen immer etwas merkwürdig aus, sodass ich id="personendaten" bevorzugen würde. Dann käme es auch zu keiner Kollision mit Überschriften (zumindest nicht, wenn der Schreibende sich an die Rechtschreibregeln hält). Wenn man vorsichtig sein will, kann man immer noch per table#personendaten selektieren.
Zur Id in den Personendaten: Viele Vorlagen haben eine id in der Form Vorlage_Personendaten. Würde das hier auch Sinn machen? oder besser nur Personendaten? Der Umherirrende 21:31, 10. Apr. 2012 (CEST)
Ich würde es hier drin lassen, weil es zuviele Altlasten sind. Früher wurde es für die User.css beworben (weil es keine Alternativen gab), da kann man jetzt schlecht sagen, wir vernachlässigen diese Benutzer jetzt. Bereinigen der User.css von einem Admins wird wohl auch ungern gesehen. Besser wäre es, das Gadget bei den Benutzern zu aktivieren, das bekommt man aber nicht hin (und das ist auch gut so). Hier darf sich gerne jemand anders austoben. Der Umherirrende 21:41, 15. Jan. 2013 (CET)
Ich habe mich mal in der Form „ausgetobt“, dass der Rahmen jetzt in der Vorlage über die Klasse rahmenfarbe1 erzeugt wird. Aus der Common.css kann der Rahmen also im Prinzip entfernt werden, und ich fände das auch recht logisch, weil es dadurch möglich wird, mit class="metadata rahmenfarbeX" (X ≠ 1) abweichend formatierte Tabellen zu erzeugen (bislang geht das wegen der Spezifitäten nicht). Ich mach’s jetzt nur deshalb nicht, um abzuwarten, welche anderen Vorlagen sich auch darauf verlassen, dass der Rahmen hier erzeugt wird.
Wenn die Schriftfarbe auch von hier entfernt würde, hielte ich das (im Gegensatz zum Rahmen) für eine relativ geringe Beeinträchtigung, irgendwer würde sich bestimmt darüber ärgern, aber ich halte es für vertretbar. Mal sehen. --Entlinkt (Diskussion) 02:13, 26. Mai 2013 (CEST)
Das ursprünglich hier gemeldete Anliegen ist längst erledigt und es bleibt nur der Klassennamen-Clash mit dem MediaViewer.
Da der zugehörige Thread in der Technikwerkstatt bereits archiviert ist, können wir das hier wohl auch archivieren (siehe das dort gezogene Fazit). Ich persönlich bin auch nicht besonders darauf aus, mir an einer in diesem Fall derzeit nicht unbedingt notwendigen Klassenumbenennung die Finger zu verbrennen, da nach wie vor viele Benutzer in ihrem persönlichen CSS den Klassennamen metadata zum Einblenden verwenden, der MediaViewer weiterhin ein Reizthema ist und das Ganze leicht in einem „politischen“ Sinne missverstanden werden kann.
Der MediaViewer verwendet den Klassennamen metadata übrigens vermutlich deshalb, weil er in der englischen Wikipedia traditionell für Wartungsbausteine verwendet wird (also für genau die Dinge, die der MediaViewer erfassen will). Ich persönlich ziehe daraus den Schluss, dass es sich durchaus lohnen kann, Klassennamen mit der englischen Wikipedia oder anderen bedeutenden Wikis (Commons, Meta, …) abzugleichen. --Entlinkt (Diskussion) 19:07, 27. Mär. 2016 (CEST)
Letzter Kommentar: vor 8 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
sollten wieder eingefügt werden, aber ohne Browserweiche. Denn auch andere Browser außer dem IE benötigen diese Anweisungen, da sie sonst die Schriftzeichen nicht darstellen können. -- Liliana•13:36, 13. Mai 2013 (CEST)
*Seufz* – Es geht um diesen Edit, der in fast allen Fällen nichts ändert, weil die Regel sowieso nur im IE 6 und 7 wirkte und keine einzige dieser drei Schriften unter Windows standardmäßig installiert ist und die beiden Klassen extrem selten verwendet werden (Vorlage:Altitalisch ist zurzeit 3-mal eingebunden, für Gotisch gibt es überhaupt keine Vorlage).
Aber Tatsache – unter Windows schafft es nur der Firefox; Internet Explorer 9, Chrome 26 und Opera 12.15 scheitern selbst dann, wenn die Schriften installiert sind. (Unter Linux schaffen es aber auch Chrome und Opera, muss also ein Windows-Bug sein.)
Für 3 Artikel lohnt sich eine Regel in der common.css, die bei 1,5 Millionen Artikelseiten mitgeladen wird, m. E. nicht wirklich. Die Schriften könnten wieder in direkt in die Vorlage eingefügt werden, wie es auch andere, selten verwendete Vorlagen in der Kategorie:Vorlage:mit Schriftfamilie derzeit tun. Aber selbst dann ist der Gewinn gering; die meisten Benutzer werden die Zeichen auch dann nicht sehen können, weil die Schriften ja in der Regel nicht installiert sind. Der Schaden für Firefox- und Nicht-Windows-Benutzer ist aber auch entsprechend gering. --Entlinkt (Diskussion) 14:19, 13. Mai 2013 (CEST)
Seit dem 9. Juli 2013 gibt es den Universal Language Selector, dieser fügt abhängig vom lang-Attribut fleißig font-family-Angaben ein. Beispiel:
Als Arabisch ausgezeichneter Text in abweichender Schriftart (Amiri)
Die von der Vorlage:Arabische Schrift eingesetzte Klasse spanAr ist damit wirkungslos geworden. Ich halte es angesichts dessen nicht mehr für sinnvoll, Vorlagen dieses Typs bzw. projektspezifische Klassennamen mit Schriftarten einzuführen, zu pflegen oder aufrecht zu erhalten. Es gibt eine neue MediaWiki-weite Infrastruktur für diesen Zweck und diese sollte dann auch genutzt werden, soweit der Bedarf besteht. --Entlinkt (Diskussion) 23:56, 10. Okt. 2013 (CEST)
Stellungnahme:
Deklarationen fremdsprachlicher Textteile, bei denen nicht-ANSI-lateinische Schriften zu erwarten sind, haben in Vorlagen eingeschlossen zu werden.
Darüberhinaus liefert dies auch das jeweilige Attribut lang= und unterstützt damit Semantik und Screenreader.
Zur Quelltext-Vereinfachung dekorieren wir allerdings nicht jede englischsprachige oder französische Vokabel mit einer Vorlage.
Gegen die Deklaration einer längeren Liste möglicher Schriftfamilien in Vorlagen ist nichts zu sagen.
Es sichert die Entnahme aller Schriftzeichen der Textstelle aus ein und demselben Font, während ansonsten die Schriftzeichen ggf. aus unterschiedlichen Fonts zusammengestoppelt werden, je nachdem wo zuerst ein Zeichen mit der entsprechenden Kodierung gefunden wird.
Beispiel: Polytonisches Griechisch; Firefox entnimmt die neugriechischen Zeichen der Grundschrift (vielleicht Arial), die dort fehlenden Zeichen der nächstbesten Spezialschriftart, weshalb gleiche Grundbuchstaben völlig anders aussehen können.
Die Schriftfamilien sollten ausschließlich über style= in Vorlagen definiert werden und nicht mehr über class= in MediaWiki:.css wie hier.
Jede Zuordnung einer Schriftfamilie/Schriftarten-Aufzählung sollte nur an exakt einer Stelle im Projekt deklariert sein.
Die gemeinsame Nuzung einer Schriftarten-Aufzählung durch mehrere Vorlagen, wie sie zurzeit durch class= erreicht wird, kann auch durch eine gemeinschaftliche interne Untervorlage erzielt werden, die von allen im Artikel eingebundenen Vorlagenvariationen mitbenutzt wird.
In Vorlagen kann die Schriftfamilien-Aufzählung von allen (angemeldeten) Benutzern ergänzt werden.
ULS
ULS ist zurzeit ausschließlich für die folgenden (asiatischen, nicht lateinisch basierten, nicht-CJK/griechisch/kyrillischen) Sprachen verfügbar: akk am ang ar arb arc as bh bho bn bo bpy bug cdo cr dv dz fa gom grc gu hbo he hi ii iu jv jv-java km kn kok lo mai mak ml mr my nan ne or pa pal peo sa saz si sux syc ta tcy te ti ur yi.
ULS wird ausgelöst durch das Attribut lang= und damit ist ohnehin erforderlich, die Textpassage in eine Vorlage einzuschließen. Die kann dann aber auch gleich für Schriftarten sorgen.
ULS arbeitet ausschließlich mit JavaScript.
ULS ist zurzeit noch recht ineffizient programmiert und erfordert bei jedem Seitenaufbau überflüssige Extra-Kommunikation.
Das Opt-Out für nichtlateinisch verschriftete Wikiprojekte auf Projekt-Ebene oder als Benutzer-Option wird deshalb gefordert. Gleichwohl sollen dann für seltene Textpassagen die traditionellen CSS-Lösungen greifen.
Für nicht angemeldete Leser ist es wohl zurzeit nicht aktiviert.
Die grundsätzliche Intention für ULS war zunächst gewesen, asiatische Wiki-Projekte mit Inhalten der oben genannten Schriftsysteme besser zu unterstützen. Wie sich das weiter entwickeln mag, ist bei WMF nicht durchschaubar.
Die Produktentwicklung erfolgt nicht durch die WMF-Kernteams, sondern ist von irgendwoher eingekauft oder über eine Kooperation mit undurchsichtigen Dritten und mit unbekanntem Ziel erfolgt. Direkten Einfluss auf die upstream-Definitionen haben WMF und die Wiki-Projekte anscheinend nicht.
Eine technische Dokumentation existiert nicht; nur Rätselraten über die Absichten aus dem Quellcode.
Fazit: ULS ist kein Pferd, auf das man setzen sollte.
Ich werde jetzt die letzten verbliebenen font-family-Regeln aus MediaWiki:Common.css entfernen. Es geht um die folgenden Codezeilen, die in genau dieser Form seit dem 22. Mai 2014 unverändert bestanden, aber auch zuvor schon seit dem 7. Juni 2010 mit einer (anders implementierten) Browserweiche versehen waren:
/* * CSS-Klassen für Schriftarten als Workaround für Defizite im IE 7. * Achtung: IE 7 mag keine Zeilenumbrüche zwischen den Fonts. * Browserweiche: IE 7 sieht die Doctype-Deklaration als Element an. *//* [[Vorlage:Unicode]] */:first-child~html.Unicode{font-family:Code2000,Sun-ExtA,"Arial Unicode MS",NSimSun,sans-serif;}/* [[Vorlage:IPA]], [[Vorlage:IPA-Text]] */:first-child~html.IPA{font-family:Quivira,Code2000,Sun-ExtA,"DejaVu Sans","Gentium Plus",Gentium,"Doulos SIL",Helvetica,"Arial Unicode MS","Lucida Sans Unicode",sans-serif;}/* [[Vorlage:He]] */:first-child~html.hebrew{font-family:Quivira,Sun-ExtA,"Arial Unicode MS","SBL Hebrew",Code2000,"MPH 2B Damase",sans-serif;}/* [[Vorlage:Arabische Schrift]] */:first-child~html.spanAr{font-family:"Arial Unicode MS",Scheherazade,Code2000,"DejaVu Sans",sans-serif;}
Begründung:
Dies ist die letzte wirklich üble Browserweiche in unserem CSS-Code und wohl auch die einzige, die wir jemals hatten. Browserweichen sind heutzutage grundsätzlich nicht mehr zeitgemäß, sondern es sind Feature-Tests angesagt.
Durch die Browserweiche wirkte der Code zuletzt ausschließlich im Internet Explorer 7, dessen Marktanteil im deutschsprachigen Raum mittlerweile im Promillebereich liegt. Die ursprüngliche Rechtfertigung für diesen Code lag darin, dem damals marktführenden Browser auf die Sprünge zu helfen. Heute wirkt er sich auf die Darstellung in anderen Browsern nicht aus, verbraucht aber dennoch Ressourcen zum Herunterladen und Parsen.
Es scheint nach wie vor Uneinigkeit darüber zu geben, ob überhaupt Schriftarten vorgegeben werden sollen und wenn ja, in welcher Form. Es ist allerdings relativ klar, dass der fragliche Code zur Klärung dieser Fragen nichts relevantes beiträgt, dafür verwirrt er aber möglicherweise. Ich halte es für sinnvoll, hier jetzt erst mal tabula rasa zu machen.
Meiner Meinung nach hätte man den Code durchaus auch sehr viel früher entfernen können, davon habe ich aber abgesehen, um zu vermeiden, dass er ohne Browserweiche wiederkommt. Ich hoffe sehr, dass das jetzt nicht passiert – es wäre ziemlich unvorteilhaft, da die Schriftartenlisten seit 6 Jahren in allen modernen Browsern unwirksam waren und deshalb nicht getestet wurden.
Wofür wird dort überhaupt die Klasse prettytable benutzt? Die Definitionen werden größtenteils wieder überschrieben. Es ist nicht sinnvoll, eine Klasse zu verwenden, die ein Gitter erzeugt, das Gitter mit einer anderen Klasse wieder zu entfernen und dann mit Inline-CSS alles außer dem Gitter auch noch zu überschreiben. --Entlinkt (Diskussion) 16:34, 1. Jun. 2013 (CEST)
Die Klasse nogrid ist mal als Workaround für einen Bug in der Definition von prettytable eingeführt, aber niemals dokumentiert worden.
Dann wurde die Definition von prettytable unter dem Namen wikitable nach shared.css kopiert.
Mit rev:107669 vor über einem Jahr wurde die Definition von wikitable gefixt, so dass nogrid für den ursprünglich angedachten Zweck weder nötig ist noch überhaupt funktioniert. Die lokale Definition von prettytable behielt den Bug.
Kürzlich habe ich die lokale Definition von prettytable an die von wikitable angeglichen (denn ein Unterschied zwischen den beiden war nie beabsichtigt) und gleichzeitig nogrid entfernt, weil es ja nicht mehr funktioniert.
Während der langen Zeit haben Benutzer herausgefunden, dass man die subtilen, nicht dokumentierten Unterschiede zwischen den Klassen ausnutzen kann, um bestimmte Effekte zu erzielen, die überhaupt nicht vorgesehen sind. (Genau deshalb sollten die beiden Klassen synchron gehalten werden, auch wenn prettytable veraltet ist, weil es sonst immer irgendwo neu eingebaut werden wird.)
Ich bin dagegen, eine Klasse wieder einzuführen, ohne dass es einen klar ersichtlichen, sinnvollen Anwendungsfall dafür gibt. (Deshalb stelle ich die Frage, vielleicht gibt es ja doch einen.) Andernfalls können meiner Meinung nach beide Klassen – prettytable und nogrid – aus der Vorlage schlicht entfernt werden: Sie heben sich im Wesentlichen gegenseitig auf.
Ich muss mich (teilweise) korrigieren: Die Klasse nogrid war tatsächlich mal für kurze Zeit dokumentiert, nämlich unter Vorlage Diskussion:Prettytable/Bugs. Dort stand:
„Untertabellen übernehmen von der Haupttabelle den Rand (Rahmen) der Zellen. Abschalten kann man das für alle Zellen mit der Angabe class="nogrid" im Kopf der Untertabelle. Für einzelne Zellen mit Direktformatierung. In manchen Fällen können sich ebenfalls die Innenabstände der Tabellenzellen ändern (da diese auch von der Haupttabelle übernommen werden). Eine Lösung ist hier wiederum die Direktformatierung einzelner Zellen (CSS-Attribut padding:…).“
nogrid ist also wirklich nur ein Workaround für diesen Bug gewesen, die Seite ist aber sehr zügig nach Einführung der Klasse wieder gelöscht worden, so dass das kaum jemand mehr wusste.
Ich habe gesehen, dass du die Klassen aus der Vorlage mittlerweile wieder entfernt hast. Allerdings hatte die Infobox von der Klasse prettytable auch die Zellinnenabstände geerbt (was ebenfalls nur ein unerwünschter Nebeneffekt war, s. o.). Falls du für alle Zellen der Tabelle Innenabstände einstellen möchtest, kannst du dafür (bis es etwas besseres gibt) das Attribut cellpadding benutzen.
In der Zwischenzeit hat sich viel getan, unter anderem haben wir eine stark verbesserte Suchfunktion erhalten, mit der man leicht überprüfen kann, dass keine kritischen Verwendungen der Klasse nogrid mehr vorliegen.
Meiner Meinung nach sind aus der Causa die folgenden Schlüsse zu ziehen:
Wenn irgendwo Bugs auftreten, sind diese durch einen ordentlichen Fix oder aber gar nicht zu beheben, und nicht durch einen Workaround mit Nebenwirkungen. Die Einführung einer neuen projektweit wirksamen Formatierungsklasse als Workaround für einen Bug in einer anderen ist aus heutiger Perspektive ein großes Übel gewesen und darf sich nicht wiederholen.
Die Bereinigung von Altlasten ist ein heikles Thema, da unerwartete Effekte einkalkuliert werden müssen, aber es wäre verkehrt, deswegen jede Schnapsidee von anno dazumal bis in alle Ewigkeit mitzuschleppen.
Die Betroffenheit der Vorlage:Infobox Flughafen hätte nicht passieren sollen und würde mit der heutigen Suchfunktion auch nicht passieren.
Letzter Kommentar: vor 8 Jahren14 Kommentare4 Personen sind an der Diskussion beteiligt
Um mittels Lua Artikel auf falsche Parameter in Vorlagen überprüfen zu können, braucht es eine Möglichkeit, die Fehlermeldungen (analoges Beispiel bei Vorlage:Information) nur bestimmten Benutzern anzuzeigen bzw. vor allen anderen zu verbergen. Unter Wikipedia:Lua/Werkstatt#Breitere Anwendung von Modul:TemplatePar wurden verschiedene Varianten diskutiert. Eine Kopplung etwa an die Aktivierung des Metadaten-Gadgets würde nebst einer kleinen Erweiterung des Gadgets selbst auch eine Ergänzung des entsprechenden display:none in der Common.css bedingen. Gibt es Einwände dagegen oder Alternativvorschläge? --Leyo19:18, 27. Aug. 2013 (CEST)
Mir leuchtet nicht so recht ein, warum die Meldung, dass man eine Vorlage gerade mit einem falschen Parameter verwenden will, dem Verursacher dieses Fehlers nicht angezeigt werden soll? Warum sollte das nicht jeder selbst beheben dürfen, statt dass sich ein paar wenige Benutzer die von anderen verursachten Fehler gebündelt aufhalsen? Wenn es um Altfälle geht, so sollten diese einer nach dem anderen zeitnah abgearbeitet werden. So lange kann die Warnung entweder sichtbar bleiben, oder man macht sie für alle unsichtbar und arbeitet sie nur per Wartungskategorie ab. Beides braucht keine Erweiterung des CSS. --TMg21:43, 27. Aug. 2013 (CEST)
Es geht mir vor allem um die Altfälle. Bei einigen Infoboxen oder sonst häufig verwendeten Vorlagen gibt es bestimmt hunderte von Artikeln mit Parameterfehlern, so dass diese nicht zeitnah abgearbeitet werden können. Ein Leser sollte solche Fehlermeldungen nicht zu Gesicht bekommen. IMO kann die Anzeige auch vom Sichterrecht abhängig (MediaWiki:Group-editor.css, analog zu MediaWiki:Group-sysop.css) gemacht werden. --Leyo23:44, 27. Aug. 2013 (CEST)
Da die verlinkte CSS-Seite ja einen Kommentar diesbezüglich enthält, funktioniert das. Autoconfirmed wird erst zur Laufzeit geprüft, daher kann man das nicht zählen oder sich auf Spezial:Benutzer auswählen. Ob der aktuelle Benutzer autoconfirmed ist, kann aber festgestellt werden. Der Umherirrende 17:31, 5. Sep. 2013 (CEST)
Es lässt sich auch parallel eine wp_adminonly definieren (nur ein Wort und ein Komma mehr); und nach und nach dorthin migrieren. Sind eh nur ein halbes Dutzend Vorkommen.
Zu den Klassennamen: Ich weiß nicht, ob man wp_ wirklich als Namenskonvention bezeichnen sollte; es wird in einigen Vorlagen verwendet, aber mehr als die genannten .wp_boppel und .wp_intro fallen mir gerade auch nicht ein, wobei „Boppel“ ein wenig nach einem Scherz klingt.
wp_ würde nie ein wikiübergreifender Standard werden, weil es nicht nur Wikipedien gibt, aber die Funktionalität ist nicht Wikipedia-spezifisch. Vielleicht wäre es nicht verkehrt, sich einfach der englischen Wikipedia anzuschließen: .editor-show, .sysop-show. --Entlinkt (Diskussion) 01:58, 19. Okt. 2013 (CEST)
Da gibt es ein Missverständnis: wp_ soll gerade nicht heißen: „wikiübergreifender Standard“, sondern „Projektweiter Selektor der deutschsprachigen Wikipedia“.
Was wikiübergreifend ist, hat durch MediaWiki definiert zu werden.
„Projektweiter Selektor“ meint: Nicht spezifisch für eine Redaktion, eine Infobox, eine einzelne Vorlage, einen bestimmten Benutzer.
wp_talkpagetext gab es auch schon. Ich fordere ja gerade die deutliche Kennzeichnung aller neu eingeführter lokaler Selektoren in Abgrenzung von den weltweit gültigen; natürlich ist dies in der Vergangenheit ungenügend kenntlich gemacht worden und deshalb zurzeit selten.
Ich möchte gern, dass am Klassennamen sofort ersichtlich ist, wer sich das ausgedacht hat und wo nach der Definition zu suchen wäre.
Wer hat ns-subject in die Welt gesetzt?
Bilderwunsch ist ganz offensichtlich eine deutschsprachige und keine weltweite Schöpfung.
mw-editsection ist ersichtlich in höheren Sphären definiert.
Aber von wem ist action-edit?
Es gibt bei MW -zigtausende an Klassennamen, und niemand auf dem Planeten hat noch irgendeinen Durchblick, wo die wie gesetzt werden.
Ein Verzicht auf Präfixe wäre dann tolerabel, wenn es für die deWP eine vollständige und zuverlässige Dokumentation geben würde.
In den letzten zehn Jahren haben jedoch Dutzende von Admins und einfacher Benutzer irgendwas in den space geschossen, ohne sich jemals um eine Projektdokumentation und Registrierung oder gar Systematik zu kümmern. Die Definitionen sind auf -zig verschiedene Seiten verteilt, so dass man auch nicht einfach nachgucken kann, welche Stile etwa hier umseitig damit verknüpft wären.
Wenn schon bisher der totale Dschungel angerichtet wurde, dann sollten wenigstens alle neuen projektweiten Selektoren nicht aus dem Ärmel geschüttelt werden.
Dazu gehört auch die Schreibweise: Einheitlich menschenfreundlich oder in einem Wort? floatright oder float-right und top-textcells oder am Stück toptextcells – adminonly oder sysop-only? Wer soll sich das denn noch alles merken können? Und wo nachschlagen?
Nicht-WP-Projekte interessieren mich bei unseren deWP-eigenen Definitionen nicht.
Alles ohne Präfix oder erkennbare deutschsprachige Komponente wie Vorlage_ ist eine weltweite Definition durch MediaWiki.
Was in irgendeinem anderem Projekt benutzt wird, ist irrelevant, solange es keine weltweit einheitliche Vorgabe durch MediaWiki gibt.
Gerade die enWP hat vor einigen Jahren davor kapituliert, alle MediaWiki-Selektoren zu dokumentieren, und dabei gleichzeitig ihre begrenzte projektspezifische Dokumentation aufgegeben. Die können ihre privaten Selektoren heute auch nicht mehr von mw unterscheiden.
Definition meint:
Auslösung für bestimmte Elemente in bestimmten Situationen.
Wann? Wo generiert?
Optionale Zuweisung eines Stils zu diesem Selektor.
Ich denke nicht, dass es ein Missverständnis gibt, ich bin lediglich anderer Meinung.
Mir persönlich gefällt der Unterstrich in wp_ nicht. MediaWiki verwendet den Präfix mw- mit Bindestrich und benutzt den Unterstrich als Ersatz für bestimmte Interpunktionszeichen, die man in CSS-Selektoren sonst escapen müsste (Beispiel: class="page-Wikipedia_Hauptseite"). Wir haben dies für vorlagenspezifische IDs recht konsequent übernommen (Beispiel: id="Vorlage_Personendaten").
Ich würde in diesem Sinne aus Konsistenzgründen den Präfix wp- für Herkunftsangaben bevorzugen (soweit man eine Herkunftsangabe überhaupt für sinnvoll erachtet). Dagegen spricht, dass wp_boppel und wp_intro bereits mit Unterstrich in Verwendung sind. Die könnte man aber auch ohne Weiteres als historisch bedingte Altlasten betrachten. id="wp_talkpagetext" (ehemals in MediaWiki:Talkpagetext) ist nicht mehr in Verwendung.
Das Anliegen, die hier vorgeschlagene Klasse, Arbeitstitel meinetwegen editoronly, mit einem Herkunfts-Präfix zu versehen, habe ich schon verstanden, bin aber bis jetzt nicht wirklich überzeugt davon. In der englischen Wikipedia gibt es schon ein konsistentes Schema zur Benennung derartiger Klassen, das für uns nicht wirklich ungeeignet ist; wenn man es übernimmt, dann könnte sich daraus einmal ein wikiübergreifender Standard entwickeln, der einmal in MediaWiki übernommen werden könnte.
Nennt man die Klasse dagegen wp_editoronly oder wp-editoronly, dann weiß man mit Sicherheit, dass dies niemals ein wikiübergreifender Standard werden wird und schon dann divergieren oder zu einer Inkonsistenz führen wird, wenn eine Vorlage aus der deutschsprachigen Wikipedia ins deutschsprachige Wiktionary kopiert wird.
Klassen wie NavFrame werden in unzählige Wikis kopiert, darunter auch solche, die gar nichts mit Wikimedia zu tun haben (Beispiel: Teil 1, Teil 2). Ich weiß nicht, ob es besser wäre, wenn sie wp_NavFrame hieße: Entweder, Nachnutzer benennen sie um und müssen immer darauf achten, dass sie bei ihnen anders heißt oder sie benennen sie nicht um und haben dann eben eine sonderbar benannte Klasse in ihrem Wiki. Mir ist das nicht egal.
Dasselbe gilt auch in umgekehrter Richtung: class="sideBox" war mal in MediaWiki, ist aber entfernt worden und wird meines Wissens nur noch in diesem Wiki benutzt; hätte man die Klasse mw-sideBox genannt, dann hätten wir jetzt einen Präfix, der eine falsche Herkunft suggeriert. Herkunftspräfixe haben also nicht nur Vorteile.
So fürchterlich unübersichtlich finde ich die jetzige Situation auch gar nicht. Wikipedia-spezifische Klassennamen sind ohnehin problematisch, weil ihre Verwendung sich (mit oder ohne Präfix) nicht ohne großen Aufwand (Dump-Auswertung) nachverfolgen lässt und sollen allgemein sparsam verwendet werden.
Einem Anwender kann es eigentlich auch meistens egal sein, wo eine Klasse definiert ist, solange sie funktioniert. Das kann man auch durch Dokumentation lösen. Nur weil eine bestimmte Dokumentation nicht gut ist, heißt das nicht, dass es keine gute Dokumentation geben kann. Man muss auch nicht jeden erdenklichen Klassennamen zentral dokumentieren (bei vorlagenspezifischen Klassen und IDs mit Präfix Vorlage_, die nur „auf Vorrat“ angelegt und nie mit bestimmten Styles verknüpft wurden, ergibt das gar keinen Sinn), sondern nur die wenigen, die von allgemeinem Interesse sind. --Entlinkt (Diskussion) 15:03, 20. Okt. 2013 (CEST)
Ich sehe hier keinen weiteren Handlungsbedarf. In MediaWiki:Group-editor.css wurde eine Klasse namens editoronly definiert, die unter diesem Namen in Modul:Vorlage:LCCN benutzt wird und anscheinend funktioniert. That's it.
Da Wikipedianer in solchen Angelegenheiten typischerweise nach Analogieprinzipien handeln und wir mit adminonly sowie editoronly bereits zwei Klassen für Benutzergruppen haben, die keinen Präfix wp_ haben und auf …only enden, wird die nächste derartige Klasse nach meiner Glaskugel bei uns autoconfirmedonly heißen, obwohl ich in Anbetracht von en:MediaWiki:Group-autoconfirmed.css lieber autoconfirmed-show hätte. Damit muss (und kann) man wohl leben. --Entlinkt (Diskussion) 04:01, 28. Mär. 2016 (CEST)
Letzter Kommentar: vor 8 Jahren22 Kommentare7 Personen sind an der Diskussion beteiligt
Beispiel
Seit die Speichern- und Vorschau-Knöpfe in einem Kasten stecken (den finde ich super, nur um das auch zu erwähnen), ist die editTools genannte Zeichenleiste unterhalb des Bearbeitungsfensters weit weg gerückt. Aktuell sind die Zeichen viel näher an der Vorlagenliste als an allem anderen, aber damit haben sie gar nichts zu tun. Sie gehören logisch direkt an das Bearbeitungsfenster heran. Eigentlich sogar über den Speichern-Knopf, mindestens aber sollte der Abstand nach oben ganz entfernt und ggf. der Abstand nach unten minimal vergrößert werden.
Nebenher möchte ich mal fragen, welcher Prozentsatz der Benutzer (wenn überhaupt, vermutlich muss man eher nach Promille fragen) mit den unter jeder Vorschau auftauchenden Profiling-Daten etwas anfangen kann? Die Benutzer sind so oder so schon überfordert und nehmen das Wesentliche oft genug gar nicht wahr. Jedes zusätzliche „Rauschen“ lenkt noch stärker davon ab, deshalb halte ich es für angebracht, das zu reduzieren. Können wir die Zeile ausblenden und per Gadget optional machen?
Die Wartungskategorien werden bei einer Vorschau jetzt doppelt angezeigt? Ist das ein Versehen?
In der englischen Wikipedia befindet sich die Sonderzeichenleiste zwischen Bearbeitungsfenster und grauer Zusammenfassungsbox (en:MediaWiki:Gadget-charinsert.js), auf Commons wurde sie in die Toolbar des WikiEditors integriert (commons:MediaWiki:Edittools.js). Beides erscheint mir irgendwie sinnvoller, als was wir haben, ersteres wäre in MediaWiki:Onlyifediting.js wohl leichter umzusetzen.
Zu den Profiling-Daten habe ich keine Meinung, die wurden erst kürzlich eingeführt.
Die doppelte Anzeige der Wartungskategorien ist lustig, war mir noch gar nicht aufgefallen. Nur der untere, ältere Eintrag (in der grauen Box) reagiert auf die Einstellung „Zeige Wartungskategorien“. Der ausklappbare Eintrag ist neu.
Den PP report können nur ein bis zwei Dutzend Vorlagenprogrammierer sinnvoll nutzen; für diese ist das allerdings in gelegentlichen Fällen eine nette Erleichterung.
Gleichwohl sind diese selbst in der Lage, eine standardmäßige Ausblendung sichtbar zu machen; ein Gadget braucht es dafür nicht. Ankündigung in der Vorlagenwerkstatt und Doku unter Hilfe:Vorlagenprogrammierung reicht völlig.
Was stattdessen fehlt und seit langem in meiner Liste zu erstellender Hilfeseiten steht, ist die (deutschsprachige) Erklärung, was diese Werte bedeuten und wie sie zu interpretieren sind. Ohne diese Info ist die PP-Tabelle für Normalbenutzer ohnehin gaga. Von den aktiven Programmierern fürchte ich, dass es allenfalls ein halbes Dutzend systematisch nutzt.
Noch zu 1.: Auf FzW gab es einen m. E. sehr berechtigten Einwand, dass der Abstand zwischen Eingabefenster und Sonderzeichenleiste viel zu groß sei. Entweder man kürzt MediaWiki:Wikimedia-copyrightwarning wirklich drastisch oder man tauscht die beiden Boxen.
Ich habe auf [1] den Code für MediaWiki:Onlyifediting.js aktualisiert und getestet, durch die Änderung kommt die Sonderzeichenleiste über den URV-Warnungskasten, außerdem ist diese CSS-Änderung für die Abstände nötig (Zahlen können auch anders ausgewürfelt werden). Beim Kopieren bitte aufpassen, mir sind beim ersten Versuch ein paar Sonderzeichen (die Spacing Modifier Letters im Türkischen etc.) abhanden gekommen, ob meine Skripte, der CodeEditor, mein Browser oder das Wetter schuld waren, kann ich nicht beurteilen. --Schnark10:48, 31. Aug. 2013 (CEST)
Als ersten Schritt habe ich jetzt mal die Parser-Profiling-Daten ausgeblendet.
Die Sonderzeichenleiste würde nach Schnarks Vorschlag in die graue Box wandern, ich hatte eher daran gedacht, sie wie in der englischen Wikipedia zwischen Bearbeitungsfenster und graue Box zu setzen, allerdings fehlen in diesem Bereich IDs, weil die Elemente unsinnigerweise nur Klassen haben … Würde das trotzdem klappen? Falls nicht, wäre es mir in der grauen Box aber auch recht. --Entlinkt (Diskussion) 10:50, 9. Sep. 2013 (CEST)
Offenbar hat keiner Lust, die Leiste an eine andere Stelle zu schieben (ich auch nicht, ich finde sie dort, wo ich sie hingeschoben habe persönlich besser platziert als direkt unter der Eingabebox). Da das gegenwärtige Skript noch addOnloadHook (absurderweise gleich doppelt) verwendet, und diese Funktion in Kürze im Debug-Modus Warnungen darüber ausgeben wird, dass sie deprecated ist, wäre es schön, wenn das Skript bald aktualisiert würde. --Schnark09:42, 4. Nov. 2013 (CET)
Wer hatte die Position innerhalb des grauen Kastens vorgeschlagen? Sie kommt mir falsch vor. Eigentlich hat der Kasten den Sinn, alles zusammenzufassen, was für das Speichern notwendig ist: Zusammenfassung, ob es eine kleine Änderung ist und ob und wie man die Änderung vorab kontrollieren möchte. Das Einfügen von Zeichen in den Text ist so gesehen keine Funktion, die zu dieser Funktionsgruppe gehört. Die englischsprachige Wikipedia macht es (fast) richtig: Da ist die Zeichenleiste oberhalb des grauen Kastens (allerdings mit einer Lücke nach oben zum Bearbeitungsfenster, eine Lücke nach unten wäre logischer). --TMg21:50, 4. Nov. 2013 (CET)
In en ist die Leiste wesentlich kompakter als bei uns. Ich habe daher die Befürchtung, dass die Leiste direkt unter dem Edit-Feld zu viel Aufmerksamkeit auf sich ziehen würde (so wichtig Typografie auch sein mag, die Zusammenfassungszeile ist wichtiger). Außerdem finde ich persönlich es etwas irritierend, wenn die Leiste zwischen den beiden Eingabefeldern steht, für die sie funktioniert und damit einmal nach oben und einmal nach unten wirkt. Wie dem auch sei, wenn du einen besseren Vorschlag hast, dann lass dir vom Umherirrenden Adminrechte auf http://de.wikipedia.beta.wmflabs.org geben und probiere ihn aus. --Schnark09:23, 5. Nov. 2013 (CET)
Die Zeichen funktionieren in der Zusammenfassungszeile? Mal ganz ehrlich, wie viele Benutzer wissen und nutzen das? Wo sie jetzt ist, mittendrin zwischen der Zusammenfassungszeile, den Optionen und den Buttons, zieht sie genauso viel Aufmerksamkeit auf sich. Daran ändert die Position nicht viel. Ich finde sogar, dass die Leiste dort unverhältnismäßig viel mehr Aufmerksamkeit auf sich zieht, weil die Benutzer beim Abarbeiten der für das Speichern notwendigen Schritte unterbrochen werden. Um zu betonen, dass die Zeichen auch für die Zusammenfassung funktionieren, müsste die Leiste direkt unter der Zusammenfassung sein, über den Optionen (wobei die Positionierung der Zusammenfassungs-Vorschau zu beachten ist, die wahrscheinlich vor der Zeichenleiste bleiben müsste). Als am ehesten erwartungskonform empfinde ich wie gesagt die Position wie im Englischen, oder zur Not wieder unterhalb, einfach nur mit optimierten Abständen. Mehr wollte ich mit meiner ursprünglichen Meldung doch gar nicht erreichen. Was genau du mit „kompakter“ meinst, verstehe ich nicht ganz. Die Leiste ist bei uns genauso nur eine einzelne Zeile wie im Englischen. --TMg16:34, 5. Nov. 2013 (CET)
Vorschlag von TMg
Ich hab mal einen Vorschlag erarbeitet. Im Einzelnen:
Nicht vom kurzen Editfenster irritieren lassen. Das ist nur, um den Screenshot kompakter zu machen.
Zeichenleiste klebt wie die Werkzeugleiste direkt am Editfenster, denn der primäre Zweck von beidem ist, den Inhalt des Editfenster zu beeinflussen.
Innenabstand in der Zeichenleiste von 1px auf .2em (oder 2px) erhöht, damit das Selektionsfeld nicht so mit dem Rahmen verschwimmt.
Rahmen auf silver umgestellt. Das ist minimal heller und konsistenter zu allen anderen Rahmen.
Mit dem Hintergrund habe ich viel experimentiert. In Frage kommen u. a. das Grau vom Kasten darunter oder der blaue Verlauf aus der Werkzeugleiste. Ich bin ganz bewusst bei Weiß geblieben. Die Leiste rückt dadurch angenehm in den Hintergrund und die Betonung bleibt beim viel wichtigeren grauen Kasten. Ein sehr heller Verlauf wäre denkbar, das PNG aus der Werkzeugleiste lässt sich aber nicht 1:1 nutzen, da es eine graue Linie unten hat und nicht dafür gemacht ist, in der Höhe zu wachsen. Die Zeichenleiste bricht viel schneller auf 2 oder gar 3 Zeilen um.
Zwischen Zeichenleiste und dem grauen Kasten ist ein 0.5em-Abstand, um die Trennung zwischen „Bearbeitung“ und „Speichern“ zu betonen. Man könnte auf die Lücke verzichten, aber dann wäre der Editor ein riesengroßer Kasten, in dem die schöne funktionale Gruppierung, die mit der Einführung des grauen Kastens entstanden ist, ziemlich untergeht.
Wie oben schon angedeutet, halte ich es für nebensächlich, dass die Zeichenleiste auch auf die Zusammenfassung wirkt. Die Werkzeugleiste kann das nicht, deswegen rechnet wohl kaum jemand damit, dass die Zeichen das können. Durch eine andere Positionierung könnte man das betonen, ich bewerte die Nachteile aber als schwerwiegender.
Ich selbst habe mir den grauen Kasten übrigens so umgestaltet (roter Kasten weg, Beschriftung „Zusammenfassung“ weg, alle Abstände kompakter) und finde das äußerst angenehm. Das ist natürlich nur etwas für erfahrene Autoren. Für die meisten ist die reguläre Gestaltung des grauen Kastens meiner Meinung nach genau richtig. --TMg18:43, 5. Nov. 2013 (CET)
Wie Benutzer:TMg schon anmerkte und wie es auch mir, trotz absoluter Unkenntnis dieser Geschichte hier auffiel: Die Edittoolleiste hat zwischen den Speicheroptionen (Zusammfassungszeile, Nur Kleinigkeiten wurden verändern, Seite speichern-Butto) nichts zu suchen und stört dort massiv. Es gibt keinerlei Grund, sie nicht unter dem Speichern-Button zu belassen, wo sie vorher war. Offensichtlich ist es nicht ohne weiteres möglich, sich den Urzustand künstlich wiederherstellen zu lassen. Dieser ist wiederum offensichtlich nicht nur von mir erwünscht. @Entlinkt: Bitte verschiebe die Edittoolleiste wieder unter die Buttons Seite speichern etc. wo sie vorher war und bisher anscheinend niemanden gestört hat. Solche Änderungen sind btw. in meinen Augen auch nichts für eine schnelle Nebenbei-Umsetzung, es handelt sich nicht um kosmetische Änderungen, die keinem auffallen. --Paulae20:32, 25. Nov. 2013 (CET)
@Paulae: Es gibt meiner Meinung nach sehr wohl Gründe, die Leiste „nicht unter dem Speichern-Button zu belassen, wo sie vorher war“, und diese sind in diesem Diskussionsabschnitt auch dargelegt (um es kurz zu machen: die Distanz zwischen dem Bearbeitungsfenster und der Leiste ist zu groß und hat sehr wohl zu expliziten Beschwerden und Änderungswünschen auf WP:FzW und sonstwo geführt, insbesondere bei denjenigen, die den riesengroßen rot umrandeten Kasten mit der Copyrightwarnung nicht ausblenden).
Übrigens stand die Leiste auch noch gar nicht so besonders lange dort unten, sondern ist erst durch eine kürzliche Änderung an MediaWiki dorthin gewandert (auch das kann man diesem Abschnitt entnehmen) und die Verschiebung diente dem Zweck, sie wieder etwas näher dorthin wandern zu lassen, wo sie vorher war.
Mir selbst gefällt die Position, an die ich sie verschoben habe, auch sehr viel weniger als das, was TMg jetzt vorschlägt, aber zum Zeitpunkt, als ich sie verschoben habe, gab es TMg Vorschlag nicht, sondern nur einen Vorschlag von Schnark und da hat mich letztlich überzeugt, dass der Vorschlag wochenlang hier stand und niemand ihn abgelehnt oder eine konkrete Alternative vorgeschlagen hat.
Nun denn: Die Leiste ist jetzt wieder unter den Buttons, wo sie vermeintlich vorher schon lange war (tatsächlich allerdings nicht) und vermeintlich niemanden gestört hat (tatsächlich allerdings doch). Vielleicht schaffen wir es ja noch, eine konsensfähige Lösung zu finden; ich werde allerdings zunächst mal keine Zeit dafür haben. --Entlinkt (Diskussion) 02:10, 26. Nov. 2013 (CET)
Also 2008 stand sie offensichtlich bereits unter dem Speichern-Button, und ja, in meinen Augen ist das eine lange Zeit. Wo soll sie denn vor kurzem sonst gewesen sein? Der Unmut kam offenbar durch die Vergrößerung des Abstandes zustande, den man auch einfach hätte verringern können. Und nein, eine MediaWiki-Diskussionsseite über Common.css habe ich (wie sicher viele Benutzer, die hier hauptsächlich Artikel schreiben) nicht auf der Beo. --Paulae10:05, 26. Nov. 2013 (CET)
(Nach BK) Danke, Entlinkt. Ich bin mir allerdings ziemlich sicher, dass die Zeichenleiste auch vor der MediaWiki-Änderung unter den Buttons war (2009, 2013). Hinzu kommt ein weiteres Problem: Die Änderung ließ die Buttons nach unten hüpfen. Beispiel: Es kommt vor, dass ich einen Abschnitt bearbeiten und sofort die Vorschau sehen will (das gibt es auch als Option, die habe ich aber absichtlich nicht aktiviert). Ich klicke also auf „Bearbeiten“, scrolle nach unten und versuche, „Vorschau zeigen“ anzuklicken. In den vergangenen Tagen kam es vor, dass mir der Knopf unter der Maus weg sprang, weil die Leiste alles verschob. Leider wird dieses Problem mit meinem obigen Lösungsvorschlag genauso auftreten, so dass ich mich inzwischen dagegen aussprechen muss. --TMg10:09, 26. Nov. 2013 (CET)
Ich habe mir den Abschnitt hier jetzt zweieinhalb Jahre später tatsächlich noch einmal komplett durchgelesen und bin der Meinung, dass er sich prima dazu eignet, für schlechte Laune zu sorgen, weshalb er dringend ins Archiv wandern sollte.
Davon abgesehen, dass mir damals wohl ein Irrtum bezüglich der Boxenreihenfolge unterlaufen ist, sieht der letzte konkrete Vorschlag (rechts wiederholt) eine Änderung der Boxenreihenfolge vor (die Boxen div.editOptions und div.mw-editTools sind gegenüber dem Status quo vertauscht) und kommt daher – ganz unabhängig von technischen Problemen – nicht wirklich in Betracht, es sei denn, man möchte sich gern die Finger verbrennen.
Letzter Kommentar: vor 8 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Nachdem bei dieser Diskussion keine weiteren Einwände kamen, wollte ich nun an dieser Stelle vorschlagen, CSS-Klassen für die Ausrichtung von Tabellenspalten in die Common.css aufzunehmen.
Zunächst zum Problem: Wenn Text und Zahlen in Tabellen gemischt werden, kommt es relativ häufig vor, dass einige Spalten links, andere zentriert und wieder anderer rechts ausgerichtet werden – hier mal ein Beispiel. Leider ist es momentan erforderlich, diese Ausrichtung für jede Zelle (!) einzeln zu definieren. Man kann zwar die Tabelle als ganzes auch zentriert ausrichten, dann muss aber jede nach links ausgerichtete Zelle wieder eine eigene Style-Anweisung bekommen. Das macht den Quelltext schwer lesbar und die Bearbeitung teilweise extrem mühselig.
CSS bietet das Element nth-child, welches dazu genutzt werden kann, bestimmte Spalten von Tabellen zu formatieren. Beispielsweise würde table.drittespaltezentriert td.nth-child(3) {text-align:center;} eine Klasse bereitstellen, die die dritte Spalte einer Tabelle zentriert, wenn der Tabelle diese Klasse zugewiesen wird. CSS-Klassen für die ersten 10 Spalten sollten die allermeisten Anwendungsfälle abdecken, zur Not gibt es ja immer noch die Möglichkeit, die bisherige Methode zu nutzen.
Alle üblichen Browser unterstützen heutzutage dieses Element, der letzte Internetexplorer, der dies nicht tat, war die Version 8, dessen Marktanteil liegt in Deutschland allerdings nur noch bei 3,2 Prozent, unter dem Strich ist es ohnehin nur ein gestalterisches Mittel.
Hier mal ein wenig Code, wie das ganze praktisch funktioniert:
Die Tabelle sollte nach Aufnahme der neuen Klassen so aussehen, eine Kombination mit wikitable ist problemlos möglich:
Links
Mitte
Rechts
1
2
3
4
5
6
7
8
9
Ich möchte deshalb vorschlagen, Klassen für die Ausrichtung von Spalten in die Common.css aufzunehmen. Als Benennung würde ich s[1-10][lcr] vorschlagen – s für Spalte, dann die Nummer der Spalte auf die sich die Klasse bezieht und schließlich l für links, c für center und r für rechts. Es müssten also folgende Zeilen in die Commons.css aufgenommen werden:
Den Wunsch einzelne HTML-Styles auf ganze Spalten auszudehnen, habe ich schon häufiger mal in der deutschsprachigen Wikipedia gelesen.
Wie sieht die Browserunterstützung deines Vorschlags aus? nth-child wird wohl in älteren IEs nicht funktionieren, daher sollte man es nicht nutzen (nth-child für die zebra-Klasse stellt eine Ausnahme da, weil die Tabelle auch ohne dies noch formattiert aussieht, nur ohne Streifen, aber trotzdem nutzbar. Wenn auf einmal die Zentrierung für Spalten fehlt, ist die Tabelle wohl nicht mehr nutzbar).
Die Notwendigkeit eine (un)begrenzte Anzahl an Regeln vorzuhalten, weil die Tabellen unterschiedlichste Anzahl an Spalten haben können, halte ich nicht für sinnvoll, weil es die CSS-Datei weiter aufbläht. Zusätzlich sind die Klassennamen nicht sprechend, so dass sie vom normalen Bearbeiter nicht verstanden und wohl auch nicht verstanden werden (s1l wird wohl "spalte 1 links" heißen). Später kommen auch noch Wünsche, das eine komplette Spalte in Fett oder kursiv oder verschiedenste Farben dargestellt werden sollte. Aus meiner Sicht bringt das kein großen Nutzen und man sollte hier weiterhin die Inline-Styles nutzen. Der Umherirrende20:41, 12. Mär. 2014 (CET)
Danke für die Antwort. Zu den Punkten im Einzelnen:
Browserunterstützung: Wie oben geschrieben, ab dem IE 9 funktioniert es. Der Marktanteil des IE≤8 liegt nur noch bei 3,5 Prozent. Grundsätzlich sind die Tabellen auch weiter nutzbar, wenn die Ausrichtung nicht stimmt, sie sehen nur (wie bei Zebra) nicht mehr so schick aus. Ich glaube, fehlende Zebras sind, wenn Zebra Sinn hat, viel schlimmer als die Ausrichtung.
Anzahl Regeln: Ich sehe das Problem des Aufblähens der CSS Datei, allerdings nicht ganz, was daran allzu schlimm ist. Die wird doch eh nur alle paar Wochen mal neu geladen und das bisschen sollte auch keine wesentlichen Performanceprobleme in der Auswertung geben.
Sprechende Namen: Diese wiederum blähen den Quelltext in den Artikeln ein wenig auf, erleichtern aber die Benutzung für neue Nutzer sehr. Kann ich mich auch mit anfreunden.
Induktion weiterer Wünsche: Naja, nur weil dadurch neue unsinnige Begehrlichkeiten entstehen, brauchen ja nicht sinnvolle Dinge pauschal abgelehnt werden. Jedes Programm, das mit Tabellen umgeht, führt so ziemlich als erstes die Ausrichtung ein, sei es nun Excel, GoogleDocs oder LaTeX. Bei letzterem ist die Spaltenausrichtung auch eine der ganz wenigen Dinge, die überhaupt als direkte Formatierung unterstützt werden – weil sie halt recht unverzichtbar in Tabellen ist. Wenn Du Dir mal die händischen Formatierungen von Spalten hier in der Wikipedia anguckst, wirst Du auch feststellen, dass die Ausrichtung den mit weitem Abstand größten Anteil hat.
Technischer Hinweis: In CSS ist es zurzeit nicht möglich, spaltenübergreifende Zellen (HTML-Attribut colspan) korrekt zu behandeln. Der Selektor td:nth-child(X) ist dafür nicht geeignet. Veranschaulichung:
CSS zählt einfach stupide von links nach rechts, wodurch man eine komplett durcheinandergewürfelte Formatierung erhält, wenn man td:nth-child(X) als „Approximation“ für die Spaltennummer nimmt.
In CSS 4 ist ein Selektor :nth-column(X)vorgesehen, der dieses Problem lösen würde, aber meines Wissens noch in keinem einzigen Browser implementiert ist. Da in die Common.css eigentlich nur 100%-ig einwandfrei funktionierende Dinge gehören, scheidet der Vorschlag meiner Meinung nach aus (von den anderen Gegenargumenten abgesehen). Gruß --Entlinkt (Diskussion) 22:32, 3. Jun. 2014 (CEST)
Ich stimme völlig zu, CSS4 noch nicht zu verwenden. Ich kann aber beim besten Willen nicht die Argumentation hier nachvollziehen. Tabellen mit kompliziert zusammengefassten Zellen sind eher die Ausnahme und werden nur von ziemlich erfahrenen Benutzern angelegt. Es geht doch darum, die ganzen großen Tabellen besser wartbar zu machen, beispielsweise jene, die sich in den Listenartikeln befinden. Ich verstehe auch beim Besten Willen nicht, wo das Problem in einem „Aufblähen“ der Common.css liegt. Da ist ein riesiger Abschnitt nur für Taxoboxen drin, da ist die Unterstützung für das uralte prettytable-Zeug noch drin, aber etwas, was auf absehbare Zeit den Quelltext sehr vieler Seiten verschlanken und Daten leichter wartbar machen würde, darf nicht rein... Naja, ich sehe aber ein, dass ich zumindest jene, die diese Seite sowie die Hilfeseite zu den Tabellen frequentieren, anscheinend nicht überzeugen kann. Mal schauen, falls ich mal Zeit und Lust habe, würde ich es halt mal per Meinungsbild probieren. Bis dahin aber erstmal danke für die Antworten... --Sepp (Diskussion) 13:52, 4. Jun. 2014 (CEST)
Das Anliegen ist klar, aber der Umsetzungsvorschlag ist mir – sorry – mit zu vielen Fragwürdigkeiten behaftet und ein besserer derzeit nicht in Sicht. Unabhängig vom hier konkret besprochenen Problem ist der Ansatz „Lösung eines Problems durch Definition neuer Klassen in MediaWiki:Common.css“ schon fast ein Auslaufmodell. Beim konkreten Vorschlag stören mich die Anzahl notwendiger Klassen und die stark eingeschränkte Kombinierbarkeit mit verschmolzenen Zellen. Ganz ehrlich, ich hätte ein Problem damit, die Klassen auf einer Hilfeseite zu dokumentieren und dazuzuschreiben, wann sie nicht funktionieren und anschließend weiter die Position zu vertreten, dass nur einwandfrei Funktionierendes in die Datei MediaWiki:Common.css aufgenommen werden darf.
Daraus, dass bereits andere fragwürdige Abschnitte in der Datei vorhanden sind, kann nicht abgeleitet werden, dass neue fragwürdige Abschnitte einzufügen sind. Gruß --Entlinkt (Diskussion) 20:13, 27. Mär. 2016 (CEST)
Letzter Kommentar: vor 8 Jahren10 Kommentare5 Personen sind an der Diskussion beteiligt
Hallo! Ich wollte hier mal kurz nachfragen: Wäre es möglich, die Definition der Zebra-Klasse so zu ändern, dass die Hintergrundfarbe(n) durch entsprechende Angaben im Quelltext frei veränderbar ist/sind? Und (zweite Frage): Wäre der Widerstand dagegen groß? Andernfalls könnte ich mir auch vorstellen, dass eine begrenzte Auswahl von unterschiedlichen Farbschemata vorgegeben würde. Wie auch immer, soll nur mal eine Tuchfühlung sein! Grüße, --XanonymusX (Diskussion) 21:32, 9. Mär. 2015 (CET)
Die Zebra-Klasse muss eine der beiden Hintergrundfarbe festlegen, da per Inline-CSS nur eine Hintergrundfarbe angegeben werden kann. Zusätzliche Klassen mit unterschiedlichen Farben halte ich für nicht sinnvoll. --Fomafix (Diskussion) 21:37, 9. Mär. 2015 (CET)
Ich verstehe natürlich, dass es ein Fass ohne Boden wäre, für jede erdenkliche Farbkombination, die für bestimmte Tabellen „gebraucht“ wird, eine eigene Klasse zu definieren. Da diese Funktion aber leider auch nicht durch irgendwelche komplizierten Vorlagen zu ersetzen ist, soweit ich weiß, sehe ich hier keine angemessene Lösungsmöglichkeit: Eine Tabelle, die zwischen zwei Farben abwechselt, unter denen nicht Weiß ist, wirft beim Sortieren Probleme auf, da die Farben natürlich starr an den Zeilen verankert sind. Konkreter Fall: Vorlage:Charttabelle. Die dortigen Farben sind inzwischen etabliert und weit verbreitet (wenn auch noch nicht als Vorlage, sondern nur als gewöhnliche Tabelle); statt Weiß wäre dort {{Farbfeld|#eeeeee}} notwendig. Mit einer Klasse ZebraGrey oder so ähnlich könnte dort sortiert werden, ohne zusammenhangslose Farbblöcke zu erzeugen, und die Vorlage würde natürlich auch vereinfacht. Mir scheint, dass dieser Farbton nicht unbedingt ein als „problematisch“ einzustufender wäre …
Noch eine Frage in diesem Zusammenhang: Wie ich sehe, ist Zebra für even definiert. Gäbe es da eine Möglichkeit, das auf odd umzumünzen, wenn einmal schon die erste Zeile weiß sein sollte (durch irgendeine Umgehungslösung im Quelltext)? Grüße, XanonymusX (Diskussion) 23:21, 9. Mär. 2015 (CET)
Ich teile die Auffassung von Fomafix, dass hier zusätzliche Farben über reinweiß hinaus nicht sinnvoll sind.
Wir versuchen, die Common.css bewusst schlank, effizient, schnörkellos und schnell zu halten.
Unser CSS-Admin ist leider momentan inaktiv, aber er wäre sicher nicht begeistert und bemüht sich im Gegenteil um den Rückbau nicht mehr notwendiger Klassen.
Der Unterschied zwischen reinweiß und dem gewünschten shade of white ist nicht so dramatisch und bringt die Leser auch nicht weiter.
Wir setzen Farben dann ein, wenn sie bedeutungsunterstützend sind; etwa grün für ja und rot für nein. Oder zwei gut unterscheidbare Hintergrundfarben wie in diesem Fall, aber dazu genügt reinweiß.
Kann ich alles nachvollziehen. Aber dass im Web (und sei es in der WP) Farben nur „bedeutungsunterstützend“ eingesetzt werden, ist faktisch nicht gegeben; vor allem bei Vorlagen zählt Design nun einmal auch. Wie dem auch sei, ließe sich denn mittels Lua ein Workaround basteln (ob das sinnvoll ist, lassen wir mal dahingestellt)?--XanonymusX (Diskussion) 21:59, 19. Mär. 2015 (CET)
CSS ist schon das richtige Stilmittel für Design. Nur ist eine zentrale Datei, die in allen Seiten geladen wird und statischen Inhalt hat, nicht der richtige Weg. CSS könnte sinnvoll eingesetzt werden, wenn die Definitionen seitenindividuell gesteuert werden könnten. Damit so etwas möglich ist, benötigt es eine Erweiterung. Es gibt bereits Erweiterungen wie mw:Extension:CSS und andere Erweiterungen. Vermutlich haben die Erweiterungen aber noch Probleme und negative Effekte. --Fomafix (Diskussion) 22:36, 19. Mär. 2015 (CET)
Der Diskussionsverlauf geht hier recht klar in Richtung Ablehnung des Vorschlags.
Da zum konkreten Vorschlag selbst meiner Meinung nach genug gesagt wurde, erlaube ich mir folgende Off-topic-Äußerungen zur Etablierung neuer Formatierungsklassen im Allgemeinen:
Die Tatsache, dass die zebra-Klasse in Vorlage:Erweiterte Navigationsleiste (aber mit Sicherheit nicht nur dort) mit einer unsichtbaren zusätzlichen Zeile (!) benutzt wird, um die Farbenfolge zu invertieren, zusammen mit ausgiebigem Inline-CSS, das fast alle Wirkungen der wikitable-Klasse wieder aufhebt (!), ist ein wunderbares Beispiel dafür, wie kreativ solche Möglichkeiten „missbraucht“ (in nicht vorgesehener Art und Weise benutzt) werden. Ein anderes, aber vergleichbares Beispiel hierfür haben wir im Abschnitt #nogrid. Das ist ein Problem, weil am Ende die „missbräuchlichen“ (so nicht vorgesehenen) Verwendungen vorgeben, dass man auch für die eigentlich vorgesehenen Verwendungen später nichts mehr ändern kann. Ein weiteres Problem ist, dass jede (naja, nicht jede, aber erfahrungsgemäß „fast jede“) derartige Klasse früher oder später den Ruf nach weiteren, analog definierten Klassen nach sich zieht.
Letzter Kommentar: vor 8 Jahren12 Kommentare3 Personen sind an der Diskussion beteiligt
Ab Firefox 40 haben abbr-Elemente eine doppelte Unterstreichung beim drüberfahren: abbr (Hier mit Inlinestyle für das Archiv abbr).
Mit phab:T107560 und den Änderungen gerrit:229331 und gerrit:230308 in MediaWiki wird dieses Problem behoben. Diese Änderungen kommen hier erst mit Version 1.26wmf18 am Donnerstag.
Durch die zusätzliche Farb-Änderung wird hier das Problem weiter bestehen. Korrigiert werden kann das indem die bisherige Definition
/* Unterstrichelung für Abkürzungen */abbr[title],.explain[title]{border-bottom-color:#ccc;/* IE 7–8 */}abbr[title],.explain[title]{border-bottom-color:rgba(50%,50%,50%,.5);}abbr[title]:hover,.explain[title]:hover{border-bottom:1pxdotted;}
Was für ein Zufall, ich bin just in diesem Moment beim Testen.
Das vorletzte border-bottom: none ist unnötig, ich werde es weglassen und ansonsten alles übernehmen. Die Bedingung in der @supports-Regel ist streng genommen nicht konsistent, aber wenn man davon ausgeht, dass jeder Browser text-decoration-color genau dann unterstützt, wenn er text-decoration: underline dotted unterstützt, wird es funktionieren. --Entlinkt (Diskussion) 13:07, 4. Mär. 2016 (CET)
MediaWiki meldet beim Abspeichern der @supports-Regel mittels Popup, das extra bestätigt werden muss, einen angeblichen Fehler. Funktionieren tut es nach dem Abspeichern aber anscheinend trotzdem.
Vermutlich hat sich deswegen bisher niemand getraut. Möglicherweise kommt das Popup jetzt bei jedem künftigen Edit, sollte uns aber egal sein. --Entlinkt (Diskussion) 13:19, 4. Mär. 2016 (CET)
Ich habe den angeblichen Syntaxfehler im Quelltext (mit der Ticketnummer) kommentiert, damit andere Bearbeiter sich nicht unnötig wundern. Ich denke, damit ist der Abschnitt erledigt.
Die gesamte Regelsammlung ist übrigens nur deshalb so kompliziert geschrieben, damit sie zumindest teilweise auch im IE 7 und 8 funktioniert. Ohne Unterstützung für diese stark angestaubten Browser könnte man das Ganze auch zu
Diese Vereinfachung kann meiner Meinung nach umgesetzt werden. MediaWiki unterstützt den IE8 nur noch als Grade C. Dabei gilt: „In the front-end this means content is presented in a readable manner, and to some extent user actions can be performed.“ Eine leicht unterschiedliche Farbe der Unterpünktelung ist sicherlich weiterhin eine lesbare Form. --Fomafix (Diskussion) 08:09, 28. Mär. 2016 (CEST)
Danke. Vielleicht sollten die beiden Zeilen noch mit Kommentaren mit den entsprechenden Browser-Versionen versehen werden, damit das später mal zugeordnet werden kann. --Fomafix (Diskussion) 18:28, 28. Mär. 2016 (CEST)
Wie wäre dein Vorschlag? Momentan wirkt text-decoration-color ja nur in Firefox ≥ 36, aber durch den Code in shared.css werden alle anderen automatisch darauf wechseln, sobald sie es unterstützen. Wie wäre es mit:
abbr[title]:not(:hover),.explain[title]:not(:hover){border-bottom-color:rgba(50%,50%,50%,.5);/* März 2016: Alle außer Firefox */text-decoration-color:rgba(50%,50%,50%,.5);/* Firefox >= 36 */}
Letzter Kommentar: vor 8 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Es ist ja in der letzten Zeit schon sehr viel übersichtlicher geworden.
Kürzlich hatte ich auf einer verwandten Disku bereits einen Vorschlag gemacht, den ich nun hierher kopiere:
Alle FR auf einem Haufen
Alle table auf einem Haufen
Alle TOC auf einem Haufen
Lose Einzelregeln bündeln:
/* Diverse Ausblendungen * #***-icon etc., .topicon * Skinabhängige absolute Positionierungen * [[MediaWiki Diskussion:Common.css/Archiv/1#Absolute Positionierungen]] * .patrollink * Eweiterung ist hier nicht aktiviert * Optik ähnelt zu sehr den gesichteten Versionen * .mw-special-Watchlist .mw-rollback-link * Rollback-Knopf auf Beobachtungsliste * dort nur von sehr beschränktem Nutzen * führt zu sehr vielen Reverts aus Versehen * .geo * [[Vorlage:Coordinate]] * "geo-microformat" zur semantischen Auszeichnung des Texts * Inhalt dieses Tags ist nicht für den Leser bestimmt * .limitreport * [[Hilfe:Vorlagenbeschränkungen|Parser-Profiling-Daten]] * .client-js .noscript * <noscript>-Emulation via <div class="noscript"></div> */#commons-icon,#coordinates,#editcount,#issnlink,#shortcut,#spoken-icon,.topicon,.patrollink,.mw-special-Watchlist.mw-rollback-link,.geo,.limitreport,.client-js.noscript{display:none;}
FlaggedRevs sieht alles nach einem Haufen aus (steht alles hintereinander)
table ist (jetzt) auch alles beieinander
Toch ist (jetzt) auch alles beieinander
Von einzelregeln bündeln halte ich nicht viel, weil es die Wartbarkeit erschwert. Keiner ließt oder updated ein Kommentar der zeilenwert entfernt steht.
Die einzelnen float-left-Regeln könnten zur Erhöhung der Spezifikation dort sein, aber dann dürfte der letzte Eintrag keine Auswirkung mehr haben. Hier müsste man eventuell mal suchen, ob sie mit einem bestimmten Bearbeitungskommentar hinzugefügt wurden. Eventuell sollten sie nur übergangsweise enthalten sein.
Aus dem Ursprungsposting sind dann wohl alle Punkte außer dem letzten („Einzelregeln bündeln“) erledigt, dieser begeistert mich auch nicht so sehr. Die absolut positionierten Teile sollten meiner Meinung nach auf alle Fälle von allem anderen getrennt bleiben (diese Teile sind technisch kompletter Blödsinn und sollten klar als „Provisorium“ erkennbar bleiben, auch wenn es ein recht langlebiges Provisorium ist); was danach übrig bleibt, kann man zusammenfassen oder auch nicht, mir isses egal, vielleicht fasse ich irgendwann einmal ein bisschen was zusammen.
sind allerdings per se überhaupt kein Schwachsinn: Sie können zwar manchmal Schwachsinn sein, ebensogut können sie aber auch notwendig sein. Das ohne Dokumentation herauszubekommen, ist zeitaufwendige Recherchearbeit, weshalb es wohl niemand macht. Für die Klasse float-right werde ich das jetzt mal versuchen, aber für weitere erst mal nicht. --Entlinkt (Diskussion) 04:23, 28. Mär. 2016 (CEST)
Aus diesem Edit, vorgenommen aufgrund dieser Anfrage (beides 2009), folgt:
Der Selektor .float-right ist geblieben, weil <span class="float-right"> vorher möglich war und möglich bleiben muss, es sei denn, man kann triftig begründen, weshalb nicht.
Der Selektor table.float-right wurde eingefügt, weil <table class="wikitable float-right"> sonst nicht richtig funktionieren würde (falsche Außenabstände), da wikitable in shared.css mit dem Selektor table.wikitable definiert ist.
Weshalb der Selektor div.float-right damals eingefügt wurde, ist mir nicht klar, man kann ihn aber heute für <div class="NavFrame float-right"> verwenden, was ohne ihn nicht gehen würde (falsche Außenabstände), weshalb er bleiben muss, da in der Zwischenzeit derartige Verwendungen entstanden sein könnten. Außerdem ist der Selektor durchaus konsistent mit der Definition der MediaWiki-eigenen Klasse floatright (ohne Bindestrich). Für die Konsistenz sehe ich zwar keinen wirklichen Grund, aber auch keinen Grund dagegen.
Aus diesem Edit, vorgenommen aufgrund dieser Anfrage (beides 2011), folgt:
Der Selektor ul.float-right wurde eingefügt, um <gallery class="float-right"> zu ermöglichen. Ohne den Selektor würde es nicht gehen (falsche Außenabstände), weil Galerien irgendwo mit dem Selektor ul.gallery definiert sind.
Man könnte die Selektorensammlung dieser Regel wahrscheinlich durch html .float-right oder Ähnliches ersetzen, dies verändert allerdings die Semantik und es ist nicht so recht klar, warum man das riskieren sollte; außerdem entstünde möglicherweise die Gefahr, dass dann jemand das html in der irrigen Annahme entfernt, es wäre unnötig. Dies hätte die Zerstörung der meisten Infoboxen zur Folge.
Diese Recherchearbeit hat jetzt keinen unmittelbaren Nutzen, aber vielleicht wird ja dadurch klarer, weshalb das CSS so ist, wie es ist und weshalb es mit den Vorschlägen manchmal ein bisschen länger dauert. Außerdem ist es ein schönes Lehrstück dafür, weshalb idealerweise jeder sein CSS so schreiben würde, dass die Spezifität der Selektoren so niedrig wie möglich ist („nicht unnötig das Überschreiben erschweren“). Aus genau diesem Grund meckert der CodeEditor übrigens manche Selektoren der Form Element.Klasse als overqualified an und fordert dazu auf, nur .Klasse zu verwenden. Leider muss man bei der Wahl der Selektoren aber gleichzeitig aufpassen, dass man nicht versehentlich zu viel selektiert (was in einem Wiki schnell passiert ist), und diese beiden Dinge wirken – kaum vermeidbar – gegeneinander.
Letzter Kommentar: vor 8 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Eine unserer lokalen Kleinstverbesserungen funktioniert seit dem Typografie-Update von 2014 nicht mehr im Vector-Skin (und hat in Cologneblue nie funktioniert). Es geht um folgende Regel, eingefügt aufgrund dieser Anfrage von 2010:
tablep,tableul{margin-top:.3em;}
Die Regel sollte dafür sorgen, dass Text und Listen in Tabellen auf gleicher Höhe anfangen und war vermutlich maßgeschneidert für bestimmte Infoboxen. Sie ergibt überhaupt nur zusammen mit style="vertical-align:top" bzw. class="toptextcells" Sinn, weil Tabellenzellen sonst standardmäßig vertikal zentriert sind. In Vector und Cologneblue funktioniert sie aber wegen der Selektorenspezifität dann trotzdem nicht. Die folgenden Beispiele illustrieren den Effekt (aus Vereinfachungsgründen ist die letzte Spalte nur für Monobook):
So sieht es derzeit aus
So sähe es aus, wenn die Regel funktionieren würde
So sähe es in Monobook aus, wenn die Regel entfernt wird
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Ich bin der Meinung, dass wir die Regel entfernen sollten, da
sie von Anfang an nicht korrekt für alle Skins formuliert wurde,
sie nur einen sehr kleinen Anwendungsbereich hat,
der sichtbare Effekt sehr klein ist,
sie im Standardskin (insbesondere für alle unangemeldeten Leser) seit 2 Jahren nicht mehr funktioniert und dies meines Wissens nie irgendwo als „Darstellungsfehler“ gemeldet wurde (→ Indiz dafür, dass sie nicht gebraucht wird).
Sollten sich tatsächlich Monobook-Benutzer über die Entfernung beschweren, kann man es ja immer noch in monobook.css aufnehmen. Aber in der common.css sollte es aus den genannten Gründen entfernt werden. --Schnark09:17, 21. Apr. 2016 (CEST)
In Monobook sitzt die erste Zeile der linken Spalte jetzt um 1 Pixel tiefer als die erste Zeile der rechten Spalte
Zeile 1 Zeile 2 Zeile 3 Zeile 4 Zeile 5
Zeile 1
Zeile 2
Zeile 3
Zeile 4
Zeile 5
Ich habe die eingangs angesprochene Regel jetzt entfernt, darüber hinaus aber auch folgendes:
Die Ausblendung der Klasse geo. Diese Ausblendung (eingefügt 2008 aufgrund dieser Anfrage) war schon immer falsch und wurde nur deshalb begehrt, weil die Spezifikation des Geo-Mikroformats bei der Programmierung der Vorlage:Coordinate missverstanden wurde. Die zugehörige Vorlagenprogrammierung ist weiterhin falsch und ich werde das auch nicht beheben, habe es aber unter Vorlage:CoordinateComplex#Mikroformat dokumentiert.
Ein explizites text-align:left in der Taxoboxendefinition. Das ist in Regelfällen unnötig, könnte in Grenzfällen theoretisch einen marginalen Nutzen haben (zum Beispiel dann, wenn ein Benutzer Blocksatz für das gesamte Dokument eingestellt hat), wäre aber in der Praxis auch in diesem Fall nutzlos, weil die Tabelle in der Vorlage:Taxobox weitere Zellen ohne explizites text-align:left besitzt.
@Atamari: Es ging um das, was in der Tabelle auf der rechten Seite zu sehen ist. Bevor ich die Regel entfernt habe, waren die ersten Zeilen der beiden Spalten in Monobook (aber nicht Vector) auf gleicher Höhe, jetzt ist die linke Spalte (in Monobook) um 1 Pixel tiefer. Dass mit der Regel eine Verbesserung intendiert war, ist klar, aber sie war so marginal und klappte schon bei der zweiten Zeile nicht mehr, da auch die Abstände zwischen den Zeilen verschieden sind. Gruß --Entlinkt (Diskussion) 23:18, 21. Apr. 2016 (CEST)
Zweck: Auf Special:Upload werden ganz weit unten (in dem Formular „Dateibeschreibung“ zwischen dem Dropdown-Menü „Lizenz“ und dem Link „Lizenzoptionen bearbeiten“) Warnmeldungen unter anderem aus den Systemnachrichten MediaWiki:Fileexists und MediaWiki:Filename-bad-prefix angezeigt, wenn man eine bereits vorhandene Datei nochmals hochlädt oder einen gemäß MediaWiki:Filename-prefix-blacklist unerwünschten Dateinamen verwendet. Durch die Regel sollte ein dünner roter Rahmen um die Warnmeldung herum gezeichnet werden. Beispiel:
Eine Datei mit diesem Namen ist bereits vorhanden. […]
Die Edits hier und dort legen die Vermutung nahe, dass das Ganze damals auch funktioniert hat. Derzeit funktioniert es leider nicht, weil sich irgendwann einmal das Markup geändert haben muss, d. h. die Warnmeldungen erscheinen ohne jede Hervorhebung. Da ich die Hervorhebung in diesem Fall durchaus sinnvoll finde, würde ich die Regel reparieren. Die Änderung beim padding soll dazu dienen, dass die Abstände auf allen vier Seiten ungefähr gleich sind, da die Warnungen in <p>-Elemente verpackt sind, die bekanntlich selbst Abstände nach oben und unten haben. Die konkret vorgeschlagenen Werte sind für Vector optimiert (in Vector gilt .mw-bodyp{margin:0.5em0;}), das Ergebnis sieht aber meiner Meinung nach in allen Skins brauchbar aus.
Da die Regel derzeit nicht funktioniert, gäbe es natürlich auch die Alternative, sie zu entfernen. In diesem Fall wäre es interessant zu wissen, seit wann sie nicht mehr funktioniert. Ich habe versucht, das herauszufinden, es ist mir aber nicht gelungen. Das betroffene Markup wird durch das Skript mediawiki.special.upload.js erzeugt. --Entlinkt (Diskussion) 00:13, 22. Apr. 2016 (CEST)
Wäre es nicht sinnvoller, diese Regel direkt in MediaWiki aufzunehmen? Ich finde übrigens auch nicht heraus, wann der Code so geändert wurde, dass das CSS nicht mehr wirkt, die mehrfachen Umbenennungen und Verschiebungen machen es nicht gerade leicht, die Änderungen nachzuverfolgen. --Schnark09:31, 22. Apr. 2016 (CEST)
@Umherirrender: Vielen Dank, genau das habe ich gesucht.
@Schnark: Ja, es kann gut sein, dass das sinnvoller wäre, aber mir persönlich wäre es den Aufwand wahrscheinlich nicht wert. Dann vielleicht doch eher löschen mit der Begründung „6 Jahre defekt und keiner hat’s gemerkt“.
Wenn MediaWiki:Onlyifuploading.js ein hidden-Gadget wäre, was vorgeschlagen wird und für mich erstmal sinnvoll klingt, gäbe es wohl auch noch die Möglichkeit, die Regel in eine dortige CSS-Komponente zu verschieben. Sie bezieht sich zwar nicht auf den dortigen JavaScript-Code, passt aber zum Szenario „Onlyifuploading“ und würde dann nicht mehr auf jeder Seite mitgeladen werden, sondern nur dort, wo sie gebraucht wird. --Entlinkt (Diskussion) 17:55, 23. Apr. 2016 (CEST)
Danke für die Rückfrage Umherirrender, ich persönlich brauche das nicht mehr, da ich mittlerweile direkt aus LightRoom oder dem UploadWizard hochlade. Damals war mir aufgefallen, dass die Warnmeldungen nicht präsent genug waren. Insofern wäre es nicht schlecht, wenn das wieder aktiviert werden könnte. Andererseits: wie oft wird Spezial:Hochladen noch verwendet? Lohnt es sich also? — RaymondDisk.22:11, 24. Apr. 2016 (CEST)
Änderungsvorschlag: Entfernen der Regel für Wikidata-Edits auf der Beobachtungsliste
Letzter Kommentar: vor 8 Jahren31 Kommentare6 Personen sind an der Diskussion beteiligt
Ich schlage vor, die folgende Regel zu entfernen:
li.wikibase-edit.plainlinks{color:#36b;}
Eingefügt wurde die Regel erst im Februar dieses Jahres durch Leyo nach dieser Diskussion. Sie besteht aus einem Teil eines Codevorschlags von TMg, der hierzu unter anderem folgendes sagte: „Die Farbe allein bringt wirklich fast gar nichts. […] Ist nicht ganz ausgereift […]“. Umgesetzt wurde sie dann, nachdem längere Zeit niemand widersprochen hatte, was aber auch daran liegen kann, dass es Zeit kostet, einen fundierten Widerspruch zu formulieren.
Wahrscheinlich wird mit der Regel bezweckt, dass Wikidata-Links auf der Beobachtungsliste wie externe Links gefärbt sein sollen. Ohne die Regel wären sie wie interne Links gefärbt. Ich habe auf der Vorderseite bereits dokumentiert, dass die gewählte Farbe für den Cologneblue-Skin nicht passt. Das ist nicht besonders gut, da die umseitige CSS-Datei für alle Skins gilt, ich werde aber angesichts der vermutlich geringen Zahl der Benutzer dieses Skins nicht weiter darauf eingehen. Auch nicht auf den Modern-Skin, der vermutlich etwas mehr, aber immer noch wenige Benutzer hat.
Für die Skins Vector und Monobook sind die Linkfarben MediaWiki-seitig in der Datei mediawiki.skinning/elements.css festgelegt. Dabei wird von sogenannten Pseudoklassen Gebrauch gemacht. MediaWiki verwendet im Zusammenhang mit der Linkfarbe nur die Pseudoklassen :visited (für einen besuchten Link) und :active (für einen aktiven Link, zum Beispiel während des Anklickens).
Durch Auswerten dieser Datei, ersatzweise auch durch Trial & Error kann man herausbekommen, dass für die folgenden Linktypen in Monobook und Vector die folgenden Linkfarben gelten:
Pseudoklasse
Interner Link oder Wikidata-Link auf der Beobachtungsliste ohne unsere Änderung
Interwiki-Link oder externer Link
Wikidata-Link auf der Beobachtungsliste mit unserer Änderung
Lange Rede, kurzer Sinn: Die Regel bewirkt, dass die dynamischen Effekte bei Wikidata-Links auf der Beobachtungsliste abgeschaltet werden und ein Zustand entsteht, der weder internen noch externen Links entspricht. Zwar ließe sich dieses Manko beheben, indem wir den gesamten Linkfarben-Code von MediaWiki lokal replizieren – und zwar einzeln für jeden Skin – aber ich denke nicht, dass wir diesen Weg gehen sollten, da es den Code bei IMHO recht geringem Nutzen stark aufblähen und dezentralisieren würde (der bisher und hoffentlich dauerhaft einzige Präzedenzfall für dieses Vorgehen sind die absolut positionierten Elemente).
Vielmehr sollte schlicht und einfach im HTML-Code ein passender Klassenname (wahrscheinlich external oder noch besser extiw) eingefügt werden, wie es in phab:T52893 sogar gesagt wurde. Mit anderen Worten: Die Lösung ist nicht nur derzeit falsch implementiert, sondern geschieht auch an einer grundsätzlichen falschen Stelle.
Für Leyo selbst würde sich durch das Entfernen nichts ändern, da die Regel auch in Benutzer:Leyo/monobook.css enthalten ist.
Ach so, falls sich jemand fragt, ob noch viel mehr Änderungsvorschläge von mir kommen: Nein, erstmal nicht, ich versuche nur gerade, die Datei wenigstens einmal annähernd frei von Defekten zu bekommen; dies ist für den Moment das Letzte, was ich als „Defekt“ ansehe.
Ich war ja schon damals dagegen (und persönlich ist es mir vollkommen egal, da ich dank phab:T46874 noch immer keine Wikidata-Änderungen auf der Beobachtungsliste sehe). Da Wikidata-Bearbeitungen durch ein D markiert werden, war das ursprüngliche Argument der Hervorhebung ja keines mehr, sodass nur die „Vereinheitlichung“ der Linkfarben der Grund für die Änderung sein kann. Da Links auf Schwesterprojekte ohnehin manchmal externe Links, manchmal extiw-Links sind, bringt eine Änderung egal welcher Art an dieser Stelle keine Vereinheitlichung, sodass auch dieses Argument hinfällig ist.
Dass dabei aber die Unterscheidung zwischen besuchten und unbesuchten Links verloren geht, ist ein echter Fehler und rechtfertigt allein schon einen Revert.
Frage am Rande: Kann man in Firefox in den Entwicklerwergzeugen irgendwie auf die Stile für :visited zugreifen? Ich schaffe es nur für :hover, :active und :focus. --Schnark10:34, 25. Apr. 2016 (CEST)
OT@Schnark:
Klingt so, als ob du getCSSStyleRules() anwenden würdest.
Dies filtert die visited vermutlich als zusätzliche Hürde aus; nicht nur, dass die tatsächliche style-Eigenschaft des momentanen Links nicht verraten wird, sondern auch der Vergleich zwischen dem :link und dem :visited soll dem JS unmöglich gemacht werden. getComputedStyle() soll immer nur den Stil für :link zurückgeben.
Hintergrund beispielsweise: CSS2 (Ende des Abschnitts, grün und folgend)
Das dürfte so tief im Kern implementiert sein, dass alle lokalen Werkzeuge auch nicht mehr rankommen. Nach dem Rendern existiert einfach kein visited-Stil mehr.
inIDOMUtils erwähnt genau die von dir aufgezählten und visited nicht, und die Werkzeugkiste ist auch nur aus diesen Bibliotheken zusammengebaut.
Ich bin schon der Meinung, dass hier wirklich ein Bug vorliegt, der aber nicht durch uns gefixt werden sollte.
Der PHP-Code aus phab:diffusion/EWBA/ erzeugt massenhaft das Konstrukt <a class="plainlinks">. Ich erhalte Treffer für die Zeichenkette plainlinks unter anderem in den folgenden Dateien:
Die Klasse plainlinks hat aber die folgende Definition (Quellenangabe):
/* Plainlinks - this can be used to switch * off special external link styling */.plainlinksa.external{background:none!important;padding:0!important;}
Aufgrund der Definition ist klar, dass die Klasse in dem Konstrukt <a class="plainlinks"> keine Wirkung entfalten kann. Es ist daher davon auszugehen, dass der PHP-Programmierer etwas anderes meinte als das, was er wirklich programmiert hat – vermutlich <a class="extiw">. Dies würde zu dem von Leyo gewünschten Aussehen führen.
Ich denke daher, dass phab:T52893 fälschlich geschlossen wurde, da das Problem möglicherweise nicht richtig verstanden wurde. Die Frage für uns ist aber, ob wir lokal einen Workaround haben wollen. Und dazu meine ich, dass wir das in diesem Fall nicht tun sollten, da der jetzt vorliegende Workaround nicht korrekt ist, ein wirklich korrekter Workaround sehr viel komplizierter wäre als ein Fix an der richtigen Stelle und der visuelle Unterschied sowieso nur sehr gering ist, so dass es den Aufwand nicht lohnt. (Nebenbei bemerkt ist es noch so eine Macke an unserem Workaround, dass er an dem <a class="plainlinks"> ansetzt, was überhaupt nicht im HTML-Code stehen sollte.)
Ich halte es für viel konsistenter, wenn der Link auf Wikidata in der Beobachtungsliste die normale Linkfarbe (#0645ad in Vector) hat. Wenn man argumentiert, dass er die Klasse extiw mit deren Farbe (oder alternativ die von externen Links) haben sollte, was ist dann mit dem Link auf das Wikidata-Objekt in der Seitenleiste? Mit den Links auf Schwesterprojekte und andere Sprachen in der Seitenleiste? Mit den Links im Footer? Mit den Diff-Links in der Versionsgeschichte und sonstwo (die ja im normalen Text die Farbe externer Links haben)? Am konsistentesten ist daher die Feststellung, dass Interface-Links (im Gegensatz zu Links in benutzergeneriertem Inhalt) immer die gleiche Farbe (in Vector eben #0645ad) haben, egal auf welches Wiki sie verweisen. --Schnark09:25, 26. Apr. 2016 (CEST)
Für mich ist es unverhandelbar, dass für OMA die Links auf Wikidata (und andere Projekte) wie externe Links eingefärbt sein müssen. Wie bzw. wo das technisch gemacht wird, ist natürlich diskutierbar. Es dürfte offensichtlich sein, dass die Markierung mittels D keinesfalls ausreichend ist. Beispielsweise
(Unterschied | Versionen) . . D Vorlage:Navigationsleiste Kader des FC Valenciennes (Q20896002); 08:03 . . Headlocker (Diskussion | Beiträge) (Sprachlink hinzugefügt: en:Adrien Tameze)
muss ersichtlich sein, welche der Links zu Wikidata führen und welche lokal sind. Ironischerweise steht das D direkt beim einzigen Nicht-Wikidata-Link. --Leyo09:56, 26. Apr. 2016 (CEST)
Aber ich frage mich immer noch, wieso es dir bei der Linkfarbe dieser paar Links auf der Beobachtungsliste geht. OMA sieht die sowieso nicht, die ist nämlich mit sehr großer Wahrscheinlichkeit ein unangemeldeter Leser ohne Beobachtungsliste, und selbst wenn sie sich angemeldet hat, dann werden Wikidata-Änderungen per Standard nicht angezeigt.
Die Links auf Schwesterprojekte, die man häufig sieht, sind die Links auf andere Sprachen in der Seitenleiste – die haben „schon immer“ die Farbe normaler Links, und nie gab es Bedarf das zu ändern. Ebenso weitere Links in der Seitenleiste: Spenden, Wikidata-Objekt, Schwesterprojekte. Die Hälfte der Links im Footer, einige Hilfe-Links (z. B. auf Versionsgeschichten) Umgekehrt gibt es genügend lokale Links (diesen beispielsweise), der wie die Farbe eines externen Links hat.
Geht es dir um alle diese Links? Dann frage ich mich, warum du immer nur von den Wikidata-Links auf der Beobachtungsliste schreibst und nicht schon viel früher für andere Linkfarben bei Interwikilinks argumentiert hast. Oder geht es dir tatsächlich nur um diese Wikidata-Links? Dann frage ich mich, was ausgerechnet an diesen Links so besonders ist, dass man dafür eine Änderung anstreben muss. --Schnark10:29, 26. Apr. 2016 (CEST)
Es geht mir primär um die Links in der Beobachtungsliste (und bei den letzten Änderungen), aber ich würde mehr Einheitlichkeit bei der Linkfarbe von externen Links natürlich begrüssen. Dort betrifft es nur Wikidata, dass man beim Klicken auf „Unterschied“, „Versionen“, „Benutzername“, „Diskussion“ oder „Beiträge“ plötzlich in einem anderen WMF-Projekt ist. So ist auf einen Blick zu erkennen, welche Links zur betroffenen (beobachteten) WP-Seite führen und welche zu Wikidata, wo die Änderung stattfand. Bei meinem obigen, komplizierteren (geändert wurde nicht das Item der beobachteten WP-Seite) Beispiel hilft das fürs Verständnis. --Leyo11:44, 26. Apr. 2016 (CEST)
Fürs Verständnis reicht das D aus: Jede solche Änderung fand nicht lokal statt, sondern auf Wikidata. Das ist wesentlich leichter zu sehen als die Linkfarbe.
Die Farbe dagegen übermittelt – wenn sie überhaupt wahrgenommen wird – praktisch keine Information, eben weil sie schon immer inkonsistent eingesetzt wurde. Daher bezweifle ich auch, dass der Durchschnittsbenutzer überhaupt weiß, dass er interne und externe Links in vielen Fällen an der Farbe unterscheiden kann. Wenn man die Links nicht anklickt, dann kann es einem vollkommen egal sein, ob sie auf Wikidata führen oder nicht, wenn man sie anklickt, dann sieht man es sofort. Die Zahl der Benutzer, die einen Link vorsichtig inspiziert, welche Farbe er hat und ob man aus dieser Farbe an dieser Stelle die Linkart erschließen kann und ihre Entscheidung, ob sie den Link anklicken, vom Ergebnis dieser Überlegungen abhängig machen, dürfte sehr klein sein. Die OMAs, um die es ja gehen soll, gehören da bestimmt nicht dazu.
Und eine Einheitlichkeit der Linkfarben würde ich auch begrüßen: Alle Interface-Links sollten die gleiche Farbe haben. Haben sie sogar, mit eben dieser einen lokalen Ausnahme. --Schnark12:09, 26. Apr. 2016 (CEST)
„Fürs Verständnis reicht das D aus“ – nein, du irrst. Aber mit genau 1 WD-Edit 2016 und einem Dutzend 2015 kann's auch an deiner fehlenden Praxis liegen. --Leyo12:14, 26. Apr. 2016 (CEST)
Wer am D nicht sieht, dass es sich um eine Wikidata-Änderung handelt, der sieht das auch nicht an der leicht anderen Farbe einiger Links. Wie du von der Zahl meiner WD-Edits auf die Zahl der WD-Änderungen auf meiner Beobachtungsliste schließt, weiß ich aber nicht. --Schnark12:21, 26. Apr. 2016 (CEST)
Dir scheint „Ironischerweise steht das D direkt beim einzigen Nicht-Wikidata-Link.“ oben entgangen zu sein.
Leyo, wenn die Farbe für dich persönlich unverhandelbar ist, dann ist das ein erstklassiges Argument für das Einfügen in Benutzer:Leyo/monobook.css, dort wird dir niemals jemand reinreden. Wenn es allerdings für dich unverhandelbar ist, dass alle Menschen die externe Linkfarbe sehen müssen, dann ist das kein Argument für ein Einfügen in MediaWiki:Common.css und auch nicht in MediaWiki:Monobook.css, sondern für eine Korrektur des PHP-Codes.
Für mich dagegen ist es unverhandelbar, nach dem Sündenfall der absolut positionierten Elemente nochmal irgendeine Anpassung vorzunehmen, die für jeden Skin einzeln gepflegt werden muss – ganz besonders dann, wenn es um eine derartige Kleinigkeit geht. Ich werde das daher auch keinesfalls machen. Ich weise auch explizit darauf hin, dass ich kein einziges anderes Wiki gefunden habe, in dem eine Anpassung dieser Art vorgenommen wird (nehme entsprechende Hinweise aber gern entgegen).
In der englischen Wikipedia wurde deine gleichlautende Anfrage übrigens unbearbeitet archiviert, nachdem du auch dort auf den Bugtracker verwiesen wurdest. Eine Argumentation, dass die externe Linkfarbe unbedingt so sein müsse, ist daher IMHO nicht tragbar, da sie offenbar nicht breit geteilt wird und es vielen Leuten sogar völlig egal zu sein scheint. In dem Fall („den meisten Leuten ist es egal“) sollte aber meiner Meinung nach grundsätzlich gelten, dass keine lokale Anpassung vorgenommen wird, um den Code hier schlank zu halten und Fehler bei zukünftigen Softwareänderungen zu vermeiden.
Wenn es mir um das mein UI gehen würde, würde ich nicht hier schreiben. Es gibt Benutzer, die etwas weniger erfahren sind als wir hier, und für diese ist die Einfärbung hilfreich (falls es jemand nicht bemerken sollte, so ist es zumindest nicht störend).
Es ist mir völlig klar, dass es dir nur um das resultierende Aussehen geht. Das merkt man deiner Editierweise (nicht nur in dieser konkreten Angelegenheit, sondern auch andernorts) sehr deutlich an.
Ich lege deshalb nochmals stichpunktartig meinen Standpunkt dar:
Mir persönlich ist es völlig egal, ob die Wikidata-Links auf der Beobachtungsliste wie interne oder wie externe Links gefärbt sind.
Ich kann die Argumentation, dass sie wie externe Links gefärbt sein sollten, durchaus nachvollziehen und würde es auch ohne jedes Murren hinnehmen, wenn sie MediaWiki-seitig so formatiert wären, nehme aber auch zur Kenntnis, dass dies nicht Konsens ist, da beispielsweise Schnark sich hier dagegen ausgesprochen hat.
Ich nehme zur Kenntnis, dass es dir egal ist, ob unser CSS-Code sauber ist, mir ist dies allerdings überhaupt nicht egal, sondern ich würde gerne erreichen, dass er einmal sauber wird und danach der Neueinbau von Unsauberkeiten dauerhaft unterlassen wird. Das mag vielleicht utopisch sein, aber man kann es ja wenigstens versuchen.
Mit dem derzeitigen Code wird das von dir gewünschte Ziel, Wikidata-Links auf der Beobachtungsliste wie externe Links aussehen zu lassen, nicht erreicht, da dein Code nicht nur auf andere Skins, sondern auch auf :visited und :active keine Rücksicht nimmt. Wir reden hier also über defekten Code, der in seiner derzeitigen Form zumindest in einigen Aspekten eine Verschlechterung des MediaWiki-Originalzustandes darstellt, was bei mangelndem Konsens über die Art der Reparatur seine Löschung nahelegt.
Ich persönlich lege deine Argumentation so aus, dass du eine Zwangsläufigkeit für die Formatierung der Wikidata-Links als externe Links postulierst. In diesem Fall wäre es angemessen, wenn du dich mindestens zusätzlich zum CSS-Hack hier auch dafür einsetzen würdest, dass die Angelegenheit zentral für alle Wikis in deinem Sinne geregelt wird.
Und nein, es ist grundsätzlich nicht egal, wie und wo ein Problem gelöst wird, selbst wenn das Ergebnis für dich gleich aussieht. Ich nenne als Grund nur mal die unterschiedliche Fehlerträchtigkeit.
Du kannst daraus, dass dir jahrelang niemand widerspricht, nicht schließen, dass dein Änderungsvorschlag OK ist; es kann auch einfach heißen, dass sich niemand damit befassen möchte. Ich habe als Experiment mal hier auf defekten CSS-Code in einem anderen Wiki hingewiesen. Natürlich kann es sein, dass das Experiment schief geht, aber ich erwarte, dass da jahrelang nichts passieren wird, weil sich niemand mit sowas befassen möchte.
Mir ist es nicht „egal, ob unser CSS-Code sauber ist“, aber ich halte das Resultat für wichtiger. Bei deinem Statement „Und nein …“ verdrehst du mir die Worte im Mund: Korrekt ist, dass es mir aufs Resultat ankommt. Dieses soll aber auch meiner Ansicht nach auf die sinnvollste Weise/mit Anpassungen am besten Ort erreicht werden.
Mit 131 Beobachtern kann mein Vorschlag inkl. Nachfragen nicht unbeachtet geblieben sein. Bei einem LA wäre dieser Abschnitt hier wohl als Wiedergänger geschlossen worden. ;-) --Leyo23:45, 26. Apr. 2016 (CEST)
Langsam fängt es doch an, mir etwas zu blöd zu werden. Fühlst du dich wirklich sicher genug, um CSS außerhalb deines Benutzernamensraums zu editieren, das kein einziger anderer Benutzer jemals aktiv gutgeheißen hat?
Zum Thema „als Wiedergänger schließen“: Nope, denn die Fehler des von dir eingefügten Codes sind in der damaligen Diskussion überhaupt nicht thematisiert worden. Deshalb passt dieser Vergleich nicht. Es stimmt allerdings, dass wir im Gegensatz zum Artikelnamensraum kein geregeltes Prozedere für das Entfernen einer einmal hier erfolgten Ergänzung haben, weshalb beim Einfügen vorsichtiger vorgegangen werden sollte, als du es getan hast.
Also nochmal: Das, was wir jetzt haben, ist aus einem Vorschlag von TMg herausgegriffen, der deutlich mehr umfasste. TMg selbst sagte hierzu folgendes:
„Die Farbe allein bringt wirklich fast gar nichts. Ohne gleichzeitig das Pfeilsymbol hinter alle externen Wikidata-Links zu setzen, sind sie nicht zu unterscheiden. Ich hab mal etwas rumgespielt. Ist nicht ganz ausgereift, aber wer mag, kann das mal in seiner eigenen common.css ausprobieren.“
Natürlich kann ich nur für mich sagen, weshalb ich in der damaligen Diskussion nichts zu deiner Umsetzungsankündigung geäußert habe, und zwar aus folgenden Gründen: (1) Ich habe eine Meinung über die Arbeitsweise/den Durchsetzungswillen bestimmter Benutzer und nehme darauf Rücksicht, soweit die Auswirkungen akzeptabel sind. (2) Ich wusste zum damaligen Zeitpunkt schon, dass die Farbe für Cologneblue nicht passt, dies allein wäre aber für mich noch kein Grund zum Handeln. Ich habe sogar zeitweise mit dem Gedanken gespielt, die Regel stillschweigend so zu ändern, dass sie Cologneblue in Ruhe lässt. (3) Es geht um eine Sache, die eine Auseinandersetzung im Zweifelsfall nicht wert ist.
Nun hat der CSS-Code aber leider noch mehr Probleme als die für Cologneblue unpassende Farbe, die ich erst jetzt gesehen habe, und müsste massiv aufgebläht und/oder dezentralisiert werden, um diese zu beheben. Das ist eine neue Situation.
Unabhängig davon halte ich es nicht für guten Stil, sich im Anbetracht erstmals angesprochener Probleme auf eine alte Diskussion zurückzuziehen, in der sehr wohl auch Leute dagegen waren und bloß ab einem gewissen Zeitpunkt nichts mehr gesagt haben, aber das nur am Rande. --Entlinkt (Diskussion) 01:06, 27. Apr. 2016 (CEST)
Die gegenwärtigen Blautöne werden zur Unterscheidung nicht ausreichen.
Es gibt jedes Blau für unbesucht und besucht; dann intern, extiw und external. Das dann womöglich variiert in Skin und Mobil.
Es bedarf anderer Mittel als der Linkfarbe, namentlich Hinterlegung und Umrahmung, um hier noch menschenfreundlich und einheitlich Besonderheiten hervorzuheben.
Wikidata ist nicht external, sondern extiw (sofern man im content area [muss nicht nur benutzergeneriert sein] Unterscheidungen treffen will, während der Portalrahmen einheitliche Farben hat und sich die Ziele schon aus der Bedeutung und Beschriftung ergeben).
Es gibt dann noch doi:10.1000/182 als extiw-befreundet jedoch faktisch external und RFC 3091 als kernbefreundet und trotzdem external.
Wikidata ist demgegenüber schon ein Projekt der WMF und damit extiw – d:Q1 ist extiw.
Beo von Wikidata-Aktivitäten:
Nur das „D“ hat hier eine auswertbare class="wikibase-edit" und die komplette Zeile ist allein mit CSS-Mitteln momentan nicht hervorhebbar.
Ginge nur mit JS und wäre Kandidat für ein phab-Ticket analog phab:T130824 (pending).
Ich denke, hier bedürfte es der Konstruktion eines reinen CSS-Gadgets linkDecoration mit einem bunten Strauß an Hinterlegungen und Umrahmungen gemäß WP:CSS#linktypes; ggf. komplett von dort übernommen und um einen allgemeinen Vorsicht-Wikidata-Stil erweitert.
Auch mit komplexeren Selektoren [href*='//www.wikidata.org/w'] und redirect und Dateiformaten und einem einheitlichen Farbschema.
Das kann dann auch für die Nicht-Techies zentral gepflegt und auf der Gadget-Doku erläutert werden.
Auch mit „Benutzer und BD im ANR im content unerwünscht“ (weil außer in QS-Signatur nix am Suchen) usw.
Für normale Leser sind die Farbenspiele verwirrend und unverständlich; sie richten sich an Autoren mit fortgeschrittenen Kenntnissen und Hintergrundwissen.
Nur-watchlist-CSS geht nicht ruckelfrei und auch nur mit JS; die CSS-Regeln müssen für ausnahmslos alle Namensräume und Benutzer geladen werden, und da die anonymen Nur-Leser keine watchlist haben, werden ihnen unangemessene Regeln zur Auswertung aufgedrückt.
Anonyme Insider können ein Gadget per JS-Greasemonkey dynamisch laden oder hin und wieder die CSS-Quelle lokal herunterladen und in der Browser-Konfiguration Domain-spezifisch vereinbaren.
Dieses <a class="plainlinks"> lässt mich nicht los. Ich habe mittlerweile herausgefunden, dass es wohl mit gerrit:27392 (Neuanlage von client/includes/ExternalChangesList.php) eingefügt wurde, wodurch phab:T42355 implementiert wurde. Mit anderen Worten, es war schon von Anfang an da, aber was damit bezweckt werden soll, bleibt weiter rätselhaft.
Die fragliche CSS-Regel habe ich jetzt allerdings entfernt, weil sie in der vorliegenden Form falsch war. Sie führte dazu, dass bei uns das Problem phab:T5112 (fehlende Auszeichnung besuchter Links, Pseudoklasse :visited) an einer Stelle bestand, an der es ohne die Regel nicht bestünde. Das ist ein Fehler.
Natürlich kann es vorkommen, dass einmal etwas falsches auf die Vorderseite gerät (allerdings kann man dieses Risiko minimieren, indem man nichts auf die Vorderseite übernimmt, was man nur als Vorschlag für eigenes CSS erhalten hat). Und natürlich wäre die Reparatur eine Möglichkeit, das zu beheben, die Löschung aber ebenso. Ich habe selber auch schon mal den einen oder anderen Fehler gemacht, aber auch die eine oder andere Reparatur vorgenommen. In diesem Fall entscheide ich mich für die Löschung aus folgenden Gründen, die zusätzlich dazu gelten, dass die Regel falsch ist:
Erklärtermaßen wünscht Leyo, dass die Umfärbung für alle Wikis vorgenommen wird. Also passt der gewählte Weg (Einfügen in das CSS der deutschsprachigen Wikipedia) nicht zum Ziel.
Der Unterschied ist sehr gering, der Aufwand einer Reparatur vergleichsweise hoch.
Zumindest bei mir hat die alte Diskussion mitnichten den Eindruck erweckt, dass die Umfärbung breit gewünscht wird. Meiner Meinung nach sollte in solchen Fällen dann spätestens beim Bekanntwerden von Problemen mit der lokalen Änderung wieder der Originalzustand der Software gewinnen, wie auch immer dieser gerade sein mag. Von anderslautenden Regularien (etwa solchen, die aus Analogien zu den Löschregeln für Artikel abgeleitet wären) weiß ich nichts.
Danke für den Ping. Ich habs mir mal angeschaut und halte es für die auch semantisch „korrekteste“ Lösung, die ohnehin wirkungslose plainlinks-Klasse vom <a>-Element zu entfernen und wie vorgeschlagen durch extiw zu ersetzen: gerrit:285922. Ich vermute, dass das die ursprüngliche Intention war: Wikidata-Links in den letzten Änderungen und der Beobachtungsliste mit der Schwesterprojekt-Linkfarbe zu versehen, ohne gleichzeitig alles mit Pfeil-Symbolen (Beispiel) zu fluten. Ich hoffe nur, dass sich kein weiteres (Benutzer-) CSS auf diese seit mindestens 2012 falsch gesetzte Klasse verlässt. --Thiemo Mättig (WMDE)12:33, 28. Apr. 2016 (CEST)
Danke schön bis hierhin.
Ja, es ging wohl jemand darum, die durch external ausgelösten Icons irgendwie wieder wegzubekommen; aber das lag am fälschlichen external statt extiw.
Wenn du jetzt noch analog zu phab:T130824 die ganze Beo-RC-Zeile mit einer Klasse versehen könntest, so dass sie umrahmt und hinterlegt werden kann, und damit dann klar ist, dass alle sonstigen Links in dieser Zeile aus dem aktuellen Projekt rausführen, machst du wahrscheinlich noch mehr Leute glücklich.
Hm? Reicht dafür nicht das <li class="wikibase-edit">? Ich habe mir damit gerade erfolgreich zur Probe einen Rahmen gemalt.
Ich hoffe aber doch, dass Rahmen und Unterlegung als Anregungen für Userstyles gemeint sind? Wir haben jetzt bereits standardmäßig ein fettes Dund bald wieder eine abweichende Schriftfarbe. In der Zusammenfassung zu gerrit:285922 schrieb TMg etwas von remove clutter. --Entlinkt (Diskussion) 13:45, 28. Apr. 2016 (CEST)
Ich bin explizit nicht für die durch gerrit:285922 implementierte globale Farbänderung, sondern hatte oben nur ausgeführt, dass der Code in einigen Aspekten „merkwürdig“ ist, damit eine Klärung herbeigeführt werden kann, was die Entwickler eigentlich wollen, da der Code Fragen aufwirft. Allerdings hatte ich auch gesagt, dass wir die Farben im Falle einer globalen Änderung nicht lokal zurückändern sollten (aus denselben Gründen wie bei der von mir zurückgesetzten lokalen Änderung) und bleibe auch dabei.
Ich hätte bei der Gelegenheit aber einige ganz, ganz große Bitten an Adminkollegen:
Nutzt die Seite MediaWiki:Common.css bitte nur für Dinge, die auch dorthin gehören.
Skinabhängiges gehört definitiv nicht auf die Vorderseite. Man sollte aus diesem Abschnitt mitnehmen, dass Linkfarben skinabhängig sind.
Fixes für (vermeintliche) Softwarebugs gehören in der Regel nicht auf die Vorderseite, sondern sollen in der Software selbst gefixt werden. Lokale Workarounds sind nur in Ausnahmefällen angezeigt, zum Beispiel dann, wenn ein Bug die Arbeit in unserem Wiki stark behindert.
Sehr geringfügige Änderungen rechtfertigen tendenziell keinen Eintrag auf der Vorderseite. Darunter fallen zum Beispiel Änderungen, bei denen man den Unterschied fast nicht sieht oder die auf besonders spitzfindigen Interpretationen beruhen.
Nutzt eure User-Stylesheets wie andere Benutzer auch.
Wenn ihr Code erhaltet, den jemand explizit für euer User-Stylesheet geschrieben hat, dann seid besonders vorsichtig damit, ihn umseitig einzufügen, da solcher Code oft nur quick and dirty zusammengeschrieben ist, weil er ja nur für euer User-Stylesheet und nicht für MediaWiki:Common.css gedacht ist.
Je mehr man persönlich davon überzeugt ist, dass eine (nicht rein technische, sondern im weitesten Sinne „gestalterische“) Änderung unbedingt vorgenommen werden sollte, um so sinnvoller wäre es, die explizite und reflektierte Zustimmung mindestens eines anderen Benutzers abzuwarten oder die Umsetzung einem anderen Admin zu überlassen.
Es gibt kein ewiges Bestandsrecht für Änderungswünsche in dem Fall, dass man sie selbst umgesetzt hat, nachdem sie über einen längeren Zeitraum ohne Reaktion auf der Diskussionsseite standen.
PS: Wie Schnark weiter oben bereits sagte, werden die bekannten Linkfarben für „intern“ und „extern“ nur in nutzergeneriertem Inhalt konsistent verwendet, jedoch nicht auf allen Spezialseiten; beispielsweise haben die Links auf andere Wikis auf der Seite Special:Centralauth die „interne“ Linkfarbe. Wer Vector oder Monobook verwendet und der Meinung ist, dass externe Links im Textfeldbereich grundsätzlich immer die „externe“ Farbe haben sollten, kann für sich persönlich das folgende CSS verwenden:
Du hast natürlich recht damit, dass es ^= statt $= heißen muss. So ist das halt mit ungetesteten Hacks für User-Stylesheets, sie können falsch sein, das sehen wir jetzt zum zweiten Mal ;)
Das .external ist allerdings falsch, da es ja gerade um Links geht, die kein.external haben. Wenn ein Link .external hat, hat er auch gleich die „externe“ Farbe.
Die tiefenphilosophische Bedeutung von externe Links im Textfeldbereich grundsätzlich immer die „externe“ Farbe haben sollten hat sich mir dann bislang nicht erschlossen.
.external wird vom Parser allem zugewiesen, was im URL-Format notiert ist; völlig egal, ob es zur eigenen Farm gehöre oder nicht.
Dementsprechend könnte es mal ein ftp zu viel erwischen; in Nullkommapromille der Links.
Dem Parser ist es egal, wer ein Wiki ins Netz stellt, und unterscheidet auch nicht zwischen WMF oder Fremdinstallation.
Ich meine, das wäre früher mal ein JS gewesen, das ich aber auch grad nicht mehr finde.
Der macht aber nur den Pfeil weg.
Wenn das aber optisch wie ein internes (doppelt geklammertes) Wikilink dekoriert werden soll, bräuchte man das von mir angegebene Konstrukt, oder das von dir skizzierte. Ansonsten wäre eigentlich überhaupt nichts zu tun, weil dann ist jede URL external.
Interne Links haben zu Beginn /wiki/ oder /w/index.php aber weder external noch extiw.
.extiw würde es theoretisch noch geben; aber de:Wikipedia:Hauptseite wird dann doch noch rechtzeitig aufgelöst.
Nicht erledigt ist das, was wir hier gerade ausdiskutieren. Auch wenn es im Sinne der Ausgangsfrage ins OT abgleitet; oder vorher schon ausgeglitten war.
Ganz ehrlich, ich bereue es mittlerweile, diese Diskussion jemals gestartet zu haben.
Anfangs ging es mir hier wirklich ausschließlich darum, eine falsche lokale Regel zu reverten. Da aber ein starker Befürworter der betroffenen Regel Adminrechte hat, hielt ich es für sinnvoll, vor dem Revert mal eine Diskussion zu starten, damit hier kein Revertwar unter Admins ausbricht, da dies für die Benutzer belästigend und auch ziemlich peinlich wäre.
Im Verlauf dieser Diskussion habe ich mich leider – unschlauerweise und nicht zum ersten Mal, aber diesmal merk’ ich’s mir wirklich, das in Zukunft nicht mehr zu tun – dazu hinreißen lassen, ein paar Argumente zu nennen, die die Befürworter der Umfärbung an der richtigen Stelle vortragen können, um eine Umfärbung zu erreichen. Dies geschah in der Absicht, den Befürwortern einen kleinen Gefallen zu tun, damit sie wissen, was sie bei den Entwicklern vortragen können, um ihnen eine Alternative zum Revertwar aufzuzeigen. Dass es jetzt aus Anlass dieser Diskussion zu einer globalen Umfärbung gekommen ist, bereitet mir ehrlich gesagt durchaus Bauchschmerzen, da ein Teilnehmer dieser Diskussion explizit dagegen war. (Allerdings scheinen die Entwickler tatsächlich so irgendwie dafür zu sein, wobei die Reviewkommentare auch etwas unschlüssig sind.)
Wahrscheinlich sollte man bei zukünftigen Vorkommnissen dieser Art keine solchen Diskussionen mehr starten, sondern je nach Laune und Schwere des Fehlers die falsche Regel entweder einfach ignorieren oder direkt mit dem Kommentar „Wer das unbedingt will, bringe es bitte in Ordnung“ reverten.
Soweit es um das Linkfärbeverhalten von MediaWiki geht, kann ich aufgrund des derzeitigen Informationsstandes nur zu dem Ergebnis kommen, dass es größtenteils nicht konsistent ist und daher Konsistenz als Argument für Änderungswünsche ausscheidet. Daher verbieten sich lokale Änderungen mit dieser Begründung und es bleibt bei Änderungswünschen nur der Ausweg, es in jedem Einzelfall mit den Entwicklern auszudiskutieren. Aus diesem Grund sehe ich wenig Revelanz in der fortgesetzten Diskussion, auch wenn es interessant sein mag, das inkonsistente Verhalten von MediaWiki zu erforschen.
Wenn ich eine Tabelle wie im Beispiel erstelle, würde ich eigentlich erwarten, das die erste Spalte die gleiche Hintergrundfarbe wie der Tabellenkopf hat, also so aussehen solle:
Spaltenüberschrift
Spalte2
Spalte3
Zeilenüberschrift1
a1
b1
Zeilenüberschrift2
a2
b2
ohne jeweils die Hintergrundfarbe in das erste Feld schreiben zu müssen, also mit so wenig html Formatierungen wie möglich auszukommen. Frohes Schaffen — Boshomi⌨22:22, 28. Okt. 2016 (CEST)
Vor einiger Zeit wurde die Hintergrundfarbe für Tabellenkopfzeilen etwas aufgehellt. Vermutlich hat man hier nur vergessen, unsere hintergrundfarbe2 mit anzupassen. -- hgzh17:50, 4. Dez. 2016 (CET)
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich wäre dafür, die Links zu en in den Kommentaren alle mit einem Doppelpunkt vorne zu entschärfen. In diesem Fall führt das zwar zu einer durchaus passenden Anzeige, aber andererseits gibt es keinen wirklichen Grund en gegenüber allen anderen Sprachen zu bevorzugen und dass der richtige Link gewählt wird, ist auch nur Zufall. --Schnark10:12, 9. Dez. 2016 (CET)
Letzter Kommentar: vor 6 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Wir zielen seit langer Zeit darauf ab, den zwangsweise projektweit in über zehn Millionen Seiten eingebundenen CSS-Code so schlank und übersichtlich wie möglich zu halten.
Heute können mal wieder zwei historische Relikte entfernt werden:
/* * Lokal erhalten gebliebene Kopie der ehemals global vorhandenen Klasse * „townBox“; vgl. [[rev:2909]], [[rev:36662]], [[Wikipedia:Archiv/TownBox]]; * ehemals verwendet in [[Wikipedia:Formatvorlage Charts]], siehe * https://de.wikipedia.org/w/index.php?diff=57274184&oldid=56781842; Ersatz * durch [[Vorlage:Infobox Chartplatzierungen]], die diese Klasse nicht nutzt */div.sideBox{background:white;border:1pxsolid#72777d;clear:right;float:right;margin-left:1em;padding:.3em;width:200px;}div.sideBoxdl{font-size:96%;margin:00.3em;}div.sideBoxdt{margin:.4em00;}div.sideBoxdd{background:#f8f9fa;margin:.1em001.1em;}
Die Klasse sideBox wird noch auf 204 Seiten verwendet, darunter viele Benutzerseiten. Willst du zig Benutzern ohne vorherige Warnung ihre Benutzerseite zerschießen? 92.74.23.20222:36, 26. Jul. 2017 (CEST)
XanonymusX hatte beim o.a. Link mitgeteilt, dass die Klasse nicht mehr für Musik (oder ANR) benötigt wird; dies hatte ich nachgeprüft, und es trifft auch zu.
„Zerstört“ wird überhaupt nichts.
Die Benutzerseiten sind genauso lesbar wie vorher.
Nur ist da irgendwo eine font-size nicht mehr 96%, sondern 100%, und irgendein Blassgrauton ist jetzt normaler Seitenhintergrund.
Die Klasse war ausschließlich dafür vorgesehen, in der Chart-Vorlage deren spezielles Design herzustellen.
Wer sich für andere Zwecke vorgesehene Stildefinitionen mardert und noch aktiv ist, der kann sich seine Seiten selber nachputzen, falls überhaupt ein Unterschied sichtbar wird.
Nebenbei ist überhaupt nicht gesagt, dass der dort hineinkopierte Klassenname irgendeine Wirkung entfaltet, weil die formatierten Elemente nicht enthalten sein müssen.
Wir haben sehr oft das Phänomen, dass Syntaxdefinitionen, Elemente und Klassennamen einfach von irgendwoher mitkopiert werden, ohne dass die Kopierer die leiseste Ahnung haben, was das bewirken solle, noch irgendeinen Gebrauch davon machen, und die Syntax völlig funktionslos mit beisteht.
Wir dürfen Benutzerseiten und Diskussonsbeiträge nicht ändern. Folgt man der Argumentation, dann muss jede Klassendefinition, die umseitig mal eingeführt wurde, auf ewige Zeiten immer weiter genauso unterstützt werden und dürfe nie verändert werden und es müssen immer neue Klassen angelegt werden, damit auch die Seiten verstorbener Benutzer immer noch genauso aussehen wie vor zehn Jahren.
Damit würde die umseitige Sammlung immer weiter anwachsen und wäre völllig unwartbar.
Nebenbei ein Grund mehr, umseitig nicht leichtfertig neue Definitionen aufzunehmen, weil man die dann ja nie wieder loswürde.
Lesson learnt: Wenn man einmal umseitig eine Klasse einführt, dann kann man auf Ewigkeiten allen Leuten hinterherrennen, die die für Gott weiß was irgendwo verbasteln, nicht aber für Wikipedia:Formatvorlage Charts.
Warum muss es eigentlich immer Schwarz oder Weiß sein? Hier verlangt niemand, sideBox auf immer und ewig zu unterstützen. Aber es spricht nichts dagegen, die betroffenen Benutzer zu warnen, damit sie ihre Benutzerseiten anpassen können. Nach einer sinnvollen Wartezeit (z. B. zwei Monate) kann das Zeug dann weg. 129.13.72.19809:33, 27. Jul. 2017 (CEST)
Da man bei unangemeldeten Benutzern logischerweise nicht die Dankefunktion nutzen kann: Danke, liebe IP(s)! :-) Ich würde für die Wartezeit btw eher zwei Wochen vorschlagen, also vielleicht irgendwas dazwischen? --nenntmichruhigip (Diskussion) 17:37, 27. Jul. 2017 (CEST)
Letzter Kommentar: vor 2 Jahren25 Kommentare5 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)
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)
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)
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)
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)
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)
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)
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)
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)
Demonstration, dass der margin-top-Wert nachfolgender Absätze für Floats völlig belanglos ist. Von Interesse ist vielmehr der margin-bottom-Wert des vorausgehenden Elements. Gruß --Entlinkt16:48, 8. Aug. 2010 (CEST)
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)
Die Unterschiede gegenüber unseren Definitionen sind:
Abstand nach oben 0 (Wird hier ebenfalls vorgeschlagen)
Abstand zur Seite und unten 0.5em (Der Seitenabstand ist mir etwas zu wendig, der Abstand unten reicht aber meiner Meinung nach)
position:relative (Spezialanwendung vorstellbar, aber bei uns ist das ein Stopper für unsere absolut positionierten Elemente wie Artikel-Koordinaten rechts oben, die üblicherweise in Infoboxtabellen erzeugt werden.)
border: 0 (Seltsame Definition. Kein Rahmen ist doch Standard. wikitable überschreibt den Rahmen dann wieder.)
div.floatleft p { font-style: italic; } (Ein seltsames Gimik, das Absätze kursiv macht, einzelne Zeilen aber nicht.)
Wegen der seltsamen Zusatzdefinitionen bin ich mit den CSS-Klassen von MediaWiki nicht so glücklich. Ein Verringern auf margin-top:0 und margin-bottom:0.5em bei uns finde ich aber akzeptabel. --Fomafix22:15, 30. Jan. 2012 (CET)
Nur zur Info: Das position:relative hat m. E. nichts mit einer Spezialanwendung zu tun, sondern ist nur ein Workaround für einen alten IE-6-Bug, den kaum jemand mehr kennt (wir haben das auch noch in Vorlage:Bausteindesign1 usw. und hatten es zeitweise auch an den Navigationsleisten und haben es immer noch an der Klasse div.sideBox). --Entlinkt (Diskussion) 17:52, 12. Mai 2013 (CEST)
Das habe ich auch vermutet. Meiner Meinung nach wäre es langsam an der Zeit diese Workarounds für den IE6 zu entfernen. Als Grade B sollte reichen, wenn an manchen Stellen der Hintergrund nicht sichtbar ist. Lesbar bleibt es ja weiterhin. Gibt es dazu bereits einen Bug? --Fomafix (Diskussion) 17:57, 12. Mai 2013 (CEST)
Ich habe keinen Bug zu diesem Thema gefunden. Aber vielleicht sollte man wirklich einen Bug zum Aufräumen von floatright und floatleft melden.
Diese beiden Klassen werden von MediaWiki verwendet, wenn man Bilder mit |right oder |left (ohne |thumb) einbindet (und anscheinend auch für nichts anderes). Für diesen Zweck genügt der Teil
Die Zusatzdefinitionen schaden dabei erstmal nicht, verhindern aber andere Nutzungen. Idealerweise könnten dabei auch die Abstände wie gewünscht eingestellt werden und wir bräuchten unsere eigenen Klassen mittelfristig nicht mehr. --Entlinkt (Diskussion) 21:05, 14. Mai 2013 (CEST)
Eine lange Diskussion. Versuch einer Zusammenfassung des aktuellen Standes (zwecks Vereinfachung beschränke ich mich auf float-right und ignoriere float-left):
Wir haben eine lokal definierte Klasse float-right, ursprünglich eingefügt im Januar 2007 mit diesem Edit und um Abstände ergänzt im März desselben Jahres mit diesem Edit nach dieser Diskussion. Man kann der Diskussion entnehmen, dass die Klasse in erster Linie zur Kombination mit wikitable als Ersatz für Vorlage:Prettytable-R gedacht war. Dies erklärt die Wahl der Abstände, es sind schlicht und einfach exakt dieselben wie in der gelöschten Vorlage. Der Selektor wurde später geändert, um weitere Verwendungen zu ermöglichen, so dass die Definition derzeit folgendermaßen lautet:
Das MediaWiki-eigene CSS definiert eine Klasse floatright mit einer völlig anderen Entstehungsgeschichte. Die Definition ist auf verschiedene Dateien verteilt. Hier eine Zusammenstellung der Teile aus mediawiki.legacy/shared.css und mediawiki.skinning/content.css:
Diese Klasse verwendet MediaWiki für rechts ausgerichtete Bilder wie das nebenstehende Beispiel. Ich vermute, dass sie für andere Verwendungen eigentlich überhaupt nicht vorgesehen ist; wegen der mit ??? kommentierten Teile ist sie für andere Verwendungen nur sehr eingeschränkt geeignet. Es ist völlig unklar, wofür diese Teile überhaupt gut sein sollen; bei Bildern sind sie weder nützlich noch störend, aber bei anderen Verwendungen wären sie störend.
Der Thread begann mit der Frage, ob wir die Abstände in unserer Definition ändern sollten, befasste sich später aber auch mit der Frage, warum es überhaupt zwei unterschiedlich definierte Klassen gibt. Die letztgenannte Frage ist meiner Meinung nach spätestens hiermit beantwortet.
Ich kann nicht mehr rekonstruieren, was mich in meinem letzten Beitrag von 2013 geritten hat, zu meinen, dass wir beides zusammenführen könnten. Momentan bin ich der Meinung, dass wir das nicht tun sollten, da die Klassen verschiedenen Zwecken dienen und floatright vermutlich sogar nur für MediaWiki-interne Zwecke vorgesehen ist. Unabhängig davon sollten die mit ??? kommentierten Teile meiner Meinung nach aus der Definition von floatright gestrichen werden, da sie nutzlos sind, aber das ist nicht unser Problem.
Was bleibt, ist die Frage, ob wir in unserer Definition von float-right die Abstände anders einstellen sollten. Hier war und bin ich der Meinung, dass eine komplizierte Heuristik wie im ursprünglichen Vorschlag nicht in Frage kommt, sondern allenfalls eine generelle Änderung (d. h. eine Änderung, die den Selektor in Ruhe lässt und nur den margin-Wert verändert).
Der initialen Beschwerde über das Aussehen würde ich nicht folgen.
Das größere Problem ist der grottige Einsatz in Artikeln, mit dem die Leute versuchen, das so aussehen zu lassen wie in ihren Papierzeitschriften.
Nix tun. Eher ein paar von den Dingern mit Überbreite zurückbauen auf normale linksbündige, dann passt das auch auf Smartphones und bei schmalen Bidschirmfenstern.
Wenn schon, dann 1em nach links und oben/unten 0.5em.
Wir haben auch noch knapp 100 floatright – das sind vermutlich Verwechslungen. Teilweise stehen noch margins mit bei.
Bei den Gemeinderatswahlen in Semmering (Niederösterreich) sehe ich keine Verschlechterung; egal ob mit oder ohne margin.
Aus Transparenzgründen habe ich mal aus den gelöschten Versionen der beiden ehemaligen Vorlagen zusammengetragen, in welchen Zeiträumen welche margin-Werte galten und welche Benutzer sie jeweils eingestellt haben. Eventuell können daraus irgendwelche Rückschlüsse gezogen werden. (Zeiträume von weniger als einem Tag habe ich vernachlässigt, d. h. die Tabelle enthält keine Tests und keine Änderungen, die sofort zurückgesetzt wurden.)
Ich würde darüber hinaus auch den Schluss ziehen, dass ein kleinerer margin-top-Wert auf jeden Fall zumindest denkbar ist. Ob es eine gute Idee wäre, das nach so vielen Jahren noch zu versuchen, weiß ich allerdings nicht. --Entlinkt (Diskussion) 01:32, 24. Apr. 2016 (CEST)
Das .floatright, .floatleft { border: 0 } wurde in gerrit:333910 entfernt.
Das .floatright p, .floatleft p { font-style: italic } wurde in gerrit:452192 entfernt.
gerrit:562836 ist nun gemerged und deployt. floatright und floatleft beinhalten nun kein position: relative mehr. Absolute Positionierungen bei der Überschrift wie bei Koordinaten sind nun wie bei float-right und float-left möglich. --Fomafix (Diskussion) 15:06, 20. Mär. 2020 (CET)
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)
Danke für die Reaktion, bis jetzt hatte ich nur in der Seite der Vorlagenwerkstadt probiert und dort keine Reaktion bekommen. Zur Zeit probiere ich es auf WP:FZW. Viele Grüße --Christian1985(Diskussion)16:22, 4. Feb. 2011 (CET)
Damit wäre dieser Abschnitt unserer Common.css identisch zur englischen Wikipedia. Die zusätzliche Zeile hebt auch Linkziele hervor, wenn sich diese innerhalb eines Literatur-Abschnitts befinden. Aktuell funktioniert es nur, wenn das Linkziel ein Einzelnachweis ist. --TMg13:32, 24. Mai 2013 (CEST)
Sorry, ich kann nicht nachvollziehen, wo die Klasse citation herkommt. Aus einer Vorlage? Habe nur herausgefunden, dass das in der englischen Wikipedia hier eingefügt wurde. --Entlinkt (Diskussion) 17:55, 25. Mai 2013 (CEST)
Die „kommt“ nirgends her sondern wird von bestimmten Vorlagen verwendet, typischerweise von den Cite-Vorlagen oder auch Vorlage:Literatur, sofern man die Klasse dort einprogrammiert. Was aber auch nur dann Sinn ergibt, wenn die Klasse etwas bewirkt. Also ein kleines Henne-Ei-Problem. Ich schätze das so ein, dass diese kleine Erweiterung keinesfalls schaden kann oder für etwas Ungewolltes missbraucht werden kann. In den Templates muss sie anschließend wie angedeutet nachgepflegt werden. --TMg00:52, 26. Mai 2013 (CEST)
OK, ich hab’s mittlerweile halbwegs verstanden: In en:Doukas (perma) gibt es eine Fußnote 1, die auf ein Kurzzitat verweist, und von dort geht es weiter auf ein Langzitat im Literaturabschnitt. In Dukas (Familie) (perma) gibt es dasselbe in kaputt. (Sorry, ich wollte es halt gern zunächst nachvollziehen können.)
Wenn man so zitiert, ist die Hervorhebung natürlich eine sinnvolle Sache. Zitationsweisen sind allerdings ein ziemlich vermintes Gelände (bis hin zu Editwars um bestimmte Vorlagen oder deren Verwendung; es gab mal einen um Vorlage:Cite web und Vorlage:Internetquelle zu einem Zeitpunkt, als sie quasi identisch waren).
Diese Zitationsweise hier erscheint mir in dewiki eher weniger üblich, kommt wohl hauptsächlich bei en-Importen vor. Ich habe so ein bisschen die Befürchtung, dass die Hervorhebung als Argument für irgendwas benutzt werden könnte. --Entlinkt (Diskussion) 11:59, 26. Mai 2013 (CEST)
Letzter Kommentar: vor 2 Jahren10 Kommentare4 Personen sind an der Diskussion beteiligt
Spricht etwas dagegen, die Definitionen für die aktuell fünf Rahmenfarben so auszuweiten, dass auch die folgenden beiden Fälle funktionieren?
Zellenweise: Die aktuell einzige Methode, um die Rahmenfarbe einer wikitable zu verändern, ist das aufwändige individuelle Umfärben jeder einzelnen Zelle per | style="border-color:…;". Das Selbe sollte auch per |class="rahmenfarbe…" funktionieren.
Tabellenweise
Die Hintergrundfarbe lässt sich schon tabellenweit ändern, mit der Rahmenfarbe sollte das genauso funktionieren.
Schwierig ist das vor allem aufgrund der Spezifität. Die ist für die aktuell recht komplizierte Implementierung der wikitable-Stile leider sehr hoch. --TMg13:54, 22. Aug. 2013 (CEST)
Eine Implementierung könnte zum Beispiel so aussehen:
Allerdings fände ich es vielleicht eleganter, die wikitable-Definition so abzuändern, dass sie auf Vererbung setzt: 4 Jahre alter Vorschlag, der nie aufgegriffen wurde, weil er im IE <= 7 nicht funktioniert. Könnte man das mittlerweile akzeptieren? --Entlinkt (Diskussion) 19:53, 22. Aug. 2013 (CEST)
Test
Stimmt, den zweiten Selektor hätte ich glatt vergessen. Die width ist für alle außer den ersten Selektor eigentlich unnötig, aber so bleibt das CSS kurz und man hat weniger Redundanz. Also von meiner Seite freigegeben. ;-) Mit der Kurzform würde ich meinem Gefühl nach noch 1…2 Jahre warten. Die Auswirkung (alle Tabellen in der gesamten Wikipedia verlieren sämtliche inneren Rahmenlinien und Abstände) ist einfach zu groß. --TMg20:33, 22. Aug. 2013 (CEST)
Im IE 6 funktioniert die jetzige wikitable-Definition sowieso schon seit rev:107669 nur noch teilweise (innere Rahmenlinien, Abstände und andere Dinge fehlen), die Klassen für Hintergrundfarben funktionieren seit März 2012 ebenfalls nicht mehr.
Betroffen wäre also nur der IE 7 und man kann die Vererbungsvariante mit einem Fallback versehen, so dass sich im IE 7 einfach nichts ändert (d. h. die inneren Rahmenlinien würden einfach grau bleiben). Genau genommen müsste man den Fallback für wikitable gar nicht implementieren, weil er in der shared.css schon vorhanden ist.
Muss natürlich nicht sein, aber ich bin ernsthaft am Überlegen, ob man das jetzt schon machen kann (das Umfärben wird wohl nicht so häufig gemacht werden und wenn doch, wird man trotzdem am Außenrahmen erkennen, dass das eine irgendwie hervorgehobene Tabelle sein soll; das Grau sollte auch zu jeder anderen Farbe einigermaßen passen).
Andernfalls wäre hier noch eine Variante ohne gedoppeltes width:
Ich sorge mich nicht nur um IE, sondern auch um obskure Mobilbrowser, die zwar mit dem gängigen > aus CSS2 etwas anfangen können, denen aber nicht jede Variation mit inherit bekannt ist. Und noch wichtiger: Wenn einer sowieso nur grauen Tabelle mal ein paar graue Linien fehlen oder Abstände kleiner sind, ist das zwar hässlich, aber der Inhalt bleibt der selbe. Wenn Farben fehlen, gehen schlimmstenfalls Inhalte verloren. Zwar sollte man Information niemals nur durch Farbunterschiede vermitteln, aber wie wir wissen, wird dieser einfache Barrierefreiheits-Grundsatz nicht immer beachtet. --TMg21:34, 27. Aug. 2013 (CEST)
Ich bin nicht dagegen, aber auch noch nicht restlos überzeugt. Ich habe mal ein wenig herumprobiert und herausgefunden, dass der IE 7 zwar das Schlüsselwort inherit nicht versteht, aber entgegen den Regeln die Eigenschaft border-color durch die Tabelle hinweg vererbt, wenn man für die Zellen keine Rahmenfarbe festlegt. Das heißt, die folgende Anpassung der wikitable-Klasse würde das gewünschte Ziel erreichen und in allen mir bekannten und heute relevanten Browsern konsistente Ergebnisse erzielen (IE 6 außen vor, weil die gesamte Klasse dort sowieso auch jetzt schon nicht funktioniert):
Als Vorteile sehe ich an, dass dies dann nicht nur mit den rahmenfarbeX-Klassen, sondern auch mit style-Attributen funktionieren würde und die lokalen Anpassungen auf einem Minimum gehalten werden können.
Wäre es sinnvoll, diese Änderung für den MediaWiki-Core vorzuschlagen? (Der Vorschlag oben ist absichtlich so kompliziert wie die jetzige MediaWiki-Definition geschrieben, damit es dazu passt, man könnte ihn auch vereinfachen.)
Zu Mobilbrowsern kann ich leider nichts sagen. Wenn aber inherit eingeführt wird, dann am besten für alle sinnvollen Attribute auf einmal. Folgende Attribute sollte geprüft werden: padding, border, vertical-align. --Fomafix (Diskussion) 12:17, 4. Okt. 2013 (CEST)
Hm, okay. Nach meinen Tests ist allerdings border-color die einzige Eigenschaft, bei der die Vererbung auch im IE 7 funktioniert. border-style und border-width funktionieren nicht, padding und vertical-align sowieso nicht; ich denke, der IE bildet damit das Verhalten der alten HTML-Attribute border und bordercolor einigermaßen sinnvoll nach:
Äußere Rahmenlinien haben in reinen HTML-Tabellen immer denselben Stil (außen outset, innen inset).
border=n setzt nur die Stärke der äußeren Linien, die inneren haben immer 1px.
bordercolor=#rrggbb setzt die Farbe aller Rahmenlinien.
Ob man den IE 7 wirklich schon abhängen sollte, weiß ich nicht; wenn Bug 25378 gefixt wäre, wäre das leichter (bis jetzt kann noch jeder im IE den Button „Kompatibilitätsansicht“ drücken und sich damit einen verkappten IE 7 einhandeln und im Zweifelsfall das Layout zerschießen).
Vielleicht sollte man noch etwas abwarten, bis das in MediaWiki deaktiviert wird (oder man weiß, dass es nicht deaktiviert wird). Es wäre die Frage, ob man unterdessen die rahmenfarbeX-Klassen wie zu Anfang vorgeschlagen anpassen will. --Entlinkt (Diskussion) 17:48, 4. Okt. 2013 (CEST)
Ich habe mittlerweile gelernt, dass auf Diskussionsseiten vor sich hingammelnde Abschnitte mit konkreten Codevorschlägen gefährlich sind, weil die Gefahr besteht, dass sie Jahre später noch umgesetzt werden, obwohl sie problematisch sind. Unter anderem haben wir neuerdings eine Regel, die in 3 von 4 Skins eine farbliche Kleinständerung von Links auf der Beobachtungsliste bewirkt, im vierten Skin allerdings eine größere und IMHO falsche Änderung, und die nach zwei Jahren vor sich hingammelnder Diskussion noch umgesetzt wurde, obwohl sogar dabei stand, dass sie nicht ausgereift ist.
Deshalb: Ich halte ganz konkret meinen eigenen Codevorschlag vom Oktober 2013, der bei uns lokal inherit-Verhaltensweisen für wikitable einführen würde, für eine nicht nur nicht besonders gute, sondern sogar ziemlich üble Sache und habe längst aufgehört, ihn zu testen. Auch die Aussagen zur Browserkompatibilität sind völlig veraltet.
Da es rund um wikitable in der Vergangenheit viel Ärger und Verwirrung gab und der jetzige Zustand („wikitable kommt von MediaWiki und ist bei uns genau so wie überall sonst“) nun schon eine ganze Weile besteht und meiner Meinung nach recht gut funktioniert, bin ich mittlerweile der Meinung, dass wir an der wikitable-Definition überhaupt gar nichts lokal verändern sollten.
Allenfalls könnte ich mir noch vorstellen, unsere lokal definierten Klassen für Rahmenfarben zu ändern, so dass sie mit wikitable kombiniert werden können. Das war ja auch der ursprüngliche Vorschlag, würde allerdings die 5 Definitionen ziemlich aufblähen. (Mein Vorschlag vom Oktober 2013 vermeidet das Aufblähen an 5 Stellen und bläht dafür nur an einer Stelle auf, hat dafür aber eine ganze Reihe von anderen Nachteilen; ich beschränke mich hier mal auf den Punkt, dass so eine Änderung an einer im MediaWiki-Core definierten Klasse natürlich aktuell gehalten und allgemein zugänglich dokumentiert werden müsste, was erfahrungsgemäß nicht geschieht.) --Entlinkt (Diskussion) 02:10, 23. Apr. 2016 (CEST)
Letzter Kommentar: vor 2 Jahren16 Kommentare6 Personen sind an der Diskussion beteiligt
Bitte den ganzen „hauptseite“ Quatsch entfernen, dabei gleich prettytable (die 50 Einbindungen die es noch gibt wird man schon verkraften und dann evtl. auch eher bemerken...) Ich besuche die Hauptseite zweimal im Jahr und dennoch rattert der Schwall an Definitionen bei jedem Seitenaufruf hoch und runter, selbst die En hat sowas nicht obwohl dort die .css mehr als doppelt so groß ist.
/* Bitte KEINE weiteren Definitionen dieser Art für Boxen hier, das gehört in entsprechende Vorlagen! */
/* Hier 20 Mal Trivialitäten wie „text-align:center“ zu definieren verlangsamt alles und ist nicht */
/* Sinn der Sache. (Und wer nicht weiß warum, hat's nicht verstanden.) */
Solange Entlinkt nicht wieder aktiv wird, wird hier auch nicht viel passieren. So viele Admins, die in CSS sattelfest sind und hier aufräumen wollten haben wir nicht.
Oh* da habe ich mich wohl verlesen und etwas untertrieben. ^^ Ich finde es aber schon beachtlich, wie Meme so funktionieren. prettytable war (wohl eigentlich?) nie in einer deutschen Anleitung für Wiki-Syntax (und da wo sie wohl irgendwie erfunden wurde in En ist sie schon gelöscht)!? Der Abschnitt soll bewirken, dass wir alle Energie und Zeit sparen und uns leichtertige Verschwendung von Ressourcen bewusst machen. Das mit der Hauptseite ist wirklich der Overkill schlecht hin, was man unter CSS technischen Kosten/Nutzen versteht. Ich würde alle classes auf der Seite auflösen und bei längeren einen Baustein erstellen (z.B. wie {{Bausteindesign8}}...) PS: Wenn etwas dagegen spricht würde ich einen Phab-Task extra für die deutsche Hauptseite eröffnen. VG ↔ User: Perhelion20:46, 2. Jun. 2015 (CEST)
Was zum Henker hat eine deWP-Hauptseite auf Phab verloren?
Was immer du vorhast, es gehört auf unsere Hauptseiten-Disk.
Und ohne einen in Vorlagenprogrammierung und CSS erfahrenen Admin, der sich der Sache annähme, wird da Null bei rauskommen, egal wie viel du wo diskutierst.
Nebenbei ist <kbd> reserviert für die semantische Bedeutung Tastatureingabe und kein Ersatz für tt oder code.
Mittlerweile kann man wohl alles in Phab eintragen (und die Hauptseite oder die globale CSS ist ja wohl nicht unwichtig!?), vor allem da dort die "kompetenten Leute" sitzen im Gegensatz zu hier (wie du sagst).
Ja du hast Recht, ich sollte das zuerst auf der Hauptseite vortragen.
Dass es keine kleine Minderheit von technisch "wissenden" Admins gibt, hatte ich nicht gewagt zu befürchten.
Ja, das ist die Sache die ich nicht verstehe, dass Elemente als deprecated eingestuft sind und es dafür keinen wirklichen Ersatz gibt.
Was du auf Phab mit irgendeinem Japaner auf Englisch ausdiskutierst, ist völlig wuascht; egal ob du es dürftest oder nicht.
Du müsstest dir überlegen, wer in die Programmierung unserer Hauptseite eingreifen soll.
Das kann nur ein hiesiger Admin sein.
Der hätte aber Phab nicht auf der Beo, sondern nur unsere Seiten.
Insofern ein von vornherein zum Scheitern verurteilter Arbeitsprozess.
Eher: Such dir erst einen Admin, der genug CSS usw. kann und Langeweile hätte, und wenn du den hast, geh die Details an, und zwar hierzuwiki.
HTML5 ist in die Semantik gegangen; und zwar nur noch.
HTML 2, 3 und überwiegend auch noch 4 waren typografisch/darstellend.
Die optische Wirkung erfolgt jetzt nur noch, indem du ausschließlich <span> verwendest und jedem einzelnen Element per class oder style das optische Aussehen mitgibst. Die unterschiedlichen Elemente ordnen nur noch die unterschiedlichen Bedeutungen zu.
Insofern braucht es keinen Ersatz zu geben, und dieses ganze Gedöns von deprecated ist für ein Wiki völlig verfehlt. Nimm <code> und gut ist.
Der Kontext, wo es herstammt, ist konfus, aber das Teil gefällt mir:
Ich halte nichts davon, thematisch fremde Dinge per Komma-Schreibweise zu verbinden, damit die Seite entschlackt wird. Für die Wartbarkeit ist es erheblich besser, wenn jede einzelne Anweisung ein Kommentar hat und man damit weiß, wofür sie da ist.
Das die Hauptseite keine eigene Seite für CSS-Anpassungen hat, ist unschön, aber nicht zu ändern. Es soll auch Benutzer geben, die über die Hauptseite einsteigen (als Lesezeichen) oder sie sogar als Startseite im Browser verwenden. Es soll auch Benutzer geben, die persönliche Anpassungen für die Hautpseite in der user.css haben, die dann auch nicht mehr so einfach wirken. Daher resultiert für mich kein Änderungsbedarf aus diesem Abschnitt. Der Umherirrende21:28, 17. Jul. 2015 (CEST)
Ich benutze diesen Thread einfach mal, um hier ein ganz und gar subjektives Code-Review zu deponieren. Keine der folgenden Bewertungen soll aussagen, dass irgendetwas gemacht werden soll oder muss, sondern es sind nur Ideen. Zeilennummern beziehen sich auf diese Version.
Zeile
Bewertung
Handlung
7–9
Unfug
löschen
28–30
Altbestand
–
33–65
sinnvoll
–
68–80
IE-6-Workaround
löschen (auch die Vorlage): Wurde deshalb angelegt, weil das automatische Verschmelzen im IE 6 nicht funktioniert. Leider sieht die Vorlage in heutigen Browsern minimal anders aus als das automatische Verschmelzen. (Beachte aber, dass der heutige, wertende Beschreibungstext „Das sieht homogener aus als Einzelvorlagen“ aus dem Jahr 2008 stammt und sich damit möglicherweise immer noch auf den großen optischen Unterschied im IE 6 bezieht und nicht auf den Minimalunterschied in heutigen Browsern.) Man hätte das Aussehen auch damals schon IE-6-kompatibel angleichen können, dies wurde aber verpennt. Wegen des minimal anderen Aussehens kann es leider Widerstand geben.
86–105
angestaubt
insource:sidebox hat noch 49 Treffer im Artikel- und Vorlagennamensraum, Löschung anpeilen
108–133
Altbestand
– (aber siehe 113–115)
113–115
redundant
Verifiziere, dass jede Verwendung von taxobox auch float-right hat und lösche diese Zeilen
136–149
Unfug
Verifiziere, dass Thumbnails in Taxoboxen nicht mehr vorkommen und lösche diese Zeilen
163–181
Betriebsunfall
Wird Jahre dauern, bis die Verwendungen weg sind (aber irgendwann kommt der Zeitpunkt, siehe auch 86–105)
184–186
ist halt da
–
188–213
OK
–
216–219
ist halt da
–
227–296
Altbestand
–
298–301
Upstream-Kandidat
Kläre, ob dies in MediaWiki aufgenommen werden kann (ggf. mit dieser Ergänzung)
303–311
sind halt da
–
313–339
Systemnachrichten
CSS zu Systemnachrichten ist mir weitgehend egal, weil ich eh nicht weiß, wie das offiziell gedacht ist
346–357
so lala
Die englische Wikipedia kommt ohne solche Regeln aus. Vielleicht wäre es doch besser gewesen, bei der Verwendung von plainlinks zu bleiben, aber die Praxis ist jetzt schwer zu ändern, die Community wird keine Lust auf eine solche Änderung haben.
367–382
ist halt da
– (Effekt ist nicht anders erreichbar)
385–387
wirkungslos
löschen (hatte früher eine Wirkung, jetzt mit display:table-cell nicht mehr)
Kläre, ob dies in MediaWiki aufgenommen werden kann
415–461
Systemnachrichten
CSS zu Systemnachrichten ist mir weitgehend egal, weil ich eh nicht weiß, wie das offiziell gedacht ist
468–487
durch IE-7/8-Workaround aufgebläht
eindampfen
490–498
Systemnachrichten
CSS zu Systemnachrichten ist mir weitgehend egal, weil ich eh nicht weiß, wie das offiziell gedacht ist
501–503
Ballast
Ehedem für die semantische Auszeichnung von IPA vorgesehen, wird es heute in der Vorlagenprogrammierung faktisch dafür benutzt, entgegen der Benutzereinstellung die Linkunterstreichung für alle möglichen Links zu entfernen, egal wie wenig sie mit IPA zu tun haben. Eventuell als Lehrbeispiel für Anti-Patterns behalten.
506–521
FlaggedRevs
FlaggedRevs-Kram ist mir weitgehend egal, da es eh kaum noch gepflegt ist (z. B. gibt es doppelt nebeneinander vorhandene Boxen(!), die seit Jahren niemandem mehr auffallen, weil man den Anblick längst gewohnt ist). Evtl. klären, ob es die Sitenotice auf der Beobachtungsliste überhaupt noch gibt.
529–531
Potenzieller Upstream-Bug
Evtl. Ansichtssache. Ich meine, ich hätte es vor Jahren sogar mal gemeldet und es wäre als ungültig geschlossen worden.
535–545
verbuggt
Die Art der Ausblendung (display:none vs. visibility:hidden) passt immer noch nicht in allen Fällen. Außerdem wäre es an sich ja sinnvoll, ungenutzte Dinge wirklich abzuschalten, anstatt sie nur auszublenden.
548–550
ist halt da
IMHO unnötige Änderung, aber kürzlich erst durchgerutscht
554–556
sinnvoll
–
559–561
Potenzieller eigener Fehler
Bin selbst nicht mehr sicher, ob das eine gute Idee war, aber da es sonst keiner entfernt, bleibt es vorerst
564–566
Upstream-Kandidat
Kläre, ob dies in MediaWiki aufgenommen werden kann
571–635
Unantastbar
Da dies durch ein Meinungsbild zustandegekommen ist, kann es auch nur durch ein Meinungsbild geändert werden
Danke Entlinkt. Dabei möchte ich erst mal nur auf den Kommentar vom Umherirrenden eingehen, ich sehe das ganz anders (ich verstehe immer noch nicht wieso man standardmäßig alle seine Beiträge als geringfügig markiert, so sehe ich niemals Antworten von ihm (in der Beo) ist ja auch nicht so, dass dies nicht erwünscht ist).
Die Hauptseite kann wie jede andere "Projekt"-Seite CSS per Vorlage oder sogar prädestiniert direkt CSS einbinden. Es ergibt gar keinen Sinn hier globale Definitionen für eine einzelne Seite zu fordern, das führt diese Technik und diese Seite ein Stück weit ad absurdum. Die Definitionen können alle in Vorlagen versteckt werden (zumal auch der Umherirrende eh generell eine Trennung/Zerstückelung bevorzuzugen scheint). Und falls es wirklich einen Layout-Engpass gibt, gibt es immer noch eine (wohl seit letztem Jahr neue) Technik, nur für einzelne Seiten CSS (oder sogar JS, Lua) anzulegen. Grüße ↔ User: Perhelion23:05, 28. Mär. 2016 (CEST)
In Bezug auf das Hauptseiten-CSS würde ich gern auf das Folgende hinweisen: Zunächst mal kann man diesbezüglich wohl durchaus den Standpunkt vertreten, dass das externe CSS tatsächlich sinnvoll sei (zwecks Anpassbarkeit); außerdem ist es die Umsetzung eines Meinungsbilds (von 2006) und deshalb etwas heikel (spezialisierte Wikijuristen können sagen, dass das Meinungsbild nicht nur das Aussehen der Hauptseite, sondern auch die Umsetzung durch externes CSS vorgibt, vielleicht hätten sie damit sogar recht – habe ich jetzt nicht nachgeprüft).
Darüber hinaus werden die Definitionen aber auch in großem Maßstab außerhalb der Hauptseite verwendet (Suchanfrage, 2000 Treffer in allen Namensräumen).
Zum weitaus größten Teil sind das die Seiten der Kategorie:Wikipedia:Hauptseite/Archiv. Diese Seiten kann man nicht einfach brechen, weil das den Zweck der Kategorie ad absurdum führen würde. Sicherlich ließe sich hierfür eine Lösung finden.
Es gibt allerdings auch Portalseiten: Portal:Segeln, Portal:Segeln/Mitarbeit, Portal:Wirtschaft/Projekt:Wiwiwiki Organizational Behaviour/t. Die erste dieser drei Seiten hat sogar eine Auszeichnung. Man müsste sich darauf einstellen, dass für jede einzelne betroffene Seite einzeln ausdiskutiert werden muss, warum dort überhaupt etwas geändert werden muss und wenn ja, was – mit offenem Ergebnis. Man sollte nämlich nicht so naiv sein, zu glauben, dass ein Beschluss auf einer CSS-Diskussionsseite „Wir entfernen jetzt das Hauptseiten-CSS“ einfach so akzeptiert wird. Wikipedianer (speziell :de-Wikipedianer) sind Besitzstandswahrer und geben nicht so einfach her, was sie einmal hatten. Im Zweifelsfall kommt das „Argument“ If it ain't broke, don't fix it.
Für mich persönlich das größte Hindernis sind allerdings die 88 Benutzerseiten (Suchanfrage). Ganz ehrlich: Die Auseinanderzusetzung damit kommt für mich auf keinen Fall in Betracht. Während Wikipedianer bei Artikeln und Vorlagen „nur“ besitzstandswahrend auftreten, können sie richtig widerwärtig werden, sobald es um ihre Benutzerseiten geht. Als Beispiel verweise ich mal auf die Diskussion unter en:Template talk:Top icon#Sorting. Dort geht es darum, dass kleine Icons auf Benutzerseiten nach einer grob vergleichbaren Umstellung (von einem CSS-Hack auf das dafür vorgesehene Softwarefeature) in einer anderen Reihenfolge als vorher angezeigt werden und Benutzer fordern, dass das Ganze zwecks Wiederherstellung des Aussehens ihrer Benutzerseite zurückgedreht wird, obwohl im Vorfeld explizit davor gewarnt wurde, dass der CSS-Hack jederzeit brechen kann. So absurd dies auch sein mag (und so idiotisch es auch sein mag, sich zwecks Gestaltung der eigenen Benutzerseite auf eine ID namens hauptseite zu verlassen), ist dies die Realität. Es hat irgendwann einmal funktioniert (und deshalb – so sagen es manche – bis in alle Ewigkeit weiter zu funktionieren) … Nein, hier fällt die Abwägung zwischen Optimierung und Lebenszeit/Lebensqualität für mich ganz klar zugunsten der Lebenszeit/Lebensqualität aus.
In diesem Punkt (Hauptseiten-CSS) wäre es wahrscheinlich strategisch günstig, ein allgemeines (optisches) Redesign der Hauptseite abzuwarten und zu schauen, ob in diesem Zusammenhang dann eine bessere Lösung für das CSS gefunden werden kann.
Dies habe ich jetzt deshalb so ausführlich dargelegt, um nochmal klarzumachen, dass jede einmal hier einfügte Ergänzung im Worst-Case niemals wieder entfernt werden kann. Das ist ein allgemeineres Problem als das Hauptseiten-CSS und betrifft selbst solche Ergänzungen, die für ihren eigentlich vorgesehenen Zweck überhaupt nicht mehr funktionieren (vgl. nogrid-Beispiel). Gruß --Entlinkt (Diskussion) 01:47, 18. Apr. 2016 (CEST)
Sobald aus phab:T483 etwas wird, könnte man das CSS für die Hauptseite zum größten Teil in eine Vorlage auslagern und dann dort einbinden, wo es gebraucht wird. --Schnark09:57, 18. Apr. 2016 (CEST)
Daran wird aktuell gearbeitet? Ist ja krass. Weitere denkbare Anwendungsanfälle:
Vorlagen mit eigenem CSS, das noch nicht in andere Vorlagen bzw. direkt in Artikel geleakt ist:
Danke erstmal für die ausführlichere Darlegung, das sieht für mich alles überaus vorsichtig aber besonnen aus (ich glaube als WMF-Mitarbeiter würdest du es schwer haben :P). Rücksicht auf irgendwelche "Userhacks" ist wohl tatsächlich das Maximum der Gefühle (vllt auch einfach aus dem Grund dass man sich als etwas technisch Versierter aus der schlichten Erfahrung her keiner Illusion mehr ergibt).
Das hauptseitenartig formatierte ausgezeichnete Portal:Segelnlebt noch. (Ein paar – sinnvolle – Formaledits sind übrigens eine ganz gute Strategie, um das herauszukriegen.)
Meiner Meinung nach sollten wir am Hauptseiten-CSS vorerst nichts ändern, bis eines der folgenden Ereignisse eintritt: (1) Optisches Redesign der Hauptseite aus der Community heraus oder (2) neue Softwaremöglichkeiten (phab:T483). Sonst würde die Frage aufgeworfen werden, warum wir hier etwas ändern bzw. andere etwas ändern sollen, und ob wir nichts Besseres zu tun haben.
Wenn sich äußere Umstände ändern, werden die „Mitbenutzer“ des Hauptseiten-CSS vielleicht sogar selbst eine Änderung wünschen, im Zweifelsfall ist eine Änderung dann leichter zu begründen. Momentan wäre die einzige Alternative sowieso Inline-CSS, was nicht nur Vorteile hat (phab:T37704).
Zum Hauptseiten-CSS ist das auch alles, was mir momentan einfällt … aber meiner Meinung nach dürfte zum Beispiel der Abschnitt „Verunstaltung von Thumbnails in Taxoboxen“ bald reif zum Entfernen sein. Da müsste man sich nur die Zeit nehmen, alles sorgfältig zu durchsuchen. Gruß --Entlinkt (Diskussion) 01:20, 19. Apr. 2016 (CEST)
Ich entferne jetzt die Regel „Verunstaltung von Thumbnails in Taxoboxen“, also folgendes:
Gründe, warum es eingefügt wurde, findet man noch immer auf der Seite Wikipedia Diskussion:Taxoboxen. Irgendwie scheint es wohl damals darum gegangen zu sein, dass man sich nicht einigen konnte, ob das Bild in einer Taxobox ein Thumbnail sein sollte oder nicht. Das Ergebnis war dann diese Regel, die bewirkt, dass Thumbnails in Taxoboxen nicht wie Thumbnails aussehen.
Zur damaligen Zeit bestanden Taxoboxen aus Tabellen (basierend auf einer Formatvorlage) direkt im Artikel, dies wurde irgendwann 2007 auf Vorlagenprogrammierung umgestellt.
In der programmierten Vorlage wurde die Bildeinbindung dann im Januar 2008 von den Biologen selbst umgestellt und ist seither kein Thumbnail mehr gewesen. Bereits dadurch ist der eigentliche Zweck dieser Regel entfallen.
In den Jahren 2013 und 2014 habe ich einige Sekundärverwendungen bereinigt, insbesondere Bachkantaten und Viren.
Im Juli 2014 habe ich die Regel als veraltet markiert, dagegen gab es nie Widerstand.
Suchanfrage für verbleibende Verwendungen: 127 Treffer in allen Namensräumen für den String "taxobox". Das ist genau genug, da die Klasse zu Zeiten ihrer aktiven Verwendung außerhalb von Vorlagen nicht mit anderen Klassen kombiniert wurde. Ein Großteil der Treffer enthält überhaupt keine Thumbnails oder betrifft uralte, längst obsolete Diskussionen oder die Bildeinbindung ist sowieso defekt. Nach Abzug solcher Treffer verbleiben 49 Benutzerseiten:
Ich habe den Eindruck, dass das Entfernen der Regel bei keiner einzigen dieser Seiten ein ernsthaftes Problem darstellt, da es sich entweder um aufgelassene Entwürfe handelt, wo man die Taxobox sowieso auf die Vorlage umstellen müsste, oder der jeweilige Benutzer nicht mehr aktiv ist.
Das Entfernen der Regel hat folgende Vorteile: Das allgemeine CSS wird übersichtlicher und es entfällt ein seit Ewigkeiten nicht mehr dokumentierter „Spezialeffekt“.
Alte – zum größten Teil sehr alte – Artikelversionen sehen durch das Entfernen anders aus als vorher, sind aber immerhin noch lesbar.
Ob nun 118 oder 116 Prozent besser passt hängt vom persönlichen Geschmack ab. Ich würde vorschlagen mit 118 zu beginnen und dann ggf weiter anzupassen.
Die Standardschriftgröße der häufig genutztesten Browser ist 16. Bei Bruchteilen von 16 kommen dann in der Regel gerade Zahlen heraus: 118.75% = 19/16 => in den meisten Fällen Schriftgröße 19 statt Standard 16. Frohes Schaffen — Boshomi⌨19:21, 18. Apr. 2016 (CEST)
Die Standardschriftgröße des Wurzelelements ist 16px, falls der Benutzer dies nicht verstellt hat. Die MediaWiki-Skins ändern dies aber, und zwar auf ziemlich unterschiedliche Weise. Derzeit so, wie in der folgenden Tabelle dargestellt. Bitte hierbei auch folgendes beachten:
Relative Angaben in em oder % beziehen sich immer auf das Elternelement im DOM und nicht etwa auf die Standardgröße des Wurzelelements.
Ist für ein Element keine Schriftgröße definiert, wird die des Elternelements geerbt.
In CSS gilt immer72pt = 96px = 1in, also insbesondere 3pt = 4px.
Die Bedeutung von x-small ist hier spezifiziert, faktisch gilt aber derzeit in allen mir bekannten Browsern x-small = 10px.
Nicht-ganze Pixelwerte werden während des Vererbungsprozesses nicht gerundet, sondern erst ganz am Ende.
Element
Vector
Monobook
Modern
Cologneblue
Definition
Ergebnis
Definition
Ergebnis
Definition
Ergebnis
Definition
Ergebnis
html
100%
16px
–
16px
–
16px
–
16px
body
–
16px
x-small
10px
x-small
10px
–
16px
div#globalWrapper
–
–
127%
12.7px
–
–
–
–
div#column-content
–
–
–
12.7px
–
–
–
–
div#content
–
16px
–
12.7px
–
–
–
16px
div#bodyContent
0.875em
14px
–
12.7px
–
–
–
–
div#mw_main
–
–
–
–
130%
13px
–
–
div#mw_contentwrapper
–
–
–
–
–
13px
–
–
div#mw_content
–
–
–
–
–
13px
–
–
div#mw_contentholder
–
–
–
–
–
13px
–
–
div#article
–
–
–
–
–
–
10pt
13.333px
div#mw-content-text
–
14px
–
12.7px
–
13px
–
13.333px
Speziell das, was in Monobook passiert, will man eigentlich gar nicht glauben, es ist aber wirklich so. Der von Benutzern eingegebene Wikitext befindet sich dann letztlich bei allen Skins in dem Element div#mw-content-text – mit je nach Skin sehr unterschiedlicher Schriftgröße. Gruß --Entlinkt (Diskussion) 19:39, 18. Apr. 2016 (CEST)
Bei Vector war div#bodyContent einst (April 2014) auch .8125em, denn das hatte ich in meinem common.js auf 0.875 ausgebessert. Schriftgröße 13 war mir zu klein. Frohes Schaffen — Boshomi⌨20:56, 18. Apr. 2016 (CEST)
Also, um mal wieder zum eigentlichen Thema zurückzukommen:
Aufgrund der Diskussion in phab:T132607 und aufgrund von Edokters Aussage hier liegt die zu klein aussehende Schrift überhaupt nicht an der Schriftgröße, sondern an der vom Browser benutzten Schriftart, und Edokter hat den Wert 118% so zusammengehackt, dass es „in Firefox“ (ohne Angabe eines Betriebssystems) gut aussieht.
Es ist ein bekanntes Phänomen, dass Benutzer eine zu geringe Schriftgröße bemängeln, dies in Wirklichkeit aber an der Schriftart liegt (vergleiche dazu beispielsweise diese Diskussion). Dies kommt dadurch zustande, dass unterschiedliche Schriftarten bei nominell gleicher Größe aufgrund ihrer Gestaltung unterschiedlich groß aussehen.
Insofern muss man leider sagen, dass in der Umfrage über etwas abgestimmt wurde, was technisch evtl. überhaupt nicht möglich ist (Vereinheitlichung der wahrgenommenen Schriftgröße geht nicht, wenn der Browser verschiedene Schriftarten verwendet, die höchstwahrscheinlich auch noch vom Schriftarten-Angebot des Betriebssystems abhängen). Dies (Abstimmen für eine Sache, die gar nicht umsetzbar ist) ist ein grundsätzliches Problem bei Umfragen und Meinungsbildern über technische Themen.
Ob wir den Hack übernehmen sollten – ich weiß es nicht. Aber wenn wir ihn übernehmen, wäre ich jetzt aus dem Bauch heraus erstmal dafür, ihn 1:1 zu übernehmen und auch in Zukunft Änderungen nachzuziehen, da ich nicht sehe, dass jemand bei uns bereit wäre, das Ganze zu pflegen. (Inhaltlich habe ich das Ganze noch gar nicht geprüft.) --Entlinkt (Diskussion) 22:30, 18. Apr. 2016 (CEST)
Etwas weniger von der Schriftart abhängig wäre font-size-adjust. Aber irgendetwas in dieser Richtung in die common.css aufzunehmen, widerstrebt mir. Wenn das CSS nicht in die Extension aufgenommen wird, weil es eben keinen für alle Nutzer guten Wert gibt, dann sollte die Reaktion nicht sein, dass alle Wikis sich auf einen Wert einigen und den dann per Copy&Paste&Zufall irgendwie in globalen CSS-Dateien verteilen. --Schnark11:07, 19. Apr. 2016 (CEST)
Ich weise auch hier wieder auf die Datei modules/libpref/init/all.js des Mozilla-Quellcodes hin. Ich bin zwar weit davon entfernt, den Mozilla-Quellcode zu verstehen, vermute aber sehr stark, dass in dieser Datei konfiguriert ist, welche Schriftarten Firefox für MathML benutzt. Konkret meine ich die Einträge mit Inhalt x-math. Natürlich ist das plattformabhängig und deshalb durch die folgenden Präprozessor-Symbole eingeschränkt: XP_WIN, XP_MACOSX, MOZ_B2G und ANDROID.
Hinweis: Unter phab:T132607#2233714 kann man mittlerweile nachlesen, warum in enwiki ausgerechnet der Wert 118% gewählt wurde, und zwar deshalb, weil die x-Höhe von Arial (angeblich) gerade 118 Prozent der x-Höhe von Times New Roman beträgt.
Mit anderen Worten: Der Wert ist genau auf bestimmte Schriftarten abgestimmt, die derzeit auf Windows-Systemen weit verbreitet sind, jedoch nicht auf anderen Systemen und möglicherweise auch nicht auf zukünftigen Windows-Systemen.
Falls eine Regel in der Art der hier vorgeschlagenen aufgenommen wird, sollte das Zustandekommen des gewählten Werts also unbedingt in einem Kommentar dokumentiert werden. Andernfalls wird folgendes passieren:
In den derzeit verbreiteten Windows-Systemen mag der gewählte Wert eine Angleichung der Schriftgrößen bewirken, aber mit den Jahren werden sich neue Betriebssysteme mit neuen Schriftarten etablieren, so dass der gewählte Wert keine Angleichung mehr bewirkt, sondern etwas anderes (zum Beispiel eine Formeldarstellung, die größer als der Haupttext ist). Wenn kein Kommentar vorhanden ist, gerät die ursprüngliche Intention der Regel in Vergessenheit und man beginnt zu glauben, ihr Zweck sei eine vergrößerte Formeldarstellung. Nachdem dieser Zustand ein paar Jahre bestanden hat, kann man die Regel nicht mehr ändern oder entfernen, weil irgendwer die vergrößerte Formeldarstellung unbedingt behalten will.
Zur Erklärung: Einfügt wurde die Regel 2008 mit dem Kommentar „Übernommen von commons. Soll bei Leuten mit "Auto-Link-Unterstreichen" helfen“, eine zugehörige Diskussion konnte ich nicht finden. Tatsächlich existierte die Regel in commons:MediaWiki:Common.css zum damaligen Zeitpunkt nicht (und existiert auch jetzt nicht), sehr wohl existiert sie aber zum Beispiel in en:MediaWiki:Common.css.
Der Zweck der Regel ist vermutlich folgender: Einerseits enthalten IPA-Ausspracheangaben oft diakritische Zeichen und sind daher schwer zu lesen, wenn sie unterstrichen sind. Andererseits gibt es eine – möglicherweise nicht jedem bekannte – Benutzereinstellung (auf Spezial:Einstellungen#mw-prefsection-rendering unten im Abschnitt „Erweiterte Optionen“), mit der man auswählen kann, ob Links unterstrichen sein sollen oder nicht. Diese Benutzereinstellung ist in ResourceLoaderUserCSSPrefsModule.php implementiert.
Standardmäßig sind Links in den Skins Vector, Monobook und Modern normalerweise nicht unterstrichen, werden aber beim Hovern (Überfahren mit der Maus) und in Vector und Monobook auch beim Fokussieren (z. B. mit den Tabulatortasten) unterstrichen. Nur in Cologneblue sind Links standardmäßig immer unterstrichen. Die Regel soll wohl in erster Linie bei denjenigen Benutzern die Linkunterstreichung entfernen, die die entsprechende Benutzereinstellung oder den Cologneblue-Skin verwenden (zusammengefasst unter der Bezeichnung „Auto-Link-Unterstreichen“).
Leider schießt sie aber über das Ziel hinaus und entfernt bei allen Benutzern sowohl den Hover-Effekt als auch den Focus-Effekt (Beispiel: [ˈbaɪ̯ʃpiːl]). Ich habe dies unter Vorlage:IPA und Wikipedia:Lautschrift#Darstellung in Browsern dokumentiert, weil es seit 8 Jahren der Realität entspricht, finde es aber extrem störend, da ich den violetten Farbton besuchter Links nur schwer von schwarz unterscheiden kann und daher gewohnheitsmäßig den Hover-Effekt nutze, um Links zu erkennen, was bei IPA-Links durch unsere Regel verunmöglicht wird.
Deshalb, und weil der jetzige Zustand ursprünglich vermutlich auch gar nicht beabsichtigt war, sondern durch reine Unachtsamkeit entstanden ist, schlage ich vor, beide Effekte mit obengenannter Codeänderung wiederherzustellen. (Mich persönlich stört das Entfernen des Focus-Effekts weniger als das Entfernen des Hover-Effekts, aber wenn wir die Nebeneffekte der Regel schon beseitigen, können wir das gleich vollständig tun.) --Entlinkt (Diskussion) 04:26, 22. Apr. 2016 (CEST)
Das :not() würde dazu führen, dass die Regel in IE <= 8 und FF <= 3 gar nicht mehr wirkt. Ich glaube nicht, dass die Zahl der Benutzer solch altertümlicher Browser mit Cologneblue bzw. "Links unterstreichen: immer" groß ist, aber wer weiß. Auch bin ich mir unsicher, ob die Unterstreichung wirklich auch beim Fokusieren zu sehen sein sollte. Beim Hovern kann man den Text ohnehin nicht wirklich lesen, da die Maus ihn teilweise verdeckt, sodass die Unterstreichung auch nicht weiter stört, fokusieren kann man den Link aber wie gesagt auch mit der Tastatur. Auch das wird sicher nicht von vielen gemacht, allerdings ist in meinen Augen die Nützlichkeit des Links auf die Liste der IPA-Zeichen jetzt auch nicht gerade so überwältigend groß, dass es unbedingt erforderlich ist, dass der Link immer deutlich als Link zu erkennen ist. Tendenziell bin ich also eher gegen eine Änderung. --Schnark09:53, 22. Apr. 2016 (CEST)
Nur mal so der Vollständigkeit halber:
Die Klasse wird unter anderem auch in MediaWiki:Onlyifediting.js verwendet (also in der Werkzeugleiste unter dem Bearbeitungsfenster, zum Einfügen einzelner IPA-Zeichen).
Die Klasse wird auch in IPA-fremden Vorlagen verwendet:
Für IPA-fremde Vorlagen würde die Attraktivität der Klasse durch die vorgeschlagene Änderung stark sinken (ich vermute sogar, dass sie dort nur wegen des Abschaltens der Effekte verwendet wurde). Beim Focus-Effekt bin ich selbst unsicher (ich hatte das im Vorschlag zuerst nicht drin und habe es dann aufgenommen, damit klar ist, wie man diesen Effekt behandeln kann). Allerdings ist durch den Focus-Effekt derzeit bei fast allen Links folgendes möglich: Aktiviert man den Link mit der Maus und lässt ihn wieder los, bleibt der Link unterstrichen (bis man irgendwo anders klickt). So kann man bestimmte Links temporär „markieren“, auch das wird durch die Definition verhindert. Andererseits haben die meisten Browser schon eine eigene Hervorhebung für Links, die mit der Tastatur fokussiert wurden.
Falls :not() ein Problem ist, lässt sich die vorgeschlagene Änderung (sinngemäß) auch ohne dies formulieren, das würde ich aber eher nicht machen (da es den Code weiter aufblähen würde) und es in dem Fall lieber beim status quo belassen. --Entlinkt (Diskussion) 16:41, 22. Apr. 2016 (CEST)
Ja, die Klasse IPA wurde in die Chemie-Vorlagen nur eingeführt, um die Unterstreichung zu entfernen: [4]
Dass bei nicht unterstrichenen Links die Unterstreichung auch beim Hovern und Fokusieren fehlt, ist übrigens konsistent mit MW: elements.css entfernt die Unterstreichung von Links für einige Sprachen mit arabischer Schrift, und zwar nach der Regel, die die Unterstreichung für Hover und Fokus setzt. Ich unterstelle einfach mal, dass es dort Absicht ist. --Schnark09:11, 23. Apr. 2016 (CEST)
Das halte ich in der Tat für ein stichhaltiges Argument.
Die Arabisch-Regel in mediawiki.skinning/elements.css kommt übrigens ebenfalls in der Werkzeugleiste unter dem Bearbeitungsfenster zur Geltung. Und ja, der Effekt dieser Regel ist beabsichtigt, sogar durch eine aktuelle Änderung aus dem Dezember 2015. Hätte ich auch sehen können.
Vorsicht:text-decoration ist eine ganz, ganz fiese CSS-Eigenschaft, die im Gegensatz zu vielen anderen Eigenschaften der Textformatierung nicht vererbt, sondern propagiert wird. Es ist daher nicht möglich, allein mit text-decoration:none im Inline-CSS die Unterstreichung eines Elements zu entfernen, wenn ein Elternelement text-decoration:underline vorgibt. Um das per Inline-CSS zu erreichen, muss man schon zu härteren Mitteln wie display:inline-block greifen. Demonstration:
Vermutlich wurde die Klassendefinition vor vielen Jahren geschaffen, weil die Lösung mit display:inline-block seinerzeit nicht in allen Browsern existierte oder nicht bekannt war. Darüber hinaus hätte die Lösung mit display:inline-block auch Nebenwirkungen, unter anderem werden normale Zeilenumbrüche unmöglich. Darüber hinaus bin ich aber nach wie vor der Meinung, dass Vorlagen in aller Regel die gewöhnliche Linkformatierung nicht verändern sollten (und es auch nicht brauchen, da Links unter „gewöhnlichen“ Umständen sowieso fast nie unterstrichen sind). Im Zweifelsfall versucht man einfach, den Link woanders unterzubringen aus ausgerechnet an einer Stelle, wo eine Unterstreichung so schlimm wäre, dass sie mit allen Mitteln verhindert werden muss. Bei diesem Thread ging es mir um den Umgang mit Altbestand. Gruß --Entlinkt (Diskussion) 22:59, 23. Apr. 2016 (CEST)
Dass der Weg über die Klassendefinition gewählt wurde, liegt mit hoher Wahrscheinlichkeit daran, dass außer dir niemand den display:inline-block-Trick kannte. Wieder was gelernt, danke dafür! --Schnark10:41, 25. Apr. 2016 (CEST)
WP-Archäologie:
Das Verhalten bei inline-block (von dem mein Hinterkopf mal was gelesen hatte, das mir jetzt spontan aber nicht mehr präsent war) hatte sich erst in der Ära HTML5 rumgesprochen.
Die IPA-Regel ist aber so uralt, dass damals noch IE6 Standardbrowser der Wikipedianer war und viele noch grausigere Dingsdas umherschwirrten, die solche feinziselierten Unterscheidungen noch nicht machten. Ich hatte sie auch noch nicht antizipiert und nur mein Netscape-Modell parat.
Chemie-Design:
Das ist so leserunfreundlich wie nur was.
Man muss schon eine Nase für die Gestaltungsideen von Wikipedianern haben sowie einen Browser mit Statuszeile, um dahinterzukommen, dass das auch anklickbare Wikilinks sind.
Gleichwohl, nach Ersatz durch eine Vorlage für Vorlagen wie oben skizziert und diese mit entsprechendem Warnvermerk versehen kann die Klasse wie dargestellt überall rausgenommen werden. Ein JS-Gadget kann sich alternativ ein Gadget-CSS dazuholen, falls das nötig wäre. Ich verwende seit fünf Jahren editToolStrIns und hatte noch nie bewusst wahrgenommen, dass beim hover was unterstrichen sei; aber wer dauerhaft alle Links unterstreicht, mag beim ≥ ein Unterscheidungsproblem bekommen.
Letzter Kommentar: vor 2 Jahren15 Kommentare7 Personen sind an der Diskussion beteiligt
Seit einiger Zeit hat gibt es in der Linken Spalte den Abschnitt "In anderen Projekten", falls ein entsprechender Eintrag auf Wikidata existiert:
Eigentlich sollte es möglich sein vor dem jeweiligen Projekt die das entsprechen Symbol einzufügen, wie etwa in frwiki der Fall ist. Siehe z.B. Fische, fr:Poisson Frohes Schaffen — Boshomi⌨18:14, 21. Mai 2016 (CEST)
Als offizielles Softwarefeature ist der Kasten „In anderen Projekten“ in der Seitenleiste relativ neu (Februar 2016). Allerdings haben wir schon seit Februar 2010 (also 6 Jahre länger) die Vorlage:InterProjekt, die zusammen mit etwas JavaScript in MediaWiki:Common.js einen Kasten „Schwesterprojekte“ für exakt denselben Zweck erzeugt. Der ältere, durch die Vorlage erzeugte Kasten war und ist beispielsweise auf der Seite Wikipedia:Fragen zur Wikipedia prominent sichtbar und hatte nie Icons. Daher stellt sich zunächst einmal die Frage, warum der neuere Kasten jetzt Icons haben soll. (Unabhängig von der Icon-Frage sollte natürlich das Problem der doppelten Kästen irgendwie gelöst werden, das ist aber eine andere Baustelle.)
Die Einträge in der Seitenleiste befinden sich weit außerhalb des skinunabhängigen Textfeldbereichs; vgl. hierzu den Hinweiskasten oben. Daher sind die Icons in der französischen Wikipedia über fr:MediaWiki:Vector.css realisiert worden; andere Skins wurden nicht berücksichtigt. So ist das Ganze zunächst einmal wenigstens nicht falsch; wenn wir das aber auch machen, dann sollten wir schon wissen, für welche Skins wir es machen und warum wir ausgerechnet diese Auswahl treffen.
Ich persönlich bin sehr zufrieden mit dem – bis auf die Nachfolger der „LinkFA/LinkGA“-Icons – einheitlichen und Blickfang-freien Erscheinungsbild der Seitenleiste. Für die Einführung der „LinkFA/LinkGA“-Icons wurden übrigens seinerzeit Meinungbilder für notwendig gehalten: LinkFA (2006), LinkGA (2009).
Auch an der konkreten Umsetzung in fr:MediaWiki:Vector.css gefällt mir etwas nicht besonders, nämlich die Verwendung von position:relative. Das kann zu subtilen Fehlern in der z-Richtung führen und lässt sich wohl mit Recht als „Hack“ bezeichnen, da es wohl noch nicht einmal notwendig ist, um das optische Ergebnis zu erreichen. Am „Richtigsten“ erscheint natürlich die Verwendung von list-style-image; da müsste man ausprobieren, ob das optisch annehmbar funktioniert (wenn man die Icons denn überhaupt haben möchte). Im Zweifelsfall würde ein negativer margin-left-Wert wohl zu demselben optischen Ergebnis führen wie position:relative, aber mit weniger Potenzial für Nebenwirkungen, und wäre insofern besser (wenn man die Icons denn überhaupt haben möchte).
Nachtrag: Die Umsetzung mit position:relative in fr:MediaWiki:Vector.css ist eindeutig falsch, weil dies dazu führt, dass sowohl die linke wie auch die rechte Kante jedes betroffenen <li>-Elements um 18px nach links rutschen (d. h. der Platz für Text in jedem <li>schrumpft auf der rechten Seite um 18px); natürlich möchte man aber erreichen, dass jedes <li> auf der linken Seite um 18px für das Icon wächst und dass der Platz für Text unverändert bleibt. --Entlinkt (Diskussion) 19:56, 21. Mai 2016 (CEST)
Natürlich ist die Seitenleiste etwas völlig anderes als der Abschnitt „Weblinks“ im Textfeldbereich. Man merkt dies schon daran, dass die Benutzergruppen, die diese Dinge jeweils bearbeiten dürfen, verschieden sind.
Das Argument der Konsequenz hätte auch schon während der letzten 6 Jahre gegolten, wenn es denn gilt. Mit dem Argument der Konsequenz kann man aber genauso gut auch begründen, dass die Icons nicht aufgenommen werden sollten, da die meisten anderen Einträge der Seitenleiste auch keine Icons haben.
Meine Meinung: In der Entwicklung der MediaWiki-Software wird nicht nur beiläufig, sondern aktiv daran gearbeitet, die Benutzeroberfläche möglichst einfach und „sauber“ zu halten, möglichst wenige verschiedene Icons zu haben, und auch möglichst wenige Farben. Dies gilt ganz besonders für den Vector-Skin und ist IMHO eine gute und unterstützenswerte Sache. Nun sind wir zwar nicht die MediaWiki-Entwickler und könnten natürlich jedes Designziel konterkarieren, sollten dies aber meiner Meinung nach nicht tun.
Soweit ich das sehe, gibt es im Vector-Skin hauptsächlich die folgenden Bilder in Navigationsbereichen:
Wikipedia-Logo oben links (grau, wie der Hintergrund der Seitenleiste)
Watchstar-Icon oben rechts (hellblau, wie der Hintergrund der Tab-Leiste)
Es sollte direkt auffallen, dass bunte Bilder nur ganz weit unten auftreten, wo sie sowieso kaum auffallen. Alle anderen Icons sind farblich an ihre Umgebung angepasst. Sicherlich ist dies kein Zufall.
Hinzu kommen noch die gelben und grauen Sternchen bei den Interwiki-Links zur Hervorhebung ausgezeichneter Artikel in anderen Sprachen. Diese passen m. E. bereits nicht wirklich ins Konzept, sind aber wohl noch akzeptabel, weil sie klein und einfarbig sind und nur in zwei verschiedenen Farben auftreten. Außerdem handelt es sich bei diesen um einen ehemals in fast allen Wikis verbreiteten Hack, der in die Software aufgenommen wurde, was immer noch besser ist als lokale Hacks in hunderten von Wikis.
Der Vorschlag in diesem Abschnitt lautet nun ganz konkret, die bisher von bunten Bildern völlig freie Seitenleiste so aussehen zu lassen wie :fr:#p-wikibase-otherprojects. Dadurch würde ein IMHO völlig willkürlich gewählter (und für mich persönlich komplett belangloser) Bereich der Seitenleiste in einer Art und Weise mit bunten Bildern ausgestattet, die dem bisherigen Design völlig zuwiderläuft und diesen Bereich über jedes vernünftige Maß hinaus betont.
Aus diesen Gründen spreche ich mich deutlich gegen diesen Vorschlag aus, und zwar für alle Skins, ganz besonders aber für den Vector-Skin, da die beeinträchtigenden Wirkungen des Vorschlags dort am größten wären. Gruß --Entlinkt (Diskussion) 22:47, 21. Mai 2016 (CEST)
Alles gute Argumente. Mir persönlich würde es trotzdem gut gefallen, wenn wir Icons wie im frwiki-Beispiel auch bei uns hätten. Manche Menschen orientieren sich eben schneller an Symbolen als an Text. Es gibt übrigens ein oranges Icon in der Werkzeugleiste: Der Link zum Atom-Feed. — RaymondDisk.23:19, 21. Mai 2016 (CEST)
Das Atom-Icon ist um einiges kleiner (12x12px) als die Projekt-Icons in frwiki (unterschiedliche Breiten von 14px bis 16px und ebenfalls unterschiedliche Höhen); die LinkFA/LinkGA-Nachfolgeicons sind ebenfalls kleiner (sogar nur 9px breit, also gerade so groß wie ein übliches Aufzählungszeichen). Zudem tritt das Atom-Icon nur einzeln auf, die LinkFA/LinkGA-Icons könnten theoretisch in Scharen auftreten, tun dies aber in der Praxis selten, während die Projekt-Icons schon auf der Hauptseite in Scharen auftreten.
Im Vector-Skin ist eine Textzeile in der Seitenleiste unter normalen Bedingungen (Browserschriftgröße 16px) genau 19px hoch, die Projekt-Icons in frwiki erreichen diese Höhe fast, berühren sich dadurch fast und ergeben dadurch eine Zusammenballung. Merklich kleiner kann man sie aber auch nicht machen, da sie dann nicht mehr erkennbar wären. Die Umsetzung in frwiki fällt zumindest nach meinen Maßstäben auf jeden Fall als „nicht wirklich professionell“ auf, und meiner Meinung nach ist für dieses Anliegen auch keine wirklich professionell aussehende Lösung möglich.
Die frwiki setzt kleine icons neben die commons-links, die das besser auffindbar machen (graue icons würden mir allerdings schon reichen) und ruwiki klebt commons- und wikidata-link direkt untereinander. Beides zusammen hätte ich gerne in dewiki! --Atlasowa (Diskussion) 23:47, 21. Mai 2016 (CEST)
Eine „psychologisierende“ These:
Ich sehe in unserer Community das grundsätzliche Problem, dass „man“ (?) mit fast jeder (sichtbaren) Softwareänderung oder -neuerung unzufrieden ist, sie nicht so akzeptieren will, wie sie ist und stattdessen relativ willkürlich daran herumändern will.
Beispiel 3: Seit Februar 2016 gibt es die Schwesterprojekt-Links als Softwarefeature. Drei Monate später gefällt es nicht und soll für alle Benutzer mit Icons versehen werden.
Speziell zu den Schwesterprojekten fällt mir noch folgendes ein: Wir haben oben auf der Seite Spezial:Letzte Änderungen einen Kasten, der unter anderem auch Schwesterprojekt-Links enthält. Dieser Kasten sah heute vor 10 Jahren so aus und sieht jetzt so aus. Soll heißen: Das Aussehen hat sich in 10 Jahren nicht geändert, die Schwesterprojekt-Links haben keine Icons und ich habe auch nirgends vernommen, dass jemand dort Icons wünscht. Warum? Weil jeder den Kasten ohne Icons kennt.
Jetzt gibt es zwei Möglichkeiten: Entweder, jemand baut die vorgeschlagenen Icons ein. Das wird ziemlich sicher einigen Leuten nicht gefallen, dann gibt es Diskussionen, aber in ein paar Jahren kennt jeder das neue Feature mit Icons und nimmt es hin, dass die Icons da sind. Oder aber, es baut niemand die vorgeschlagenen Icons ein. Auch das würde einigen Leuten nicht gefallen, aber in ein paar Jahren kennt jeder das neue Feature ohne Icons und nimmt es so hin. Und die nächste sichtbare Softwareänderung kommt bestimt, da geht das Ganze wieder von vorne los.
Ach, noch etwas: Ich habe mir mal die Hauptseiten aller 51 Wikipedien angesehen, die von unserer Hauptseite verlinkt sind. Nur auf 4 davon habe ich Icons wie die vorgeschlagenen gefunden: da:, fr:, frp:, sv:. Wenn man jetzt noch die Seiten da:MediaWiki:Vector.css, fr:MediaWiki:Vector.css und frp:MediaWiki:Vector.css miteinander vergleicht, kann man feststellen, dass alle drei denselben Code mit denselben Fehlern verwenden. Mit anderen Worten: da: und frp: haben von fr: kopiert, also wollten sie die Icons wohl haben, aber so wichtig, den Code mal auf Sinnhaftigkeit zu prüfen, war es ihnen doch nicht.
Interessant ist die Lösung der schwedischen Wikipedia. Dort ist das Ganze nämlich ein Gadget mit einem CSS-Teil und einem JavaScript-Teil. Die haben sich anscheinend tatsächlich Gedanken darüber gemacht. Bei den anderen deutet meiner Meinung nach ehrlich gesagt nicht so viel darauf hin. Gruß --Entlinkt (Diskussion) 07:23, 22. Mai 2016 (CEST)
OT zu Beispiel 2: Kennen tu ich's, vermisst habe ich es auch schon, und letzlich als HTML-Kommentar in der feritgen Seite gefunden, zusammen mit dem "Transclusion expansion time report". Da ich jetzt weiß, warum ich ihn vermisste, werde ich das vorraussichtlich in meiner global.css wieder einblenden, auch wenn ich den andere Report dadurch vermutlich vergessen werde. Ich würde mich aber freuen, wenn das auf allen Wikis gleich werden könnte; Sich also nur die Nutzer, die vom Standard abweichen wollen, anpassen müssen, statt alle Benutzer: Die, die es anders wollen, um es auch in anderen Wikis anders zu haben, und die, die es "normal" haben wollen, um es auch hier zu haben… Zum eigentlichen Thema stimme ich dir zu. Auch wenn ich mir vorstellen kann, dass die Icons in anderen Schriftsystemen hilfreich sein könnten – Aber so gering, dass mir selbst bei einer guten Umsetzung wahrscheinlich wegen der Einheitlichkeit keine Icons lieber wären. --nenntmichruhigip (Diskussion) 13:16, 22. Mai 2016 (CEST)
Wenn man mal über den Tellerrand hierzuwiki schauen möchte:
T66315 Move "Data item" link outside of sidebar toolbox: "the link feels out of place after "Page information" and before "Cite this page" (completely different audiences). (...) A possible fix is to add the link to the "in other projects" sidebar..."
Gibt es auch einen Phabricator-task für die "other projects" logos? Das könnte dann ordentliches Layout für alle svwiki, dawiki, frwiki usw. schaffen, die icons/logos haben wollen. --Atlasowa (Diskussion) 23:45, 22. Mai 2016 (CEST)
Ein nicht unbeträchtlicher Teil der Links auf andere Projekte in der Seitenleiste sind Commons-Kategorien, die genau die Artikel enthaltenen Bilder zeigen. Willkürliches Beispiel, das ich durch ein paar Klicks auf "Zufälliger Artikel" gefunden habe: Victor Razafimahatratra So etwas durch ein Icon hervorzuheben, ist einfach nur – tut mir Leid – Leserverarschung.
Unabhängig jedoch von der Frage, ob man die Icons will oder nicht – eine Softwarefunktion, die es in allen Wikis gibt, sollte auch in allen Wikis gleich aussehen, Alleingänge einzelner Wikis, noch dazu bei Funktionen, die der Vernetzung verschiedener Wikis dienen dienen, sind nicht zielführend. --Schnark09:35, 23. Mai 2016 (CEST)
Inwieweit sich die Schweden Gedanken gemacht haben, ist etwas fraglich, ich glaube, dass der Code anfällig für XSS ist. Müsste ich jetzt noch ein bisschen rumprobieren und dann dort einen finden, der sich dafür verantwortlich fühlt. --Schnark12:11, 23. Mai 2016 (CEST)
Der Vorschlag die Formatierung über alle Projekt hinweg zentral durch die Mediawiki-Software vorzunehmen scheint mir vernünftiger, als Einzelanpassungen für jedes einzelne Wiki und jeden einzelnen Skin extra.
Zu commons: da kommt auch was vernünftiges dabei heraus, siehe etwa SMS_Moltke_(1910), das war bei mir der erste zufällige Artikel mit Commons in der linken Spalte. Ob da wirklich was vernünftiges herauskommt, hängt von den Inhalten ab, die die Benutzer eingeben. Bei commons könnte es vernünftig sein, das erst dann anzuzeigen, wenn mindestens 2 Dateien vorhanden sind. Aber auch das sollte möglichst zentral geregelt werden. Frohes Schaffen — Boshomi⌨15:27, 24. Mai 2016 (CEST)
Hervorhebung von Suchergebnissen in anderen Sprachen
Letzter Kommentar: vor 2 Jahren11 Kommentare5 Personen sind an der Diskussion beteiligt
@Elya, Raymond: Diese Farbgebung ist hoffentlich nicht ernst gemeint, oder? Abgesehen davon, dass ich dieses Türkis als hässlich empfinde (aber persönliches Empfinden ist natürlich erst einmal kein Maßstab für oder gegen eine Änderung), ist der Kontrast zwischen Hintergrund und Text viel zu schwach. http://webaim.org/resources/contrastchecker/ kommt auf 2,09:1, während nach WCAG als Minimum 4,5:1 gefordert wird und in MW die Einhaltung des strengeren Wertes 7:1 angestrebt wird.
Das ist keine Hervorhebung, sondern versteckt den Hinweis, dass es sich um Ergebnisse aus einer anderen Sprachversion handelt, ziemlich effektiv vor allen Benutzern mit Sehschwächen. Und es wäre schön, wenn solche Änderungen an zentralen Stylesheets erst diskutiert werden, und nicht nach „mir gefällt diese Farbe, also mache ich das so“ ohne Berücksichtigung wichtiger Standards eingebracht würden. --Schnark09:27, 29. Jul. 2016 (CEST)
Hallo @Schnark: Danke für dein konstruktives Feedback. Welche Farben schlägst du konkret vor, um eine deutliche Abgrenzung zu den lokalen Suchergebnissen zu erreichen? Ich selber nutze oft knallige Farben, die aber nicht auf Gegenliebe stoßen. Und nun ist es wohl zu dezent. Im übrigen hielt ich ein zügiges Handeln nach Einführung der Funktion für notwendig, da die Standardausgabe gar kein Styling enthält und der kurz, zusätzliche Satz einfach übersehen wurde. An dem noch nicht perfekten Styling können wir nun weiterarbeiten.
Interessant übrigens die heute Abend auf der Kurier-Diskussion vorgestellte Suchergebnisliste sowohl mit einem lokaken als auch einem englischsprachigen Ergebnis. — RaymondDisk.20:27, 29. Jul. 2016 (CEST)
Andererseits wurde das irgendwo auch schon als "knallig-bunt" (oder so ähnlich) beschrieben. Ich schlage vor, die Anzeige der Suchergebnisse selbst anders zu gestalten (Selektor z.B. .mw-search-interwiki-header + .mw-search-results; vllt ein Rahmen?), das sollte allerdings bei allen Projekten gleich sein, also schon von MediaWiki so kommen -> Phab-Task. --nenntmichruhigip (Diskussion) 01:17, 30. Jul. 2016 (CEST)
Tja, wenn ich die Suche ausführe, kommt ein Ergebnis in Türkis ;-) Wobei ich mal vorsichtig nachfrage, ob es "Suchergebnisse von der englischen Wikipedia." heißen sollte? Oder nur Ergebnisse? Oder aus der en:? Oder 'englischsprachigen' Wikipedia? --Manorainjan (Diskussion) 02:20, 30. Jul. 2016 (CEST) PS: Dicodin ist ein 1A-Testcase ;-)
Wenn man den auszugsweise angezeigten Text in den Suchergebnissen liest, dann sollte man auch ohne irgendeine Hervorhebung feststellen können, dass es sich nicht um deutsche Artikel handelt. Und wenn man das nicht tut, bevor man eine Weiterleitung anlegt, dann muss man mit fehlerhaften Weiterleitungen rechnen, unabhängig davon, ob die Ergebnisse aus einer anderen Sprache stammen oder nicht. Das ist daher in meinen Augen kein Argument dafür, irgendeine Hervorhebung einzubauen.
Hintergrundfarben zur Hervorhebung werden hier nur äußerst selten eingesetzt. Die einzigen Hinweise mit buntem Hintergrund, die mir einfallen, sind der Hinweis, wenn man unangemeldet eine Seite bearbeitet (wobei die farbliche Hervorhebung nur im Quelltext-Editor vorhanden und sehr schwach ist) und der Hinweis auf neue Nachrichten auf der eigenen Diskussionsseite. Der Hinweis, dass die Suchergebnisse aus einer anderen Sprache stammen, ist nun wirklich nicht so wichtig, dass eine ungewöhnlich starke Hervorhebung gerechtfertigt ist. Mein Farbvorschlag lautet also: Schwarz auf Weiß, so wie fast alle anderen Hinweise auch.
Wenn wirklich eine Hervorhebung notwendig sein sollte, dann käme ein border-top: 3px solid #c00000; in Frage, das wäre im Aussehen konsistent mit lokalen Dateibeschreibungsseiten, wo durch eine Linie dieser Farbe lokale und Commons-Inhalte abgetrennt werden.
Bei Funktionen, die einer stärkeren Vernetzung der einzelnen Wikis dienen, halte ich Konsistenz zwischen den einzelnen Sprachen für sehr wichtig. Man kann eine Hervorhebung lokal kurz testen, aber eine dauerhafte Umsetzung muss über ein Phab-Ticket erfolgen, wie Nenntmichruhigip schon geschrieben hat.
Die Qualität des eingefügten CSS-Codes ist sichtbar schlechter als der Rest des Stylesheets: Es fehlt ein dokumentierender Kommentar, Leerzeichen sind uneinheitlich gesetzt, es sind unnötige Eigenschaften (border: none) enthalten, es gibt vermeidbare !important. --Schnark08:47, 30. Jul. 2016 (CEST)
Da ich in meinem früheren Leben auch 'n Bisschen programmiert habe, und mich erinnere, dass die WP diverse Skins anbietet, scheint es mir erforderlich, mit den hoffentlich irgendwie standardisierten Auszeichnungen für diese Skins zu arbeiten, damit es in jedem Skin passend aussieht. --Manorainjan (Diskussion) 11:58, 30. Jul. 2016 (CEST)
Ähm, was wird das jetzt hier? Warten wir jetzt einfach so lange ab, bis jeder Versuch diese „Hervorhebung“ zu revertieren oder zumindest vernünftiger zu gestalten, mit „War schon immer so, bleibt also so“ abgelehnt werden kann? Soweit ich sehen kann, hat noch immer niemand eine Phabricator-Task mit der Bitte um Hervorhebung des Hinweises in allen Wikis angelegt (und das sollte jemand machen, der auf Nachfragen, warum eine solche Hervorhebung notwendig ist, auch eine sinnvolle Antwort nennen kann). Was an sich ja auch nicht verwundert, denn Raymonds Variante verwendet ja kräftige Warnfarben, während Elya genau gegenteilig gestaltete, sodass offenbar noch nicht einmal unter den Befürwortern einer Hervorhebung Einigkeit darüber besteht, was eigentlich ihr Zweck sein soll. --Schnark08:37, 1. Aug. 2016 (CEST)
Kein Aussitzen, sondern ich hatte mir noch mehr Meinungen erhofft übers Wochenende. Aber eben auch in der Wikipedia gilt: Sommer, Sonne, Ferienzeit :-) Und du hast Recht, den Task hätte ich schon vor dem Wochenende schreiben können, jetzt nachgeholt mit Phab:T141768. Und ich habe deinen Vorschlag mit der roten Linie aufgegriffen. Ein guter Kompromiss, damit kann ich leben :-) — RaymondDisk.17:00, 1. Aug. 2016 (CEST)
Bei der endgültigen Implementierung darf dann aber ruhig noch etwas Innenabstand nach oben dazu, bisher klebt der Text für meine Augen unangenehm nah an der roten Linie. Ist aber nicht so wichtig. -- hgzh17:08, 1. Aug. 2016 (CEST)
Letzter Kommentar: vor 2 Jahren12 Kommentare5 Personen sind an der Diskussion beteiligt
Einige in MW verwendeten Farben wurden leicht geändert um sie an die Farbpalette anzupassen. Da sich einige der in Common.css verwendeten Farben explizit auf diese Farben beziehen (prettytable, "wie Inhaltsverzeichnis"), sollten sie übernommen werden. Ich schlage folgende Änderungen vor (alles Grautöne):
Rahmenfarben
#aaa
#a2a9b1
gray
#72777d
#e9e9e9
#eaecf0
Hintergrundfarben
#efefef
#eaecf0
#f3f3f3
#f8f9fa
#f9f9f9
#f8f9fa
#e0e0e0
#eaecf0
#eee
#eaecf0
Die anderen Farben unterscheiden sich recht stark von denen der Farbpalette, sodass ich dort keine Änderung vornehmen würde. --Schnark10:56, 9. Dez. 2016 (CET)
@MBq: Willst du auch die anderen Farben erledigen? Zumal du ja gerade die hintergrundfarbe1 durch ein fehlendes f vorne kaputt (=weiß) gemacht hast? --Schnark11:32, 9. Dez. 2016 (CET)
Arbeit zieht Arbeit nach sich ;-) Schau bitte mal, ob [5] so stimmt und ob ich nichts vergessen habe. Die Ergänzung im mobilen css müsstest Du mir genauer vorgeben. -- MBqDisk12:13, 9. Dez. 2016 (CET)
Kopiere aus Common.css ab ".rahmenfarbe1" bis zum Kommentar über ".IPA a" (nicht einschließlich) und ersetze den entsprechenden Block in MediaWiki:Mobile.css damit, also dort ebenfalls ab ".rahmenfarbe1" bis zum Kommentar über ".metadata" (ebenfalls nicht einschließlich). --Schnark10:00, 10. Dez. 2016 (CET)
Nur mal so, weil’s mir zufälligerweise aufgefallen ist: Ich bin der Meinung, dass sich mit der kürzlichen Farbänderung eine Art „Bug“ in die MediaWiki-eigene wikitable-Definition eingeschlichen hat.
Konkret: Wenn bei einer Tabelle die Rahmenfarbe der Gesamttabelle von der Rahmenfarbe der einzelnen Zellen abweicht, dann kommt per CSS-Spezifikation eine Art Algorithmus zur Anwendung, um die gezeichnete Rahmenfarbe zu bestimmen. Nach diesem Algorithmus übertrumpft bei wikitable die Rahmenfarbe der einzelnen Zellen diejenige der Gesamttabelle. Beispiel:
Dies ist eine Tabelle mit blauem Rahmen, ihre einzige Zelle hat einen orangefarbenen Rahmen.
Dies bedeutet, dass die mit gerrit:324534versuchte Änderung des Grautons von #aaa nach #a2a9b1 tatsächlich wirkungslos ist (man überprüfe hier, dass das #aaa bei den Zellen stehen gelassen wurde und daher das #a2a9b1 der Gesamttabelle übertrumpft). Mag jemand schauen, ob da noch mehr solche Fehler gemacht wurden und einen Bugreport schreiben? Mir fehlt gerade RL-bedingt leider die Zeit dafür. Gruß --Entlinkt (Diskussion) 04:21, 14. Dez. 2016 (CET)
Richtig analysiert. Die unterschiedlichen Rahmenfarben treten auch bei einer wikitable-Tabelle bei leeren Zellen auf. Beispiel:
1
2
3
Optisch kann ich den Unterschied zwar nicht wahrnehmen, aber mit einer Farbpipette kann ich am Rahmen der leeren Zelle rechts unten die Farbe #A2A9B1 entnehmen, während ich am Rahmen den befüllten Zellen die Farbe #AAAAAA entnehmen kann. Ich habe zu diesem Fehler gerrit:327144 eingestellt. --Fomafix (Diskussion) 07:21, 14. Dez. 2016 (CET)
Kam die Klasse nicht sogar mal aus dem Musikbereich? Ich erinnere mich dunkel an gelöschte Vorlagen, irgendwelche früheren Charts?
Vorlage:DDR-Jahreshitparade scheint mir dann auch gleich komplett Löschkandidat zu sein, nicht mehr benutzte Vorlage, aber das ist eher dein Metier als Musiker.
Offenbar war die Klasse ja Vorgängerversion der heutigen Vorlage:Infobox Chartplatzierungen (vor meiner Zeit). Wird heute nur noch für optisch suboptimale Darstellungen von „DDR-Charts“ verwendet, wie mir bei meiner aktuellen Band-Infobox-Aufräumaktion aufgefallen ist. Hatte zuletzt eine kurze Diskussion darüber mit Vanellus, daher hier mal der Hinweis auch an ihn. Grundsätzlich sollte die Klasse vollständig in die Vorlage übergeführt worden sein, wäre auch in diesen Fällen wohl ein vollwertiger Ersatz. Gruß--XanonymusX (Diskussion) 21:28, 26. Apr. 2017 (CEST)
Scheint auch Junge bekommenn zu haben, war mal nur 1 Treffer gewesen.
Bot in den ANR schicken, oder Mini-(Unter-)vorlage mit den noch benötigten Regeln basten, und die statt der class inline einfügen oder so, oder anders lösen. Was muss an Ostrock denn anders sein als beim Westrock?
Mir ist die Vorlage persönlich egal (stammt auch nicht von mir), wichtig ist nur eine Ersatzlösung, keine Löschung der Informationen. --Vanellus (Diskussion) 07:12, 27. Apr. 2017 (CEST)
Also, für mein laienhaftes Ohr wirkt das, was in den 43 Artikeln über Silly, City, Pankow, Puhdys, Karat & Co. dargestellt wird, wie die ungeboxte Info für Vorlage:Infobox Chartplatzierungen.
Müssten halt drei Freiwillige jeden Tag einen Artikel aufmotzen, und in zwei Wochen wäre die Altlast abgewickelt.
Daraufhin werden über zehn Millionen Seiten eine Hundertstelsekunde effizienter, weil sie nicht mehr nach diesem Spezifikum für ein halbes Hundert Seiten durchsucht werden müssen.
Die zwei Nicht-DDR-Fälle sind schnell erledigt. Das Problem mit den DDR-Fällen ist, dass sie nicht mit der WP:FVC konform gehen und daher wohl erstmal diskutiert werden müssen (zum einen, weil DDR-Charts als solche nicht existier(t)en; zum anderen, weil wir es hier mit Jahrescharts zu tun haben, die weder für Chartbox noch -tabelle wirklich geeignet sind). Das dürfte sich also noch ein bisschen hinziehen.--XanonymusX (Diskussion) 19:21, 27. Apr. 2017 (CEST)
Wir warten schon seit Jahren drauf, dass die letzten Altfälle erschwinden; da käme es auf ein paar Wochen auch nicht mehr an.
Es scheint nur um die Überschrift zu gehen? Also dass „Chartplatzierungen“ nicht angemessen wäre, und es „Sozialistische Musikbeliebtheit“ sein solle, oder die oben schon auftauchende „Jahreshitparade (DDR)“?
Die beiden sowieso auf dieselbe Basisvorlage Album und Single verlinkenden Einträge für einzelne Zeilen scheinen sich hier ebenfalls verwenden zu lassen. Halt ohne 4=Wo. mit konstantem 1=DDR.
Damit hätte man in der neuen Technik ein einheitliches Erscheinungsbild.
In Silly (Band) stehen beide sideboxen übereinander.
Die Vorlage:Infobox Chartplatzierungen könnte man kopieren und ausweiden, diverse Parameter eliminieren. DVD & DDR gab es wohl nicht gleichzeitig. Die Kopie bekäme eine neue Überschrift, und ob das jetzt Titel oder Singles oder Alben wären müsstet ihr sehen.
Damit gäbe es einheitliche Optik, einheitliche Vorlagenbedienung und einheitliche Systematik für NSW und DDR. Bei den symtembedingt notwendigen Unterschieden und Eigenheiten.
Gut, @PerfektesChaos: endlich konnte ich mich dazu aufraffen, die beiden umfangreichsten Fälle auch noch zu erledigen! Damit ist die Klasse jetzt nicht mehr in Verwendung und kann wohl weg. Gruß--XanonymusX (Diskussion) 18:26, 26. Jul. 2017 (CEST)
Letzter Kommentar: vor 2 Jahren14 Kommentare5 Personen sind an der Diskussion beteiligt
Hallo zusammen! Ich bin bei verschiedenen Gelegenheiten (AKtionsseiten, Vorlagen, Buttons) immer wieder auf das Problem gestoßen, dass es schwierig bis unmöglich ist, einfach mal einen Block negativ (also heller Text auf dunklem Hintergrund) zu setzen.
Natürlich kann man Text- und Hintergrundfarbe in jedem Container per Inline-CSS einstellen. Dummerweise betrifft das aber nicht die im Text enthalten Links. Die werden dann weiterhin Blau dargestellt und das ist auf dunklen Hintergrundfarben kaum zu lesen. Die Methode ein <span style="color:#FFF">...</span> in jeden einzelnen Link zu schreiben ist nicht wirklich praktikabel, wenn dieser Links (wie in vielen Vorlagen) auch mal nutzergeneriert sein können.
Ich würde daher vorschlagen, für negative Inhaltselemente einen Standardklasse anzulegen, die so aussehen könnte:
Ergänzung: Hab's mittlerweile mal getestet. Das Tripeln des Selectors ist hier notwendig, um ohne !important die überpräziesen Selektoren im MediaWiki-CSS zu überschreiben. // Martin K. (Diskussion) 18:00, 26. Jul. 2017 (CEST)
Die Tatsächliche Hintergrundfarbe könnte man dann entweder via Inline-Style angepassen. Oder wir legen gleich einen Satz Vorlagen für die dunklen CI-Farben an.
Ich glaube nicht, dass wir pauschal die Browser beim Leser in über zehn Millionen Seiten dazu auffordern sollten, die dargestellte Seite daraufhin zu untersuchen, ob „einfach mal ein Block negativ“ darzustellen sei.
Insbesondere gibt es ein den Lesern vertrautes Farbschema, wie ihre noch nicht besuchten Links, schon besuchten Links, Weiterleitungen, interne Links markiert wären; und Fortgeschrittene markieren neben BKS auch Verlinkungen in bestimmte Namensräume, innerhalb derselben Seite usw.
Alles das wird von dem Vorschlag locker unterlaufen und rigoros beiseitegeschoben.
Eben weil die Farbgebungen unserer Verlinkungen darauf abgestimmt sind, dass der Text in dunkleren Farben gehalten ist, also auf einigermaßen hellem Hintergrund erwartet wird, verbietet es sich, „einfach mal einen Block negativ“ darzustellen, sofern er Verlinkungen enthält.
Der zusätzliche Erkenntnisgewinn von weißer Schrift auf großflächig schwarzem Grund will mir auch grad nicht einleuchten. Für eine kleine Fläche, etwa eine Überschrift oder einen Warnhinweis, kann man das aus Jux ja mal machen, aber ohne Links, und dann reicht lokales inline.
Es geht hier nicht darum, ganze Artikel oder Diskussionsabschnitte negativ zu stellen.
Es geht vielmehr um ein Werkzeug, mit denen diejenigen arbeiten können, die Portale, Meta- und Wartungsseiten, Hinweisbausteine, Warnungen und der gleichen gestalten – Z.B. den DÜP-Baustein, z.B. die WLM-Seite, z.B. die sich aktuell in monotoner unübersichtlichkeit ergehenden Lizenzvorlagen für Bilder. Und da macht Negativ-Satz mitunter schon sehr viel Sinn und ist im übrigen Netz auch für entsprechende Anwendungszwecke auch etabliert. Es ist einfach ineffizient und wartungs-verkomplizierend, die Leute in solchen Fällen zu irgendwelchen Inline-Spans oder zum Verzicht auf dunklere Hintergrundfarben zu nötigen. Dass in diesem Projekt im Jahre 2017 Farben immer noch vor allem als blase Pastelltöne eingestetzt werden, wodurch alles so aussieht als wären wir gestalterisch irgendwo in den frühen 2000ern hängen geblieben, liegt ja vor allem daran, dass sich die Alternative (nämlich Negativsatz) z.Z. nur mit murksigen Workarrounds bewerkstelligen lässt. Im Zeitalter von Material- und Flat-Design ist das mMn weder zeitgemäß noch entspricht es den Nutzererwartungen. Der Wikipedia-Style-Guide ist da schon viel weiter, nur wurde das leider nie konsequent in Vektor umgesetzt.
Ich halte das daher nach wie vor für eine gute Idee. Zumal es mMn auch keine echten Nachteile hat. Die paar Zeilen CSS tun niemandem weh und beeinträchtigen ja auch keine der vorhanden Darstellungen. Aber sie würden die Sache für diejenigen, die dieses Feature gebrauchen können, wirklich erheblich vereinfachen. // Martin K. (Diskussion) 19:22, 6. Mai 2017 (CEST)
Ich stimme in dem einen Punkt zu, dass ein gut gemachtes dunkles Design eine Bereicherung sein kann. Aber hier sehe ich deutlich mehr Nacht- als Vorteile:
Du willst die Textfarbe und die Hintergrundfarbe an getrennten Stellen angeben. Wie groß ist die Wahrscheinlichkeit, dass in der Mobilversion, in einer App oder einer sonstigen alternativen Nutzung genau eine der beiden Definitionen verloren geht und man dann weiß auf weiß oder schwarz auf schwarz hat?
Alle Links in weiß und unterstrichen klingt erst einmal sinnvoll bei dunklem Hintergrund. Aber wie unterscheide ich Links zu vorhandenen und fehlenden Artikeln? Besuchte und unbesuchte? Was ist bei Benutzern, die die Linkfarben vom Browserstandard überschreiben lassen? Was ist mit Benutzern, die auf andere Weise (etwas mittels Benutzer:PDD/monobook-clean.css) andere Linkfarben setzen?
In allen aktuellen Skins wirkt ein dunkler Hintergrund als Fremdkörper, der mehr störend als irgendwie anders auffällt.
Im Fazit ergibt sich für mich, dass das ganze deutlich mehr Wartung erfordern würde als sich in Anbetracht des begrenzten Einsatzgebietes rechtfertigen lässt. –Schnark12:02, 9. Mai 2017 (CEST)
Wie Du in meinem Code-Vorschlag oben sehen kannst, würde ich eine Default-Hintergrundfarbe festlegen, so das dieser Fall eigentlich nicht auftreten kann. Alternativ könnte man auch mit mehreren Farb-Klassen arbeiten, die dann komplett autark ohne inline-CSS funktionieren.
Für die Einsatzzwecke, für die wir diesen Negativsatz benötigen spielt die Unterscheidung zwischen vorhanden und fehlenden Artikeln eh keine Rolle. Es geht ja nicht um ein großflächiges Umfärben des ANR, sondern kleinere Blöche auf Funktionsseiten.
Es geht doch gerade um Layout-Elemete die wie Buttons, Warnhinweise oder Tab-Bars aus dem aktuellen Design hervorstechen sollen. Und wie man z.B. an dem mw-ui-Buttons sieht, werden solche Elemente dem aktuellen CD zu Folge doch heute schon negativ gesetzt.
Das Argument, dass dies deutlich mehr Wartung erfordere kann ich nicht nachvoll ziehen. Es ist doch genau das Gegenteil der Teil der Fall: Eine zentral wartbare Klasse für Negativ-Satz ist doch um mehrere Zehnerpotenzen wartbarer als über hunderte Seiten verteilte <span style="color:#FFF">-Schnippsel?!
„Die Tatsächliche Hintergrundfarbe könnte man dann entweder via Inline-Style angepassen.“ hast du geschrieben. Und damit werden Hintergrund- und Textfarbe getrennt. Würde man die von dir vorgeschlagenen Zeilen in die Common.css einfügen und dann irgendwo schreiben <div class="negative" style="background-color: #222;">…</div>, sähe das Ergebnis im Desktopbrowser so aus, wie du es dir vorstellst, in der Mobilversion wäre es nicht sichtbar.
Füge die von dir vorgeschlagenen Codezeilen einfach mal in deine private common.css ein, lege Benutzerunterseiten an, die die neue Klasse verwenden und betrachte das Ergebnis in verschiedenen Browsern. In der Mobilversion. Mit verschiedenen Browsereinstellungen bezüglich Farbeinstellungen. Mit alten Browsern (https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-tabular-view kommt für letztes Jahr auf absurde 3 % für IE 8 und älter). Dann stell dir vor, die Mobilversion ändert mal wieder die Art, wie sie mit Inline-Styles umgeht. Stell dir vor, dass in Zukunft vielleicht mal ein Skin eingeführt wird, der von Haus aus einen dunklen Hintergrund hat. Stell dir vor, dass eine CSS-Anpassung notwendig würde, aber niemand Lust oder Ahnung hat, wie sie umzusetzen ist.
Vor ein paar Monaten ist dir aufgefallen, dass Vorlage:Button problematisch ist. Dreimal darfst du raten, welcher aktuelle Wettbewerb die Vorlage trotzdem prominent verwendet. Glaubst du ernsthaft, dass der Einsatz deiner vorschlagen „negativ“-Klasse in der mittelfernen Zukunft weniger problematisch würde? –Schnark08:16, 13. Mai 2017 (CEST)
Ehm ... wir sprechen hier von den Eigenschaften color und background-color. Das ist CSS der allerersten Stunden. Es gibt keinen auch nur ansatzweise CSS-fähigen Browser, der das nicht unterstützt.
Wenn Dir die Kombination von Inline- und normalem CSS-Bauchgrummen beschert, dann dürftest Du eigentlich vor lauter Bauchschmerzen kaum noch laufen können ;) Das wird in diesem Projekt nämlich dauernd gemacht. Aber sei's drum: Sprechen wir also darüber, feste Klassen für die wesentlichen CD-Farben im Negativsatz anzulegen. Da dürfte es ja keine Probleme geben, oder?
Und was sie Mobil-Vesion angeht: Sinnigerweise sollte man die gleichen Klassen dann auch in der Mobile.css anlegen. Genauso, wie das mit den nicht CS-konformen pastelligen Farbklassen auch gemacht wurde.
P.S.: Das Argument „Man dürfe so etwas nicht machen, weil sich ja irgendwann mal der Skin ändern könne“ halte ich für wenig zielführend. Das gilt nämlich nicht nur für alles, was in der commons.css steht sondern auch für jeden einzelnen Inline-Style. In so einen Fall müssten wir da eh nochmal ran. Dafür ist es ja ein Wiki.
P.P.S.: Es ist übrigens kein Wunder, dass so etwas wie {{Button}} immer wieder verwendet wird, wenn nicht klar und deutlich kommuniziert, durch was sie ersetzt werden sollte und das auch konsequent umsetzt. So gesehen handelt es sich auch bei den nicht CI-konformen Pastell-Klassen .hintergrundfarbeXY um fiesesten, nichtsemantischen, wartungsfeindlichen Legacy-Code, der dringend überarbeitet und ersetzt werden sollte. Und der hiesige Vorschlag, wäre eine Möglichkeit dafür.
Du bist bislang mit keiner Silbe auf die wesentlichen Gegenargumente eingegangen:
Es gibt ein breites Feld an spezifischen Link-Farben, die auf dunkle Schriftfarbe abzielen, namentlich für unbesuchte, besuchte, Wiki-interne, externe Weblinks, Weiterleitungen und schließlich redlinks, ergänzt durch vielfältige benutzerdefinierte bedeutungstragende Linkschriteinfärbungen, die alle alle miteinander einen maximal pastellfarbenen Hintergrund voraussetzen.
Du willst eine winzige Handvoll Seiten mit dunklem Hintergrund ausstatten, wofür über zehn Millionen anderer Seiten im Browser jedes Lesers daraufhin durchsucht werden sollen, ob sie zu den paar Dingern gehören würden.
Du willst nicht nur einen kleinen Textbereich ausstatten, sondern anscheinend den gesamten Inhaltsbereich, der jedoch in einem unverändert hellfarbenen beliebigen Desktop-Skin bzw. heller Mobil-Umgebung steht. Super-Design.
Du kannst maximal einen kleinen Bereich dunkel hinterlegen, nicht aber beliebigen Freitext. Nur in einem engen Bereich, in dem es auch keine besonderen Verlinkungen gäbe, und wo du die Benutzer- und Browser-Eigenschaft „Link bereits besucht“ auch noch unterpflügst zum Nachteil der Navigationsqualität, kann dein Plan überhaupt sinnvoll sein. Dafür setzen wir jedoch seit Ewigikeiten direkten inline-style ein, und mehr braucht es dafür auch nicht.
So wie es aussieht, scheint es immer noch nicht klar zu sein, worum es mir eigentlich geht?! Und das obwohl ich das schon mehrfach beschrieben habe – daher nochmal:
Es geht NICHT darum, ganze Seiten mit einem dunklen Hintergrund zu gestalten.
Es geht darum, (dort wo es Sinn macht) einzelne Seitenelement negativ gestalten zu können. Es geht um so etwas wie:
DÜP-Bausteine, Lizenzhinweise, Löschvermerke
Hinweiskästen auf Funktionsseiten
Tabs
Banner
Teaser
usw.
Es geht also nicht um ein Werkzeug für den ANR, sondern um etwas, was vor allem im Meta-Bereich eingesetzt wird. Und bei diesen Anwendungsfällen, spielen Rotlinks, Besuchte-Links usw. ein untergeordnete bis keine Rolle. Und es macht wirklich keinen Sinn bei all diesen Anwendungsfällen jeden einzelnen Link intern noch mal mit einem Inline-Style-Span zu versehen.
Zu 2. sei gesagt, dass es (a) gar nicht so wenige Seiten sind, auf denen man so etwas einsetzen könnte. Und (b) machen die paar Zeilen CSS den Bock nun wirklich nicht fett, wenn man bedenkt, dass wir umseitig neben etlichen Modulen, die nur auf einer Seite oder in einer Vorlage eine Rolle spielen, ganze 75 Zeilen CSS allein für die Hauptseite mitladen. // Martin K. (Diskussion) 18:17, 17. Mai 2017 (CEST)
Alles, was du da aufgezählt hast, kannst du dir jederzeit selbst in Elemente stecken und mit inline-style versehen, und das haben andere schon vor mehr als einem Jahrzehnt hie und da mal realisiert, in dunkelviolett, dunkelbraun, navyblue oder was immer; mit weißer oder gelber Schrift und Verlinkung. Projektweiter Definitionen für alle Seiten, wegen derer du hier vorstellig geworden bist, bedarf es nicht. Und die einzige Hintergrundfarbe, die du vorgesehen hast, ist nachtschwarz. VG --PerfektesChaos20:09, 17. Mai 2017 (CEST)
Ach komm, Du weißt so gut wie ich, dass Inline-Styles per se ein Anti-Pattern sind. Kein ernstzunehmender Frontend-Entwickler würde die als Best-Practice propagieren, sondern die Hände über dem Kopf zusammenschlagen, wenn er eine Website warten müsste, in der diese so exzessive eingesetzt würden wie hier. Wir machen das hier-zu-Wiki doch auch nur, weil es halt nicht anders geht.
Und gerade deshalb ist es sinnvoll für Standard-Fälle Standard-Klassen bereit zustellen, um so den unsinnig exzessiven Einsatz von Inlinestyles zu reduzieren und einen halbwegs leserlichen Wikitext gewährleisten.
Der CSS-Code, den ich oben gepostet habe, war nur eine Diskussionsgrundlage und nicht die fertige Lösung. Ich hatte ja schon angedeutet, dass wir das gerne über Standardklassen für alle offiziellen CI-Farben regeln können. Und von mir aus kann ich da auch einen entsprechend getesten Code-Vorschlag präsentieren. Das macht aber nur Sinn, wenn es hier nicht auf Fundamentalsopposition hinausläuft. // Martin K. (Diskussion) 20:21, 17. Mai 2017 (CEST)
Standardklasse für responsive herunterskalierende Bilder
Letzter Kommentar: vor 2 Jahren46 Kommentare9 Personen sind an der Diskussion beteiligt
Da in WikiText (scheinbar?) nur fixe Bildgrößen gesetzt werden können, gibt es gerade bei Infoboxen häufig das Problem, dass...
..auf kleinen Auflösungen zu große Bilder das Layout unnötig aufspreizen und ggf. sogar horizontales Scrollen verursachen.
..zu kleine Bilder verwendet werden, die dann in großen Auflösungen umgeben von zwei großen Leerräumen winzig in der Mitte sitzen.
Ich glaube Ihr stimmt mir zu dass das suboptimal ist. Auf normalen Websites umgeht man das durch ein Fuides Layout und responsive Techniken wir srcset (wovon ich hier garnicht erst träume).
Als ersten Schritt zur Lösung des Problem würde ich vorschlagen, hier eine Klasse einzubauen, mit deren Hilfe man Bilder fluid runterskalieren lassen kann. D.h. man baut die Bilder in der größten sinnvollen Auflösung ein und sobald diese größer ist als der zur Verfügung stehende Raum, werden sie runterskaliert.
Hier mein Implementierungsvorschlag:
.fluid-img{max-width:100%;}.fluid-img>img,.fluid-img>.image>img{max-width:100%;width:auto!important;/* Überschreibt width-Attribut in HTML */height:auto!important;/* Überschreibt height-Attribut in HTML */}
Ich bin mir nicht sicher, Martin, ob die Richtung stimmt. Es sind mindestens 2 Fälle zu unterscheiden:
Infoboxen mit festen Bildbreiten. Da mag dein Ansatz für funktionieren
Bilder im Fließtext, idR rechts: Diese sollten *immer* ohne feste Bildgröße eingebunden sind, höchstens mit hochkant bzw. hochkant=Skalierungsparameter relativ gesetzt werden. — RaymondDisk.18:36, 26. Jul. 2017 (CEST)
Diese CSS-Klasse dürfte vor allem in Vorlagen und bei anderen Layout-Sonderfällen zum Einsatz kommen. Für die normalen Vorschaubilder im Textinhalt ist sie nicht gedacht – und es käme wohl kaum ein Autor auf die Idee, dort den obigen HTML-Code einzusetzen.
Aber mal abgesehen davon muss man hier zwischen der WikiText-Eingabe und der HTML-Ausgabe unterschieden. Denn auch wenn im WikiText keine fixe Bildbreite gesetzt wird, rendert MediaWiki eine fest Pixel-Breite (i.d.R. 220px) ins HTML. Und das ist das, was der Browser letzten Endes interpretiert. Dummerweise sperren diese fixen Bildgrößen dann erbarmungslos die Container (Info-Boxen, Tabellen, etc.) auf, in denen die Bilder sitzen, oder sorgen sogar dafür, dass die Bilder ihre Container und andere Elemente überlappen.
Auf „normalen“ Websites behebt man dieses Problem, indem man Bilder grundsätzlich ohne Höhen und Breiten-Attribute ausgibt und irgendwo im CSS das hier stehen hat:
img{max-width:100%;}
Das wäre auch in MediaWiki sinnvoll, aber ich bezweifle, dass es in absehbarer Zeit dazu kommt. Leider (und das ist das eigentliche Problem) lässt die statische Größenausgabe selbst im Bedarfsfall nicht mit Inline-CSS überstimmen, weil die <img src="">-Tags direkt von MediaWiki inkl. der Höhen und Breitenangaben erzeugt werden, ohne dass man ihnen irgendein CSS mitgeben könnte. Das bekommt also nur mit einem richtigen StyleSheet in den Griff.
Aus meiner Sicht wäre daher ein CSS-Hack, wie der oben, die einzige Möglichkeit, um bei Bedarf ein fluides Verhalten von Bilder zu erzwingen. // Martin K. (Diskussion) 20:03, 26. Jul. 2017 (CEST)
P.S.: Bei Interesse kann ich Euch gerne einen Login zu meinem Test-Wiki zukommenlassen. Da habe ich diesen Vorschlag hier und den oben drüber schon mal testweise implementiert. // Martin K. (Diskussion) 20:23, 26. Jul. 2017 (CEST)
Ich habe noch nicht restlos das Ziel der Aktion verstanden. Ich bin aber der Auffassung, dass
das ggf. auf MediaWiki-Ebene vom dortigen MultiMedia-Team angepackt und diesem verdeutlicht werden sollte;
wir hier keine privaten Bastel-Hack-Wege in Seiten der dewiki etablieren sollten;
wir insbesondere nicht die projektweit in über zehn Millionen Seiten eingebundenen CSS-Konstrukte mit Angelegenheiten belasten sollten, die dann in zwei oder drei Seiten mal benutzt würden.
Im Übrigen wäre hier die Etablierung einer werbenden deutsch-englischen Benutzerseite anzuraten, die das Problem verdeutlicht, und Beispielanwendungen zeigt, nebst Code-Sequenzen. die sich dann jeder temporär in sein privates CSS injizieren kann, um die Effekte live auszuprobieren, nebst Verlinkung von Hintergrundmaterial.
Insbesondere ist mir auch nicht klar, warum der o. a. Code !important enthalten müsse.
Mal abgesehen von MediaViewer hat das MultiMedia-Team (so es ein solches überhaupt noch gibt) meiner Wahrnehmung nach in den letzten 5 Jahren nichts substanzielles mehr an der Medienanzeige im Desktop-Frontend verbessert. Vielversprechende Ansätze wie Winter verschwanden wieder in der Schublade, Innovationen gab es wenn dann auf der mobilen Seite oder in der App. Hier in Vector herrscht Grabesstille. Und wenn ich die WMDE-Techniker mit denen ich mich darüber unterhalten habe richtig verstehe, wird sich daran in absehbarer Zeit nichts ändern. Kein Wundern, dass andere Sprach-Communities (wie die en.WP) mittlerweile selbst in erheblichem Umfang an ihrem Layout und den Bilddarstellungen rumdoktorn – leider mit einem sehr durchwachsenen Ergebnis.
Wenn es darum geht „keine privaten Bastel-Hack-Wege in Seiten der dewiki etablieren“ bist Du leider 15 Jahre zu spät dran ;) Dieses Wiki inkl. seiner Vorlagen steckt voller „Bastel-Hack-Wege“. Die hier (aus Ermangelung vernünftiger Alternativen) bis zum Exzess eingesetzten Inline-Styles sind nichts anderes als „Bastel-Hack-Wege“, die bei jedem Front-Endentwickler, den ich kenne das blanke Grausen hervorrufen. Da kann jede gut durchdachte und vernünftig dokumentierte globale CSS-Klasse nur dazu beitragen, den Code in diesem Projekt wartbarer zu machen und weitere Inline-CSS-Hacks zu verhindern.
Die hier vorgeschlagen Lösung belastet keine einzige Inline-CSS-Konstrukution, weil sie ja überhaupt nur dann zur Anwendung kommt, wenn der Anwender ausdrücklich die CSS-Klasse .fluid-img verwendet. Und wenn er das im von ihm selbst verantworteten Code (z.B. einer Infobox-Vorlage) tut, dann muss er dabei, wie bei allen anderen Änderungen auch, die Konsequenzen bedenken.
User-CSS ist keine Lösung. Weil die oben beschrieben Probleme unser Nachnutzer in vielgrößerem Maße betreffen als die hier aktiven Autoren. Schau Dir den doch einfach mal den Artikel Sonnensystem in einem schmalen Browserfenster an.
Die !important Anweisung habe ich hier eingefügt, weil ich mir nicht sicher war ob MediaWiki die Bildgrößen in bestimmten Fällen auch per Inline-CSS setzt. Wenn das immer nur HTML-Attribute sind können sie (nach meinen jüngsten Tests) auch weg.
Ich bin der festen Überzeugung, dass wir bei solchen Problem zweigleisig fahren müssen:
Auf der einen Seite müssen wir natürlich dafür werben, dass die WMF und WMDE das Responsive Webdesign des Desktop-Frontends endlich angehen. Und bei den technischen Wünschen habe ich genau das auch schon getan. Nur leider wird das bestenfalls mittel- bis langfristig Wirkung zeigen.
Und deshalb müssen wir auf der anderen Seite dort, wo Probleme besonders offensichtlich sind, selbst auf dem kleinen Dienstweg Lösungen implementieren, die verhindern, dass die fünft größte Website der Welt nicht auf vielen Geräten total zerschossen aussieht, und eine halbwegs zeitgemäße Darstellung ermöglichen. // Martin K. (Diskussion) 20:50, 26. Jul. 2017 (CEST)
P.S.: Ich habe mir gerade mal angesehen, wie die das in der Mobilversion lösen. Und siehe da, dort steht im CSS im Endeffekt genau das, was auch ich hier vorschlage – mit dem kleinen aber feinen Unterschied, das es nicht dezent bei Bedarf durch eine Klassen eingebaut werden kann, sondern einmal brachial über alles drübergebügelt wird (!important inkl.).
Please don't do this, unless you really have to! It is really bad for maintenance (you might have to update the same information multiple times per document), and it also mixes your presentational CSS information with your HTML structural information, making the CSS harder to read and understand. Keeping your different types of code separated and pure makes for a much easier job for all who work on the code.
The only time you might have to resort to using inline styles is when your working environment is really restrictive (perhaps your CMS only allows you to edit the HTML body.)
Was die Mär angeht von „Inline-CSS ist bööööööse, nimm immer projektweite Klassen“:
Das stimmt für Websites, die wenige unterschiedliche Elemente in allen ihren Seiten anbieten.
Das trifft nicht für uns zu, die wir zigtausende unterschiedliche Formatierungen haben, mal für Feuerwehrautos, mal für das Thema Borussia-Mönchengladbach, mal für Laub- und Nadelwälder, mal für tibetische Schrift.
Wenn wir das tun würden, was hier vorgeschlagen wurde, dann landen wir bei Zigtausenden von Klassen mit lustigen Namenskonventionssystemen und einem CSS-Wust von 50 MB, die in jeder der über zehn Millionen Inhaltsseiten präsent sein müsste und bei der Hunderttausende von Selektoren in jeder Seite vom Browser durchzuprobieren wären. Wobei nur eine Handvoll wirklich greifen würde.
Das nicht begriffen zu haben und mit Super-responsive-web-designer-Phrasen anzukommen entwertet das Begehr.
Wenn wir für jede Idee, die irgendwer hat und auf einem Dutzend Seiten einbauen will, jedesmal die umseitige projektweite und von Admins zu pflegende Seite um neue Definitionen erweitern würden, dann käme man bei genau diesem Müll raus.
In den ersten Jahren der deWP hatte man mal den Riesen-Riesen-Fehler begangen, und für allerlei Vorlagen statt Inline-CSS jedesmal die umseitigen Definitionen erweitert.
Was zur konfusen Aufblähung führte und nicht mehr wartbar wurde.
Um sowas wieder loszuwerden, wird teilweise ein Dutzend Jahre extrem aufwändiger Pflegearbeit benötigt.
Wenn umseitig etwas neu hineinkommen soll, dann muss die Notwendigkeit für sehr viele Seiten und sehr viele Situationen bei vielen Benutzern dargelegt werden.
Das ist bislang nicht ansatzweise der Fall.
Eine übersichtliche Darlegung, was eigentlich wann wo passieren und bewirken soll, ist bisher nicht erfolgt.
Dafür ist hier auch der falsche Ort.
Es ist durch Screenshots zu verdeutlichen und Nutzungsstatistiken sind nachzuweisen.
Ein lokaler Hack wird umseitig ohnehin nicht mehr reingepfuscht; wenn das wirklich ein ernsthaftes Problem sei, dann müsste sich ja auch das WebDesign-Team von Mediawiki leicht überzeugen lassen, und dann kann das ja auch weltweit bereitgestellt und gepflegt werden.
Es gibt nicht nur die Optionen Inlines-Styles oder Projektweite Klassen. Es wäre durchaus machbar Themen oder Namensraum spezifische CSS-Dokumente einzubinden. Dass dieses schon seit Jahren angedachte Projekt noch immer nicht ausgerollt, liegt sicher auch daran, dass es sich die meisten im hießigen Inline-Style-Wildwuchs bequem eingerichtet haben. Der Eindruck drängt sich jedenfalls auf, wenn man bedenkt, dass hier Vorschläge wie dieser oder der oben drüber refelxartig mit dem Beamtendreisatz abgeblockt werden.
Zeige mir mal irgendeine umfangreiche Website, die so massiv über Inlne-Styles formatiert wird wie die Wikimedia Wikis. Zeige mir ein Lehrbuch, eine Doku oder einen W3C-Draft der die Verwendung von Inline-Styles in einem so massiven Ausmaß empfiehlt.
Dass es hier "zigtausende unterschiedliche Formatierungen" gibt, ist mMn kein schützenswerter Zustand sondern Teil des Problems. Wenn man z.B. früh genug eine saubere CSS-Bibliothek für Infoboxen etabliert hätte, hätte man sich hunderte Inline-Style-Orgien unterschiedlichster Qualität genauso sparen können, wie die Hacks, die dafür nötig sind diesen Murks mobil und in der App anzuzeigen.
"Wenn wir das tun würden, was hier vorgeschlagen wurde" hätten wir irgendwann ein vernünftiges CSS-Framework (vgl. Bootstrap, Skeleton oder Foundation), dass uns hundertausende KB an InlineStyle-Murks ersparen würde. Und nein: Wir können nicht darauf warten, dass das irgendwann mal vom WMF-Himmel fällt.
Dass ich hier immer wieder für responsive Lösungen plädiere sind keine hohlen Phrasen, sondern die Erfahrung aus mehr als 12 Jahren Berufs- und mehr als 3 Jahren Hochschullehrerfahrung in diesem Bereicht.
Es geht nicht um irgendeine Idee für ein paar dutzend Seiten, sondern um eine generalisierte Lösung die in theoretisch in allen Infobox-Vorlagen mit Bild Anwendung finden könnte. Und die sind in einigen hundertausend Seiten eingebunden.
Nochmal: Es ist keine Insellösung für eine Vorlage, sondern eine Standard-Klasse, die in Dutzenden Vorlagen und zehntausenden Seiten Verwendung finden könnte.
s.o.
Es wurde beschrieben worum es geht. Und es wurde dargestellt, dass genau diese Funktionalität im Mobile-Skin bereits angewandt wird. Was willst Du denn noch wissen?
P.S.: Ich finde es übrigens interessant, dass man sich hier an ein paar Zeilen Code stört, die auf tausenden Seiten Verwendung finden könnten aber scheinbar kein Problem damit hat, das bei jedem Seiten Aufruf 60 Zeilen CSS mitausgeliefert werden, die exakt auf einer Seite einer Rolle spielen: Der Hauptseite.
P.P.S.: Um abschätzen zu können welche Last dieser Inline-Style Unsinn verursacht, sollte man sich einfach mal test weise anschauen, wie viel in davon in den einzelnen Artikel gebaut ist:
Im Artikel Sonnensystem sind es 64 Style-Attribute mit 1.621 Zeichen.
Im Artikel Deutschland 417 Attribute mit 9.325 Zeichen.
Im Zuge einer normalen Wikipedia-Recherche kommt da so einiges a KB zusammen. Auf jeden Fall deutlich mehr als in der umseitigen Datei, die im Gegensatz zu den Styles im Artikel nur einermal geladen wird und dann gecached ist. @PerfectesChaos: Hälst Du das wirklich für eine sinnvolle Lösung? // Martin K. (Diskussion) 00:02, 27. Jul. 2017 (CEST)
Ich darf auf mw:Extension:TemplateStyles verweisen? Mit der Technik kann Seiten- und Vorlagespezifisches CSS gepflegt werden. Damit kann dann auch die Common.css deutlich entschlackt werden. Immerhin schon auf Betalabs aktiv, siehe WP:NEU#Bald™. Ein genauer Zeitplan zur Einführung hier habe ich nocht gefunden. Aber wir können da ja schonmal was vorbeireiten :-) — RaymondDisk.23:49, 26. Jul. 2017 (CEST)
@Raymond: Danke, die Extension kannte ich schon. Da wurde bei solchen Gelegenheiten ja schon oft drauf verwiesen, nur scheint mir da ein RollOut im Wiki nicht wirklich absehbar und falls ja findet sich hier sicher wieder irgendwer, der das Zugunsten der ach so tollen Inline-Styles reglementieren möchte.
Die hier vorgeschlagene Lösung würde übrigens die hier vorgeschlagene CSS-Ergänzung nicht überflüssig machen: Wenn Dinge so oft eingesetzt werden, wie es bei dieser Funktion absehbar ist, dann macht es keinen Sinn, sie redundant in zig Vorlagen-StyleSheets zu deklarieren. Dann macht man das besser einmal global.
Und meines Erachtens ist die Tatsache, dass man im mobilen Skin genau das getan hat, ein deutliches Indiz dafür, dass es diesen Bedarf gibt. // Martin K. (Diskussion) 00:23, 27. Jul. 2017 (CEST)
Kontra. Wenn ich es recht verstehe, sind Infoboxen u. A. dazu gedacht, für ein einigermaßen einheitliches Erscheinungsbild im Layout zu sorgen. Die Annahme eines solchen Vorschlags wäre geeignet, diesen Aspekt völlig zu konterkarieren. MagentaGreen (Diskussion) 23:47, 26. Jul. 2017 (CEST)
@MagentaGreen: Inwiefern sollte es denn ein einheitliches Erscheinungsbild konterkarrieren, bloß weil die enthalten Bilder jetzt fluide als statisch angezeigt werde? Grundsätzlich sind globale StyleSheets sind doch gerade, dazu da ein einheitliches Erscheinungsbild sicher zustellen?! Und dass es bisher keine vernünftigen Standardstile gibt, ist doch gerade der Grund dafür, dass die Infoboxen in diesem Projekt alles andere als Einheitlich sind. // Martin K. (Diskussion) 00:04, 27. Jul. 2017 (CEST)
@Martin, Inline-Styles
Bei deiner Berechnung hast du entweder einen Riesen-Riesen-Denkfehler gemacht und es immer noch nicht begriffen, oder du arbeitest vorsätzlich mit manipulativen Zahlen.
Der Grund, warum es in den Artikeln solche Inline-Styles gibt, ist, dass sie in genau diesem Artikel benötigt werden.
Die Styles, die in einem Artikel über Berlin und Kulturdenkmäler benutzt werden, gehören zu Berlin und Denkmälern.
In einem Artikel über Wien und Naturschutzgebiete mag grün für Natur anstehen, und zu den Tönungen der Stadtfarben hat man vielleicht wieder andere Wünsche.
Deine Vorstellung eines Verzichts auf Inline-Styles läuft darauf hinaus, dass die Grundfarbe des Heimtrikots des Hamburger Sportvereins einen Klassennnamen bekäme, die zweite Farbe einen weiteren Klassennnamen, das gleiche Paar für das Auswärtstrikot zwei weitere, dies genauso für alle Vereine der FIFA bis zum letzten Drittligisten, nach dem Soccer auch für Basketball, Baseball und Eishockey. Genauso haben SPÖ, SPD, die SDAP in der Weimarer Republik eine bestimmte Parteifarbe; jede Partei in jedem Staat in politischen Epochen ebenfalls einen Klassennamen.
Da du nicht wissen kannst, worum es in einem Artikel geht, willst du alle diese Klassen umseitig auflisten; damit auch die marineblaue Kennfarbe für Infoboxen über Kriegsschiffe in dem Artikel über Spanische Literatur mitgeliefert wird.
Das Namenssystem für alle diese Klassen sollen die Admins dann nebst Farbwerten auf Zuruf umseitig einpflegen.
Dabei kommen für eine Wikipedia unseres Zuschnitts, die sich nicht monothematisch nur mit Briefmarkensammlungen beschäftigt, utopische Dimensionen heraus, die auf jede gelesene Seite anzuwenden sind.
Da die Inline-Styles spezifisch für den Inhalt der Seite sind, werden genau die benötigten jeder Seite mitgeliefert.
Für die Ausrichtung einer Tabellenzelle ist es gehupft wie gesprungen, ob da Inline steht style="text-align:center" oder nach Art der Hochschullehrer class="table-cell-centered", aber das erste wird in jeder HTML-Anleitung erklärt und bedarf keiner Nachforschung, wo die Stildefinition herkommt und wie sie in welchem Wiki in welchem Jahrzehnt heißt und wie viele Jahre sie noch unterstützt werden würde – es funktioniert robust und stand-alone.
Alles das stellst du unfairerweise als Nachteil hin, und behauptest, Jazzmusik müsse unbedingt das Auswärtstrikot von Manchester United kennen und als CSS-Klasse mitgeliefert bekommen, sonst wäre das eines Hochschullehrers unwürdig. Was soll Charlie Parker denn mit der Trikotfarbe anfangen, oder mit dem Grünton für B’90/G?
Benutzer, teils auf Sichterrechte beschränkt, können fast alle Vorlagen bearbeiten.
Diese ermöglichen seit anderthalb Jahrzehnten nur Inline-Styles.
Die Vorlagen sorgen innerhalb ihres thematischen Bereichs für Einheitlichkeit.
Klassendefinitionen in der Gesamt-Seite sind aus guten Gründen auf Admin-Rechte begrenzt.
Das Projekt ist demokratisch organisiert, und jedes Fachgebiet hat das Recht, sich seine Infoboxen nach eigenen Ideen zu gestalten und zu programmieren.
Für Navileisten bieten wir Vorlage:Navigationsleiste als Basisfunktionalität an (mehr als eine halbe Milluion Einbindungen); freiwillig gäbe es seit 2006 auch Vorlage:Infobox – wird aber kaum benutzt, und es gibt hier keinen Oberhochschullehrer, der die Fachgebiete dazu zwingen könnte oder davon abhalten könnte, sich ihre Infoboxen so zu programmieren, wie sie das möchten.
Die Benutzer und gar die gefürchteten Haupt- und Erstautoren sind sehr frei, Artikel und andere Seiten so zu gestalten und zu formatieren, wie sie das für richtig halten, und werden sich von Martin K. sicher keine responsiven Vorschriften machen lassen. Nicht wenige lehnen sogar Vorlagen und Technik völlig ab.
In den Kinderjahren der WP wurden einige Fehler gemacht.
Einer der Fehler war gewesen, für einzelne Vorlagen und für einzelne Themengebiete Klassendefinitionen anzubieten, statt auf Inline-Styles zu verweisen, die von den Benutzern in den Themengebieten selbst verwaltet werden könen.
Woraufhin die Stildefinitionen einfach frech für völlig andere Zwecke missbraucht wurden; siehe ein Abschnitt tiefer.
Weshalb man eine einmal definierte Klasse praktisch nie wieder los wird, und die Admins bei der Betreuung des umseitigen CSS dann allen verwendenden Seiten hinterherrennen sollen? Oder wer soll das deiner Meinung nach alles pflegen? Oder jede einmal definierte Klasse solle in alle Ewigkeit weitergepflegt werden, und immer neue dazukommen?
Die Hauptseite ist auch so ein Fehler gewesen, und der ganze Block ist sicher allererster Kandidat für eine 1:1-Auslagerung in die neue seitenpezifische Klassendefinition; bis dahin bleibt es beim Status quo und wird nicht verbastelt.
Es gibt wohl 10–11 Millionen Vorderseiten und wahrscheinlich 5 Millionen Diskussionsseiten und deren Archive, plus Spezialseitenaufrufe. Ein CSS, das mit einer Chance unter 1:15000000 einen Selektor trifft, ist einfach unwirtschaftlich und eine Frechheit gegenüber allen, die irgendeine der anderen Seiten lesen wollen.
Lektionen haben wir gelernt:
Wir machen kein projektweites CSS mehr, das nur eine Handvoll Seiten treffen wird.
Wir machen keine Parallelentwicklungen mehr zu für alle Wikis weltweit verwendbares CSS.
Beispielsweise gibt es eine weltweit gepflegte und in allen Seiten verfügbare wikitable. Unsere sehr ähnliche aber doch nicht immer 1:1 kompatible prettytable ist seit einem Jahrzehnt veraltet, steckt aber immer noch in vielen Köpfen oller Wikipedianer drin, wird immer wieder neu verbaut und ist trotz aller Bemühungen immer noch in 10 % der Artikel mit formatierten Tabellen vorhanden.
Wir überlegen deshalb sehr sorgfältig, ob es wirklich unumgänglich ist, umseitig neue „Standardklassen“ zu definieren, die dann sonstwo verbaut werden und die wir auf Jahrzehnte nicht mehr loswerden und separat pflegen müssen; und ob das auch genügend viele Seiten erreichen würde. Insbesondere wenn bereits absehbar wäre, dass es mittelfristig eine wieder anders strukturierte MediaWiki-Lösung geben würde.
Das umseitige CSS ist dazu da, die Angelegenheiten zu definieren, die deutschsprachig definitiv anders sind als in der weltweiten Wiki-Software; es wird nach und nach zurückgebaut und ist idealerweise eines Tages eine leere Seite.
@Martin, MediaWiki
Wo ist eigentlich die Tasknummer deines Vorschlags?
Das müsste ja alle Webseiten betreffen, die im letzten Vierteljahrhundert erstellt wurden und auf einen hochauflösenden Bildschirm treffen. Ein Browser weiß, was für ein Bildschirm vorliegt; ist denn ausgeschlossen, dass Browser demnächst das aus eigenen Stücken angemessen darstellen werden? Sie kennen ja das Verhältnis von Schriftgröße zu Pixeln, und das wäre ja offenbar alles.
Vorab: Dir ist aber schon klar, dass Du hier im Endeffekt gegen das Paradigma der Trennung von Design und Inhalt und die Grundidee der Cascading Style Sheets an argumentierst? Falls ja: Ist Dir bewusst, dass Du mit der Ablehnung dieser Prinzipien unter denen, die sich professionell mit der Gestaltung und Programmierung von Websites beschäftigen, ziemlich allein auf weiter Flur stehen dürftest?
Ich hatte das JavaScript, mit dem ich diese Zahlen ermittelt habe, oben gepostet. Falls da eine Denkfehler drin sein sollte (was natürlich nicht ausgeschlossen ist), sag mir bitte wo (Das wäre in jedem Fall redlicher als mir hier Manipulation zu unterstellen). Um meine User-Styles und irgendwelche Spezial-Scripte auszuschließen habe, ich die Seiten übrigens unangemeldet in einem aktuellen Firefox im Inkognito-Modus getestet, und zwar nachdem sie vollständig geladen waren. Ich glaube als jemand, der vorallem an den Vorlagen selbst arbeitet, unterschätzt Du massiv, wie oft hier gerade die kleineren Vorlagen und mit Inline-Styles versehenen Elemente eingesetzt werden.
Dass Styles in einem Artikel benötigt werden, ist kein Argument für Inline-Styles. Selbst wenn sie (was bei Vorlagen-Styles praktisch nie vorkommt) nur in einem einzigen Artikel verwendet würden, könnte man das häufig mittels eines echten StyleSheets besser lösen.
Gerade die Denkmallisten sind ein hervorragendes Beispiel für den Irrsinn von Inline-Styles und anderen Code-Redundanzen, weil optisch praktisch identische Element hunderte Male auf einer Seite eingefügt werden. Mit vernünftigen CSS wäre dass alles kein Problem, weil das Aussgehen genau einmal definiert würde, mit Inline-Styles hingegen wird das Aussehen mit jedem neuen Element erneut definiert. Und das ist nicht nur aus Bandbreiten- sondern auch aus Performance-Sicht absurd. Die Liste_der_Kulturdenkmale_in_Berlin-Kreuzberg ist da noch nicht mal besonders schlimm, weil sie nur auf Tabellen und nicht auf Vorlagen basiert. Aber auch hier wird z.B. {{Coordinate}} 371mal eingebunden. Und das erzeugt dann bei jedem einzelnen Eintrag für einen winzigen Button diesen Wusts hier:
In einer Vorlagen basierenden Liste sieht das ganze noch viel schlimmer aus. Unter Liste der Kulturdenkmäler in Frankfurt-Altstadt z.B. komme ich auf 684 Style-Attribute mit 22.211 Styles und das obwohl die Liste sehr viel kürzer ist und {{Denkmalliste Hessen Tabellenzeile}} "nur" 104mal eingebunden wurde. Dummerweise ertzeugt aber jede dieser Einbettung für eine einzelne Zeile das hier:
<trstyle="vertical-align:top;"class="vcard"><tdstyle="background-color:#eee; text-align:center; vertical-align:middle;"><ahref="/wiki/Datei:Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg"class="image"title="Berliner Straße 60 / Kornmarkt 4, von Südwesten gesehen"><imgalt="Berliner Straße 60 / Kornmarkt 4, von Südwesten gesehen"src="//upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg/120px-Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg"srcset="//upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg/180px-Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg/240px-Frankfurt_Am_Main-Berliner_Strasse_60_Kornmarkt_4_von_Suedwesten-20110615.jpg 2x"data-file-width="4500"data-file-height="3000"width="120"height="80"></a><br><spanid="Ehemaliges_Haus_Breslau"><spanid="Anker:Ehemaliges_Haus_Breslau"></span></span><spanid="Berliner_Stra.C3.9Fe.C2.A060.28.3D_Kornmarkt.C2.A04.29"><spanid="Anker:Berliner_Stra.C3.9Fe.C2.A060.28.3D_Kornmarkt.C2.A04.29"></span></span></td><td>Ehemaliges Haus Breslau</td><tddata-sort-value="Berliner Strasse 60(= Kornmarkt 4)"><ahref="/wiki/Berliner_Stra%C3%9Fe_(Frankfurt_am_Main)"title="Berliner Straße (Frankfurt am Main)">Berliner Straße</a> 60<br>
(= <ahref="/wiki/Kornmarkt_(Frankfurt_am_Main)"title="Kornmarkt (Frankfurt am Main)">Kornmarkt</a> 4)<br><spanid="Ehemaliges_Haus_Breslau"class="plainlinks-print"title="Koordinate"><spanstyle="white-space: nowrap;"><spanstyle="color: blue; padding: 0px 3px 0px 0px; cursor: pointer;"class="wmamapbutton noprint"title="Ort auf interaktiver Karte anzeigen"alt="">♁</span><aclass="external text"href="//tools.wmflabs.org/geohack/geohack.php?pagename=Liste_der_Kulturdenkm%C3%A4ler_in_Frankfurt-Altstadt&language=de&params=50.111444_N_8.679646_E_region:DE-HE_type:landmark&title=Ehemaliges+Haus+Breslau"style="white-space: normal;">Lage</a></span></span></td><td><spanid="Berliner_Strasse_060"><spanid="Anker:Berliner_Strasse_060"></span></span>Büro- und Geschäftshaus an der neugeschaffenen Ost-West-Achse. Fassade durch Fensterbänder horizontal betont, zurückgesetztes Dachgeschoss.<supid="cite_ref-Kaiser_2000-8_24-4"class="reference"><ahref="#cite_note-Kaiser_2000-8-24">[24]</a></sup></td><td><spanstyle="display:none"class="sortkey">1954!</span>1954<supid="cite_ref-Kaiser_2000-8_24-5"class="reference"><ahref="#cite_note-Kaiser_2000-8-24">[24]</a></sup></td></tr>
Dass der von Vorlagen generierte Code so ausladend ist, liegt natürlich nicht ausschließlich aber doch zu einem erheblichen Teil am exzessiven Inline-Style-Gebrauch. Und mMn käme es einer Realitätsleugung gleich, wenn man dieses offensichtliche Problem abstreiten würde.
Ich sehe weder in der Liste der Naturschutzgebiete in Wien noch im Artikel Wien irgendwelche Kontext abhängigen Farben. Kann es sein, dass Du hier den Inhalt (namentlich das Bildmaterial) mit dem dem Layout durcheinander wirfst (s.o.)?
Mal abgesehen davon, dass ich Inline-Styles gar nicht kategorisch ausschließen (das wäre unrealistisch) sondern nur so weit wie möglich eindämmen will, verwechselst Du auch beim Hamburger SV Inhalt und Layout. Das Aussehen der Trikot ist aus Gestalterischer Sicht ein Bild-Inhalt (auch wenn der hier aus diversen Einzelteilen zusammengebastelt wird), der so in genau einem Artikel zur Anwendung kommt. Das hat mit dem hiesigen Thema genauso wenig etwas zu tun, wie irgendwelche Diagramme oder SVGs.
Ungeachtet der Tatsache, dass es mMn eh viel zu viele nicht unbedingt selbsterklärende Farbcodes in InfoBoxen gibt, wäre das Styling von Infoboxen über Themen, wie die Marine oder spanische Literatur wäre ein Anwendungsfall für die von Raymond verlinkte Style-Extension (wenn die denn mal kommt).
Habe ich gefordert hier für Hunderte Farben Klassen anzulegen? Nein, das habe ich nicht! Mir geht es hier um Standardklassen für Standardanwendungsfälle. Also genau das, was in üblichen CSS-Frameworks auch definiert wird.
Die Behauptung, ich wolle hier alles in der Commons.css regeln, ist nichts weiter als eine Strohmannargument. Das habe ich nirgendwo gefordert.
Es gibt nur sehr wenige Fälle in denen Stile wirklich nur auf exakt einer Seite und dort auch nur exakt einmal angewendet werden. Gerade für Vorlagen trifft dies nie zu.
Wenn Du wirklich meinst, dass es mir darum ging die Inline-Styles 1:1 gegen eine Klasse auszutauschen, hast Du scheinbar das Konzept der Trennung von Code und Design nicht verstanden. Natürlich ist es sinnlos in hunderten Tabellenzellen statt style="text-align:center"class="table-cell-centered". Sinn voll wäre es, der Tabelle eine Klasse zu geben, über der sie dann die wesentlichen Formatierung für alle Zeilen und Zellen einmal vernünftig definiert würden:
Das was Du als „robust bezeichnest“ würden andere „unwartbar“ nennen. Wie Du im Thread eins weiter unten siehst, ist es ziemlich einfach, herauszufinden wo eine bestimmte Klasse überall verwendet wird. Entsprechend einfach liesen sich Fehler aufspüren und ggf. mit einem Bot-Lauf diese Klasse gegen eine andere austauschen. Bei Inline-Styles ist das nicht so einfach möglich. Wenn man hier merkt, dass eine bestimmte Formatierungsart in einem Rendering die komplette Seite zerschießt, dann reicht es nicht das einmal irgendwo zentral zu ändern, dann kann man nichtmal mit einer einfachen Suche herausfinden, wo überall das Problem auftritt. Dann muss man mühsam durch tausende Seiten gehen, in den Einzel-Anweisungen stehen, die irgendwas damit zu tun haben könnten, um diese dann jeweils einzeln zu debuggen. Und da darauf keiner Lust hat, bleiben die Fehler halt drin und/oder werden von denjenigen, die die mobile Ansicht verantworten mit wüsten !importants überschrieben. Oder was glaubst Du, warum im Minerva CSS ganze 53mal !important steht?!
Wie gesagt, die Behauptung, ich wolle alles in ein CSS stecken ist ein Strohmann!
Die einfachen Benutzer die für Ihren Bereich eine Vorlage erstellen, erledigen das mangels Alternativen i.d.R. via Copy'n'Paste aus irgendeiner Vorlage, die so ähnlich aussieht. Und wenn wenn da Inline-Style-Murks drin steht, dann nehmen sie diesen Murks und kleben noch etwas mehr Murks dran, damit es irgendwie so aussieht, wie sie das gerne hätten. Wenn in den der kopierten Vorlage aber Klassen verwendet würden, und es irgendwo auch noch eine Vernünftige Doku zu diesen Klassen und einen CSS-Baukasten gäbe aus dem man sich einfach bedienen könnte, dann würden diese Nutzer auch das einfach kopieren und einsetzen. Dass es hier so viel Inline-Styles angesetzt werden, liegt mEn vor allem daran, dass es hier schon so viele Inline-Styles gibt und vernünftige Alternativen für den Otto-Normal-Autor nicht auffindbar sind.
Natürlich wurden in den Kinder Jahren der WP viele Fehler gemacht:
Aber die Behauptung, es wäre besser gewesen sofort zu 100% auf InlineStyles, wird jedem, der sich auch nur ansatzweise mit Frontend-Entwicklung beschäftigt, zum Kopfschütteln und Lachen bringen. Das ist schlicht wirdersinnig.
Ich haben keine Ahnung, wie das mit der Vergabe von Klassennamen damals ablief, aber offensichtlich nicht so, wie es eigentlich sein sollte.
In einer idealen Welt hätte man in der Wikipedia von Anfang an Design und Inhalt strickt von einander getrennt und einen vernünftigen Prozess für die Erstellung neuer Content-Module etabliert. Das hätte nicht nru den Autoren erhebliche Mengen für sie unsinniger Arbeit abgenommen, sondern auch sicher gestellt, dass sich das Interface dieser Enzyklopädie über die Jahre kontinuierlich weiterentwickelt und qualitativ verbessert hätte. So wie es heute ist, leben die Autoren in der Wahnvorstellung, sie würden das Aussehen der Artikel maßgeblich festlegen und übersehen dabei, dass das was sie auf ihrem Desktop-Monitor sehen nicht mal die halbe Wahrheit ist. Nicht nur, das die mobile Version heute oft mehr Leser hat als die Desktop-Version und die Inhalte mit gestrippten Inline-Styles auch auf zig anderen Plattformen verwurstet werden, auch der Vector-Skin läuft auch auf unterschiedlichen Viewport-Größen nun mal unterschiedlich (von Monobook ganz zu schweigen). Und deshalb haben die Bebilderungs- und Designdiskussionen bei denen verschieden Autoren jeweils auf Basis der Ansicht auf ihrem Computer argumentieren etwas von absurdem Theater: Das ist wie in der Geschichte mit den Blinden und dem Elefanten.
Lass einfach mal die Strohmänner weg!
Gilt das nicht für alles andere, was da umseitig steht genauso. Mal abgesehen von Hauptseiten CSS entdecke ich da jedenfalls kaum einen Style, der nicht theoretisch auch in anderen Wikipedia-Sprachversionen angewandt werden könnte.
Zu „@Martin, MediaWiki“ worauf auch immer sich das beziehen würde:
Ich habe diverse Technische Wünsche eingereicht (die Du z.T. auch kommentiert hast) und verschiedentlich mit den zugehörigen Stellen in der WMF und bei WMDE darüber gesprochen. Um das ganze in Phabricator als Projekt in Phabricator anzulegen und mühseelig über Jahre und Monate voranzudrücken fehlt mir leider die Zeit – ich mach das hier nämlich nicht hauptamtlich. Zumal solche Top-Down-Lösungen hier doch eh immer wieder auf Widerstand stoßen. Denk nur mal an die letzten „Innovationen“ der WMF, vom VisualsEditor über dem MediaViewer bis hin zu sowas lächerlich kleinem wie dem Typographic-Refresh! Leider gibt es in diesem Projekt einen unglaublichen Strukturkonservatismus was die Technik angeht. Statt darüber nachzudenken, wie man sie sinnvoll implementieren und gewinnbringend einsetzen könnte. Werden Neuerungen fast immer reflexartig abgeblockt (und auch diese Diskussion ist leider ein Beispiel dafür). Und deshalb bin ich der Überzeugung, dass man solche Dinge hier besser im Bottom-Up-Verfahren einführt: Nämlich in dem man sinnvolle Angebote machte, deren Nutzung den Autoren reale Vorteile bringt und so idealerweise eine Sogwirkung erzeugt, die dann irgendwann zu einer projektweiten Anpassung führt.
Dass Browser alle Styles strippen und die Website einfach so anzeigen, wie sie sie für lesbar halten gibt es bereits: Es nennt sich Lesemodus. Aus Sicht des Website-Anbieters ist das aber nichts anders eine Bankrotterklärung, weil es letztlich nichts anderes heißt, als dass man selbst unfähig, ist eine funktionale und lesbare Nutzeroberfläche zur Verfügung zu stellen. Dass Vector sich seit seiner Einführung kaum nennenswert weiterenwickelt ist sicher auch einer der Gründe dafür, dass der Desktop-Version die Leser (und damit die potentiellen Autoren) weglaufen.
Es wäre daher schön, wenn Du Deine Fundamentalopposition gegen jede klassenbasierende Stylvereinheitlichung mal überdenken könntest. // Martin K. (Diskussion) 11:13, 27. Jul. 2017 (CEST)
@Martin Kraft: Da hier schon diverse Leute Contra gegeben haben, vermutlich weil sie sich nicht vorstellen können, wo das Problem genau liegt (ich übrigens auch nicht), wäre es klasse, wenn du Screenshots mit vorher/nachher zur Verfügung stellen könntest.
Und zur allgemeinen Info: Phab:T133410 für das Deployment der TemplateStyles-Extension. Sieht glaube ich gar nicht so schlecht aus, das noch dieses Jahr zu bekommen. — RaymondDisk.12:24, 27. Jul. 2017 (CEST)
Grundsätzlich betrifft das Problem jede Info-Box, Tabelle oder Box, die fluide wäre, wenn sie nicht ein Bild mit fester Größe enthalten würde. Dieses sorgt dann dafür, dass entweder der ganze Container aus der Seite oder über andere Dinge drüberragt und/oder gleich samt seinem Textinhalt abgeschnitten wird.
Das Problem ist deshalb nicht so offensichtlich, weil es meistens dadurch umgangen wird, dass nur anachronistisch winzig Bilder eingesetzt werden, weil größere bei kleineren Auflösung eben mangels Skalierbarkeit das Layout zerlegen würden.
Um das zu sehen musst einfach nur mal irgendeinen Seite auf machen in der breite Bilder und Tabellen eingebunden sind und dann Dein Browserfenster schmal (<800px) ziehen. Im Firefox kann manmit Str-M einen Modus öffenen in dem sich das gut simulieren lässt:
@Martin Kraft: Sorry, das hilft mir nicht weiter. Wie sähe es denn mit deiner Lösung aus? Ohne konkrete Screenshots vorher/nachher kommen wir hier nicht weiter, fürchte ich. — RaymondDisk.13:05, 27. Jul. 2017 (CEST)
Vergleich
Also gut, hier ein Screenshot der alten Version des Artikels Sonnensystem. Oben, so murksig wie war (man beachte das "Das"), und unten, wie genau dieselbe Infobox aussähe, wenn man das Bild mit Hilfe der hiesigen Klasse fluide gemacht hätte. In einem breiten Viewport sähen beide Versionen identisch aus.
Damit keine Missverständnisse aufkommen: Es geht hier nicht um einen HotFix für irgendwelche existierenden Detail-Probleme (die sind im fraglichen Artikel durch eine fixe Verkleinerung des Bildes mittlerweile behoben). Es geht um einen Standard-Klasse, die es uns erlauben würde zukünftig in diversen Vorlagen mit fluide skalierenden Bildern zu arbeiten und es so ermöglicht, Bildmaterial ganz anders einzusetzen, ohne dabei in Gefahr zu laufen die Seite auf kleineren Auflösungen zu zerstören. // Martin K. (Diskussion) 13:36, 27. Jul. 2017 (CEST)
@Raymond: Hast Du die TemplateStyles schon in irgendeinem Wiki zu Laufen bekommen.
Mein TestWiki wirft zwar keinen Fehler, aber es verarbeitet leider auch die Tags nicht korrekt. Statt einfach den Style anzuwenden steht da bloß "Vorlagenspezifisches Stylesheet:" und ein leerer grauer Kasten. Was für mich so aussieht, als würde er versuchen einfach die WikiSeite mit dem CSS-Code einzubetten.
Nun hab ich zugegebenermaßer auch "nur" MediaWiki 1.28.2 laufen. Aber das ist immerhin die jüngste stabile Version. Und wenn die jetzt darüber nachdenken, dass in die Wikimedia Wikis ausszurollen, sollte man das da doch zumindest mal testen können, oder? // Martin K. (Diskussion) 15:00, 27. Jul. 2017 (CEST)
Dann liegt's an der Version. Ist diese 1.30alpha so stabil, dass man damit vernünftig testen kann und kann man die einfach über die bestehende Installatipon drüberladen oder hat sich da was an der Datenbank geändert? // Martin K. (Diskussion) 16:57, 27. Jul. 2017 (CEST)
Bin gerade auf dem Sprung: Lass uns doch gemeinsam im Beta-Testwiki testen. Schau dir mal an:
Danke - sieht wirklich vielversprechend aus. Wäre ein Traum, wenn das live ginge bevor die diesjährige WEM-Kampagne startet.
Auch wenn es den hiesigen Vorschlag nicht obsolet macht. Bei wirklich regelmäßig verwendete Features macht eine globale Definition nämlich immer noch mehr Sinn, als es zig mal in irgendwelchen Vorlagen-Stylesheets zu definieren. // Martin K. (Diskussion) 18:35, 27. Jul. 2017 (CEST)
Drei Punkte:
1. MediaWiki master (1.30alpha): Im Prinzip läuft Wikipedia & Co damit. Jede Woche wird ein wmf-Branch vom Master erstellt und phasenweise auf die Wikis ausgerollt. Am einfachsten ist es, wenn du ein Testwiki dir einrichtest und das via Git mit dem Code befüllst. Dann ich es eine Frage von Sekunden, die Installation upzudaten. Datenbankupdates sind zwischen der 1.28 und 1.30alpha wahrscheinlich, jetzt aber nicht geprüft.
2. Inhaltlich kann ich selber nicht beurteilen, ob dein CSS-Code richtig ist. Da müssen Experten ran.
Verstehe nicht ganz: Was genau möchtest Du da testen?
Die Ergänzung der commons.css (die darf ich auch da nicht editieren) und die Einbindung in die Artikel? Oder eine Simulation des selbigen mittels der neuen Extension?
Es wurde 00:02, 27. Jul. 2017 mit der Länge von Inline-Style-Werten argumentiert.
Dabei wurde suggeriert, dass all diese Inline-Style-Angaben den Code aufblähen würden, und man dies durch die Verwendung projektweiter Klassendefinitionen einsparen könnne.
Ich hatte dir bereits dargelegt, dass derartige Klassendefinitionen mitnichten erwas einsparen, sondern nur Unmengen an Klassendefinitionen in jeder Seite bereitstellen müssen, und die Sache nur unendlich verkomplizieren.
Nun gut, nehmen wir mal Grasshopper Club Zürich und als Teilmenge der Vereinsfarben die Farben der Trikots.
Inline-Style
Mehode Martin K.
style="background:#0000FF"
class="grasshopper-zurich-tricot-leftarm1"
style="background:#FFFFFF"
class="grasshopper-zurich-tricot-body1"
style="background:#FFFFFF"
class="grasshopper-zurich-tricot-rightarm1"
style="background:#FFFFFF"
class="grasshopper-zurich-tricot-shorts1"
style="background:#FFFFFF"
class="grasshopper-zurich-tricot-socks1"
style="background:#FF8000"
class="grasshopper-zurich-tricot-leftarm2"
style="background:#FF8000"
class="grasshopper-zurich-tricot-body2"
style="background:#FF8000"
class="grasshopper-zurich-tricot-rightarm2"
style="background:#FF8000"
class="grasshopper-zurich-tricot-shorts2"
style="background:#FF8000"
class="grasshopper-zurich-tricot-socks2"
Jedes Kleinkind wird kapieren, dass der Klassenselektor länger ist als der Inline-Style; bei sonst gleicher Wirkung.
Der wiedergegebene JS-Code zählt nur die Werte, also links immer 18 Bytes, der Klassenbezeichner hat um 30 Bytes.
Es wird vorgetäuscht, die Kennzeichnung der Elemente mit Inline-Style würde Bytes kosten, wenn man dafür hingegen Klassenbezeichner verwenden würde, könne man all das einsparen und käme mit Null Bytes heraus.
Tatsächlich muss aber jedes einzelne Element mit einem eindeutigen Selektor versehen werden, und er ist bald doppelt so lang wie das Inline-Style. Hinzu kommt, dass irgendwo noch die Zuordnung von ID und Stildefinition erfolgen muss.
Den Aufwand für die eigene Idee mit Null Bytes darzustellen, aber den Inline-Styles angeblichen Mehraufwand zuzurechnen, ist unredlich.
In den fraglichen Seiten tauchen vorwiegend minimale typografische Zuweisungen auf, namentlich in Tabellenzellen style="text-align:right" etc. – diese jeweils zu ersetzen durch class="table-cell-align-right" macht es weder kürzer noch übersichtlicher, sondern erfordert nur die langjährige/ewige Pflege und Bereitstellung eines welt- oder projektweiten Klassenbezeichners table-cell-align-right.
Zusammenfassend: Die Auswertung war hochgradig manipulativ.
<templatestyles src="Foo/style.css" />
Das wird mitnichten zukünftig der Notwendigkeit entheben, projektweit eindeutige konfliktfreie Klassenbezeichner zu koordinieren.
In derselben darzustellenden Zielseite können mehrere solche Vorlagen (oder gar direkte Element-Einbindungen) auftreten. Werden in diiesen die gleichen Klassenbezeichner mit unterschiedlichen Zuweisungen verwendet, dann obsiegt (kaskadierend) derjenige, der zuletzt eingebunden wurde, also mutmaßlich die im Wikitext zuletzt auftretende Anforderung.
Das ist der Hintergrund von „Trennung von Design und Inhalt“, und wenn das once-only-Paradigma erfüllt ist, dann ist es automatisch auch die „Trennung von Design und Inhalt“.
Das machen wir aber schon seit ewig; oder versuchen es weitgehend durchzusetzen.
Ob das Ziel nun mit dem HTML-Attribut class= oder style= erreicht wird, ist völlig irrelevant und nur Gegenstand deiner verbohrten Verteufelungsideologie.
Mit Please don't do this, unless you really have to! It is really bad for maintenance und deinen Unterstreichungen hast du höchstpersönlich die Inline-Styles verdammt; darauf antworte ich dir hier.
Dein CSS-Code-Beispiel mit der Tabelle hinkt völlig.
Es geht von dem einen Spezialfall aus, in dem genau die erste Spalte vielleicht zentriert sein möge, die anderen aber unverändert bleiben. Für genau diesen einen bietest du eine Lösung an.
Wir haben aber eine enorme Viefalt von Tabellen; seien es Chartplatzierungen, Wahlergebnisse oder volkswirtschaftliche Daten, und die technischen Daten von Güterzuglokomotiven; mal quer und mal hochkant angeordnet.
Da ist dann die siebte Spalte zentriert, die achte linksbündig, die neunte rechtsbündig, die zehnte wieder anders.
Für jedes Schema jeder Tabelle willst du dann dein Klassensystem vorbereitet halten – ich repariere seit Jahren Tabellen in unserem ANR und weiß, dass du definitiv dein Klassensystem nicht in eine für Bearbeiter verständliche Form bringen wirst, die dann auch noch jedes ESC-Ergebnis abdecken würde. Es wird dir noch nicht einmal gelingen, alle Konfigurationen von momentan vorhandenen Tabellen zu versorgen; geschweige denn jede zukünftig noch hinzukommende.
Du kannst auch keinem Autor vermitteln, er dürfe für seine Inhalte nur die drei oder fünf Tabellenformate verwenden, die du erlaubst, weil du danach keine Lust mehr hattest, Klassenstile zu unterstützen; die zweitausend anderen erforderlichen Tabellenstrukturen sind dann verboten – oder müssten konventionell formatiert werden. Dann können wir aber auch gleich universell eine einheitliche Methode benutzen, die immer funktioniert und wo man sich nicht erst in irgendwelche abstrakten Systeme einarbeiten muss, um am Ende zu festzustellen, das es damit doch nicht geht.
Wenn wir Tabellen formatieren wollen, setzen wir übrigens gern Vorlagen ein, die dann nur noch die inhaltlichen Daten erhalten und diese dann (mit den von dir niedergemachten Inline-Styles) formatieren, größer oder kleiner, mittig oder rechtsbündig darstellen und Verlinkungen generieren: Kategorie:Vorlage:Tabellenformatierung Du findest da auch viel Denkmallisten: Kategorie:Vorlage:Denkmaltabelle. Dass das längst nicht überall eingesetzt wird, weiß ich auch; es macht erstmal eine erhebliche geistige Investition erforderlich, um ein derartiges Schema konzeptionell für die eigene Thematik zu erarbeiten. Mit deinem Klassensystem wäre das noch weitaus komplizierter. Es ist für die Tabellenvorlagen absolut wurscht, ob die Programmierung der Vorlage direkt inline erfolgt oder über eine nochmal gesonderte Abstaktionsebene als Klasse. Das mit dem Inline kapiert aber jeder sofort; auch jeder spätere Bearbeiter, der das pflegen und warten muss – was bei einem abstrahierten Klassensystem für jede Vorlage nicht der Fall ist und die meisten, die sich mühsam in die Vorlagennanpassung reingefummelt hatten, rigoros vor die Tür setzt. (Nebenbei sind genau diese Vorlagen die Trennung von Inhalt und Design, mit Mehrwert bei Verlinkungen usw.)
Deine ganzen Vorstellungen sind blanke Theoretisiererei und gehen weit am Horizont der Artikelautoren vorbei.
Die haben ein fachliches Interesse an ihrem Artikelthema und wollen eine möglichst einfache und verständliche und robuste Syntax haben; und haben keinerlei Lust, sich in irgendwelche Designphilosophien hineinzudenken. Du nennst das „einen unglaublichen Strukturkonservatismus was die Technik angeht“ – unsere Autoren sind aber Japanologen oder Chemiker oder Automechaniker und keine Web-Designer oder Informatik-Philosophen. Wenn du das immer noch nicht gerafft hast, ist es dein Pech.
Die Wikis sind typografisch und nicht semantisch orientiert. Theoetisch müsste auch jedes Fremdwort oder fremdsprachliche Sequenz mit lang= markiert werden, jeder Werktitel mit <cite> und dessen Parametern eingefasst werden, jedes Zitat statt in Anführungszeichen in <q> und mit dessen Parameter eingeschlossen werden. Das ist alles viel zu kompliziert – das Wiki beruht auf einer simplen, unmittelbar einsichtigen Syntax, und die Autoren und insbeondere die Newcomer stöhnen trotzdem, dass das alles viel viel zu kompliziert und zu schwierig wäre.
Und da obendrauf willst du noch deine Klassendefinitionssysteme draufsatteln, die dann projektweit zu koordinieren wären. Mit mir nur, wo unvermeidlich; genauso, wie wir Lua nur dort einsetzen, wo herkömmliche Vorlagenprogrammierung es nicht mehr sinnvoll liefern kann.
Nur rund ein Prozent der Zitationen ist per Vorlage formatiert; der ganze Rest handgeklöppelt in Elemantarsyntax. Das ist ein Zustand, den ich auch bedenklich finde, aber ich kann die Autoren nicht umfrittieren. Auf der aktuellen Kurierdisk kannst du nachlesen, dass es eine lautstarke kleine Minderheit gibt, die hier Vorlagen strikt ablehnt und alles in Basis-Typografie formatiert haben will; du könntest dir ja mal überlegen, was Normalautoren von deinen Theorien begreifen. Projektweit gäbe es grad mal eine Handvoll Leute, die deine Ideen nachvollziehen können, und die haben schon genug anderes zu tun und zu pflegen.
Zitat: Dass es hier "zigtausende unterschiedliche Formatierungen" gibt, ist mMn kein schützenswerter Zustand – du bist hier aber nicht in einer Firma, in der du als Arbeitgeber deinen ausgebildeten Mitarbeitern Anweisungen geben kannst, nach welchen Klassenbibliotheken sie was formatieren müssen, sondern in einem wilden Haufen, in dem seit anderthalb Jahrzehnten jeder Laie mit möglichst null Vorkenntnissen und Voraussetzungen drauflosschreiben kann, wie er mag. Was Zigtausende getan haben, und was erfolgreich zum Aufbau und zur Pflege von über zwei Millionen Artikeln geführt. Ansonsten gibt es hier keinen Style Guide, keine Vorschriften und Vorgaben für nichts, und nur ein Hauch an Konventionen für die Gestaltungen und Formatierungen ist halbwegs anerkannt. Man kann sich noh nicht einmal darauf einigen, wie die Überschriften am Ende des Artikels heißen sollen und in welcher Reihenfolge sie zum Vorteil der Leser anzuordnen wären, und auch die WP:ZR werden teilweise nur widerstrebend beachtet, und es gibt immer noch ein Dutzend Einzelkämpfer, die sie ablehnen und es in „ihren“ Artikeln aber partout anders haben wollen. Gleiches gilt für die Entwicklung der Vorlagen, die sich etwa als Infoboxen zu Tausenden nach individuellen Vorstellungen und Vorkenntnnissen (bzw. mit Null Vorkenntnnissen) vieler Hunderter Beteiligter aus dem Nichts entwickelt hatten. Und dann kommt ein Dutzend Jahre später ein Hochschullehrer angedappelt und doziert was von sauberen CSS-Bibliotheken, an die sich alle von vornherein hätten halten müssen – du hast ersichtlich weder irgendwelche Ahnung von den Vorlagen (wie sich auch an deinem Editcount ablesen lässt) noch davon, wie das Projekt und die Leute hier ticken.
Übrigens ist ein Klassensystem eine nette Sache für ein kleines, überschaubares Webprojekt, mit bis zu einem Dutzend gelernter Informatiker und Web-Designer, die es ausschließlich betreuen.
Ich war live dabei, als die Style Sheets in HTML.2 eingeführt wurden, hatte das als Erleichterung begrüßt, und sehe das als sehr sinnvollen Unterbau an.
Für ein Wiki aber eher nur dort, wo es um weltweit gepflegte technologische Basics geht.
Ach ja, duu bist uns immer noch die Tasknummer deines Vorschlags bei MediaWiki schuldig geblieben.
Das Übrige ist bereits beantwortet; lies es nach.
Es steht dir frei, uns eine Neuprogrammierung von Vorlage:Coordinate vorzustellen und <spanstyle="white-space: nowrap;"> usw. durch <spanclass="template-Coordinate-link-wmflabs-tools-geohack"> zu ersetzen, wenn du meinst, dass das die Welt verbessert.
Wobei da heute schon lauter class= drinstehen.
Du erwartest aber hoffentlich nicht, dass unsere Admins diese Klassendefintion jetzt umseitig aufnehmen, die nächste Ewigkeit pflegen und in sämtliche >15 Millionen Seiten einspeisen, obwohl die Vorlage in „nur“ etwas über einer halben Million vorkommt.
Einschub @PerfektesChaos: Die Funktionsweise eines Browser-Caches ist Dir aber schon geläufig, oder? Es ist völlig egal ob diese Datei hier 10 oder 15 Millionen-Mal eingebunden ist, so lange sie pro Nutzer nur einmal geladen wird und dann im Cache liegt. Es ist aber nicht egal, wenn das, was hier ein einziges mal stehen könnten, immer wieder inline in 10 Millionen unterschiedlichen HTML-Dateien ausgeliefert wird! // Martin K. (Diskussion) 13:03, 28. Jul. 2017 (CEST)
Allerdings haben wir mit dieser Vorlage völlig andere Probleme und werden in den nächsten Jahren noch Riesenärger damit bekommen, wogegen deine Linkdekorationssorgen absolut lächerlich sind.
Im Übrigen wiederhole ich es gern: Keine deutschsprachigen Sonderwege für weltweite Basis-Technologie, die du uns hier mal kurz mit großem Getöse vor den Latz knallst, und dann jetzt schon ankündigst, dich vom Acker zu machen und uns deine Ruinen hier zur Wartung und Pflege zu hinterlassen, und dann sollen wir noch an deiner Stelle bei MediaWiki das für dich „im Bottom-Up-Verfahren einführen“. Das kannst du hübsch alleine machen. Unsere Autoren werden von deiner Glanzleistung herzlich wenig mitbekommen (es scheint auch noch nie auf FZW oder sonstwo jemandem aufgefallen zu sein, aus TWS ist nichts bekannt); wer keinen hochauflösenden Bildschirm hat und darauf im Vollbildmodus Wikiseiten anguckt (ich habe zwar erstere, mache aber nicht zweites) bemerkt keinerlei Unterschied. Wenn das so dringend benötigt würde, wie du es darstellst, dann würde MediaWiki ja sofort darauf anspringen und es mit Kusshand blitzefix entgegennehmen.
@PerfektesChaos: Geht es Dir um eine sachliche Lösung, oder darum meinen Vorschlag mit unlauteren rethorischen Mitteln zu diskreditieren um ihn genauso plump auflaufen zu lassen wie den oben drüber?
Ich habe es oben wirklich schon x-mal geschrieben: Es geht mir ausdrücklich NICHT darum, jeden Sch***ß in die common.css zu schreiben! Es geht um ein klar abgegrenztes Set von Standard-Styles, die so oft eingesetzt werden können, dass eine globale Definition Sinn macht. Es geht also um das, was in üblicherweise in einem CSS-Framework definiert wird! Und es geht mir definitiv NICHT um diese albernen Fußball-Tricot-zusammenstückel-Codes.
P.S.: Dass Du hier wiederholt einzelne Inline-Style-Zuweisungen mit einzelnen Klassenzuweisungen vergleichst, belegt nur, dass dass Du entweder die Grundidee von Cascading Stylesheets nicht verstanden hast, oder Dich absichtlich dumm stellst, weil Du überhaupt keine Interesse an eine zielorientierten Lösung hast. Ich bin mittlerweile echt genervt von Deiner destruktiven Diskussionsweise, die im Endeffekt nichts anderes ist als die kindische Verteidigung Deiner Hauptautorenschaft an der umseitigen CSS-Datei.
Ich verbringe einen nicht unerheblichen Teil meines Arbeitslebens damit CSS zu programmieren und CSS-Zuweisungen, die so trivial sind, wir die von denen Du da oben ausgehst, kommen nur sehr, sehr selten vor:
Wie würdest Du denn mit Deinen tollen Inline-Styles das Problem lösen, dass dieses Bild hier bei geringeren Auflösungen über den Seitenrand ragt ohne dass es auf allen Auflösungen dieselbe kleine Größe hat, die auf der kleinsten Auflösung gerade noch so ins Fenster passt. Ich bin gespannt auf Deine Lösung! // 11:23, 28. Jul. 2017 (CEST)
Eine Lösung für die Tabellen-Ausrichtungsprobleme
Da es hier scheinbar ein paar Missverständisse im Bezug auf Styledeklarationen, CSS-Frameworks und sinnvolles Kaskadieren gibt, hier mal ein Beispiel, wie man die von PerfektesChaos beschrieben Tabellen-Ausrichtungsprobleme lösen könnte, ohne für jede Tabelle einen Spezialfall anzulegen oder den Code in für Laien nur schwer wartbarem Inline-Styles zu spicken.
In einem CSS-Framework würde man das so lösen, in dem man ein einziges Mal global die folgende Klassensammlung anlegt:
table.cell-centertd{text-align:center;}table.cell-righttd{text-align:right;}table.cell-lefttd{text-align:left;}table.col-1-centertd:nth-of-type(1){text-align:center;}table.col-1-righttd:nth-of-type(1){text-align:right;}table.col-1-lefttd:nth-of-type(1){text-align:left;}table.col-2-centertd:nth-of-type(2){text-align:center;}table.col-2-righttd:nth-of-type(2){text-align:right;}table.col-2-lefttd:nth-of-type(2){text-align:left;}/* usw. bis zur maximal angenommen Anzahl von Tabellen-Spalten */
Und das würde es einem erlauben in allen einfachen Tabellen einen Wikitext/Inline-Style-Mischmasch wie diesen hier, in dem in z.T. hunderten Zeilen identische Style-Anweisungen stehen,...
{| class="wikitable"
|-
| style="text-align:right"| Some Content
| style="text-align:left"| Some Content
| style="text-align:right"| Some Content
| style="text-align:center"| Some Content
| style="text-align:right"| Some Content
| style="text-align:right"| Some Content
|-
| style="text-align:right"| Some Content
| style="text-align:left"| Some Content
| style="text-align:right"| Some Content
| style="text-align:center"| Some Content
| style="text-align:right"| Some Content
| style="text-align:right"| Some Content
|-
| style="text-align:right"| Some Content
| style="text-align:left"| Some Content
| style="text-align:right"| Some Content
| style="text-align:center"| Some Content
| style="text-align:right"| Some Content
| style="text-align:right"| Some Content
|-
| usw...
|}
...durch diesen deutlich kürzeren, besser lesbaren und vor allem einfach abänderbaren Code zu ersetzen:
{| class="wikitable cell-right col-2-left col-4-center"
|-
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
|-
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
|-
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
| Some Content
|-
| usw...
|}
Und der einzige Preis, den man dafür zahlen müsste, wäre es, diese absurde „Globale Styles sind grundsätzlich böse“-Haltung aufzugeben. // Martin K. (Diskussion) 12:28, 28. Jul. 2017 (CEST)
Aber das macht doch den Quelltext voll schlecht lesbar, weil dann kann man ja gar nicht mehr sich an den style-Attributen orientieren tun </sarcas> --nenntmichruhigip (Diskussion) 22:00, 28. Jul. 2017 (CEST)
Also hier mal ein konkreter Vorschlag für ein CSS-Framework zur horizontalen und vertikalen Spaltenausrichtung in Tabellen mit bis zu 16 Spalten (das sollte ja eigentlich für unsere Zwecke ausreichen):
Na ja, mir fallen einige Tabellen ein, die mehr als 16 Spalten haben... so richtig praktikabel erscheint mir das nicht. Ich halte das Ausrichtungsproblem in Tabellen aber auch nicht für so gravierend. Da gibts eher andere:
keine ordentliche Lösung für Spaltensatz samt der aus dieser Not heraus entstandenen Krückenlösungen. Spalten werden ineinandergeschoben, horizontales Scrollen, vertikale Verschiebung von zusammengehörigen Inhalten in unterschiedlichen Spalten.
Zwanghaft in den Vereinsfarben (um beim Beispiel zu bleiben) gestaltete Kadertabellen, deren Rot-Blaue Kopfzeilen zwar thematisch passen, aber hinsichtlich Kontrast und Lesbarkeit schlimmste Magenkrämpfe verursachen
Massenhafte Tabellen- und Containerverschachtelungen, durch die niemand mehr wirklich durchsieht und einem in der Mobilversion mit Sicherheit um die Ohren fliegen. Besonders häufig zu entdecken auf irgendwelchen Portalseiten, Projektseiten-Intros oder Ähnlichem. Dazu haufenweise teils widersprüchliches oder sich gegenseitig aufhebendes Inline-CSS, das irgendjemand dort mal hineinkopiert hat, ohne wirklich zu wissen, was das eigentlich bezweckt. Der Klassiker hier: Spaltensatz-Muttertabelle mit nur einem Kind drin.
Bildausrichtung, häufig zu beobachten bei kleinen Ortsstubs: rechts eine Infobox, die länger als der Fließtext ist, links eine Reihe unterschiedlich breiter und zwanghaft hingepresster Ansichten der ältesten Pappel hinter der Kirche, daneben noch ne Nachbargemeinden-Windrose und eine dreispaltige Einwohnerzahltabelle, für den eigentlichen Text ist kaum noch Platz. Am liebsten wären mir drei Inhaltsspalten, die breiteste mittlere für den Text und die beiden äußeren für Infoboxen und Bilder samt automatischer Skalierung.
MediaWiki:Mobile.css enthält einige Definitionen von hier gar nicht, sodass z.B. Prettytable-Tabellen als komplett unformatiertes Etwas daherkommen, genauso werden Navigationsleisten blank ans Artikelende getackert.
Ich sehe schon die für Wikipedia spezifischen Vorteile von Inline-CSS und der damit einhergehenden großen Gestaltungsbreite, aber vielerorts hat diese uns auch genau solche Problemstellen geschaffen, die wir jetzt nie mehr ausmerzen können. TemplateStyles halte ich schon mal für einen guten Ansatz. Aber eine angemessen aussehende Artikelgestaltung nach Anzeigebreite werden wir im Artikel wohl nicht hinbekommen, da hab ich kaum Hoffnung. -- hgzh13:57, 29. Jul. 2017 (CEST)
@Hgzh: Ich fände es gut, wenn wir hier bei einem Thema bleiben könnten, statt diesen Vorschlag mit dem Hinweis auf andere Themen zu verwässern. Du kannst gerne zu den Themen Verschachtelung, Spaltensatz, Bildausrichtung (s.o.) usw. neue Absätze anlegen in denen entsprechende Lösungen diskutiert werden können. Defätismus allein wird uns im Angesicht des hier übiquitären HTML/CSS-Murks nämlich nicht weiterbringen: Noch ist Polen nicht verloren!
Im hiesigen Abschnitt sollte es aber um die Ausrichtung von Tabellenspalten gehen und dieses Problem bestitzt offensichtlich eine hohe Relevanz, da extrem viele Artikel Tabellen einsetzen und in den meisten davon irgendwann die Frage auftaucht, wie man ein Spalte rechtsbündig oder eine andere zentriert bekommt. Und es würde den Autoren sicher helfen, wenn sie das lösen könnten ohne in hunderte Zellen Inlinestyles zu tippen.
Und was die Anzahl der Spalten angeht: Die ist (im Gegensatz zur Anzahl der Zeilen) allein schon Layout-bedingt endlich. Und wenn man irgendwann feststellt, dass 16 nicht ausreichen, dann legt man eben im CSS noch 10 mehr an - das ist nur wirklich kein großes Problem. // Martin K. (Diskussion) 19:21, 29. Jul. 2017 (CEST)
Ich halte überhaupt nichts davon, dies hier umseitig vorzuhalten, in 15 Millionen Inhaltsseiten plus Versionsgeschichten etc. plus Spezialseitenabrufe bereitzustellen; und das obendrein mit administrativer Wartung und Pflege.
Am Ende ist es dann in 3 oder 33 Artikel mal eingebunden.
Wenn überhaupt, dann sowas nur noch auf besondere Anforderung per Vorlage plus Vorlagen-CSS und in Selbstverwaltung durch den Ersteller.
Eigentlich gehört auch das nach MediaWiki, weil unverselle Basisfunktionalität und hat nichts mit deutschsprachiger Besonderheit zu tun. In enwiki kommt dann auch wer auf diese Idee, denkt sich ein anderes Namensschema aus und wir können dann wieder hinterherpflegen.
Alle ein bis zwei Wochen eliminiere ich ähnliche Spezialkonstruktionen aus dem Bestand, die irgendwer vor fünf oder zehn Jahren mal mit großem Tamtam in die Welt gesetzt hatte, sehr von sich und seinen tollen Ideen überzeugt war, die dann in einer Handvoll Seiten verwendet wurde, für die sich aber keine Sau interessiert hatte und die in der Flut von möglichen Konstrukten überhaupt nicht wahrgenommen wurden. Es ist ein Riesen-Aufwand, sowas auf ewig zu pflegen und zu propagieren und aktuell zu halten, und das am Ende für zwei Autoren und fünf Artikel.
VisualEditor kümmert sich übrigens nicht drum und löst es anders: Spalte markieren, zentrieren, fertig. Mit Inline-Style, robust, narrensicher.
@PerfektesChaos: Sorry, aber die Art und Weise, wie Du hier argumentierst, kann ich mittlerweile echt nicht mehr ernst nehmen. Lösungsorientiert ist jedenfalls anders.
Hast nicht Du selbst oben noch behauptet, dass die Ausrichtung in Tabellen einer der häufigsten Anwendugnsfälle für Inlinestyles sei? Widersprichst Du Dir nicht selbst, wenn Du jetzt versuchst genau diesen Anwendungsfall runterzuspielen?
Den String | style="text-alignfindet unsere Suche in 69.031 Artikeln und insgesamt 102.934 Wikiseiten. | align= findet man auf 422.870 Wikiseiten, 197.809 davon Artikel. Die überwiegende Mehrheit davon dürften Fälle sein, in denen die hier vorgeschlagenen Klassen zur Anwendung kommen könnten. Es ist also absolut lächerlich hier von "3 oder 33 Artikel" zusprechen.
Außerdem solltest Du mal aus der Vorlagen/Inline-Style-Denke Rauskommen. Globale-CSS-Definitionen müssen nicht von den Autoren dediziert "eingebunden" werden. Sie sind einfach da und entfalten ihre Wirkung sofort, wenn irgendwo eine der genannten CSS-Klassen angegeben wird. Und gerade die hier vorgeschlagene Struktur macht die Anwendung auch für Otto-Normal-Autoren denkbar einfach. Viel einfacher jedenfalls als dutzende Zellen pro Tabelle mit kryptischen Inline-Style-Attributen zu versehen.
Und bitte hör mal mit dieser alberen 15 Mio-Seiten-Leier auf! Da das hiesige StyleSheet nach dem ersten Seitenaufruf eh im Browser-Cache landet, belastet es die Wikipedia nicht mehr als irgendein Code auf irgendeiner anderen Seite, die der Nutzer ansurft. Im Gegenteil: Eine Klassensammlung, wie die hiesige ermöglicht es, auf tausenden von WIkiseiten auf redundante Inline-Styles zu verzichten und entlasstet so aktiv Server und Bandbreite. // Martin K. (Diskussion) 00:23, 30. Jul. 2017 (CEST)
P.S.: Sobald so eine Klassensammlung erstmal verfügbar und etabliert ist, sollte sie natürlich auch vom VisualEditor unterstützt werden - genauso wie das auch heute schon bei anderen Klassen der Fall ist.
Es wäre sicherlich sinnvoll und elegant, wenn nicht nur Inline-CSS, sondern auch kaskadierendes CSS mit Selektoren im Wikitext verwendet werden könnte. Die MediaWiki:Common.css ist dafür aber nicht so geeignet, wie PerfektesChaos zurecht dargelegt hat.
Theoretisch wäre ein <style scoped> im Body eine elegante Lösung. phab:T52644 ist aber konsequenter Weise abgelehnt worden, weil die Browser dies nicht oder nicht mehr unterstützten. Vom Ladevorgang her wäre das auch ungünstig.
Vielleicht schafft es die neue Extension CSS sicher aus dem Wikitext heraus zu erzeugen. Es gab dazu schon einige Versuche, die an der Security gescheitert sind. Ich habe mir die neue Extension aber noch nicht näher angeschaut.
Ich würde mir wünschen, wenn aus dem Wikitext heraus vollständiges CSS inklusive LESS-Präprozesser nutzbar wäre:
Bei Bedarf sollte die CSS-Definition in eine Vorlage ausgelagert werden können, wo auch Parameter, wie eine Themenfarbe übergeben werden können. Vielleicht bietet die neue Extension genau so etwas auch an. --Fomafix (Diskussion) 15:08, 29. Jul. 2017 (CEST)
Letzter Kommentar: vor 2 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Die derzeitige Implementierung von jQuery.makeCollapsible.js hat den unschönen Nebeneffekt, dass beim Seitenladen als ".mw-collapsed" markierter Content erst geöffnet dargestellt und dann skriptgesteuert geschlossen wird. Das führt unter anderem dazu, dass unterhalb liegende Abschnittslinks nicht genau angesprungen werden. Ich habe hier einen (rudimentären) Vorschlag gemacht, wie das zu umgehen sein könnte. Vielleicht nicht die beste Lösung, aber als vorläufiger Workaround möglicherweise geeignet. --Prüm19:20, 3. Dez. 2017 (CET)
Letzter Kommentar: vor 2 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo zusammen, kann mir jemand sagen, wo die Definitionen aus [6] vorgenommen werden? Weiß vielleicht auch jemand, warum in der Mobilversion die Zellen der letzten Zeile einer Infobox keinen eigenen Rand besitzen sollen? Vielen Dank --Wiegels„…“01:08, 19. Jan. 2018 (CET)
Bedauerlicherweise hat man sich vor einer Weile dazu entschlossen, das komplett umzustrukturieren, und hat sämtliche Pfade umgeschmissen.
Bevor die damit nicht irgendwann mal fertig geworden sind, ist es sinnlos, dem hinterherzuhecheln; das muss erstmal für einige Monate eine robuste Gestalt bekommen haben.
Der Inhalt ist irgendwie komponiert aus den unter 1.) angegebenen Ressourcen.
Grundsätzlich ist der Mobil-Stil völlig eigenständig und kennt vieles nicht, was in den Desktop-Skins von MediaWiki definiert wird, und von uns hier schon gleich gar nicht.
Anfragen dieser Art, die nicht auf Änderung unserer Common.css abzielen, sind besser auf WP:TWS aufgehoben.
Auf Smartphones sind Infoboxen nicht wie auf Desktop rechts neben dem Einleitungsabschnitt darstellbar. (Tablet müsste aber gehen)
Deshalb jonglieren die irgendwie: Der Text-Absatz-Bereich und die erste Tabelle (oder Bild?) im ersten Abschnitt einer Seite werden drunter und drüber geschoben, per important-Eingriffe.
Mir ist so, als ob erstmal der Einleitungstext kommen soll, dann ausklappbar die Infobox womöglich in voller Bildschirmbreite, und dann die erste Abschnittsüberschrift zum Ausklappen des jeweiligen einen Abschnitts. Zumindest war das wohl mal der Plan, als ich mich zuletzt damit beschäftigt hatte, aber da ist viel rumgebaut worden.
Die Unterkante der Infobox stößt dann wohl an die Überschriftsklapperei oder so.
Das mit dem !important; ist echt ein unglaublicher Murks und nur deshalb notwendig, weil wir hier praktisch alles mit InlineStyles lösen (müssen). Ich würde daher vorschlagen, dass wir uns dafür einsetzen die TemplateStyles-Erweiterung endlich auf de.Wiki zu deployen und dann die Infoboxen so umbauen, dass Sie von selbst bei zu geringer Bildschirmbreiten von float:right; auf float:none; umschalten.
Es wäre technisch natürlich auch jetzt schon möglich, hier in der common.css eine Klasse zu definieren, die genau dieses Verhalten für alle Infoboxen implementiert. Aber da ich mit meinen letzten beiden Vorschlägen für solche generellen Klassen hier gegen eine Wand gelaufen bin, mach ich mir da keine Illusionen...// Martin K. (Diskussion) 18:21, 19. Jan. 2018 (CET)
Klassen-Spezifikationen hier auf MediaWiki:Common.css, wie von dir vorgeschlagen, sind für Mobilgeräte herzlichst wirkungslos.
Auf einem Smartphone sieht der Einleitungstext links neben der Infobox nach deinem Vorschlag ziemlich lustig aus.
Der Mechanismus hat weniger mit „Infobox“ zu tun, sondern mit den ersten Tabellen vor der ersten content-Überschrift.
An komplexen Angelegenheiten dieser Art machen wir grundsätzlich nicht lokal herum und kämpfen uns nicht gegen die sich im Mobilbereich von einer Woche auf die andere ändernde Elementstruktur der Seite an.
Die sachgerechte Unterstützung der Mobilgeräte, so dass sie dann auch für alle Geräte aller Leser funktioniert, beschäftigt bei MediaWiki eine ganze Fachgruppe in Vollzeit.
Bitte trage deine konkret ausgearbeiteten Vorstellungen für Realisierungen der Seitenstruktur mittels zukünftiger Browser-Versionen auf MediaWiki vor und nicht hier.
Nebenbei bemerkt bin ich grundsätzlich nicht zu erwärmen für ideologische Theoriegebäude, die mangels Kompatibilität und Robustheit und durch Performance-Desaster für die praktische Anwendung katastrophal sind und die Nachteile ihrer Umsetzung konsequent aus dem Weltbild ausblenden.
Im Übrigen ist das hier eine Seite, auf der erörtert wird, welche konkreten Veränderungen der Konfiguration speziell für die deutschsprachige Wikipedia sinnvoll wären; nicht aber zur Philosophiererei, wie MediaWiki sich die Welt gestalten könnte, wenn die Leser andere Browser hätten als sie nunmal haben. Obendrein geht es hier immer noch um Desktop, auch wenn das in Unkenntnis unpassend begonnen wurde.
Letzter Kommentar: vor 2 Jahren16 Kommentare4 Personen sind an der Diskussion beteiligt
Seit dem jüngsten Softwareupdate ist diese Warnung per default orange unterlegt und wird ausreichend hervorgehoben. Der umseitig eingefügte zusätzliche rote Rahmen stört da eigentlich nur noch. Die Regel dafür könnte also raus. Gruß, -- hgzh22:38, 10. Okt. 2019 (CEST)
Hm, naja. Ich denke wenn der Kasten immer orange ist, dann läuft man Gefahr bei vollgeschützten Seiten zu übersehen, das man hier nicht bearbeiten sollte/darf. Wenn an jeder Ecke ein gleiches Warnschild steht, dann wird es irgendwann nicht mehr wahrgenommen. Wenn der rote Rahmen stilistisch nicht passt, dann lässt sich das bestimmt anpassen, aber ich würde es weiterhin für sinnvoll halten bei Vollschutz extra zu warnen. Ggf. kann man den Kasten dann rot gestalten, sowie die Kästen in der enwp allgemein? Also so z.B.? Viele Grüße, Luke08151515:22, 11. Okt. 2019 (CEST)
Von mir aus auch rot, allerdings ist dieser doppelte unförmige Rahmen m.E. ziemlich hässlich und sollte ersetzt werden. Meiner Meinung nach machen wir sowieso viel zu häufig um zuviele Dinge noch irgendwelche dicken Rahmen, Bildchen und Hintergrundfarben. Die en-Kollegen machen den Rahmen übrigens wieder mithilfe der common.css rot, was wir ja eigentlich nicht mehr wollen. Gruß, -- hgzh18:07, 12. Okt. 2019 (CEST)
Ich habe nichts dagegen wenn der Rahmen verschwindet, ich würde mir aber wünschen, das sich die Meldung für vollgeschützte Seiten irgendwie von den anderne beiden abhebt, damit ich nachher nich noch unabsichtlich irgendwo schreibe wo ich nicht darf ;) Viele Grüße, Luke08151520:20, 12. Okt. 2019 (CEST)
Generell: Gern umseitig so viel als möglich eliminieren.
Je schlanker Common.css ist, je weniger es auf Einzelfälle in den mehreren zig Millionen Konstellationen aufrufbarer Seiten eingeht, desto effizienter ist es für die Anwenderschaft, und um so übersichtlicher wird der allgemeine Brei.
Die CSS-Regel zu .mw-titleprotectedwarning kann vermutlich komplett entfallen.
Möglicherweise fände man einen weißen Hintergrund unter dem Text sympathischer; dieser kann durch ein <div> um die MediaWiki:Titleprotectedwarning erreicht werden, und mit Abständen zur neuen .warningbox ausgestattet (margin+padding).
Was den Wunsch von Luke angeht: Mit {{PROTECTIONLEVEL:create}} ließe sich Text und/oder Farbgebung entsprechend der Schutzstufe halb, dreiviertel und voll innerhalb von MediaWiki:Titleprotectedwarning anpassen.
Mir ist grad die auslösende Situation nicht klar bzw. nicht reproduzierbar; ich bekomme die konkrete Meldung nicht, zumindest nicht hier als Normaldussel. Sähen das nur Admins?
includes/EditPage.php
Was mir dabei grad auffällt:
div#specialchars braucht kein CSS mehr; menuSwitcher macht das selbst und MediaWiki:Onlyifediting.js ist nicht aktiv.
Ich bin blöd, ich sehe natürlich als Admin hier was anderes als du... das war mir entfallen. Dass der VE auf Beta aber trotzdem Titleprotectedwarning ausgibt (unangemeldet getestet), ist andererseits auch wieder verwirrend. -- hgzh16:42, 16. Okt. 2019 (CEST)
BK
Ja, auf Admin-Normalo bin ich auch inzwischen gekommen.
Auf BETA habe ich bewusst nur create gesetzt.
Also nochmal entheddert:
Benutzer, die nicht zu der (Erstellungs?)-Aktion berechtigt wären, sehen MediaWiki:Titleprotected. (BETA-Fall????)
Benutzer, die zu der Aktion berechtigt sind, sehen MediaWiki:Titleprotectedwarning und drumrum eine .warningbox und diese mit der .mw-titleprotectedwarning.
Oder wie auch immer; includes/EditPage.php nach Zeile 4000 auseinanderpfriemeln.
Die .mw-titleprotectedwarning sollte umseitig eliminiert werden, da sie nur in 0,00000000000000001 % der Seitenaufrufe zum Tragen kommt. Für den Rest Ressourcenvergeudung. Holzweg damaliger Dogmatiker von 2009, die predigten, dass inline-style immer böse böse böse wäre und alles in class zu stecken wäre weil damit wäre das viel viel professioneller.
So deute ich includes/EditPage.php wo das anscheinend auch schon vor einem Jahrzehnt in diese Richtung ging.
Nun haben die VE-Programmier Titleprotectedwarning in die Finger bekommen wo sie Titleprotected hätten nehmen sollen.
Obendrein ist der VE nicht sehr intelligent: Er startet den vollen Edit-Modus, weist jedoch mit einer riesigen Blase von zwei Desktop-Bildschirmhöhen darauf hin, dass dies hinterher nicht abgespeichert werden dürfe. Wobei der Hinweis außerhalb des Desktop steht, und wahrscheinlich auf dem fünften Smartphone. Wenn er schon weiß, dass Speichern nicht möglich ist, sollte blockiert werden, kein Edit-Modus, kein Speichern, nur Warnung, und das Wichtigste zuerst und auffallend.
Es sollte ein HTML-Kommentar bei dieser und bei der MediaWiki:Titleprotected drunter, dass diese Nachricht nur den Admins bzw. den Unberechtigten angezeigt werden würden sollen täte; auch angesichts des VE-Gewirr.
Da steht noch {{#switch:{{PROTECTIONLEVEL:edit}} mit edit drin; stimmt die Logik denn in dieser Form wegen create oder ist das immer gleich? Oder bessere Robustheit wenn create weil sonst fallen wir in zwei Jahren aus allen Wolken und niemand findet den Fehler?
Letzter Kommentar: vor 2 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo zusammen, es wurde schonmal in der Vorlagenwerkstatt angesprochen, aber vielleicht ist hier die geeignetere Anlaufstelle für ein unschönes Aussehen, das mir immer wieder mal auffällt. Es geht darum, dass bei Notensätzen die unteren Enden von Notenschlüsseln, einigen Noten/Akkorden oder Musiktexten durch darunter platzierte Abspieler verdeckt werden, wie bei Hilfe:Notensatz oder Hilfe Diskussion:Notensatz zu sehen ist. Eine maßvolle Vergrößerung des Außenabstands würde da helfen, beispielsweise durch .mediaContainer { margin: 1em 0; }. Bin ich mir meinem Anliegen hier richtig? --Wiegels„…“23:39, 15. Mär. 2020 (CET)
@Wiegels: Ich denke auch, dass das hier machbar wäre und wollte gerade denselben Vorschlag machen (wobei mir ein oberer Abstand mit margin-top reichen würde). Noch besser wäre allerdings eine internationale Lösung, denn von dem Problem sind sämtliche Wiki-Projekte betroffen. --Rodomonte (Diskussion) 22:43, 2. Mai 2020 (CEST)
So ganz richtig seid ihr heutzutage nicht mehr; weil Wikipedia:Technik/Skin/MediaWiki/Änderungen mittlerweile der eine zentrale Anlaufpunkt für alle derartigen Anliegen ist.
Euer Begehr habe ich noch nicht restlos verstanden, ahne es jedoch.
Was mir hingegen missfällt, ist dass der umseitige Code bei -zig Millionen Wiki-URL eingebunden und den Browser zum Durchsuchen der Seite zwingt, aber irgendwie nur in ein paar Dutzend Seiten wirken soll. Das ist eine ziemlich miserable Trefferquote. Umseitig soll tendenziell abgespeckt und gegen Null gebracht werden.
Im Zusammenhang mit Vorlagen verwenden wir TemplateStyles, wodurch exakt die Seiten den CSS-Code bekommen, die ihn brauchen, und der Rest nicht.
Hier ist es ein Element, und da können wir nicht selektiv wirken.
Wer hingegen selektiv ist, das ist die globale Programmierung, die das CSS immer nur in den Seiten ausliefert, wo es auch wirksam wird.
Insofern wäre MediaWiki/Phabricator die besseree Adresse.
hinter das Link gemalt wird; reine Dekoration, kann mit dem Problem nichts zu tun haben.
(CallMyCenter) 02:43, 6. Sep. 2013 (CEST)
.png)
Andernfalls könnte ich mir auch vorstellen, dass eine begrenzte Auswahl von unterschiedlichen Farbschemata vorgegeben würde. Wie auch immer, soll nur mal eine Tuchfühlung sein! Grüße, --XanonymusX (Diskussion) 21:32, 9. Mär. 2015 (CET)
22:22, 28. Okt. 2016 (CEST)
19:21, 18. Apr. 2016 (CEST)
.png){kind=link}
00:34, 21. Mär. 2019 (CET)