MediaWiki Diskussion:Monobook.css

aus Wikipedia, der freien Enzyklopädie

[Bearbeiten] Großschreibpatch

Hallo Fristu, Dein Großschreibpatch funktioniert nicht richtig, jetzt schauts noch schlimmer aus als vorher. Davon abgesehen bin ich gar nicht damit einverstanden, derartige Änderungen allen Benutzern einfach vorzuschreiben. Wer mit dem Skin nicht einverstanden ist, kann ihn gerne über sein User-CSS ändern, aber ständig an den Globaleinstellungen runzuschrauben führt dazu, dass alle ständig an ihrem User-CSS rumbauen müssen, um wieder die Form zu bekommen, die sie bis vor kurzem hatten oder die sie haben wollen und dsa führt zu ziemlichem Unmut! Deshalb war ich so frei und hab den Großschreibpatch wieder rausgenommen. -- Sansculotte ✏ 01:58, 4. Jul 2004 (CEST)

Inwiefern funktioniert er nicht richtig? Es kann natürlich sein, dass bestimmte Browser das nicht unterstützen, aber das Einführen einer zusätzlichen CSS-Klasse sehe ich nicht als gravierenden Eingriff, da ja diese Möglichkeit vorher auch bestand. Statt im Wikitext zu schreiben <font style="text-variant:small-caps>Eine Person</font> könnte man nun dasselbe mit <font class="Person">die Person</font> tun. Der Effekt sollte der gleiche sein, aber eins von beiden lässt sich einfacher merken. Ich kann deinen Argumenten bisher noch nicht folgen. --Wiki Wichtel sowie KatEgo 02:22, 4. Jul 2004 (CEST)

ich meinte nicht die Personen-Klasse, sondern das Tab-Großschreibdings. manche Tabs werden groß geschreiben, manche klein, oben anders als unten... -- Sansculotte ✏ 02:24, 4. Jul 2004 (CEST)

ah ja, sehe ich jetzt erst, der Patch ist aber schon einige Wochen alt, und vielleicht tatsächliich überflüssig, mal testen... --Wiki Wichtel sowie KatEgo 02:26, 4. Jul 2004 (CEST)

nein, nicht überflüssig.

Die Großbuchstaben stossen bei mir oben an, ausserdem erstreckt sich die Änderung nicht auf meine grade eben eingebaute zweite Edit-Bar unten, sodass ich dann oben Großbuchstaben und unten dasselbe nochmal mit Kleinbuchstaben habe.

Wenn die Großbuchstaben irdendwo anstoßen, müsste doch wohl der Abstand verändert werden und nicht am Symptom geschraubt werden. Es kamen nach Einführung von monobook Beschwerden, dass die Nomen _falsch_ kleingeschrieben seien. Wem das Design wichtiger ist als Korrektheit, sollte sich seine eigenes Design per User-css bauen. Aber allen Usern falschgeschriebene Links zu bieten widerstrebt mir. --Wiki Wichtel sowie KatEgo 02:35, 4. Jul 2004 (CEST)

Wir könnten tauschen: ich hab nun oben Kleinbuchstaben und unten Großbuchstaben... --WW

So, ich habe wieder meine Großbuchstaben, bei dir müsste es jetzt auch stimmen.--WW+K

Zur zweiten Sache: seit wann schreiben wir denn Personennamen hier in Kapitälchen? Das habe ich noch nirgendwo gesehen, und das sollten wir, um den Quellcode auch für Newbies lesbar zu halten, auch nicht einführen. Prinzipiell wäre ich dafür, globale Änderungen nur dann zu machen, wenn eine breite Mehrheit der Nutzer eine Änderung wünscht (Vorstellen könnte ich mir das zum Beispiel bei dem Benutzer-Icon, das einige, wie ich hörte, als überflüssig empfinden). --elian 02:29, 4. Jul 2004 (CEST)

Die Personennamen wurden hier bisher nicht in Kapitälchen geschrieben, aber z.B. in eo wurden seit anfang Großbuchstaben für Familiennamen verwendet. Das finde ich nicht so schön wie Kapitälchen. HTML/CSS bietet nunmal diese Möglichkeit und in Wikipedia:Ich brauche Hilfe kam die Frage, ob sowas möglich sei. Es ist ja keine Pflicht dieses zu nutzen. Außerdem wird durch "class=Person" erstens der Quellcode lesbar/merkbar (lesbarer als style=textvarian:smallcaps) und zweitens kann sich jeder dann die Klasse selber designen. Und drittens könnte es ja sein, dass irgendwann sogar ein Personen-tag eingeführt wird, das dann von einem Bot konvertiert werden könnte-

aber bitte als <span class="person">, nicht als *schauder* *grusel* *brr* *weglauf* <font>! TheK 03:40, 4. Jul 2004 (CEST)

wie gesagt, ich hab ja nix gegen den Patch, das ist im Prinzip eine feine Sache, was mich schon seit Einführung von Monobook sehr stört ist, dass ständig was am Aussehen geändert wird (und zwar am Standard-Monobook-CSS) und ich dann mein user-css anpassen darf, damits wieder so aussieht wie vorher. Und da bin ich bestimmt nicht der einzige, den sowas tierisch ärgert. abgesehen davon, daß ich noch nicht mal den Funken einer Idee habe, wie ich diesen Patch wieder rückgängig machen könnte ;) -- Sansculotte ✏ 02:30, 4. Jul 2004 (CEST)

Das ließe sich dann mit "text-transform:lowercase" wieder designen. --Wiki Wichtel sowie KatEgo 02:37, 4. Jul 2004 (CEST)

fassen wir mal zusammen: In der Datenbank steht es groß. Im allgemeinen CSS wird's kleingemacht. In dem Ding hier wieder groß. Und dann soll es der Benutzer wieder klein machen.. Eh, wieso lassen wir es nicht einfach so, wie es aus der Datenbank kommt? TheK 02:43, 4. Jul 2004 (CEST)

Weil uns kleinen Admins nur dieses Ding zur Verfügung steht, man könnte einen Entwickler bitten das aus dem allgemeinen monobook zu entfernen. Die wollen aber mit solchen Wünschen möglichst nicht belastet werden. (Deswegen haben sie ja dieses Ding eingeführt). Wie gesagt: Mir geht die Korrektheit vor, und daher setze ich den Patch gleich wieder rein. --Wiki Wichtel sowie KatEgo 02:52, 4. Jul 2004 (CEST)

Da bin ich eigentlich strikt dagegen, denn das ist nur Deine persönliche Meinung. Mit einer ähnlichen Begründung könnte ich z.B. #catlinks {display:none;} reinsetzen... Wenn Du es denn doch machst, wärst Du dann bitte so nett und könntest mir eine Zeile für mein CSS geben, die ich nur zu pasten brauche? Weil "text-transform:lowercase" alleine tuts ja auch nicht. -- Sansculotte ✏ 02:56, 4. Jul 2004 (CEST)

.portlet h5,.portlet h6,#p-personal ul,#p-cactions li a{text-transform:lowercase;}

Da war TheK schneller :( Und ist übrigens nicht nur meine persönliche Meinung, sondern es kamen mehrere 'Hilfeschreie'/Änderungswünsche deren Meinung meiner Meinung verblüffend ähnlich war, ist und sein wird...

korrekterweise (also grammatikalisch korrekt, nicht typographisch) müssten eigentlich alle Begriffe in den Tabs mit Großbuchstaben anfangen, ebenso wie die Begriffe ganz oben in der ersten Zeile... -- Sansculotte ✏ 03:04, 4. Jul 2004 (CEST)

dann machen wir doch text-transform:capitalize drauß ;) TheK 03:06, 4. Jul 2004 (CEST)

Um dann einen Button "Nicht Mehr Beobachten" zu haben? was soll daran grammatisch korrekt sein? -Wiki Wichtel sowie KatEgo 03:14, 4. Jul 2004 (CEST)

mist, geht auch nit.. Damit kann man nur #ca-edit und #ca-move zu Leibe rücken. Für den "Beobachten" hilft nur den String ändern. TheK 03:16, 4. Jul 2004 (CEST)

Ehm, Fristu - ich hätte eigentlich gerne Kleinbuchstaben oben und unten, nicht Großbuchstaben. Ausserdem nochmal: Könnt ihr bitte das globale CSS in Ruhe lassen? Da hat sich Gwicke viel dazu überlegt, und auch die Kleinbuchstaben sind nicht falsch, sondern haben ihren Sinn. --Elian Φ 03:18, 4. Jul 2004 (CEST)

bitte, nun ists klein (oder?). Zu dem nochmal: Die Änderung von Sansculotte (groß->klein) betraf eine Sache, die jetzt 1 Monat lang ohne Beschwerden funktionierte (weil eben Großschreibung korrekt) Meine Ergänzung mit der PersonenKlasse ist eine _zusätzliche_ Möglichkeit, die noch bei garkeinem User irgendwas geändert haben kann.

Ich bin total begeistert von Gwickes Skin, vorallem davon, dass er anpassbar ist. Nur hat er sich eben nicht nur in meinen Augen beim Designen der Groß/Kleinschreibung vertan. Das mag im Englischen seine Berechtigung haben, aber im Deutschen eben nicht. --Wiki Wichtel sowie KatEgo 03:51, 4. Jul 2004 (CEST)

