MediaWiki Diskussion:Monobook.css/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

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

[[MediaWiki Diskussion:Monobook.css/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Monobook.css/Archiv#Thema_1

#coordinates

bitte anpassen

#coordinates {display:inline;
 position:absolute; z-index:1; border:none; background:none; right:12px; top:0.2em; float:right;
 margin:0 18px 0 0; padding: 0 0.1em 0 0; line-height:11px; text-align:right; text-indent:0; font-size:10px;
 text-transform:none; white-space:nowrap;
}

/* kleinen Abstand neben der Geookordinate wegen der Bapperl-Icons */ #coordinates a[href ^="http://"] { padding-right: 18px !important;}

→Diskussion

Die entsprechenden Änderungen an MediaWiki:Modern.css wurden schon vollzogen

Danke -- visi-on 14:26, 21. Nov. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: visi-on 01:15, 25. Nov. 2008 (CET)

Abstand Überschrift

In diesem Beitrag habe ich mein Problem geschildert. Durch einen temporären Fehler wird über der Überschrift ein Abstand gezeigt, der die ganze Überschrift nach unten drückt (siehe Bild: [1]). Der Fehler liegt in #siteNotice. Der Fehler wurde bereits bei BugZilla gemeldet (Bug 19219) und in der englischsprachigen Wikipedia behoben. Wär jemand so nett und fügt folgende Zeile in #siteNotice ein, bis der Fehler behoben wurde?

padding: 0 0.9em; /* bugzilla:19219 */

Im Voraus danke.--Totie (Diskussion) 18:08, 20. Jun. 2009 (CEST)

Keine Reaktion? :(--Totie (Diskussion) 08:59, 24. Jun. 2009 (CEST)

Ich denke, den tempoprären Fix können wir uns sparen. Im Code wurde der Fehler mit rev:51081 behoben und ich hoffe, er geht schnell live. — Raymond ^{Disk. Bew.} 09:13, 24. Jun. 2009 (CEST)

Andererseits, wie lange dauert es denn bis ein Update aufgespielt wird? Tage, Wochen, Monate? Es dauert nur wenige Sekunden um diesen Fix einzubauen und zu entfernen. Wo ist das Problem? :)--Totie (Diskussion) 23:12, 3. Jul. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 23:57, 18. Jul. 2009 (CEST)

Wäre es möglich, die Box mit id="contentSub" immer anzuzeigen, auch wenn leer, dann würde das Seitenlayout bei Weiterleitungen nicht "hüpfen". Für eine Antwort herzlichen Dank im voraus! --Uncopy 10:51, 6. Okt. 2009 (CEST)

<div id="contentSub"> wird immer angezeigt, ist nur leer, wenn das Lemma keine Weiterleitung ist. Mit

#contentSub { height:1em; }

hätte die Box immer die gleiche Höhe. Bei Lemma ohne Weiterleitung wird dadurch eine größere Lücke entstehen. Mir gefällt es besser wie es derzeit aussieht. Wenn Du es anders haben willst, dann trage es in Deine monobook.css ein. --Fomafix 11:38, 6. Okt. 2009 (CEST)

Danke für die prompte Reaktion. Ich meinte natürlich den Seiteninhalt unterhalb von h1, der hüpft. Dass man nun diese Idee sofort umsetzen würde hätte ich übrigens eh nicht erwartet. Aber mir gefällt es besser ist als Grund eigentlich zu dünn. Das Hüpfen stört in Bezug auf umflossene Elemente wie Navigationsboxen. So kann eine Seite ganz schön an Charme verlieren. Auf jeden Fall: Danke für die Nachhilfe in CSS :-) Grüße --Uncopy 14:19, 6. Okt. 2009 (CEST)