Danke schön. Jetzt sind aber auch die Links in der persönlichen Leiste, die ich links in die Toolbar verschoben habe, auf einmal klein. Dort links machen die Kleinbuchstaben natürlich überhaupt keinen Sinn im Gegensatz zu in den Tabs oben (In meinen Augen hat er sich damit nämlich nicht vertan). Wie macht man die jetzt wieder groß? --Elian Φ 03:58, 4. Jul 2004 (CEST)

[Bearbeiten] font-weight:bold;

so klappt's dann auch ;) TheK 17:13, 14. Jul 2004 (CEST)

[Bearbeiten] Weiße Rahmen um Float-Objekte

Hallo! Zur Zeit gibt es hässliche weiße Rahmen um Float-Objekte (z.B. Bilder) in Seiten mit andersfarbigem Hintergrund. Siehe z.B. das Bild im exzellenten Artikel auf dem Portal:Berlin. Die folgenden Anweisungen sollte dies Abschalten. Natürlich wäre eine Korrektur im echten Mediawiki-Stylesheet besser, insbesondere weil hier border zur Darstellung eines Abstandes missbraucht wird. (Aber genau dafür gibt es margin!)

/* Vermeide hässliche weiße Ränder bei Float-Objekten auf nicht-weißen Hintergründen. */
div.floatright { border: none; margin-left: 1em; margin-top: 0.5ex; margin-bottom: 0.5ex }
div.floatleft { border: none; margin-right: 1em; margin-top: 0.5ex; margin-bottom: 0.5ex }

Es wäre nett, wenn ein Admin das einbinden könnte. – Sebari ☢ 01:45, 22. Dez 2004 (CET)

Das Problem scheint uebrigens bei neueren MediaWiki-Versionen behoben zu sein. (In monobook.css 1.4.) – Sebari ☢ 16:18, 22. Dez 2004 (CET)

Nein, ist doch nicht behoben. Dafür ist jetzt ein anderer Patch nötig:

/* Vermeide hässliche weiße Ränder bei Float-Objekten auf nicht-weißen Hintergründen. */
div.thumb { border: none }
div.tright { border: none; margin: 0.5em 0 0.8em 1.4em }
div.tleft { border: none; margin: 0.5em 1.4em 0.8em 0 }

Könnte jemand das einbauen und an die Mediawiki-Entwickler weiterreichen? Danke, – Sebari ☢ 21:35, 7. Jan 2005 (CET)

Ok, soll ich das einbauen? Hast du das vorher in Deinem eingenen Monobook.css getestet? mfg --Paddy 22:21, 7. Jan 2005 (CET)

In meinem lokalen monobook.css funktioniert das problemlos. Zur Veranschaulichung des Problems, siehe auch Benutzer:Srittau/Bugtest. – Sebari ☢ 12:02, 8. Jan 2005 (CET)

Die Sache hatte übrigens eine Motivation: Durch den weißen Rand wurde es vermieden, daß bei Bildern neben Überschriften der Strich unter der Überschrift bis an das Bild stößt. Natürlich muß der Rand dann die Farbe des Hintergrundes haben, was außerhalb von normalen Artikeln nicht immer der Fall ist. (Allerdings könnte man in solchen Spezialfällen für Bilder den Parameter "none" verwenden und zur Positionierung das Bild in ein weiteres -- wenn auch semantisch redundantes -- "div" einfassen.) --“Remember me!” 14:19, 10. Mai 2005 (CEST)

[Bearbeiten] Abrundungen von Kanten

Hallo, ich möchte gerne auf die Design-Verbesserungen der französischen Wikipedia hinweisen. Dort ist unter dem Logo "Navigation" als Reiter grau hinterlegt und die Reiter "bearbeiten", "Versionen", usw. alle samt schön abgerundet. Wär doch was, oder?

Ich finde es so wie wir es haben schöner. --::Slomox:: >< 23:04, 6. Feb 2005 (CET)

Aber das darf sich ja jeder gerne aus http://fr.wikipedia.org/wiki/MediaWiki:Monobook.css kopieren und in http://de.wikipedia.org/wiki/Benutzer:.../monobook.css einfügen. -- Schnargel 00:50, 7. Feb 2005 (CET)

Problem daran: es funktioniert nur in Gecko-Browsern (Firefox, Mozilla, Netscape, Galeon, Epiphany, ..) und nicht im IE, denn es handelt sich dabei um eine proprietäre Erweiterung von Gecko (-moz-border-radius). Daher sollte man meinem Empfinden nach darauf verzichten, um nicht unnötigerweise inkorrektes CSS zu erzeugen. Auch wenn das keine Fehlermeldungen ergibt, ist es dennoch im Sinne von Standardkompatibilität eher abzuraten, das in der globalen monobook.css zu verwenden. Schnargel sagt's ja, in ner privaten monobook.css kann's ja jeder einfügen, nur sollte nicht schon die Grundversion nicht genormte Befehle beinhalten. -- FloSch ¿? 11:27, 9. Feb 2005 (CET)

[Bearbeiten] Seite schützen

Hi, sollte diese MediaWiki-Template nicht geschützt sein? Denn mit nur wenigen Eingriffen hätten wir statt der Wikipedia eine leere Seite... --Filzstift ✑ 6. Jul 2005 07:54 (CEST)

Alle Seiten im MediaWiki-Namensraum können nur von SysOps bearbeitet werden, auch wenn sie nicht als "geschützt" angezeigt werden. Normalbenutzer (wie z.B. ich) können keine Änderungen daran machen, was unter Admins in der Tat sehr unbekannt zu sein scheint. --FloSch ¿? 6. Jul 2005 10:48 (CEST)

[Bearbeiten] Prettytable

Ähnlich wie in der englischen Wikipedia mit der Klasse wikitable sollte man auch hier die Vorlage Prettytable ersetzen. Allerdings sollte man sie nicht 1:1 übernehmen, sondern dem aktuellen Stil der Vorlage angepasst. --ChristianErtl 21:50, 17. Okt 2005 (CEST)

Ich schließe mich diesem Wunsch an. Eventuell könnten wir damit auch etwas Last von den Servern nehmen, weil weniger Vorlagen verarbeitet werden müssten. Könnte sich mal einer der Administratoren bei diesem Thema zu Wort melden? --jpp ?! 18:00, 26. Okt 2005 (CEST)

Die Vorlagen sind flexibler (sie könnten auch HTML-Attribute enthalten) und wir sollten uns diese Möglichkeit nicht verbauen. Die Belastung der Server durch das einfache Einbinden von Vorlagen hält sich in erträglichen Grenzen, so lange man es mit der Verschachstelungstiefe nicht übertreibt. --Hendrik Brummermann (kein Admin) 22:49, 26. Okt 2005 (CEST)

Wie bitte? Sie sind doch nicht flexibler, mit einer class-Angabe in der Vorlage ändert sich doch daran nichts.

Das Ersetzen der style-Definition in der Vorlage (wie von Dir vorgeschlagen) durch eine class-Definition halte ich für sinnvoll; nicht aber das Ersetzen der Vorlage durch eine class-Definition in den Artikel. --Hendrik Brummermann 19:57, 29. Okt 2005 (CEST)

Allerdings kann man dann auch Anpassungen über das style-Attribut verwenden, momentan geht das nicht. Die anderen HTML-Attribute sollten in XHTML sowieso nicht auftauchen. --ChristianErtl 02:04, 29. Okt 2005 (CEST)

Inwiefern ist denn die aktuelle Prettytable-Vorlage flexibler als eine, in der der depracted-Müll durch ein class-Attribut ersetzt ist? Wenn ich momentan zusätzliche Angaben per style-Attribut machen möchte, kann ich die Vorlage so vergessen. --ChristianErtl 02:06, 29. Okt 2005 (CEST)

http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-table-1.mod sagt 'was anderes. --Hendrik Brummermann 09:22, 29. Okt 2005 (CEST)

Ich bin mir nicht ganz sicher, was du sagen willst: Zwischen sollen und dürfen ist ein Unterschied. Ich würde mir ernsthafte Argumente wünschen, die dagegen sprechen. Die englische Wikipedia hatte damit offenbar kein Problem. --ChristianErtl 21:15, 29. Okt 2005 (CEST)

Dort sind für das table-Tag HTML-Attribute definiert. Diese Datei ist Teil des offiziellen Standards "XHTML Strict", in dem die "deprecated" - Elemente älterer (X)HTML-Versionen entfernt wurden. Aus meiner Sicht sind das „ernsthafte Argumente“, gegen Deine Behauptungen „Die anderen HTML-Attribute sollten in XHTML sowieso nicht auftauchen.“ und seien „depracted-Müll“. Laut [1] wird die Vorlage Prettytable dort mehr als 6500 mal verwendet. Dagegen gibt es laut [2] nur 98 Treffer für eine Suche nach class="prettytable" im Artikelnamensraum. Völlig unabhängig davon, was die englische Wikipedia macht, halte ich HTML-Code in Artikeln für keine gute Idee. --Hendrik Brummermann 17:37, 1. Nov 2005 (CET)

Schau dir mal die Vorlage Prettytable in der englischen Wikipedia an. Man kann auch dann noch die Vorlage verwenden. So leicht kannst du dir es also nicht machen. Außerdem führt die Nicht-Anpassbarkeit nur dazu, dass die Vorlage nicht verwendet wird. --ChristianErtl 20:08, 1. Nov 2005 (CET)

Hast Du diesen Abschnitt überlesen? „Das Ersetzen der style-Definition in der Vorlage (wie von Dir vorgeschlagen) durch eine class-Definition halte ich für sinnvoll; nicht aber das Ersetzen der Vorlage durch eine class-Definition in den Artikel. --Hendrik Brummermann 19:57, 29. Okt 2005 (CEST)“ --Hendrik Brummermann 21:39, 1. Nov 2005 (CET)

Überlesen. Weshalb? Crissov und andere stimmen mir hier zu (er hat ja an der Variante in der engl. Wikipedia mitgewirkt). --ChristianErtl 22:36, 1. Nov 2005 (CET)

Ach ja, wie ich schrieb: Die Klasse heißt wikitable. Danach brauchst du aber auch nicht suchen, da die Vorlage nichts anderes ist, die aber auch nicht viel verständlicher ist als die direkte Verwendung. Das ist also kein Argument. --ChristianErtl 20:22, 1. Nov 2005 (CET)

[Bearbeiten] MediaWiki:Common.css

Zur Zeit sind alle Stylesheet-Definitionen in zwei Teile geteilt. Der erste allgemeine Teil kann nach einer kürzlichen Softwareerweiterung jetzt nach MediaWiki:Common.css ausgelagert werden, so dass er nicht mehr in parallel in MediaWiki:Amethyst.css, MediaWiki:Chick.css, MediaWiki:Cologneblue.css, MediaWiki:Monobook.css, MediaWiki:Myskin.css, MediaWiki:Nostalgia.css, MediaWiki:Simple.css und MediaWiki:Standard.css gepflegt werden muss. --Hendrik Brummermann 23:30, 4. Nov 2005 (CET)

Jetzt aber endlich :-) --:Bdk: 19:48, 17. Dez 2005 (CET)

[Bearbeiten] Hintergrundfarben

Die Definition

.ns--1 table,
.ns-2 table,
.ns-4 table,
.ns--1 form {
        background: inherit;
}

behindert für Monobook-Nutzer auf Benutzer- und Wikipediaseiten die Hintergrundfarbendefinition über CSS-Klassen in Tabellen (siehe MediaWiki_Diskussion:Common.css). Sollte es sich um eine Art Bugfix handeln, lässt sich das vielleicht an anderer Stelle besser und allgemeiner (sprich für alle Seiten/Skins/...) behandeln. Ich kommentiere das deswegen mal aus. Bei Beschwerden bitte wiederherstellen, dabei bedenken, dass es auch in anderen Namensräumen und Skins Hintergrundfarben gibt und den Zweck dazuschreiben. -- Schnargel 00:50, 30. Jan 2006 (CET)

Könnte man solche Experimente vielleicht in Zukunft sein lassen? Es sieht m.M.n. ziemlich grottig aus und ich hatte auch nach diesem Testeinbau irgendwelche Reste im Browsercache wodurch das ganze bis zu einem Cacheleeren ziemlich zerwürfelt aussah. Solche Änderungen vielleicht vorher ankündigen und erstmal irgendwo testen. Vielen Dank! -- Jonathan Haas 00:38, 8. Dez. 2007 (CET)

Ich verm. du bist in diesem Abschnitt falsch. --DaB. 00:44, 8. Dez. 2007 (CET)

Vermute ich jetzt auch. Meine Anmerkung bezog sich allgemein auf die farbigen Diskussionshinterlegungen. Kannst mich gerne an die richtige Stelle schieben, bin zu müde zum suchen. ;-) -- Jonathan Haas 00:46, 8. Dez. 2007 (CET)

[Bearbeiten] Kleines Globus-Symbol neben der Geookordinate

Das verlinkt png ist in diesem absoluten Pfad nicht mehr vorhanden. Gestern hatte ich es kurz durch den neuen Pfad auf Commons ersetzt, allerdings ist der Globus dort zu groß und die Anzeige völlig anders als ich sie in Erinnerung habe. Entweder sollten wir wieder einen passenden Globus einsetzen oder der Abschnitt kann herausgenommen werden.

Zudem habe ich heute morgen einen kleinen Abschnitt eingefügt, der den hellblauen Pfeil für externe Weblinks speziell nur für im Artikel eingebettete Koordinaten (Vorlagen „Koordinate Text“ und „Koordinate Text Artikel“) unterdrückt. Speziell für die Koordinaten finde ich den Pfeil sehr störend. Der externe Link verweist ja auf ein befreundeted Wiki (Kvaleberg). Und bei der Vorlage „Koordinate Artikel“ wurde er schon lange nicht mehr angezeigt. Ich hoffe dafür bekomme ich jetzt keine Haue :) --Raymond ^Disk. 08:45, 23. Jun 2006 (CEST)

[Bearbeiten] Gallery

Hallo,
die einzelnen Bilder in den Galerien werden außen mit einem weißen Rahmen umrandet. Da der Kontrast zwischen #F9F9F9 und #FFFFFF natürlich nicht so groß ist, würde ich es besser finden wenn man das weiß gleich durch #F9F9F9 ersetzt. In meiner monobook.css hab ich das schon mit folgenden Code ausprobiert:

table.gallery {
  background-color: #F9F9F9;
}
table.gallery td {
  border-color: #F9F9F9;
}

Meinungen dazu? -- San Jose 13:54, 23. Jul 2006 (CEST)

[Bearbeiten] Eigenes Wiki - Links nicht unterstreichen

Hallo, Ich möchte in meinem eigenen Wiki gerne auch die Links nicht unterstrichen haben. Hier wird es ja über

 a {
       text-decoration: none;
 }

gelöst. Wenn ich das bei mir in die Monobook.css eintrage sehe ich aber leider kein Änderung bzw. Wirkung.

Mache ich was falsch. Hat hier jemand einen Tip? Danke im Voraus. --Ali aka Alexander 13:32, 29. Sep 2006 (CEST)

Der Witz daran ist (habe ich soeben festgestellt), dass der IE 6 die Wikipedia richtig macht, mein Wiki nicht. Opera hingegen macht beide richtig. Muss ich in den IE Fixes irgendwas nachtragen??? --Ali aka Alexander 13:42, 29. Sep 2006 (CEST)

Firefox 1.5.0.3 macht es auch nicht. --Ali aka Alexander 13:46, 29. Sep 2006 (CEST)

Hat sich erübrigt. War wohl ein Cache-Problem.--192.77.115.33 15:50, 29. Sep 2006 (CEST)

[Bearbeiten] Links im Portal:Punk

Sehe ich das richtig, dass diese Stile im Punk-Portal gar nicht mehr genutzt werden? Die könnten dann ja auch raus... --Gnu1742 08:15, 1. Jun. 2007 (CEST)

Die schwarze Hintergrundfarbe, die eine andere Linkfarbe notwendig gemacht hat, ist entfernt worden. Die rote Linkfarbe kann daher entfernt werden. Allerdings gibt es durchaus sinnvolle und auch geeignete Stellen wo eine dunkle Hintergrundfarbe und daher eine helle Schrift- und Linkfarbe sinnvoll ist. Siehe: MediaWiki Diskussion:Common.css#Links auf dunklem Hintergrund --Fomafix 23:45, 23. Aug. 2007 (CEST)

Sprich doch lieber von "benötigen" als "sinnvoll", das ist nämlich Ansichtssache. --BLueFiSH ✉ (Langeweile?) 12:43, 24. Aug. 2007 (CEST)

[Bearbeiten] Urrheberrecht

Dürfte ich einige Sachen davon auch in meinem Wiki übernehmen, oder verletzt das das Urrheberrecht? --Latias13 10:47, 21. Jun. 2007 (CEST)

Wenn es ein lokales, nicht vom Internet aus zugängliches Wiki ist, sieht es keiner... --BLueFiSH ✉ (Langeweile?) 13:41, 21. Jun. 2007 (CEST)

[Bearbeiten] Probleme mit mehreren Thumbnails hintereinander

Hallo liebe Kollegen, Vor einigen Tagen bin ich auf einen Fehler in Zusammenhang mit Thumbnail-Bildern gestoßen, der die Browser der Mozilla-Familie beim Erstellen der Druckvorschau zum Absturz bringt. Die genaue Fehlerbeschreibung und weitere bisherige Erkenntnisse zu dem Fehler findet ihr unter Wikipedia:Redaktion Bilder#Probleme mit mehreren Thumbnails hintereinander. Hat jemand von euch einen guten Vorschlag wie wir weiter mit dem Problem verfahren sollen? Besten Dank & Grüße --Alcibiades 10:14, 27. Jun. 2007 (CEST)

[Bearbeiten] Übersichtlichere Diskussionen

Ich bin gerade darauf gestoßen, dass die Franzosen verschachtelte Diskussionen per CSS etwas übersichtlicher gestalten, siehe zum Beispiel hier. Wäre das nicht auch was für hier, es muss ja auch nicht ganz so bunt sein? -- Nichtich 23:58, 2. Dez. 2007 (CET)

Diese Verschachtelung funktioniert aber nur richtig, wenn die Diskussionsbeiträge nicht durch Absätze voneinander getrennt sind (ansonsten werden Beiträge mehrmals umrahmt - bei langen Diskussion bis zu acht Mal!). Der Bug müsste vorher unbedingt gefixt werden. -- Prince Kassad 19:35, 7. Dez. 2007 (CET)

an diesem beispiel fällt mir vor allem eines auf: ich finde vor lauter rähmchen die diskussion nicht mehr. an sich vielleicht keine schlechte idee, aber so wie die rahmen dort angeordnet sind ist es in meinen augen schlechter lesbar als ohne. -- ∂ 20:22, 7. Dez. 2007 (CET)