Scheint doch nicht zu funktionieren, dein CSS oben. :-( --Uncopy 14:32, 6. Okt. 2009 (CEST)

Oh sorry, ich sehe gerade, der Fehler lag bei mir. Es geht natürlich! Danke nochmals! --Uncopy 14:35, 6. Okt. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:37, 14. Okt. 2009 (CEST)

Hintergrund von class="NavPic"

Auf Nicht-Artikelseiten stört es, das hinter dem Bild in Navigationsleisten ein weißer Kasten ist. Ich halte es für sinnvoller hier die jeweilige Hintergrundfarbe zu verwenden. Ein transparent erzeugt nicht das passende Ergebnis, da dann der Kopf der Navigationsleiste hinter dem Bild erscheint und es sieht so aus, als ob das Bild darüber schwebt. Ist es möglich die Hintergrundfarbe dort hinzu bekommen? Ist dies sinnvoll? Der Umherirrende 21:01, 6. Okt. 2008 (CEST)

Das wurde hier schon mal angesprochen. Ich halte ein transparenten Hintergrund für schön, aber für problematisch, weil sonst der graue Streifen der der Titelleiste durch ein transparentes Bild zu sehen sein könnte. --Fomafix 21:09, 6. Okt. 2008 (CEST)

Ja, das Problem hatte ich auch erkannt, daher ist mein Vorschlag auch, das man die Hintergrundfarbe nutzt, dann scheint der Streifen nicht durch. Ist dies technisch überhaupt möglich? Der Umherirrende 22:09, 6. Okt. 2008 (CEST)

Das Thema gehört nach MediaWiki Diskussion:Monobook.css, denn unter MediaWiki:Monobook.css sind sie Hintergrundfarben für für Namensräume definiert. Mit folgender CSS-Definition würde das beschriebene Verhalten aktivieren lassen:

div.NavPic {
	background-color: #F3F3FF; /* ein leichtes blau */
}
.ns-0 div.NavPic {
	background-color: white;
}

Ich kann keine Nachteile erkennen und teste es gerade. --Fomafix 15:26, 22. Jun. 2009 (CEST)

Benutzer:Euku hat zunächst die Namensraumfarbe übernommen, hat dann aber die weiße Hintergrundfarbe für die Bilder entfernt. Der Bildhintergrund ist damit transparent und die Namenraumfarbe wird nicht mehr benötigt. Wenn es irgendwo Probleme mit dem transparenten Hintergrund durch durchscheinende Objekte gibt, könnte diese Lösung mit Namensraumfarbe wieder aktiviert werden. --Fomafix 11:17, 22. Feb. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 11:17, 22. Feb. 2010 (CET)

flaggedrevs_short

Die Definition .flaggedrevs_short ist (teilweise) nicht mehr wirksam, weil in http://de.wikipedia.org/w/extensions/FlaggedRevs/client/flaggedrevs.css seit heute die Definiton mit div.flaggedrevs_short geschieht. Der neue Rahmen ist ganz sinnvoll, weil ein Menü dazugekommen ist. Verloren gegangen ist nur der negative Abstand nach unten. Folgende minimale Definition würde meiner Meinung nach ausreichen:

div.flaggedrevs_short {
	position: relative;
	top: -33px;
	margin-bottom: -28px;
}

--Fomafix 13:45, 15. Jun. 2010 (CEST)

Weil derzeit das margin-bottom: -28px; überschrieben wird, aber das top: -33px; nicht, kommt es zu Darstellungsfehlern: Die Infoboxen werden nach unten verschoben und teilweise mit Fließtext überlappt. Bitte umgehend ändern. --Fomafix 20:21, 17. Jun. 2010 (CEST)

Danke für den Hinweis und fürs Nachhaken. Den z-index habe ich aber vorsichtshalber stehen gelassen. In MediaWiki:Vector.css ist er auch nur auf Probe draußen. Wenn es sich bewährt, kann er vielleicht überall weg (auch hier, dann aber hier auch an den Koordinaten usw.). Gruß --Entlinkt 20:37, 17. Jun. 2010 (CEST)

Den z-index drin zu lassen, war eine ganz gute Entscheidung, denn ohne z-index tritt ein ganz anderes Problem auf (betrifft nicht nur Vector, sondern alle Skins außer Monobook).

Lösungsvorschläge? z-index für die Prüfbox in Common.css aufnehmen oder position:relative aus den Bausteinen entfernen und eventuelle Probleme mit dem IE 6 in Kauf nehmen? Gruß --Entlinkt 21:20, 19. Jun. 2010 (CEST)

Weil das Problem auch Vorlagen betrifft, in denen position:relative nicht nur als IE-6-Workaround, sondern sinnvoll genutzt wird (z. B. Vorlage:Positionskarte und Vorlage:Lageplan), habe ich den z-index in Common.css aufgenommen. Der hier ist damit dann eigentlich überflüssig. --Entlinkt 04:41, 22. Jun. 2010 (CEST)

MiniWikiAtlas

Boxen wie div#mw-fr-revisiondetails, die über den Artikeltext eingeblendet werden, müssen mit z-index:1 gegenüber möglichen position:relative im Artikeltext gesichert werden. Bei den Boxen, die oben rechts positioniert werden, sehe ich die Notwendigkeit nicht. Helferlein wie MiniWikiAtlas müssen aber überprüft werden. --Fomafix 09:00, 22. Jun. 2010 (CEST)

Ich glaube, es ist einfacher, über Klassen als über IDs zu sprechen, weil in flaggedrevs.css alles über Klassen gestylt wird. Je nachdem, was unter Spezial:Einstellungen → Bearbeitungsberechtigung eingestellt ist, verhalten sich die Elemente unterschiedlich, indem sie andere Klassen (und teils eine andere, teils aber auch dieselbe ID) haben.

Problematisch ist in allen Skins das Element, das bei Seiten mit ungesichteten Versionen in #contentSub erscheint, wenn in den Benutzereinstellungen „Verwende kleine Symbole und wenig Text …“ aktiviert ist (div#mw-fr-revisiontag.flaggedrevs_short), genauer: dessen absolut positionierter ausklappbarer Teil (div#mw-fr-revisiondetails.flaggedrevs_short_details). Dieser ausklappbare Teil braucht und hat jetzt in allen Skins einen z-index.

In Monobook hat zusätzlich der immer sichtbare Teil einen z-index. Am immer sichtbaren Teil kann ein z-index nur in Monobook eine Wirkung haben, weil er nur in Monobook relativ positioniert ist (und erweckte den falschen Anschein, als brauche der ausklappbare Teil keinen z-index, aber nur, weil er den des immer sichtbaren Teils erbte). Soweit ich das sehe, ist der z-index hier irgendwann einmal an eine eigentlich ungeeignete Stelle gesetzt worden, an der er zufällig die gewünschte Wirkung hatte, und könnte entfernt werden (also Zustimmung). Gruß --Entlinkt 08:35, 23. Jun. 2010 (CEST)

Wie ich inzwischen erfahren habe, ist der z-index hier tatsächlich notwendig, weil der IE <= 7 nicht zwischen z-index:auto und z-index:0 unterscheidet, sondern beides wie z-index:0 behandelt. Als Konsequenz muss in der Praxis ein z-index, der eigentlich nur an einem Kindelement gebraucht wird, an das nächsthöhere positionierte Element gesetzt werden, also hat das hier schon seine Richtigkeit. In Common.css bestand dasselbe Problem. Gruß --Entlinkt 00:36, 24. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt 00:36, 24. Jun. 2010 (CEST)

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)