Hallo, die Rahmen werden dann unübersichtlich, wenn die mit Doppelpunkt(en) eingeleiteten Zeilen, anders als hier, durch Leerzeilen getrennt sind und deshalb obere Zwischenränder gezeichnet werden. Das sollte sich durch eine Erweiterung des Skripts beheben lassen. Vielleicht kann ich dafür etwas basteln... --Wiegels „…“ 21:00, 7. Dez. 2007 (CET)

Hallo nochmal, mit diesem Skript in MediaWiki:Monobook.js würden die zurzeit getrennt stehenden Definitionslisten weitgehend miteinander verschmolzen. Ich habe es mit Firefox 2 und MS Internet Explorer 7 erfolgreich getestet. Wäre diese Erweiterung nicht ein sinnvolles Gadget? Dann könnte jeder angemeldete Benutzer entscheiden, ob er das Design umstellt. Für die Farben möchte ich #dbedff (Rand), #e7f3ff (dunkler) und #f3f9ff (heller) vorschlagen. --Wiegels „…“ 17:31, 8. Dez. 2007 (CET)

Guckt ihr hier, da ist das auch zur Sprache gekommen. --Versusray (Disku | Bew.) | Skin 15:08, 17. Dez. 2007 (CET)

[Bearbeiten] nowrap in CSS-id coordinates

MediaWiki:Monobook.css definiert:

 #coordinates {
    display: inline;
    position:absolute; z-index:1; border:none; background:none; right:12px; top:0.3em; float:right; margin:0.0em;
    padding:0.0em; line-height:1.5em; text-align:right; text-indent:0; font-size:85%; text-transform:none; white-space:normal;
 }

MediaWiki:Amethyst.css definiert:

 #coordinates {  
  position:absolute; z-index:1; border:none; background:none; right:12px; top:0.3em; float:right; margin:0.0em;
  padding:0.0em; line-height:1.5em; text-align:right; text-indent:0; font-size:85%; text-transform:none; white-space:normal;
 }

MediaWiki:Nostalgia.css definiert:

 #coordinates {
    display: inline;
  position:absolute; z-index:1; border:none; background:none; right:12px; top:0.3em; float:right; margin:0.0em;
  padding:0.0em; line-height:1.5em; text-align:right; text-indent:0; font-size:85%; text-transform:none; white-space:normal;
 }

die Koordinatenvorlagen überschreiben:

style="white-space:nowrap; z-index:1;"

Die neuerliche Definition von z-index ist schon mal für die Katz, aber wenn man schon an den Vorlagen ändert könnte man auch gleich alles anpassen. Die Nachbesserung in den Vorlagen muss nicht sein. Weitere Skins sind nach meiner Analyse nicht betroffen. Neben den Koordinatenvorlagen (Vorlage:Koordinate Artikel, Vorlage:Koordinate Text Artikel) verwenden noch die Vorlage:Text oben rechts die coordinates-id (Intro Vorlagen). Ich bitte darum an oben aufgezeigten stellen «white-space:normal» durch «white-space:nowrap» zu ersetzen. -- visi-on 14:46, 7. Feb. 2008 (CET)

PS: die Anpassung von Vorlage:Coordinate kann ich selbst vornehmen. Die andern Vorlagen sind gesperrt und müssen von einem Admin editiert werden. -- visi-on 14:53, 7. Feb. 2008 (CET)

[Bearbeiten] Verbergen-Link überdeckt Shortcuts u.ä.

Der nachfolgende Code aus der aktuellen MediaWiki:Monobook.css

greift bei der derzeitigen Sitenotice nicht, da diese einzeilig ist. Daher werden Shortcuts u.ä. durch den "Verbergen"-Link der Sitenotice überdeckt. Sollte der "Verbergen"-Link nicht besser nach links gefloatet werden, um diesen Kollisionen dauerhaft aus dem Wege zu gehen? Gruß --W_I^KImaniac 00:17, 6. Apr. 2008 (CEST)

[Bearbeiten] FlaggedRev-Box

Bitte #mw-revisiontag durch .flaggedrevs_short ersetzen, sonst wird .flaggedrevs_notice auf ...?action=history und ...?oldid=XYZ etc. ebenfalls verschoben! --87.173.194.95 16:13, 6. Mai 2008 (CEST)

[Bearbeiten] Box für gesichtete Version verdeckt ohne Javascript den Text

Siehe zu dem Problem Fragen zur Wikipedia und Bug für Mediawiki. Im Bug sind ein paar Modifikationen genannt, auf deren Basis ich meine private Monobook.css gebastelt habe, mit der ich dast Problem löse: Benutzer:Dishayloo/monobook.css. Das wird aber wohl kaum IP's helfen, die ohne Javascript unterwegs sind. Soll ich meine Änderungen in diese Monobook.css übertragen, oder gibt es ernsthafte Einwände? -- Dishayloo + 22:36, 15. Mai 2008 (CEST)

Gute Idee. Bei mir funktioniert Deine Anpassung in allen Varianten ohne Probleme (FireFox 2.0.0.14 und IE 7.0.5730.11). Ich wäre also dafür. -- ^ηeonZERO  07:24, 16. Mai 2008 (CEST)

Ich habe Dishayloos Vorschlag in diese Monobook übernommen. Getestet mit dem FF 3 beta 5, Opers 9.27 und IE7 jeweils mit und ohne JavaScript. Die üblichen Unterschiede zwischen den Browsern, aber ich habe keine gravierenden Nachteile gesehen. — Raymond ^{Disk. Bew.} 08:21, 16. Mai 2008 (CEST)

Vielen Dank. Interessanterweise umfliesst jetzt der Text auch die gesichtet-Box, also scheinst Du noch etwas mehr gemacht zu haben. :-)

Ich habe die Änderungen wieder aus meiner persönlichen monobook.css entfernt (damit es keine Kollisionen gibt) - nur damit sich niemand wundert. -- Dishayloo + 08:48, 16. Mai 2008 (CEST)

Wesentlich besser! Ein margin: 0 0 1em 1em; wäre aber noch schön, weil der Text sonst manchmal sehr nah an die Box ranrückt. --Revolus Echo der Stille 09:12, 16. Mai 2008 (CEST)

Ok, ergänzt. — Raymond ^{Disk. Bew.} 09:16, 16. Mai 2008 (CEST)

Ein Problem hab ich gefunden: auch wenn die Box per Javascript "eingeklappt" ist, wird sie auf die volle Höhe vergrößert, wenn man mit der Maus drüberfährt (FF2, FF3beta5, IE7). --Tokikake 09:40, 16. Mai 2008 (CEST)

Stimmt, war mir auch aufgefallen. — Raymond

^{Disk. Bew.} 09:45, 16. Mai 2008 (CEST)

Bei Infoboxen (z.B. Infobox PKW-Modell) überlappt nun Text den oberen Teil der Infobox, die Umfließung klappt nicht mehr richtig. Das sieht nicht unbedingt schön aus. Mir persönlich käme es entgegen, diese "Gesichtet-Box" wieder in den oberen Teil bei der Überschrift zu verlagern, so daß sie den Artikeltext nicht beeinflussen kann. --Nobsy 10:56, 16. Mai 2008 (CEST)

Nur am Rande: Mich interessiert, was der ursprüngliche Beweggrund war, die Box an diese Stelle zu verschieben? --Rainer Lewalter 12:00, 16. Mai 2008 (CEST)

Kann man das Kästchen nicht umformen zu einem Icon? Also: Nur das Icon ist sichtbar, und das dann unter das zum Beispiel "Lesenswert-Icon" klemmen. Bei klick auf das Icon würde sich das Kästchen dann aufklappen. So ist das ziemlich blöde gelöst. Gruß --Thot 1 12:24, 16. Mai 2008 (CEST)

Was unter Benutzer:Tokikake/monobook.css steht funktioniert besser. Im Firefox tritt der Effekt nicht mehr auf, im IE wird die Box nur noch 1-2 Pixel höher. --Tokikake 12:25, 16. Mai 2008 (CEST)

Danke, deine Variante habe ich jetzt eingebaut. — Raymond ^{Disk. Bew.} 12:48, 16. Mai 2008 (CEST)

Immer nch nicht ideal. Bei mir (Safari, MacOs X) wird der Text verdeckt und das zappelnde Bild beim klicken stört auch, bei geöffneter Box. --Thot 1 12:56, 16. Mai 2008 (CEST)

Was spricht denn gegen die Standardeinstellung? Wenn die Box weiter oben sein soll, sollte sie neben das Lemma gefloatet werden, wie man es mit javascript:(function(){var d=document,g='getElementById';d[g]('content').insertBefore(d[g]('contentSub').removeChild(d[g]('mw-revisiontag')),d[g]('top'))})() ausprobieren und notfalls auch in MediaWiki:monobook.js eintragen kann (dann ist es für skriptlose Leser wahrscheinlich hübscher als wenn es fest neben dem Lemma steht). --77.135.134.3 12:37, 16. Mai 2008 (CEST)

Hinweis: Infoboxen sind jetzt teilweise links neben der Gesichtet-Box (Beispiel: Adlernebel) --Church of emacs ツ ⍨ 13:04, 16. Mai 2008 (CEST)

Lässt sich mit clear:right in der Infobox beheben. --77.135.134.3 13:12, 16. Mai 2008 (CEST)

Dafür läuft jetzt der Artikeltext in die IB und drüber... sieht auch scheiße aus. Macht das Sichtungsbapperl ans Artikelende und oben ein kleines Icon. --84.139.35.10 13:14, 16. Mai 2008 (CEST)

Genau so! Alles andere ist humbug. Gruß --Thot 1 13:33, 16. Mai 2008 (CEST)

Ich schließe mich an. Im Artikeltext ist das keine optimale Lösung - vorher hat das Sichtungsicon die Artikelformatierung nicht gestört. --Nobsy 15:18, 16. Mai 2008 (CEST)

Wenn man das Dingens jetzt aufklappt und mit der Maus drüberfährt, zappelt es hin und her und überlagert Bild und Text. Ist nicht nur nicht optimal sondern ... --Thot 1 15:27, 16. Mai 2008 (CEST)

Welcher Browser/-version auf welchem Betriebssystem nutzt du? — Raymond ^{Disk. Bew.} 15:35, 16. Mai 2008 (CEST)

Hi Raimond, es ist Safari 3.1.1 auf Mac OS X 10.4.11 --Thot 1 15:37, 16. Mai 2008 (CEST)

Auf diesem Rechner benutze ich gerade den Mozilla Firefox 1.5.0.12 (ich weiß, der ist nicht brandaktuell...) unter Windows 2000. Damit wird die IB mit Artikeltext oben überlagert, fährt man mit der Maus über das Sichtungsdingens, zappelt die IB ein paar Pixel hoch und runter. --Nobsy 15:47, 16. Mai 2008 (CEST)

Jeder standardkonforme Browser macht das, sobald height:auto größer als height:20px ist, was von der Schriftgröße abhängt, aber zumindest bei aufgeklappter Box immer der Fall ist. Bitte nehmt doch diesen Sonderstyle ganz raus und lasst es bei der Voreinstellung, solang nicht wirklich was verbessert wird (testbar mit javascript:(function(){var s=document.styleSheets.item(3).cssRules.item(1).styleSheet,i=5;while(--i)s.deleteRule(s.cssRules.length-i)})()). --89.59.137.171 15:53, 16. Mai 2008 (CEST)

Ich habe auch kein Problem damit, wenn oben nur ein Icon und unten die Sichtungsinformation ist, wie hier vorgeschlagen wurde. Hauptsache die Box überdeckt nicht mehr den Text bei Scriptlosen Benutzern. -- Dishayloo + 16:02, 16. Mai 2008 (CEST)

Als die „gesichtet“-Hinweisbox im Überschriftenteil lag, war das wesentlich besser. Im Bereich der Einleitung stört sie (egal ob mit oder ohne Java). Seit wann landet man übrigens nun zuerst auf der Entwurfsseite, statt auf der gesichteten Version eines Artikels? Unter dieser Voraussetzung brauchen wir wohl keine gesichtete Version mehr… (bzw. kann ich mir nicht vorstellen, dass das Absicht ist) -- ^ηeonZERO  16:18, 16. Mai 2008 (CEST)

Die Box verdeckt auch Text bei mit eingeschalteten Javascript. --Atamari 16:25, 16. Mai 2008 (CEST)

Schlimmer noch, wenn rechts ein Bild oder eine Infobox ist, verdeckt das Bild oder die IB jetzt teilweise den Text, etwa in Erdbeben in Sichuan 2008. Ganz eindeutig eine Verschlimmbesserung, also besser wieder zurück wie es war, direkt unterhalb des Koordinatenlinks anordnen. --Matthiasb 16:43, 16. Mai 2008 (CEST) (FF 2.0.0.14)

Und dann nur ein einzelnes Icon, welches beim anklicken aufpoppt. Das +− braucht man doch nicht, oder? --Thot 1 16:48, 16. Mai 2008 (CEST)

<nach BK> PS:Die Problematik wurde übrigens lang und breit diskutiert, etwa hier. Dutzende von Infoboxen wurden deswegen verändert und ihr pfuscht erneut daran rum. --Matthiasb 16:53, 16. Mai 2008 (CEST)

Und schaut euch mal an, wie besch... ein Artikel mit Vorlage:Dieser Artikel nun aussieht. --Matthiasb 16:56, 16. Mai 2008 (CEST)

Dass die erste Zeile in eine nach unten verschobene Floatbox reinragen kann, ist ein üblicher Browserbug (für Mozilla z.B. Bug 25888; Konqueror hat ihn auch). Wenn die gesichtet-Box (oder nur das Icon) neben dem Lemma floaten würde, könnte das nur bei extrem kleinen Schriftarten oder aufgeklappter Box passieren (natürlich müssten dann auch die anderen Sachen, die an dieser Stelle auftreten können (lesenswert-Icon, Koordinaten &c.) in vernünftige Floats verwandelt werden, was aber eh sinnvoll ist). Die absolute Positionierung (wie in den letzten Tagen) ist jedenfalls die schlechteste Lösung. --89.59.137.171 17:40, 16. Mai 2008 (CEST)

Die Lösung war besser wie die jetzige: zuvor litten nur User ohne JS, jetzt leiden alle. Solange nichts besseres einfällt, sollte das zurückgesetzt werden und zwar im Eilzugtempo. --Matthiasb 17:58, 16. Mai 2008 (CEST)

Mit der absoluten Positionierung waren auch mit JavaScript längere Lemmata teils verdeckt; ohne JavaScript war der Zustand völlig untragbar, nachdem die Einleitung nicht lesbar war. --89.59.137.171 18:13, 16. Mai 2008 (CEST)

Vergiss mal dein fehlendes JS – wer surft denn schon ohnen – und die etwa 28 zu langen Lemmata. Das ist das weitaus geringere übel. Jetzt sind geschätzte 500.000 Artikel verhunzt und sehen beschissen aus. --Matthiasb 18:20, 16. Mai 2008 (CEST)

Es gibt Leute ohne JavaScript (ich habs schon an), und für die ist es tragisch. Den Browserbug kann man übrigens ziemlich leicht unwahrscheinlich machen, wenn man die gesichtet-Box in bisschen niedriger macht, was eh schöner ist, z.B. so (zum Testen): javascript:(function(){var s=document.styleSheets.item(3).cssRules.item(1).styleSheet;s.insertRule('.flaggedrevs_short{padding:3px .5em}',s.cssRules.length)})() --89.59.137.171 18:29, 16. Mai 2008 (CEST)

Das ändert nix daran, daß die Box nichts im Raum zu tun hat, der dem Artikeltext vorbehalten ist. Wo die Gesichtet-Box jetzt ist, gehört sie nicht hin, nicht in der jetzigen Höhe und auch nicht nur einen halben Millimeter hoch. Ich verstehe die Logik nicht: weil es für geschätzte 2% Nutzer ohne JS "tragisch" war, muß es jetzt für 100 % der Benutzer viel tragischer sein? Ich habe übrigens keine Lust was mit dem Teufelskram herumzutesten. Schon mal den Satz gehört Never change a winning game? --Matthiasb 18:44, 16. Mai 2008 (CEST)

Die jetzige Lösung ist nur unschön, nicht tragisch. Dass die Box besser neben dem Lemma (aber als Float) oder unter dem Artikel stehn sollte, ist allerdings richtig. --89.59.137.171 19:11, 16. Mai 2008 (CEST)

Am besten ganz weg lassen! Braucht eh nur Bertelsmann. ;-) --Thot 1 18:00, 16. Mai 2008 (CEST)

Zumindest hat sie unterhalb des Querstriches, auf dem die Überschrift steht, gar nichts aber wirklich gar nix verloren. Sie gehört nämlich nicht zum Artikel. --Matthiasb 18:03, 16. Mai 2008 (CEST)

Na das Zeit- und Ressourcen-verschwendende Feature wird ja hoffentlich eh bald wieder abgeschaltet. *hoff* --STBR – !? 19:07, 16. Mai 2008 (CEST)

Vielleicht wurde das schon mal besprochen, weiß ich aber nicht. Drucken ist auch mies. Das Dingens wird mitgedruckt und überlagert beim Druck den Lemmatitel. Das Plus- und Minuszeichen wird auch mitgedruckt. --Thot 1 20:54, 16. Mai 2008 (CEST)

Die Monobook.css wurde auf die Variante zurückgesetzt, die ausschließlich für Browser mit aktiviertem Java akzeptabel ist, nicht aber für alle anderen Anwender, die Java aus Sicherheitsgründen lieber deaktiviert lassen. Das ist meiner Meinung nach der falsche Weg. Die erste Lösung war für beide Anwender akzeptabel - mit _kleinen_ Schönheitsfehlern sicherlich (nicht zu vergleichen mit dem aktuellen Debakel). Darauf sollte zurückgesetzt werden. Die größeren Probleme fingen erst mit darauf folgenden Versionen an. -- ^ηeonZERO  21:16, 16. Mai 2008 (CEST)

[Bearbeiten] Box eingedampft

Ich habe die Box jetzt deutlich eingedampft:

1. Der Satz, dass die Seite bearbeitet werden kann, ist redundant zum normaDarunlen Bearbeiten-Reiter.

2. Darunter war nochmal ein breiter, bunter Balken "Status: gesichtet". Ebenfalls redundant zum Auge mit "Gesichtet".

Nun sollte die ausgeklappte Box, bzw. bei Nutzern ohne JavaScript, den Text nicht mehr überlagern. Hoffe ich... — Raymond ^{Disk. Bew.} 21:31, 16. Mai 2008 (CEST)

Doch, macht sie noch. In der ersten Zeile der Einleitung ist nun zwar nur noch die obere Hälfte des Textes weg - immerhin - aber er ist weg.