Mit Bug 26423 ist dieses Verhalten nun direkt in MediaWiki durch r79010 und r79011 umgesetzt worden und mit Version 1.17 aktiv gegangen. Die Definitionen hier können nun entfallen, siehe #MW1.17. --Fomafix 00:25, 19. Feb. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 00:25, 19. Feb. 2011 (CET)

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:[2]

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)

Prinzipell sollte es mit folgendem Funktionen:

/* sorgt dafür, das die Linie von Überschriften nicht bis zum Thumb laufen,
    färbe erst alle Namensräume, um danach den Artikelnamensraum zu überschreiben */
 div.thumb {
  border-style: solid;
  border-color: #F3F3FF;
 }
 .ns-0 div.thumb {
  border-style: solid;
  border-color: white;
 }

Das Problem ist nur, das die Abstände im IE7 (ca. 8mm) und FF2.0.0.14 (ca. 2mm) erheblich unterschiedlich sind, kann aber nicht sagen, woher das stammt. Ein weitere Nachteil ist, das die Linie jetzt nicht an Bilder heranlaufen, aber bei rechtsseitigen Tabellen die Linie heranläuft und dadurch das alles uneinheitlich wirkt. Für rechtsseitige Tabellen könnte man auf die CSS-Klasse float-right zurückgreifen, aber die ist auch nicht bei jeder rechtsseitigen Tabelle gesetzt. Daher wäre es sicherlich sinnvoll, keine (globalen) Veränderungen vorzunehmen. Der Umherirrende 10:25, 3. Jul. 2008 (CEST)

Mit Bug 26449 ist dieses Problem behoben. --Fomafix 23:00, 18. Feb. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 23:00, 18. Feb. 2011 (CET)

font-weight:bold;

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

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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 [3] wird die Vorlage Prettytable dort mehr als 6500 mal verwendet. Dagegen gibt es laut [4] 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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Das Portal:Punk verwendet nun seit über einem Jahr #punk nicht mehr. #punk sollte daher aus der MediaWiki:Monobook.css entfernt werden, damit diese unnötige Definition nicht in anderen Artikel verwendet wird. Oder gibt es noch irgendwo ein id="punk"? Spezial:Suche/id="punk" eignet sich leider nicht als Suche. --Fomafix 10:11, 7. Jul. 2008 (CEST)

Ich würde es generell für sinnvoll zu halten, die zu entfernen, da eine Extrawurst nicht für jedes Portal gelten sollte.

• Einbau1 und Einbau2
• Versuch und revert
• Versuch2 und revert2

Da es aber auch nicht im Portal verwendet wird, sollte es problemlos entfernt werden können. Mich würde auch interessieren in welcher Version es verwendet wurde. Ich habe nichts gefunden in den versionen nach dem Einbau. Der Umherirrende 11:22, 7. Jul. 2008 (CEST)

Im Portal:Punk wurde id="punk" am 15. Februar 2007 ausgebaut. Ältere Versionen des Portals würden nach entfernen des Codes aus MediaWiki:Commons.css schlechter lesbar sein. Das sollte aber inzwischen vertretbar sein. Wer häufiger ältere Versionen des Portal betrachtet kann sich die CSS-Definition in seine eigene CSS-Datei aufnehmen. In der globalen MediaWiki:Common.css sollte sie aber entfernt werden. --Fomafix 11:35, 7. Jul. 2008 (CEST)

Da es nicht mehr benötigt wird, so schnell raus wie möglich. Eine generische Heller-Text-auf-dunklem-Grund-Lösung sollte anders aussehen. --Elian Φ 19:44, 7. Jul. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Aktuelle Versionen von Firefox haben dieses Problem nicht mehr. --Fomafix 20:51, 19. Feb. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