Es gibt seit den Anpassungen noch ein weiteres Phänomen: Unter FF und IE gelange ich _im_angemeldeten_Zustand_ beim Klick auf verlinkte Seiten (z.B. Virtual Private Network) auf den Entwurf, wobei ich als IP auf die gesichtete Seite komme. Beides unabhängig von Java. Löschen der eigenen Monobook hat nichts gebracht. Da das Problem auch bei einer vollkommen neu erstellten Kennung unter beiden Browsern auftritt, ist es eher unwahrscheinlich, dass es an den privaten Einstellungen liegt. Aber ob die Monobook etwas damit zu tun hat, ist ebenso fraglich. *grübel* -- ^ηeonZERO  21:38, 16. Mai 2008 (CEST)

<quetsch>Leute: Java ist nicht Javascript! Danke für eure Aufmerksamkeit. --V•R•S (☣|☢) 10:20, 18. Mai 2008 (CEST)

<ot>Keine Ursache. Ist bekannt. Dennoch weiß jeder, was damit gemeint ist. Danke trotzdem für den Hinweis.</ot> -- ^ηeonZERO  10:42, 18. Mai 2008 (CEST)

@NeonZero: Das ist das gewünschte Verhalten. IP sieht stabil, Benutzer sieht aktuell/vandaliert. --- MfG, Melancholie 23:49, 16. Mai 2008 (CEST)

Na, da kann ich ja lange suchen. Danke für den Hinweis. -- ^ηeonZERO  07:23, 17. Mai 2008 (CEST)

Eine (im Prinzip zumindest) vernünftige Version hab ich mal unter Benutzer:Floats1/monobook.css und Benutzer:Floats1/monobook.js erstellt. Oben neben dem Lemma floaten damit alle Sachen, die sonst absolut positioniert sind, untereinander, ohne sich gegenseitig oder sonstwas zu überlappen. Von den Sichtungen ist oben nur das Icon; die Box ist unten (könnte man noch verschönern und die Icons in der Größe angleichen). Zum Testen ein Artikel mit Koordinaten, Exzellenz und langem Lemma: Dienstgebäude der Königlichen Eisenbahndirektion Berlin. Koordinaten, lesenswert, kurzes Lemma und Begriffsklärung: Helgoland. Koordinaten, lesenswert, kurzes Lemma und Infobox: Hiddensee (bei sehr kleiner Schriftart kann hier obiger Browserbug auftreten; könnte man verhindern, indem man #contentSub { clear: right } ergänzt). Im IE hab ichs nicht getestet, aber sonst (Gecko 1.8 & 1.9, Opera, Konqueror) seh ich keine Probleme damit. --Floats1 01:28, 17. Mai 2008 (CEST)

Hab die Icons noch gegebenenfalls nebeneinander gesetzt statt untereinander. Einen Härtetest gibts hier. --Floats1 02:14, 17. Mai 2008 (CEST)

[Bearbeiten] Wissen für alle?

Seltsam, ich dachte Wikipedia dient dem Ziel, Wissen für alle bereitszustellen. Aber ich sehe hier durchaus die Einstellung, dass man die Nutzer ohne Javascript opfert, weil einem die Darstellung nicht gefällt. Um es nochmal klar zu machen: Ohne Javascript ist dank der gesichtet-Boxen die Wikipedia unbrauchbar! Man kann den Einführungstext nämlich nicht lesen. Aber die paar menschlich minderwertigen Idioten, die Javascript ausstellen, sind es eben nicht wert, die Wikipedia lesen zu dürfen. Oder? Jedenfalls bemühe ich mich, für die zwei Prozent der Nutzer, die solche Windows-DAUs sind, dass sie nichtmal den Knopf zum Ausstellen von Javascript zu finden, die Darstellung zum Gewohnten zu beeinflussen. Man schaue Benutzer:Dishayloo/monobook.js und Benutzer:Dishayloo/monobook.css. Ich versuche bei angeschaltetem Javascript den Stil zu benutzen, der für Nicht-Javascriptler die WP unbenutzbar macht. Leider klappt das noch nicht. Kann jemand mit mehr JS-Ahnung mal draufschauen und sagen was nicht stimmt? -- Dishayloo + 10:34, 17. Mai 2008 (CEST)

OK, ich habe eine Lösung, die nach meinen Experimenten für alle erträglich sein sollte (außer die Javascript-Divas bestehen auf der Millimetergenauen Positionierung, dann dürfen sie gerne mit dem top und dem roght-Werten spielen): Benutzer:Dishayloo/monobook.css. Das ist ohne Hover-Effekte, also nicht so schön, aber durch Verzicht auf die absolute Positionierung kann der Artikeltext die Box umfliessen. Ist das OK? Kann noch jemand anderes das bitte mal prüfen? -- Dishayloo + 10:47, 17. Mai 2008 (CEST)

Da es scheinbar niemanden gibt, der Probleme damit hat, war ich mal mutig und habe es geändert. Lässt sich ja gegebenenfalls erneut revertieren. -- Dishayloo + 13:26, 17. Mai 2008 (CEST)

[Bearbeiten] Zusammenfassung und Vorschlag

Vorschlag: Im Artikel ist lediglich ein Icon (ähnlich dem Exzellent-Icon) sichtbar. Wenn man mit den Mauszeiger über das Icon fährt, dann geht das Pop-up auf.

Seitdem die Box im Artikelbereich ist (also unter der Hauptüberschrift) sind vermehrt Probleme aufgetaucht, die bereits ausführlich beschrieben wurden. Dennoch möchte ich hier noch einmal darauf hinweisen und darum bitten die Box wieder über bzw. neben die Hauptüberschrift zu setzen. Hier nochmal die wichtigsten Gründe:

• Die Gesichtet-Box behört vom Sinn her nicht in den Artikelbereich.
• Zwischen Hauptüberschrift und {{Dieser Artikel}} entsteht ein unschöner und überflüssiger Abstand (zB. Nil).
• Text wird teilweise verdeckt (FF 2.0.0.14) (zB. Ausschließliche Wirtschaftszone).
• Die aufgeklapte Gesichtet-Box wird bei darüberfahren mit der Maus abwechselnd durchsichtig/undurchsichtig (FF 2.0.0.14) (zB. Vic Nees).

Zudem ist die Angabe Gesichtet neben dem Auge und die Angabe Gesichtet in dem Balken redundant. Daher will ich noch einen Vorschlag einbringe. Bevor ich diesen aber lange beschreibe, habe ich eine Animation erstellt. Grüße -- San Jose 13:40, 17. Mai 2008 (CEST)

Dein Vorschlag ist technisch realisierbar (und auch ohne Javascript möglich, CSS macht es möglich). Nur leider können wir ohne größere Probleme erstmal nur diese CSS hier bearbeiten, basierend auf dem bestehenden HTML-Quelltext. Hast Du etwas CSS-Code, wie wir Deinen Vorschlag realisieren können, indem wir ihn hier einbringen? Ansonsten muss vielleicht auch eine Anpassung für Mediawiki her, kennst Du diesen Bug? -- Dishayloo + 13:50, 17. Mai 2008 (CEST)

Oh, Dein Bild mit der Problembeschreibung deutet darauf hin, dass Du noch eine ältere Monobook.css im Cache hast. Lade mal folgende Seite in Deinem Firefox und bei dem muss man noch ein Reload auf diese Seite ausführen, dann mach noch einen Reload auf die Seite mit dem Problem. Besteht das Problem dann immer noch? -- Dishayloo + 13:58, 17. Mai 2008 (CEST)

Das sieht schon viel besser aus :) Jetzt sind aber noch zwei kleinere Probleme aufgetaucht:

• Die Koordinatenangaben berühren fast die Box (zB: Martinsburg (Burg))
• Wenn man die Box aufklappt, wieder zuklappt und dann noch mal aufklappt, dann ist das Layout der Box etwas verschoben.

Einen CSS-Code für meinen Vorschlag habe ich nicht (die Animation basiert auf Bildmontage und ist kein 1:1 Bildschirmfoto). Mit Bugs und JS bzw. CSS kenn ich mich nicht so gut aus. -- San Jose 14:13, 17. Mai 2008 (CEST)

Hab die Variante mit :hover in Benutzer:Floats2/monobook.css und Benutzer:Floats2/monobook.js realisiert (ohne inhärent problematischer absoluter Positionierung, deshalb ist das Skripting zum Umbau des DOM-Trees notwendig). Das :hover wird aber in älteren IEs nicht funktionieren; da müsste man wohl noch einen onclick- oder never-Handler einbauen, damit solche Benutzer auch an die Informationen kommen können. Ohne Skripting bleibt es bei der bisherigen Anzeige im Artikeltext, weil dann der DOM-Tree nicht umgebaut werden kann und mit dem bestehenden keine vernünftige Implementation möglich ist (wär natürlich durch entsprechende Änderungen in FlaggedRevs selbst machbar). Ich halt obige statische Variante (Benutzer:Floats1/monobook.css und Benutzer:Floats1/monobook.js) für sinnvoller. --Floats2 17:15, 17. Mai 2008 (CEST)

Ich habe das mal ausprobiert. Dadurch wird bei Nicht-Javascriptern nichts überdeckt, insofern ist es in Ordnung. Aber die Box liegt dann unschön zwischen Überschrift und Artikel, sie sollte wenigstens nach rechts gefloatet werden. -- Dishayloo + 17:34, 17. Mai 2008 (CEST)

Habs entsprechend geändert (in der :hover-Variante war es ohnehin schon so). --Floats1 17:56, 17. Mai 2008 (CEST)