Verbergen-Link überdeckt Shortcuts u.ä.

Der nachfolgende Code aus der aktuellen MediaWiki:Monobook.css

/* verhindert, dass der Verbergen-Link die Icons rechts oben verdeckt */
#mw-dismissable-notice td {
    vertical-align: bottom;
}

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

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)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

Zusammenfassung und Vorschlag

Datei:San jose entwurf.gif

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

WTF ... ist das der finale Zustand? Bei mir (mit aus Sicherheits- und Nerv-Gründen deaktiviertem JavaScript, FF 3.5.9) sieht's so aus: [6].

Spricht irgendetwas dagegen, den ganzen bürokratischen Sichtungskram oberhalb der Trennlinie zwischen Titel und Artikel zu plazieren? --79.218.196.148 13:14, 17. Jun. 2010 (CEST)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 20:51, 19. Feb. 2011 (CET)

MW1.17

Seit MediaWiki 1.17 können folgenden Definitionen entfallen:

Bug 26423 → r79010, r79011, r79086, r79091

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

/* Tabellenhintergründe transparent machen */
/* Vor allem auf Spezialseiten, da diese eine andere Hintergrundfarbe haben. */
/* Update 21. März 2008: Wurde mit [[rev:32269]] und [[rev:32270]] zentralisiert. */
 
table.searchResultImage,
table.fr-diff-ratings,
table.mw-specialpages-table,
table.TablePager_nav,
table#mw-search-top-table,
#mw-subcategories table,
#mw-pages table {
	background-color: transparent;
}

table#sv-software und table#sv-ext unter Spezial:Version, table.mw-listgrouprights-table unter Spezial:Gruppenrechte, table#mw-sitematrix-table unter Spezial:Liste der Wikimedia-Wikis und table.mw-tags-table unter Special:Tags sieht als normale wikitable auch besser aus und kann entfallen.

Die Tabelle table.mw-tags-table habe ich nicht gefunden. Vermutlich kann sie jetzt auch entfallen, weil seit MW1.17 nicht mehr table { background-color:white } gilt. --Fomafix 22:25, 18. Feb. 2011 (CET)

#siteNotice table kann auch entfallen, denn derzeit werden divs geschaltet und da stören die Hintergrundfarben auch nicht. --Fomafix 22:51, 18. Feb. 2011 (CET)

table.mw-tags-table findest du hier: Special:Tags. --UV 20:51, 19. Feb. 2011 (CET)

Danke. Ich habe sie in die Tabellen oben eingetragen. --Fomafix 20:59, 19. Feb. 2011 (CET)

Benutzer:32X hat aufgeräumt, hat aber table#sv-software vergessen zu entfernen. --Fomafix 10:20, 8. Mär. 2011 (CET)

erledigt. --Fomafix 08:48, 9. Mär. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 08:48, 9. Mär. 2011 (CET)

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)

Die Anfangsbuchstaben der Knopf-Beschriftungen sind zentral in MediaWiki inzwischen sprachspezifisch geregelt. --Fomafix 14:07, 27. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 14:07, 27. Jan. 2012 (CET)

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)

Auch fr:MediaWiki:Monobook.css enthält keine abgerundete Ecken mehr. --Fomafix 15:39, 27. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 15:39, 27. Jan. 2012 (CET)

Formatierung von <dt>

Bisher wird in einer Definition-List der obenstehende Begriff via main.css fett dargestellt, was im Augenblick zu erheblichem Unmut führt, weil dadurch unnötig viel 'Fetter Text' in den Artikeln auftaucht. IMHO ist der Begriff durch seinen kleineren Einzug schon hinreichend genug ausgezeichnet und von daher könnte die Fett-Darstellung via Monobook.css aufgehoben werden. --Gnu1742 09:56, 16. Okt. 2008 (CEST)

dt { font-weight: bold; }

ist Wikistandard. Ich sehe keinen Grund, warum in unserem Projekt davon abgewichen werden sollte. --Fomafix 14:03, 27. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 14:03, 27. Jan. 2012 (CET)

Problem mit dem css

Hallo! Ich bin Ihrer Freund von dem afrikanischen Wikipedia. Ich hab kurzlich die folgende css-Kode auf dem afrikanischen Wikipedia dargestellt:

/* Kategorien etwas schöner darstellen */
#catlinks {
	border: 0px;
	border-top: 2px dotted #aaaaaa;
}

Dies ist wirklich eine schöne Art, die Kategorien unter der Artikeln darzustellen. Es geht mein Verstand aber draussen, warum dieser Kategorienabteilung nicht auch so schön an andere Platzen dargestellt wird. Schau z.B. bei af:Wikipedia:Geselshoekie, im vergleich mit z.B. af:Holisme (Artikel) und af:Sjabloon:Saadjie (Vorlag) Es scheint, dass es nur dieser "Wikipedia"-Namenplatz ist, der nicht sein altes Kategorienline zu dem neuen "dotted line" verliert. Schauen Sie bitte am af: MediaWiki:Monobook.css‎‎ was fehlt. Kontakten Sie mich bitte an meiner afrikanischen Diskussionseite. Ich danke Ihnen! Adriaan90 22:14, 25. Mai 2009 (CEST)

Ah! Schauen Sie bitte auch hier: [7] − dies ist ja im Artikelnamenplatz, und trotzdem gibt es kein schönes "dotted line". Glaub es hat etwas zu tun mit dem "no redirect"? Ich versteh dies wirklich nicht − hilfen Sie mir bitte!Adriaan90 22:23, 25. Mai 2009 (CEST)

Auch an der Bearbeitungsfenster gibts kein schönes "dottet line" (doch - es gibt es doch - aber es ist ober der Kategorienabteilung, und nicht teil davon, wie es z.B. schön in af:Holisme ist.) Adriaan90 22:26, 25. Mai 2009 (CEST)

Eigentlich ist es kein Problem, hotcat.js macht das XD Adriaan90 06:57, 26. Mai 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 14:54, 27. Jan. 2012 (CET)

oldskinonly

div.oldskinonly {
	display: none;
}

kann entfallen, da in MediaWiki:Preferences-summary class="oldskinonly" nicht mehr verwendet wird. --Fomafix 13:54, 15. Jun. 2010 (CEST)

In Vector.css hatte ich vectorskinnot (das an derselben Stelle verwendet wurde und IMHO wirklich obsolet ist) bereits entfernt, aber oldskinonly bewusst stehen gelassen, weil ich mit der Entfernung aus MediaWiki:Preferences-summary nicht hundertprozentig einverstanden bin. Für die Nutzer der ganz alten Skins hat sich ja nichts geändert, ihre Skins sind immer noch veraltet. Der Klassenname ist IMHO auch geeignet, für andere Hinweise ggf. wiederverwendet zu werden. --Entlinkt 15:06, 15. Jun. 2010 (CEST)

Ich finde die Definition nicht ganz geeignet, weil sie alle anderen Skins – auch eigene – als veraltet definiert. Ein skinspezifisches Einblenden wie bei MediaWiki:Group-sysop.css fände ich flexibler:

span.skin-monobook { display: inline !important; }
div.skin-monobook { display: block !important; }

Verwendet werden kann diese Definition dann so:

<div style="display:none" class="skin-simple skin-standard skin-cologneblue skin-chick skin-nostalgia">Anmerkung für bestimmte Skins</div>

Anmerkung: Die CSS-Klasse skin-monobook wird bereits von MediaWiki an das body-Element gehängt. Die beiden Definitionen sollten sich aber wegen der Einschränkung auf ein HTML-Element nicht beeinflussen. --Fomafix 15:59, 15. Jun. 2010 (CEST)

Die umgekehrte Definition wäre auch möglich:

.not-skin-monobook { display: none; }

mit der Verwendung

<div class="not-skin-monobook not-skin-vector">Anmerkung für bestimmte Skins</div>

Wichtig ist, dass die Selektion der Skins und der Text in der gleichen Version vom Wikitext stehen. Was zu oldskin gehört kann sich im Nachhinein ändern und dann passt der Text und die Selektion eventuell nicht mehr zusammen.

Daher zunächst die Definition oldskin hier und in den anderen Skins entfernen. Wenn mal wieder eine Skin-spezifische Meldung benötigt wird, dann kann eine der beiden Vorschläge aktiviert werden. --Fomafix 13:42, 27. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 19:31, 27. Jan. 2012 (CET)

Versionsvergleiche verbessern

• HIERHER KOPIERT START (VON „Wikipedia Diskussion:Gesichtete Versionen“)

Ich wiederhole es einfach noch ein paar Mal, vielleicht hilft es.;-) Die Standardschriftgröße in Versionsvergleich ist viel zu klein, da ist es echt anstrengend zu arbeiten (ich vermute, dass die meisten Sichter monobook.css nicht haben, mit dem das besser ist).Dies zu ändern würde die usability imo erheblich verbessern und die Fehlerquote gering halten. Grüße --Septembermorgen 13:40, 21. Dez. 2008 (CET)

„Standardschriftgröße in Versionsvergleich ist viel zu klein“: Mein Tipp: Siehe in meiner monobook.css den Abschnitt:

• „/*** &diff=Versionsvergleich ***/“

Damit arbeite ich schon sehr lange sehr zufrieden. Gruß, --ParaDox/ParaDoxa 12:03, 22. Dez. 2008 (CET)

Ich auch und bin mit dieser Einstellung des Versionsvergleichs ebenfalls sehr zufrieden, deshalb bin ich ja auch der Meinung, dass dies allen Benutzern (nicht nur Sichtern) als Standard eingestellt werden sollte, da viele Wenigsichter diese Monobook.css-Einstellung nicht kennen oder nicht verwenden und es ist wirklich ein großer Vorteil nicht mit dem Standardversionsvergleich arbeiten zu müssen. --Septembermorgen 12:40, 22. Dez. 2008 (CET)