Ich habe es nochmal ausprobiert. Sieht schon besser aus, aber bei Festung Mainz floaten die Bilder auch nach rechts und landen dabei direkt links von der Box. Schau mal den Artikel mit abgeschalteten Javascript an. Du bist aber definitiv auf einem guten Weg, jedenfalls ohne Javascript. Vielleicht sagen die Javascript-Nutzer noch etwas dazu. -- Dishayloo + 19:06, 17. Mai 2008 (CEST)

Ich habe mir erlaubt, den artikel anzupassen, das Problem entstand nur, da ein einfaches 'align=right' verwendet wurde, ohne ein 'clear:right', aber die tabelle ist unnötig, da Bilder untereinander genauso dargestellt werden, alternativ hätte auch die class "float-right" für die tabelle verwendet werden können. Wird auch an anderen stellen vorkommen, wo kein clear verwendet wird. Der Umherirrende 19:18, 17. Mai 2008 (CEST)

Annähernd so wie meine Versionen für Leute ohne JavaScript ausschauen, würd es übrigens auch ausschauen, wenn man gar nichts verändern und die Standardeinstellungen von FlaggedRevs lassen würde (mit JavaScript ist dann halt die Box einfach kleiner und vergrößert sich erst auf Klick). --Floats1 21:01, 17. Mai 2008 (CEST)

OK, ich habe das Problem mit den Koordinaten auch beseitigt, indem ich die Box noch etwas nach unten verschoben habe. Ihr müsst die im Browsercache gespeicherte Version neu laden, damit die Änderung sichtbar wird. Notiz: Berlin ist ein guter Testfall, der Artikel hat Koordinaten, ist Lesenswert und gesprochen. -- Dishayloo + 09:57, 18. Mai 2008 (CEST)

Also die allererste Version von Dishayloo war wesentlich besser. Position so wie jetzt (nicht wie bei Floats2, sondern wie in der allgemeinen gerade aktuellen Monobook.css) und der zusätzliche Text nur sichtbar, wenn man mit der Maus drüber fährt. Das war doch nie ein Problem. Wenn ich die Disku oben sehe, gab es die Probleme doch erst, nachdem der Hinweistext in den Bereich der Einleitung verschoben wurde. -- ^ηeonZERO  18:18, 17. Mai 2008 (CEST) (Die Lösung wie in San Jose Grafik dargestellt, wäre meiner Meinung nach noch besser, nur sollten wir bis dahin erst einmal auf die ursprüngliche Version von Dishayloo zurückrudern)

Naja, es gab wohl auch bei meiner ursprünglichen Version das Problem für Javascriptler, dass sie auf (+/-) geklickt haben um die Box auszuklappen, die dann per Hover-Effekt aus- und zugeklappt wurde. Das kann schon etwas verwirren. Da ich nicht weiß, wie ich die Pseudoklasse hover per Javascript überschreibe und damit daktiviere, bin ich zur aktuellen Lösung gekommen, die die Box immer ausklappt. Da Raymond auch die box selbst verkleinert hat, ist das kein allzu großes Problem mehr. -- Dishayloo + 18:37, 17. Mai 2008 (CEST)

Warum nicht auf die "+/-"-Funktion verzichten und statt dessen einheitlich auf die Funktion der automatischen Textanzeige zurückgreifen, sobald die Maus darüber fährt? -- ^ηeonZERO  18:45, 17. Mai 2008 (CEST)

Das wäre für mich auch OK, ebenso wie der Vorschlag von San Jose. Wie wäre eine solche Lösung zu implementieren (also wo müssten welche JS-Funktionen gestrichen werden). Kann das mal jemand herausfinden und am Besten in seiner persönlichen Monobook.css und Monobook.js testen? -- Dishayloo + 19:02, 17. Mai 2008 (CEST)

Das Problem ist, dass eine reine :hover-Variante im IE frühestens ab Version 7 funktioniert (Hacks für den IE6 sind möglich, involvieren aber standardwiedrigen Code mit möglichen Kollateralschäden bei standardkonformen Browsern). Solang der IE6 noch einen nennenswerten Marktanteil hat, scheidet das IMO aus. Zumindest müsste man das "+/-" beibehalten, damit dessen Benutzer überhaupt eine Möglichkeit haben, an die Informationen zu kommen. Abgesehn davon halt ich es nicht für sinnvoll, Benutzer, die JavaScript deaktiviert haben, per CSS-Skripting oder sonstwie doch mit dynamischen Effekten zu belästigen, zumal man auch damit rechnen muss, dass die Browser ihr derzeitiges Fehlverhalten irgendwann fixen und :hover u.Ä. nur noch bei eingeschaltetem Skripting zulassen. --Floats1 21:01, 17. Mai 2008 (CEST)

Hmm, der alte IE kann aber auch gar nichts: kein before und after, kein position:fixed und also auch kein Hover.... hmpf. Hat halt viele Jahre auf dem Buckel. Gehört in den Ruhestand.

Wieso meinst Du hover sollte nur mit eingeschaltetem Scripting funktionieren? Hover ist eine normale CSS-Pseudoklasse, das hat nichts mit Scripting am Hut. -- Dishayloo + 21:45, 17. Mai 2008 (CEST)

@Floats1: Das mit dem deaktivierten Java und der "Belästigung durch dynamische Effekte" ist schon sehr an den Haaren herbeigezogen, meinst Du nicht? Wer sollte sich von der beschriebenen Funktionalität belästigt fühlen? Java wird eher deaktiviert, weil es sicherheitstechnisch bedenklich ist und weil man keine durch Java-Effekte auf die Spitze getriebene Werbung erhalten möchte. -- ^ηeonZERO  21:59, 17. Mai 2008 (CEST)

JavaScript an sich ist nicht sicherheitstechnisch bedenklich (und Java, was was völlig Anderes ist, auch nicht), sondern nur die Zugriffsmöglichkeiten auf bestimmte Sachen, die aber heute in der Regel eh standardmäßig deaktiviert sind bzw. teilweise einzeln regelbar sind. Ein gewisses Problem sind halt potenzielle zusätzliche Bugs, insbesondere wenn man seinen Browser nicht aktuell hält. Die Privatsphäre ist durch :hover genauso verletzbar, weil damit jede Mausbewegung auf einem beliebigen Server protokollierbar ist, und :visited ist z.B. als Cookie zweckentfremdbar. Mit rein deklarativem SVG ist noch viel mehr realisierbar, und mit proprietärer Technik wie XUL/XBL in Mozilla sowieso. Mit welcher Technik das jeweils konkret realisiert wird, macht für den Benutzer keinen Unterschied, außer dass Angreifer eher die einfachere Variante benutzen werden, solang sie fast überall funktioniert. Zumindest ein Teil der Leute, die JavaScript deaktivieren, tut das, um dynamische Effekte wie z.B. Popups generell zu verhindern. Aber die vorgeschlagene Variante ist ja nichts Anderes als ein Popup. Die Vorstellung, dass CSS generell "gut" und JavaScript generell "böse" ist, ist einfach falsch. Der IE6 war übrigens schon beim Erscheinen nicht sonderlich auf dem Stand der Technik, und selbst der IE8 wird den Rückstand noch nicht ganz aufholen. --Floats1 22:55, 17. Mai 2008 (CEST)

Nee, das ist komplett falsch. Erstens: Javascript ist eine Programmiersprache. Die ist an sich nicht böse oder gut. Aber unsignierte Programme von jedermann bei mir auszuführen macht mich schlicht nervös. Das tue ich nicht. Dann zu hover und visited: Davon bekommt der Server nichts mit, das wird komplett im Browser interpretiert. Das heisst, dass visited keineswegs ein Cookie-Ersatz ist und auch die Mausbewegungen werden bei hover nicht auf dem Server protokolliert. Auch bei Javascript wird Deine Mausbewegung nicht auf den Server übertragen, außer das Script überträgt das explizit. Diese Aussagen sind kompletter Mumpitz, tut mir leid.

Popups kann ich unabhängig von Javascript deaktivieren. Im Browser oder mithilfe von Privoxy. Ich habe aber nichts gegen Hover-Effekte. -- Dishayloo + 00:35, 18. Mai 2008 (CEST)

Schon eine simple HTML-Datei ist im Prinzip ein Programm, das vom Browser interpretiert wird, genauso wie JavaScript (das auch weder echten Maschinencode enthält noch Zugriff auf das Betriebssystem hat, sondern ebenfalls vom Browser interpretiert wird), bloß etwas weniger flexibel. Von :hover, :visited u.Ä. bekommt der Server schon was mit, wenn damit z.B. Hintergrundbilder eingebunden werden, und zwar bei entsprechendem Cache-Control bei jeder Änderung neu (siehe z.B. [3]). --Floats1 01:25, 18. Mai 2008 (CEST)

Gut, mit solchen Tricks ist das möglich. -- Dishayloo + 09:21, 18. Mai 2008 (CEST)

Guter Vorschlag, viel schöner :) --Mudd1 09:07, 13. Jun. 2008 (CEST)

[Bearbeiten] Verweise werden unterstrichen, wenn man eingeloggt ist

Ich habe festgestellt, dass Links auf andere Artikel und Seiten dann unterstrichen werden, sobald man sich in der Wikipedia einloggt. In dieser CSS-Datei steht zwar

a { text-decoration:none }

.. vielleicht überschreibt das eine andere Datei? Ich konnte den genauen Fehler noch nicht ausfindig machen.

Ich habe das Verhalten in Firefox und Opera getestet, andere berichten auch von diesem "Problem".
Ist das so beabsichtigt? --Diluculum 19:14, 28. Mai 2008 (CEST)