• HIERHER KOPIERT ENDE --ParaDoxa 13:43, 22. Dez. 2008 (CET)

Damit wird die Schrift ja noch kleiner (Verdana hat eh jeder, der auf Lesbarkeit Wert legt, als Standardschrift, und entfetten macht sie schmaler). Von den Farben krieg ich Augenkrebs (mag aber bildschirmabhängig sein).

Übrigens würd ich von background-image:url() abraten. Das heißt, dass Benutzer:ParaDox/monobook.css als Hintergrundbild genommen werden soll, was potenziell Probleme bereitet (leere (relative) URL heißt "selbe URL"; manche (ältere?) Browser laden fälschlicherweise die übergeordnete Seite, die nichtmal gecachet werden kann. Korrekt für "kein Bild" ist background-image:none. --89.55.21.74 07:49, 23. Dez. 2008 (CET)

Wie ParaDox' Einstellungen in Natura aussehen, kann ich mir schlecht vorstellen. Ich bin auf jedenfall mit den eigenen Monobook-Einstellungen: Benutzer:Septembermorgen/monobook.css sehr zufrieden und denke, dass sie als Standard recht gut geeignet wären, zumindest was die Schriftgröße betrifft. --Septembermorgen 00:56, 26. Dez. 2008 (CET)

So sieht es bei mit aus (siehe in voller Größe). --ParaDoxa 02:34, 26. Dez. 2008 (CET)

Ich denke mal, das ist erledigt. In der Zwischenzeit wurde auch am Versionsunterschied gedreht, so dass erstmal kein Bedarf bestehen dürfte. Der Umherirrende 20:44, 28. Jun. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:44, 28. Jun. 2012 (CEST)

MediaWiki 1.19

Wenn rev:105280 mit MediaWiki 1.19 live ist kann folgende lokale Definition entfallen:

/* Tabellenhintergründe transparent machen */
table.diff,
td.diff-otitle,
td.diff-ntitle {
	background-color: transparent;
}

--Fomafix 14:12, 27. Jan. 2012 (CET)

MediaWiki 1.19 ist live, aber rev:105280 ist vorerst mit rev:112750/rev:112763 rückgängig gemacht worden. --Fomafix (Diskussion) 09:44, 1. Mär. 2012 (CET)

Die letzten Änderungen am Versionsunterschied beinhalten wieder ein background:white, daher halte ich eine Entfernung für wenig hilfreich. Der Umherirrende 20:42, 28. Jun. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:42, 28. Jun. 2012 (CEST)

Hauptseite

/* Korrektur des oberen Rands auf der Hauptseite nach Entfernung des Redirhinweises */
.page-Wikipedia_Hauptseite div#content {
	padding: 1em;
}

sollte wie das Ausblenden der Überschrift in MediaWiki:Common.css auf body.action-view beschränkt werden, damit bei der Versionsgeschichte nicht der Abstand verstellt wird:

/* Korrektur des oberen Rands auf der Hauptseite nach Entfernung des Redirhinweises */
body.page-Wikipedia_Hauptseite.action-view div#content {
	padding: 1em;
}

--Fomafix (Diskussion) 10:51, 26. Jun. 2012 (CEST)

Es scheint aber nicht zu stören/zu wirken, weil auf #content ein padding mit 0px !important liegt, wo das allerdings her kommt, weiß ich gerade auch nicht. Der Umherirrende

Bei mir ist bei Monobook kein #content { padding: 0px !important }. Weder angemeldet, noch unangemeldet. Daher ist der Abstand auf der Hauptseite störend sichtbar, weil die Überschrift verrutscht. Woher kommt bei Dir das padding: 0 !important? --Fomafix (Diskussion) 21:55, 28. Jun. 2012 (CEST)

Scheint aus mediawiki.legacy.commonPrint zukommen, welche das Entwicklertool des IE8 wohl anzeigt, warum auch immer das media => print hier nicht richtig ausgewertet wird. Ich habe aber noch mal genauer geschaut und den kleinen Abstand entdeckt und nun entfernt. Der Umherirrende 22:08, 28. Jun. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:08, 28. Jun. 2012 (CEST)

CentralNotice

Die CentralNotice klebt mal wieder am oberen Rand und überlappt mit den Koordinaten bei Monobook. Diesmal hat das div direkt ein style="margin-top:0". Um dieses zu überschreiben kann das bestehende

div#centralNotice > * {
	margin-top: 1.9em;
}

durch

div#centralNotice > * {
	margin-top: 1.9em !important;
}

ersetzt werden. --Fomafix (Diskussion) 16:14, 3. Sep. 2012 (CEST)

Habe ich mal gemacht, wobei ich mich aber frage, warum da eigentlich immer mal wieder Korrekturen notwendig sind. Der Umherirrende 18:41, 3. Sep. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:41, 3. Sep. 2012 (CEST)

Abstand der centralNotice

Derzeit wird ein Abstand oberhalb einer eingeblendeten centralNotice folgendermaßen erzeugt:

/* Abstand der Box zu den positionierten Elementen oben rechts (WP:ABK, Geokoordinaten, Bapperl) */
div#centralNotice.expanded {
	margin-top: 1.9em;
}

Derzeit wird aber mal wieder eine centralNotice eingebaut, die expanded ist aber der darin enthaltene div-Container mit der CSS-Klasse siteNoticeWrapper ist mit style="display:none" ausgeblendet. Dadurch entsteht eine ärgerliche Leerzeile und der Seiteninhalt springt nach dem Laden nochmal nach unten.

Mit folgendem Code müsste sich das Problem beheben lassen:

/* Abstand der Box zu den positionierten Elementen oben rechts (WP:ABK, Geokoordinaten, Bapperl) */
div.siteNoticeWrapper {
	margin-top: 1.9em;
}

--Fomafix 11:16, 26. Jan. 2012 (CET)

Hast du denn schon eine böse Mail an den Veranwortlichen geschrieben, er solle sich um anständiges JS bemühen? Aber  Pro dafür, dass wir eine anständige Lösung bekommen. -- ✓ ^Bergi 19:03, 26. Jan. 2012 (CET)

32X hat’s wie gewünscht umgesetzt.

Derzeit wird mal wieder eine normale sichtbare Sitenotice eingeblendet. Diesmal heißt der innere Container aber nicht mehr siteNoticeWrapper, sondern mw-wmscholnotice. Damit wirkt der oben aufgeführte Abstand wieder nicht. Derzeit könnte der Abstand eingeblendet und kein Abstand ausgeblendet folgendermaßen erzeugt werden:

/* Abstand der Box zu den positionierten Elementen oben rechts (WP:ABK, Geokoordinaten, Bapperl) */
div#centralNotice {
	margin-top: 1.9em;
}

--Fomafix 16:58, 2. Feb. 2012 (CET)

Wie wärs mit div#centralNotice > *? -- ✓ ^Bergi 18:48, 2. Feb. 2012 (CET)

Wurde am 4. Februar 2012 von 32X umgesetzt. --Fomafix (Diskussion) 15:21, 14. Sep. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 15:21, 14. Sep. 2012 (CEST)

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)

Die aktuelle Position der gesichtet-Box scheint unproblematisch zu sein, weil seit Jahren stabil. Der Umherirrende 21:07, 7. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:07, 7. Jun. 2013 (CEST)

Markierung von Sprungzielen

Wenn man im Inhaltsverzeichnis Abschnitte gegen Ende der Seite anwählt, ist es sehr lästig, dass das Sprungziel überhaupt nicht hervorgehoben wird und man es immer erst mühsam suchen muss (gilt auch für manche Redirects und Links).

Mit folgendem Code wird eine Markierung gesetzt, die gut sichtbar sein sollte, ohne aber zu aufdringlich zu sein:

p>a:only-child:empty:target {
  float: left;  /* Hack, damit es in älterem Mozilla besser ausschaut */
  margin-top: .75em;
  position: relative;
  text-decoration: none;
  cursor: default;
}
p>a:only-child:empty:target:before {
  content: "\25ba\2009";  /*   wegen älterem Mozilla angehängt */
  position: absolute;  /* wird in :before erst ab CSS 2.1 verwendet */
  left: -1.05em;
  font-size: 1.5em;
  color: #c00000;
}

Funktioniert in Konqueror, Opera und neuerem Mozilla (ältere Mozilla scheitern an der absoluten Positionierung von :before, aber als Float schaut es auch nicht viel schlechter aus). Browser ohne CSS3-Selektor-Support ignorieren es einfach; wie es im IE8 ausschaut, weiß ich nicht (hab kein Windows). In Safari geht es vermutlich, nachdem es Konqueror kann.

Die Lösung ist nicht perfekt, weil sie nur für die (üblichen) Überschriften der 2. Ebene optimal passt, aber ohne Eingriffe ins DOM geht es nicht anders, weil sich im bestehenden DOM die Überschrift des angesprungenen Abschnitts nicht mit CSS adressieren lässt (Struktur ist <p><a id=anker></a><h2>...; man könnte den Ankern mit ECMAScript levelabhängige Klassen verpassen oder die Anker in die Überschriften verschieben oder in MediaWiki besseren Code erzeugen). --89.55.40.199 04:42, 12. Dez. 2008 (CET)

Kein Diskussionsbedarf? Dann würd ich drum bitten, den Code einzufügen. Oder testet ihr noch? --89.55.58.189 21:02, 15. Dez. 2008 (CET)

Das ist nicht IE massentauglich. Meld dich an und wirf den Code in dein persönliches Spezial:Mypage/monobook.css -- visi-on 02:29, 16. Dez. 2008 (CET)

Inwiefern ist es nicht "IE massentauglich"? Bis inklusiv IE7 wird es doch einfach ignoriert, und der IE8 ist momentan noch kein Massenprodukt, sondern im Betastadium (falls es da Probleme geben sollte).