Ich kann dein Problem nicht nachvollziehen. Bin ich richtig in der Annahme, das bei dir die normalen Hyperlinks auf jeder Seite unterstrichen dargestellt werden, sobald du die Seite anschaust, aber dies auch erst nach dem anmelden? Das kann eigentlich nicht sein, da du diese css-Datei auch als IP bekommst, somit muss auch vorher schon alles unterstrichen sein. Bei mir wird ein link erst dann unterstrichen, wenn ich mit der Maus darüberfahre um ihn beispielsweise anzuklicken. Ich tippe daher, da es kein wikipedia problem ist, sondern eher etwas mit dem browers, den eine eigen css-Datei hast du ja nicht, somit sollte auch nichts überschrieben werden. Vielleicht mal Cache leeren? Der Umherirrende 22:02, 28. Mai 2008 (CEST)

Also es ist so: Ausgeloggt - Links sind nicht unterstrichen, Hover ist unterstrichen. Eingeloggt - Links sind immer unterstrichen (normal, hover, visited). Am Cache kann es nicht liegen, denn ich benutze Opera nur in Ausnahmefällen und habe Wikipedia damit noch nie besucht... aber das genannte Verhalten hat sich sofort eingestellt. Ich habe soeben noch den Internet Explorer getestet (Version 8 beta), selbes Verhalten. Fehler im Router, WLAN/LAN o.ä. schließe ich einfach mal aus, denn, wie gesagt, andere haben mir von den unterstrichenen Links auch berichtet. --Diluculum 17:01, 29. Mai 2008 (CEST)

Schau mal in deinen Spezial:Einstellungen, Reiter „Verschiedenes“. Da gibt es eine Option zu Linkunterstreichungen. — Raymond ^{Disk. Bew.} 17:13, 29. Mai 2008 (CEST)

Ja das war es, Danke...--Diluculum 20:55, 3. Jun. 2008 (CEST)

[Bearbeiten] CSS-Fehler?

Hoi, bei dem Reiter "Seite bearbeiten" fehlt bei mir die obere Linie. Ist das so gewollt, oder ein Fehler?

--Stummi(D|B) 14:08, 12. Jun. 2008 (CEST)

[Bearbeiten] Darstellungslösung auch für unangemeldete Firefox- und Opera-Benutzer sogar bei deaktiviertem JavaScript

Für die Skins „MonoBook“ und „Kölnisch Blau“ siehe „Benutzer Diskussion:ParaDox/monobook/revisionTag.js“ ^[1]. Für die Möglichkeit der Anwendung auch bei deaktiviertem JavaScript siehe dort den Abschnitt „Doku: Für unangemeldete Benutzer+innen (Greasemonkey)“ ^[1]. Vielleicht kann meinem (mMn nur Notlösungs-)Script auch der eine oder andere Lösungsansatz entnommen werden, um eine ganz allgemeine „JavaScript-FREIE CSS-Lösung“ zu entwickeln, welche auch andere Browser ^[1] „schlucken“.

• [1] als bzw. für Firefox und Opera

--ParaDox 11:22, 22. Jun. 2008 (CEST)

[Bearbeiten] Anecken von Linien an Bildern verhindern

Bezugnehmend auf die folgende Diskussion, könnte sich mal ein Wikipedia-Techniker des Problems annehmen? Wie könnte eine Lösung aussehen (?), danke! Das gleiche gilt auch für Tabellen, siehe hier. Könnte man die Matrix nicht so programmieren, dass zwischen der Tabelle und den Linien eine weiße "Lücke" von 1-2cm bleibt?--Interrex 14:07, 26. Jun. 2008 (CEST)

Eine „uralte“ Geschichte bei Bildern, siehe:

• „Wikipedia:Fragen zur Wikipedia/Archiv/2007/Woche 02#OptikBilder_JavaScript“

--ParaDox 14:49, 26. Jun. 2008 (CEST)

• Dort wird die These aufgestellt, es würde nicht funktionieren, es gebe unterschiedliche Browsereinstellungen etc... Ich habe mehrere Browser und jedesmal stößt die Linie im Artikel auf das Bild, ich denke nicht, dass es von der Einstellungen in den Browsern abhängt, sondern von der Matrix. Man sollte sie so programmieren, dass wenn die Linie ein Bild oder ein Tabelle "berührt", eine Lücke gelassen wird, zw. ihr und dem Objekt. Was machen die Franzosen richtig, was die Deutschen falsch machen? Es geht, nur wie?--Interrex 18:16, 26. Jun. 2008 (CEST)

Die Linien können nur entfernt werden, indem sie mit einer nicht transparenten Farbe übermalt werden. MediaWiki macht das sogar von Haus aus, indem ein weißer Rahmen um Thumbnails gemacht wird:[4]

div.thumb {
        border-style: solid;
        border-color: white;
}
div.tright {
        border-width: .5em 0 .8em 1.4em;
}

In der deutschen Wikipedia jedoch wird in der MediaWiki:Monobook.css der Rahmen wieder überschrieben und durch ein normalen transparenten Rand ersetzt:

/* Vermeide hässliche weiße Ränder bei Float-Objekten auf nicht-weißen Hintergründen. */
div.tright {
        border: none;
        margin: 0.5em 0 0.8em 1.4em;
}

In der französischen Wikipedia hingegen werden in fr:MediaWiki:Monobook.css die Rahmen mit der Standardfarbe des Namensraums eingefärbt:

/* bordure des thumb au memes couleurs que le fond */
.ns-1 div.thumb,
.ns-3 div.thumb,
.ns-5 div.thumb,
.ns-7 div.thumb,
.ns-9 div.thumb,
.ns-11 div.thumb,
.ns-13 div.thumb,
.ns-101 div.thumb,
.ns-103 div.thumb,
.ns-105 div.thumb{
border-color:#FFE;
}
 
.ns-4 div.thumb{
border-color:#F4F4F4;
}

Das französische Verfahren hat den Nachteil, dass fließende Thumbnails in eingefärbten Tabellen einen hässlichen weißen Rand haben:

Tabelle mit class="prettytable"

normales thumb

simuliertes thumb

Solche Tabellen werden in der deutschen Wikipedia leider häufig verwendet, weil thumb das gleiche ist wie thumb|right.

Das oben aufgeführt Beispiel löst dieses Problem, indem per JavaScript die Hintergrundfarbe des übergeordneten Objektes als Rahmenfarbe verwendet wird. Nur mit CSS lässt sich das nicht komplett sauber lösen. Es wäre aber möglich beide Verfahren zu kombinieren, indem das überschreiben bei der deutschen Wikipedia eingeschränkt wird: Statt für alle div.tright könnte nur problematische table div.tright, *[bgcolor] div.tright, *[style] div.tright überschrieben werden. --Fomafix 19:13, 26. Jun. 2008 (CEST)

Ich hätte eine Bitte an Dich, weil mich diese Linien doch stören (und nicht nur mich), wenn sie auf einen Rahmen (Bildrahmen, Tabellenrahmen) einfach so "knallen". Schau mal im Artikel Anna Jagiellonica, dort versuchte ich diese Linien mit {|align=right |} zu lösen, aber ich habe da viele Gegner und es droht sogar ein Editwar durch meinen Lieblings"freund" Benutzer:GDK. Könntest du das irgendwie machen (für die gesamte deutsche Wikipedia), dass zwischen den Ojekten und den Linien grundsätzlich eine Lücke bleibt?--Interrex 21:44, 26. Jun. 2008 (CEST)

Tabellen (und {| … |} sind auch Tabellen) gehören grundsätzlich nicht im Artikelraum um Bilder, nur um die Linien zu kürzen. Da hat GDK schon recht. Du kannst für Dich in Deiner Benutzer:Interrex/monobook.css mit CSS experimentieren, um den Bildern einen weißen Rahmen zu geben. Mit folgendem Code müssten Definitionen der Monobook.css wieder überschrieben werden und auf die main.css zurückgesetzt werden:

div.thumb {
        border-style: solid;
        border-color: white;
}
div.tright {
        margin: 0 0 .5em 0;
        border-width: .5em 0 .8em 1.4em;
}
div.tleft {
        margin: 0 .5em .5em 0;
        border-width: .5em 1.4em .8em 0;
}

Dann kannst Du meine oben vorgeschlagenen Erweiterungen testen. Wenn wir eine in allen Browsern funktionierende Methode gefunden haben, die vor allem die derzeitige Darstellung nicht beeinträchtigt, dann könnte die in die globale Monobook.css aufgenommen werden. --Fomafix 22:18, 26. Jun. 2008 (CEST)

Verstehe, mir geht es aber in erster Linie um eine "globale Lösung", keine, die "nur" mich zufrieden stellt. Und was ist eigentlich an der Tabellendefinition so schädlich, im Artikel ist sie so gar nicht sichtbar, kann hier keine Nachteile erkennen für den Artikel...--Interrex 22:39, 26. Jun. 2008 (CEST)

Weil damit die Barrierefreiheit zerstört wird. Ein Voicebrowser für Sehbehinderte wird durch diese Tabelle in die Irre geleietet. Das ist einfach zu viel Kollateralschaden für einen dekorativen Effekt. Und was Formafix meinte ist, dass Du erst eine Lösung in Deiner monobook.css testen kannst und wenn die einwandfrei funktioniert, kannst Du sie für die globale monobook.css vorschlagen. --GDK Δ 23:21, 26. Jun. 2008 (CEST)