Dauernd angemeldet die Wikipedia zu benutzen, kommt für mich nicht in Frage, weil es erstens zu kostenintensiv ist (auch wenn Geld für Wikimedia kaum eine Rolle zu spielen scheint) und ich mich zweitens zu Bearbeitungen doch immer wieder ausloggen (oder Accounts wechseln) müsste, nachdem ich kein zu großes öffentlich zugängliches Profil von mir erzeugen will.

Ich bin trotzdem in der Lage, den Effekt für mich clientseitig per User-Stylesheets zu erzielen, aber wenn ich nicht Andere teilhaben lassen mögen würde, bräuchte ich überhaupt nicht in der Wikipedia mitzuarbeiten. --89.55.58.189 03:58, 16. Dez. 2008 (CET)

In die globalen Stylesheets kommen in der deutschsprachigen Wikipedia eigentlich nur browserunabhängige Anpassungen, da diese keine solche ist, wird sich auch keiner darum bemühen. Ich kann mir nicht vorstellen, das angemeldet zu lesen (wesentlich) teurer ist, der traffic sollte ja der gleiche sein. Ein öffentliches Profil der Interessen entsteht durch IP-Edits nicht, aber man kann dafür die Herkunft herrausbekommen. Der Umherirrende 18:12, 16. Dez. 2008 (CET)

MediaWiki:Monobook.css enthält auch jetzt schon CSS3, das bis jetzt weder standardisiert ist noch vom IE unterstützt wird (Präfixselektor ^= bei den Koordinatenangaben). CSS ist per se browserabhängig, weil es von älteren und Textbrowsern gar nicht unterstützt wird und z.B. für grafische Browser andere Regeln gelten als für sprachbasierte.

Obiger Code ist nicht in dem Sinn browserabhängig, dass Browserfehler ausgenützt würden; er verwendet nur die in CSS vorgesehenen Mechanismen, um unterschiedliche Grade an Unterstützung zu berücksichtigen: Browser ohne CSS3-Support ignorieren die Regeln komplett; position für erzeugten Inhalt ist erst ab CSS 2.1 vorgesehn und wird z.B. von Mozilla vor Version 1.9.1 ignoriert, ansonsten ist das float im Prinzip weitgehend redundant. Wenn es in jedem Browser mit grundsätzlicher :target-Unterstützung (die ja bereits bei den Fußnoten verwendet wird) ungefähr gleich ausschauen soll (exakte Gleichheit ist wegen unterschiedlicher Zeichensätze unmöglich), kann man das position auch rausnehmen.

Traffic ist in den Wikimediaprojekten nicht der wesentliche Kostenfaktor, sondern die Auslastung der Datenbankserver. Anonyme Zugriffe können zu einem guten Teil aus den Caches bedient werden, ohne die Seiten neu erzeugen zu müssen. Eine gewisse Lokalisierbarkeit stört mich nicht. Bis vor Kurzem hat mein Provider (Freenet) die Adressen für telekomunabhängiges DSL ohnehin nicht regional vergeben, sondern aus einem deutschlandweiten Pool genommen, und die entsprechenden Tools geben bis heute entweder gar keine oder eine völlig falsche detailiertere Herkunft an. --89.55.61.2 21:58, 16. Dez. 2008 (CET)

7 Jahre später eine Antwort: Der vorgeschlagene Code (mit nicht weniger als drei Pseudoklassen hintereinander) wirkt heute abenteuerlich. Da das Markup zwischenzeitlich stark geändert wurde, geht das heute sehr viel einfacher. Trotzdem ist nicht erkennbar, weshalb eine Anpassung wie diese ausgerechnet für alle Benutzer des Monobook-Skins gelten soll (und nicht etwa für alle Benutzer überhaupt, oder nur für diejenigen, die es explizit wünschen). Deshalb archiviere ich den Abschnitt. --Entlinkt (Diskussion) 23:26, 25. Mär. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 23:26, 25. Mär. 2016 (CET)

Leichter Blaustich des Hintergrundes im Benutzernamensraum

Bei „Monobook“ ist mir im Benutzernamensraum der leichte Blaustich des Hintergrundes aufgefallen.

Stört mich nicht (könnte ich andernfalls sowieso mittels CSS ändern), aber aus Neugierde, was hat es eigentlich damit auf sich? --Wiisixtyfour (Diskussion) 01:56, 3. Mär. 2022 (CET)

Es ging wohl darum, kenntlich zu machen, dass diese Seiten keine Inhaltsseiten sind. -- hgzh 23:27, 3. Mär. 2022 (CET)

Wird in anderen Sprachversionen auch generell gemacht: In itWP ist etwa der WP-Namensraum grün, der Hilfe-Namensraum rot und der MediaWiki-Namensraum grau. --XanonymusX (Diskussion) 23:42, 3. Mär. 2022 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:22, 19. Apr. 2022 (CEST)