MediaWiki Diskussion:Vector.js/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:Vector.js/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Vector.js/Archiv#Thema_1

Editsection mit CSS

Wie wäre es, wenn statt

 <span class="editsection">[<a>Bearbeiten</a>]</span>

nur

<span class="editsection"><a></a></span>

mit

span.editsection:before { content: " ["; }
span.editsection:after { content: "]"; }
span.editsection a:before { content: "Bearbeiten"; }

erzeugt werden würde? Das hätte den großen Vorteil, dass beim Kopieren des Textes in die Zwischenablage (zumindest beim Firefox) die Bedienelemente nicht mitkopiert werden. Der Internet Explorer unterstützt content anscheinend erst ab Version 8[1]. --Fomafix 11:21, 17. Jun. 2010 (CEST)

Letzteres ist IMHO das Killer-Argument für diese Idee. Den 7er werden wir wohl noch supporten müssen.... --Guandalug 11:27, 17. Jun. 2010 (CEST)

Nachdem das sowieso per JavaScript im Browser erzeugt wird könnte da auch eine Browserweiche eingebaut werden. --Fomafix 11:29, 17. Jun. 2010 (CEST)

Man sollte keinen Code auf das Vorhandensein von Bugs stützen (auch wenn es momentan nicht nach einem schnellen Fix ausschaut). --84.151.12.60 04:50, 21. Jun. 2010 (CEST)

Mit Bug 34445 habe ich vorgeschlagen die Bearbeiten-Knöpfe mit

.editsection {
    -moz-user-select: none;
    -webkit-user-select: none;
    -ms-user-select: none;
}

gegen Selektieren und – wenn es die Browser unterstützen – auch gegen Kopieren zu schützen. Mit rev:111676 kommt es in MediaWiki 1.20.

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 19:40, 22. Feb. 2012 (CET)

Einleitungshelferlein funktioniert nicht mehr richtig

Die aktuellen Optimierungen waren etwas zu viel des Guten. Da jetzt nur noch Überschriften innerhalb des bodyContent gesucht werden, funktioniert das Einleitungshelferlein nicht mehr richtig. Bitte ändern in content. --TMg 10:38, 14. Jun. 2010 (CEST)

Das wundert mich jetzt etwas - was hat das Einleitungshelferlein mit den Bearbeiten-Links außerhalb des BodyContent zu tun? Aber wo ich das Teil schon sehe, das kann man auch mal etwas optimieren. Wird jedenfalls repariert. --Guandalug 11:05, 14. Jun. 2010 (CEST)

Die Frage ist etwas merkwürdig, denn der Sinn des Einleitungshelferleins ist gerade der, einen Bearbeiten-Links außerhalb des bodyContent zu erzeugen. Das Helferlein ist so optimiert, dass es möglichst wenig tut und vor allem keine Redundanzen enthält. Es macht deshalb nur ein wenig Vorarbeit und verlässt sich anschließend auf dieses Skript hier. Das wurde durch die jetzige Änderung unterbunden, was wie gesagt aber sehr leicht zu beheben wäre. --TMg 11:10, 14. Jun. 2010 (CEST)

Aaaah, das Gadget arbeitet anders als die PDD-Version im alten Monobook - JETZT wird's klarer. Sorry, ich hatte da was anderes im Sinn. Okay, dann reicht deine vorgeschlagene Änderung auch für den Anfang. --Guandalug 11:18, 14. Jun. 2010 (CEST)

Danke, jetzt funktioniert es wieder. Optimierungen lohnen sich da übrigens nicht, da das Gadget dem obigen Benchmark zufolge nur 2 ms benötigt. Die Schleife scheint nur zeitkritisch zu sein, in Wirklichkeit wird sie extrem zeitig abgebrochen. --TMg 12:40, 14. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 21:10, 22. Feb. 2012 (CET)

MW 1.18

Auf FzW wird es wohl etwas untergehen: Damit der Code weiterhin das tut, was er tun sollte, müsste wohl das float:none; entweder noch mit einem !important unterstrichen oder alternativ die Spezifizität das Selektors noch durch ein #bodyContent erhöht werden. --Schnark 11:58, 6. Okt. 2011 (CEST)

Ich hab mal die Alternative gewählt - das "!important" möchte ich der "letzten Ebene", also den Benutzereigenen CSS-Styles, vorbehalten. --Guandalug 12:16, 6. Okt. 2011 (CEST)

erledigt. --Fomafix 15:57, 22. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 15:57, 22. Feb. 2012 (CET)

topicon und firstHeading

Aus optischen Gründen gefällt es mit nicht, dass die Linie unter der ersten Überschrift durch das Topicon verkürzt wird. Vermieden werden kann das, indem die Zeile

h1.parentNode.insertBefore(icon, h1);

ersetzt wird durch

h1.insertBefore(icon, h1.firstChild);

Es könnten sich allerdings Skripte darauf verlassen, dass unter id="firstHeading" der Seitentitel inklusive Formatierungen von {{SEITENTITEL:…}} steht. Vielleicht sollten wir um ein separates span für den formatierten Seitentitel bitten. Das wäre auch sinnvoll für Sprache und Schreibrichtungsausrichtung des Seitentitels innerhalb von zusammengesetzten Texten wie bei der Versionsgeschichte: Beispiel --Fomafix 21:20, 21. Feb. 2012 (CET)

Ein solches betroffenes Skript wäre beispielsweise Benutzer:Complex/mnh-modern.js. Nach rev:105870 wird das Skript sowieso Probleme mit firstHeading haben. Dabei gibt es mit mw.config.get( 'wgTitle' ) eine viel einfachere und zuverlässigere Methode zum Abfragen des Seitentitels. --Fomafix 22:31, 21. Feb. 2012 (CET)

In der neuen Nachricht MediaWiki:Specialpage-helplink wird auch topicon verwendet, um ein Hilfe-Bildchen und -Text in der oberen Ecke anzuzeigen. Mit einer Verschiebung von vor der Überschrift nach in der Überschrift wird die Schriftgröße des Hilfetextes größer. --Fomafix (Diskussion) 15:50, 3. Mai 2012 (CEST)

Bei Monobook ist die Schriftgröße des Topicon deutlich kleiner, weil sie dort über font-size: 90% aus dem #bodyContent heraus erzeugt werden. Hier werden die Topicons aus dem #bodyContent heraus geschoben und haben daher nicht mehr font-size: 0.8em. Für reine Icons – was die ursprüngliche Idee war – spielt font-size keine Rolle. Wenn nun hier auch Text verwendet wird, dann sollte er meiner Meinung nach die gleiche Schriftgröße wie der normale Text im Body haben. font-size: 0.8em verändert die Schriftgröße relativ zum darüberliegenden Element. Wenn das Topicon in h1 ist, dann ist die Schriftgröße auch größer. Eine Alternative wäre font-size: 0.8rem, das aber erst von neueren Browsern unterstützt wird: https://developer.mozilla.org/en/CSS/length#Browser_Compatibility. --Fomafix (Diskussion) 09:37, 4. Mai 2012 (CEST)

Ein Verschieben des Topicon in das h1-Element hat ein weiteren Nachteil: Wenn die Überschrift mit einem Dreifachklick markiert wird und in die Zwischenablage kopiert wird, dann wird auch das Topicon mit Text und Titel mitkopiert.

Dass die Linie nicht durch das Topicon unterbrochen wird kann auch erreicht werden, indem das overflow: hidden für h1#firstHeading entfernt wird, bzw. auf overflow: visible gesetzt wird.

h1, h2, h3, h4, h5, h6 { overflow: hidden; } wurde gesetzt wegen Bug 26449. Bei der ersten Überschrift besteht das Problem nicht und kann #firstHeading { overflow: visible; } zurückgesetzt werden. Dies löst auch Bug 35430 für die erste Überschrift. --Fomafix (Diskussion) 11:41, 5. Mai 2012 (CEST)

Ich habe diesen Vorschlag unter Bug 35430#c4 gemeldet. Ein #firstHeading { overflow: visible; } ist besser als ein Verschieben des Topicon in die erste Überschrift. Bei meinem obigen Codevorschlag habe ich die Änderung daher wieder entfernt. --Fomafix (Diskussion) 12:00, 5. Mai 2012 (CEST)

Wurde in der Skin-Werkstatt bearbeitet. Der Umherirrende 19:27, 27. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:27, 27. Mai 2012 (CEST)

topicon bei RTL

Wenn die Benutzeroberflächensprache auf eine RTL-Sprache umgestellt wird, wird derzeit die erste Überschrift auch auf RTL umgestellt: Beispiel. Vielleicht ändert sich das mit Bug 34514 mal, aber solange sollen die absolut positionierten Elemente entsprechend mitgeflippt werden. Die Koordinaten werden bereits automatisch geflippt. Die topicons werden aber noch nicht geflippt. Damit diese automatisch geflippt werden muss folgendes geändert werden:

In MediaWiki:Vector.js muss folgendes entfernt werden:

icon.style.cssFloat = icon.style.styleFloat = "right";
icon.style.marginLeft = "3px";

und in MediaWiki:Vector.css muss folgendes aufgenommen werden:

div.topicon {
	float: right;
	margin-left: 3px;
}

Das display:block bleibt im JavaScript-Code, damit die Icons erst eingeblendet werden, nachdem sie durch JavaScript im DOM-Baum umgehängt worden sind. --Fomafix 15:20, 20. Feb. 2012 (CET)

Außerdem sollte das getElementsByClassName() nach mw:ResourceLoader/JavaScript Deprecations durch jQuery ersetzt werden. --Fomafix 15:20, 20. Feb. 2012 (CET)

Damit ergibt sich folgender Code:

/*
 * showTopicon
 * Funktion zum Anzeigen von Bewertungskästchen im rechten oberen Bereich des Artikels,
 * um exzellente bzw. lesenswerte Artikel, ausgezeichnete Bilder und dergleichen zu kennzeichnen.
 *
 * Abschaltbar für angemeldete Benutzer durch 'mw.config.set( 'dontShowTopicons', true );' in der eigenen vector.js.
 *
 * Der Code basiert auf der Lösung der frWP
 */
$( function () {
	if ( mw.config.get( 'dontShowTopicons' ) ) return;
	var h1 = document.getElementById( 'firstHeading' );
	if ( !h1 ) return;
	mw.util.$content.find( 'div.topicon' )
	.each( function ( index, icon ) {
		h1.parentNode.insertBefore( icon, h1 );
		icon.style.display = "block";
	} );
} );

--Fomafix (Diskussion) 10:26, 11. Apr. 2012 (CEST)

Mit jQuery kann das noch weiter vereinfacht werden:

$( function () {
	if ( mw.config.get( 'dontShowTopicons' ) ) return;
	mw.util.$content
	.find( 'div.topicon' )
	.insertBefore( '#firstHeading' )
	.show();
} );

Eventuell fehlt noch das Umdrehen der Reihenfolge. --Fomafix (Diskussion) 18:56, 5. Mai 2012 (CEST)

Zum Umdrehen der Reihenfolge habe ich bei jQuery nur diesen abgelehnten Bug gefunden: http://bugs.jquery.com/ticket/7411. Damit lässt sich die Reihenfolge umdrehen:

$( function () {
	$.fn.reverse = Array.prototype.reverse; // http://bugs.jquery.com/ticket/7411
	if ( mw.config.get( 'dontShowTopicons' ) ) return;
	mw.util.$content
	.find( 'div.topicon' )
	.reverse()
	.insertBefore( '#firstHeading' )
	.show();
} );

Was nun hier die „richtige“ Reihenfolge ist, ist Ansichtssache. Meiner Meinung nach kann auf das reverse() verzichtet werden. --Fomafix (Diskussion) 21:24, 5. Mai 2012 (CEST)

Die Änderungen in Vector.js und Vector.css sind umgesetzt. --Fomafix (Diskussion) 21:26, 28. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 21:26, 28. Mai 2012 (CEST)

Skript ist extrem langsam

Ist zwar in Monobook nicht anders, aber man könnte die extreme Zähheit von Vector zumindest etwas erträglicher machen, indem man dieses Skript optimiert (wenn es schon unbedingt überhaupt sein muss):

addOnloadHook(
  function () {
    if ( window.oldEditsectionLinks )
      return;
    var doc= document, root= doc.getElementById( "bodyContent" );
    var sty= doc.createTextNode( ".editsection{margin-left:.75em}" );
    var elt= doc.createElement( "style" );
    elt.type= "text/css";
    elt.appendChild( sty );
    doc.getElementsByTagName( "head" )[0].appendChild( elt );
    for ( var i= 1; i <= 6; ++i ) {
      var item, list= root.getElementsByTagName( "h" + i );
      for ( var j= 0, je= list.length; j < je; ++j ) {
        elt= (item= list[j]).firstChild;
        if ( elt && elt.className == "editsection" )
          item.insertBefore( item.lastChild, elt );
      }
    }
  }
);

Das halbiert annähernd die Ladezeit von Seiten wie Wikipedia: Usability-Initiative/Feedback (von knapp 10 Sekunden auf 5 auf einem Athlon 64 bei fix 1 GHz, 64 Bit, Linux, Firefox 3.6.6pre). Das bisherige Skript ist um einen Faktor 18 langsamer. --84.151.27.97 04:59, 13. Jun. 2010 (CEST)

Ich habe den Code noch mal etwas angepasst (apendCSS sieht einfach besser aus als das manuelle). Besten Dank für die Verbesserung. --Guandalug 12:27, 13. Jun. 2010 (CEST)

Die 5px, die jetzt als Abstand eingestellt sind, sind schon bei normalen Schriftgrößen recht knapp, aber bei großer Schrift nicht nur hässlich, sondern erschweren dann auch die Übersicht, weil sich der eigentliche Text nicht mehr richtig absetzt. Der Abstand sollte relativ zur Schriftgröße sein; die .75em von oben halte ich für angemessen. Noch besser wäre es u.U., margin-right bei der eigentlichen Überschrift zu setzen. Da würden .5em reichen (oder .25em, wenn man die 5px drin lässt). --84.151.27.97 17:45, 13. Jun. 2010 (CEST)

Das sah Kollege Entlinkt anders, daher will ich jetzt mal nicht einfach revertieren. Ist der Seitenaufbau denn jetzt wirklich erkennbar schneller? --Guandalug 17:50, 13. Jun. 2010 (CEST)

Der Edit ist so zu verstehen, dass ich es eleganter fände, denselben Wert zu nehmen, der aus http://bits.wikimedia.org/skins-1.5/common/shared.css kommt und benutzt wird, wenn dieses Skript nicht läuft. (Wenn 5px zu wenig sind, sind sie – IMHO – auch dann zu wenig, wenn nicht dieses Skript genutzt wird, also – IMHO – ein Fall für eine Änderung in shared.css). Ich persönlich fände eine Leerzeichenbreite angemessen (auch deshalb, weil dann, wenn dieses Skript nicht läuft und float:none gesetzt wird, so dass die Links links stehen, ein Leerzeichen zwischen den spans steht). 0.75em wären deutlich mehr als ein Leerzeichen. Eine Alternative wäre, wirklich ein Leerzeichen einzubauen und dann margin:0 zu setzen. Oder noch anders: Ein Leerzeichen plus die 5px aus shared.css (dann wären wir wieder näher an den 0.75em). Ein Leerzeichen fände ich auch von der Theorie her „logischer“, weil die eigentliche Überschrift (span class="mw-headline") und der Bearbeiten-Link (span class="editsection") jeweils Inline-Elemente sind und man im Fließtext auch ein Leerzeichen setzt, wenn man nicht möchte, dass Inline-Elemente aneinander kleben. Ein margin kann ggf. dazukommen. Gruß --Entlinkt 18:05, 13. Jun. 2010 (CEST)

Hmm. Dann also im Script ein Leerzeichen prependen? Sollte kein Problem sein. --Guandalug 18:33, 13. Jun. 2010 (CEST)

Ja, fände ich am logischsten, wenn das nicht zuviel Performance kostet: h2 (block) und darin zwei spans (inline) mit einem Leerzeichen dazwischen. So isses jedenfalls ohne Skript, und das Leerzeichen, das standardmäßig drin ist, hat, glaube ich, auch seinen Grund. Mit Skript wäre es dann dasselbe, nur die spans andersrum. Visuell dürfte das auch ungefähr wieder die 0.75em ergeben (Leerzeichen in der Schriftgröße der eigentlichen Überschrift + 5px vom Bearbeiten-Link). --Entlinkt 18:48, 13. Jun. 2010 (CEST)

Die Vorversion war zwar langsam, aber sie hatte das Leerzeichen, und das war auch ganz richtig so und ist nicht nur Theorie, denn wenn man zum Beispiel die Überschrift dieses Abschnitts in eine Textdatei kopiert, sollte es schon „… langsam [Bearbeiten]“ und nicht „… langsam[Bearbeiten]“ heißen. Mit der Schrift skalieren tut es auch problemlos. Die zusätzlichen 5px aus shared.css halte ich persönlich für überflüssig, habe sie jetzt aber trotzdem mal drin gelassen. Dass die nicht skalieren, halte ich für unbedenklich. Meine Empfehlungen wären deshalb, entweder lokal offen lassen und ggf. in shared.css skalierbar machen oder – wie die Vorversion und nach meinem Geschmack besser – lokal explizit auf 0 setzen. --Entlinkt 21:51, 13. Jun. 2010 (CEST)

Der Geschwindigkeitsunterschied liegt nicht im leerzeichen, sondern in der Schleife: Die Vorversion ging über alle span's, die neue Version beschränkt sich auf Überschriften. Von letzteren gibt es weniger. --Guandalug 22:13, 13. Jun. 2010 (CEST)

Ist mir mittlerweile klar. ;-) Im Übrigen finde ich dieses Skript eher fragwürdig. Die einzige objektive Existenzberechtigung ist IHMO, zu vermeiden, dass die Bearbeiten-Links unter rechts ausgerichtete Bilder rutschen und nicht mehr dem Abschnitt zuzuordnen sind, zu dem sie gehören. Dieses in Bug 1629 geschilderte Problem, das seit rev:1407 besteht, besteht weiterhin und führt in anderen Wikis dazu, dass Benutzer Bilder anders anordnen, bis es bei ihnen passt, was aber nicht zielführend ist, weil es dann nur bei Leuten mit anderer Bildschirmauflösung nicht mehr passt. Der dabei entstehende „Flattersatz“ der Bearbeiten-Links ist, äh, Geschmackssache. Der Modern-Skin löst das hier lokal durch linksbündige Anordnung mittels float:none. Der Verursacher ist das float:right in shared.css und betrifft alle Skins. --Entlinkt 22:41, 13. Jun. 2010 (CEST)

Na ja, die Links linksseitig der Überschrift zu haben halte ich für Layouttechnisch unschön (das verschiebt die Überschriften). Und dieses script tauscht halt die Überschrift und den Link. Schöne wäre es, diesen Tausch im Skin durchzuführen und dieses Script für die Gegenrichtung in ein Gadget zu schubsen, wenns denn unbedingt sein muss. --Guandalug 22:56, 13. Jun. 2010 (CEST)

Dieses Skript gibt es schon auch als Gadget: MediaWiki:Gadget-editsection-right, allerdings die langsame Version.

Aber mal wieder zurück zu den Abständen: In den Inhaltsverzeichnissen heißt es „Inhaltsverzeichnis [Verbergen]“ mit einem Leerzeichen dazwischen und ohne margin am [Verbergen]. Je mehr ich nachdenke, um so mehr habe ich den Eindruck, dass für [Bearbeiten] wirklich auch margin-left:0 gelten sollte. Das Leerzeichen, so groß wie eines in der Überschrift, sollte genügen. --Entlinkt 23:11, 13. Jun. 2010 (CEST)

DAS ist, wenn ich das richtig sehe, NOCH schlimmer. Im Monobook setzt das Monobook.js - Script die Bearbeiten-Links von ganz links nach (float) ganz rechts. Besagtes Gadget holt sie dann zurück rechts von der Überschrift.... --Guandalug 23:39, 13. Jun. 2010 (CEST)

Nein, in Monobook läuft es ebenso wie hier, das Skript wurde einfach von MediaWiki:Monobook.js hierher kopiert. Das HTML ist in allen Skins gleich (Links sind vor der Überschrift), shared.css auch (float:right für alle Skins), und ab da machen die Skins es lokal unterschiedlich (Modern lässt sie links und macht float:none, für Monobook und Vector ändert das Skript die Reihenfolge im HTML). Das Gadget können Monobook- und Vector-User einfach deshalb nicht benutzen, weil derselbe Code in Monobook und Vector standardmäßig läuft. --Entlinkt 00:00, 14. Jun. 2010 (CEST)

Okay, wo kamen dann vorhin die ganz rechts rumgammelnden Links her? Na egal, ich glaub dir mal ;) --Guandalug 00:05, 14. Jun. 2010 (CEST)

Die Bearbeitenlinks sind eine ganz heikle Sache, siehe 1, 2, 3, 4, 5, 6, 7 – jedenfalls ist von MediaWiki aus für alle Skins die Position rechts außen vorgesehen, lokal schrauben alle Skins auf die eine (Monobook, Vector) oder andere (Modern) Art daran herum.

Aber ich muss trotzdem nochmal mit dem margin nerven. Der margin am Bearbeitenlink zusätzlich zum Leerzeichen ist eine neue Nebenwirkung der (ansonsten sehr löblichen) beschleunigten Version. Monobook hat seit 2006 bis jetzt nur ein Leerzeichen, das Gadget (das nur Modern-User benutzen können) ebenso, Vector bis heute mittag ebenso. Ist mehr als das eine Leerzeichen hier wirklich nötig? --Entlinkt 00:41, 14. Jun. 2010 (CEST)

willkürliche Zwischenüberschrift

Erstmal enthält die aktuelle Version einen groben Bug (fehlende Klammern), der dringend repariert werden sollte, weil er u.U. ziemliche Auswirkungen haben kann.

Zur Performance: Das Hauptproblem war das direkte Setzen von style. Jede Zeile verursacht da potenziell (und in der Realität meist tatsächlich) einen Reflow, und das ist das Zeitaufwändigste überhaupt. Das direkte Suchen nach den Überschriften macht da sehr viel weniger aus. Ein weiterer Punkt ist, dass appendChild deutlich langsamer als das umgekehrte insertBefore ist, vor allem weil sich die Überschriften in der Regel wegen dem einfacheren Aufbau schneller umkopieren lassen als der komplexe Button. Das Leerzeichen als eigener Node ist schon sehr kostspielig, aber mit direkter Manipulation des vorhandenen Nodes fällt es nicht allzu sehr ins Gewicht (dazu muss man aber den Button nehmen, weil man sich nicht drauf verlassen kann, dass die eigentliche Überschrift mit einem Textnode endet).

Das Leerzeichen halte ich an dieser Stelle nicht für dringend notwendig, da Textbrowser eh vorher aussteigen und der Button beim Kopieren sowieso deplatziert ist. Eigentlich sollte man da .editsection::selection { display: none } haben, aber ::selection unterstützt das nicht und ist inzwischen ganz aus CSS3 gestrichen worden.

Zum Abstand: Die 5px sollten eigentlich auch ohne die Umkopieraktion in eine relative Angabe geändert werden, aber bei normaler Schriftgröße reicht diese Breite, weil es sich nur um einen Mindestabstand handelt und die Buttons normalerweise ohnehin weit abgesetzt sind. Hier ist aber ein Abstand der Breite eines Wortabstands in der Überschrift das Allermindeste, das noch keinerlei echte Absetzung bewirkt, die aber sinnvoll ist.

Das Inhaltsverzeichnis ist übrigens das zweitgrößte Performanceproblem, obwohl es da keine Schleife gibt und der Code nicht allzu schlecht ist.

Ich hab eine Testseite mit verschiedenen Codevarianten, die per Fragment wählbar sind, ins Netz gestellt. Nach dem Laden wird oben links die Zeit in Sekunden für das Skript und die gesamte Ladezeit angezeigt (insbesondere Reflows, die vom Skript verursacht werden, können asynchron sein und finden sich dann nur in der Gesamtzeit). Die veränderte Skriptdatei hab ich direkt ins Dokument kopiert; der entscheidende Code ist ab Zeile 628. Reloads (und das erste Laden) können die Messung verfälschen; man sollte die Links jeweils in einen neuen Tab kopieren, nachdem die Technik mit den Fragmenten auch dessen Wiederverwendung nicht erlaubt. Eine einzelne Messung ist wenig aussagekräftig, insbesondere wenn man seine CPU nicht auf eine feste Frequenz eingestellt hat.

• [2] Ohne Skript (MediaWiki-Standard)
• [3] Zusätzliche Optimierung mit statischer Kopie der Elementliste (hilft angeblich insbesondere dem MSIE, den ich hier unter Linux nicht hab)
• [4] Ursprüngliche Neufassung
• [5] appendChild statt insertBefore
• [6] Suche nach span
• [7] Aktuelle Neufassung (Klammer korrigiert)
• [8] Leerzeichen ohne eigenen Node
• [9] Dito, mit insertBefore
• [10] Leerzeichen außerhalb vom Baum eingefügt (nicht vorteilhaft)
• [11] Vorhandenes Leerzeichen recycelt
• [12] Alte Version

--84.151.12.206 06:16, 14. Jun. 2010 (CEST)

Erstmal sorry wegen des Klammerbugs. Bei den Leerzeichen möchte ich aber doch mal nachfragen. Es gibt an ganz verschiedenen Stellen der Oberfläche Links der Form „Irgendwas [Irgendwas anderes]“, und die haben als Abstand alle 1 Leerzeichen (und zwar ein umbrechbares) zwischen „Irgendwas“ und „[Irgendwas anderes]“ (keine Regelung des Abstands ausschließlich über margin oder über Leerzeichen am Anfang oder Ende von „Irgendwas“ oder „Irgendwas anderes“). Gefunden habe ich bisher:

• Inhaltsverzeichnis: <h2 style="display: inline;">Inhaltsverzeichnis</h2>" "<span class="toctoggle">[Verbergen]</span>
• Rollback: <span class="comment">Bearbeitungskommentar</span>" "<span class="mw-rollback-link">[Zurücksetzen]</span>
• Bearbeitenlinks ohne dieses Skript: <span class="editsection">[Bearbeiten]</span>" "<span class="mw-headline">Überschrift</span>. Leerzeichen wurde in rev:17078 eingefügt, als der Aufbau der Überschriften zuletzt grundlegend geändert wurde, und das gewiss bewusst und bewusst zwischen den spans.
• Bearbeitenlinks mit der Version des Skripts, das noch bei Monobook läuft: <span class="mw-headline">Überschrift</span>" "<span class="editsection">[Bearbeiten]</span>
• Seitenschutz-Logbuch: " schützte „"<a href="/wiki/Artikelname" title="Artikelname">Artikelname</a>"“ [edit=autoconfirmed]"

Wenn es noch mehr Links dieser Art gäbe, bin ich ziemlich sicher, dass sie genauso aufgebaut wären, weil es so auch sinnvoll ist, denn so hat jeder auf jeden Fall eine Leerzeichenbreite als Abstand, den er individuell mit CSS erhöhen kann. (Betrachten sollte man übrigens auch den Fall, dass der [Bearbeiten]-Link bei langen Überschriften auf die nächste Zeile umbrechen kann und meiner Meinung nach auch soll und dann keinen Abstand nach links haben soll – ist mir gestern auf verschiedenen Diskussionsseiten aufgefallen. Er soll sich schlicht so verhalten, als wäre er das letzte Wort der Überschrift.)

So wichtig das Optimieren dieses Skripts auch ist (auf MediaWiki Diskussion:Monobook.js gibt es übrigens auch Vorschläge, die in eine ganz andere Richtung gehen und bloß nie umgesetzt wurden), würde ich schon gerne vorher festlegen, was es tun soll und erst danach, wie es das tun soll. Was es tun soll, ist meiner Meinung nach das Umdrehen der beiden spans, aus denen die Überschriften bestehen, und sonst nichts. Zwischen diesen beiden spans steht aber nun mal von Hause aus ein Leerzeichen, das ich sehr sinnvoll finde und das zu opfern oder in das Innere eines der spans (und damit an eine Stelle, an die es nicht gehört) zu setzen dieses Skript IMHO nicht wert ist. Gäbe es nicht vielleicht die Möglichkeit, das zwischen den spans eh schon vorhandene, sinnvolle und an der ganzen Angelegenheit völlig unschuldige Leerzeichen an Ort und Stelle zu belassen (wiederzuverwenden) und einfach nur die beiden spans umzudrehen? Wenn nicht, würde ich schon die Frage stellen, ob dieses Skript überhaupt noch weiter aufrecht erhalten werden kann. --Entlinkt 12:54, 14. Jun. 2010 (CEST)

Danke für die letzte Änderung - das zweimalige Tauschen ist glaube ich die beste Lösung derzeit. Das script ganz zu entfernen dürfte die nächste Protestwelle auslösen..... Da wäre es vermutlich besser, man würde die Funktion dieses Scriptes einfach (tm) in den Skin reinbasteln..... ;) --Guandalug 17:33, 14. Jun. 2010 (CEST)

Der Zeilenumbruch ist in der Tat ein Argument für das Leerzeichen. Dass der Button mit margin-left etwas eingerückt ist, halt ich zwar eher für vorteilhaft (stattdessen könnte man margin-right bei der eigentlichen Überschrift ziemlich nebenwirkungsfrei setzen), aber ohne Leerzeichen geht die Trennstelle verloren. Andererseits klebt ein abgetrennter Button zu sehr an der Überschrift (das liegt daran, dass unvernünftigerweise line-height:1.5em statt line-height:1.5 für bodyContent gesetzt und damit die absolute Höhe vererbt wird).

Die Struktur ist ohnehin falsch. Der Button gehört nicht in die Überschrift (wo er beispielsweise von Suchmaschinen falsch interpretiert wird), sondern heraus (die jetzigen Überschriftelemente müssten also divs sein und die eigentliche Überschrift mit dispay:inline innen). Das ist aber eine Frage des vom Server generierten Codes; im letztlichen DOM ist die Semantik reichlich egal. Strukturell gehört ein Leerzeichen zum Button, da es ohne ihn keine Existenzberechtigung hat (und auch tatsächlich bei gesperrten Seiten nicht vorhanden ist). Technisch lässt sich aber das vorhandene Leerzeichen ohne nennenswerten Performancenachteil gegenüber dem Einsetzen im Button (jedenfalls bei Mozilla und Opera) recyceln:

        if (elt && elt.className == "editsection") {
          item.insertBefore(item.lastChild, elt);
          item.insertBefore(item.lastChild, elt);
        }

Direktes Umdrehen ist nicht möglich, weil childNodes readonly ist. Ich hab oben bei den Testcases diesen Fall ergänzt, außerdem den Fall ganz ohne Skript (das immer noch einen deutlichen Preis hat).

Wie der vom Server gelieferte Code genau ausschaut, ist ziemlich belanglos, weil der Zweck jedenfalls das Floaten nach rechts ist. Links steht der Button nur deshalb, weil sonst die Wahrscheinlichkeit höher ist, dass er bei beabsichtigter Anwendung (eben das Floaten nach rechts) unter die Überschrift rutscht. Insbesondere angesichts der Nachteile der Umsetzung seh ich eigentlich keinen Grund, überhaupt vom beabsichtigten Standardverhalten von MediaWiki abzuweichen.

Die Abstände der Buttons auf den Wartungsseiten sind ein völlig anderer Fall als die im Artikel, weil sie dort systematisch dazugehören. Beim Inhaltsverzeichnis ist der Fall dagegen analog; dort ist der Abstand auch zu klein. Eigentlich ist schon die Frage, ob man die Buttons im Artikel überhaupt standardmäßig sichtbar haben sollte. Nachdem Edits von unangemeldeten Benutzern inzwischen faktisch eh unerwünscht sind, wär es sinnvoller, sie für diese nur per Werkzeugleiste einblendbar zu machen. --84.151.12.206 17:58, 14. Jun. 2010 (CEST)

„Edits von unangemeldeten Benutzern inzwischen faktisch eh unerwünscht“ würde ich so nicht sagen. Ganz im Gegenteil, ich bin dir sehr dankbar dafür, dass du hier die Initiative ergriffen hast. Andernfalls würden die Berichte über Zähigkeit auf der Feedbackseite weitergehen und keiner wissen, woran es liegt. (Die Langsamkeit ist von Monobook her durchaus bekannt, siehe MediaWiki Diskussion:Monobook.js#moveEditsection und XPath, aber in der Umsetzung eingeschlafen.)

Zur Sache:

• Die Idee, das insertBefore für das Leerzeichen einfach noch ein zweites Mal zu machen, hatte ich jetzt auch. Jetzt sind wir fast wieder, wo wir angefangen haben. Sorge bereiteten mir Behauptungen auf diversen Webseiten, im IE funktioniere das nicht, weil er mit Textknoten, die nur aus Leerzeichen bestehen, falsch umgeht, aber das scheint (in diesem Fall zumindest) nicht zu stimmen.
• Mit einem margin-right an der eigentlichen Überschrift (mw-headline) könnte ich mich eher anfreunden, aber ganz nebenwirkungsfrei ist es auch nicht. Es kann dazu führen, dass eine Zeile, die umbrechen muss, an einer anderen Stelle umbricht, als sie es sonst würde. Solche Sachen bereiten mir immer Sorge (wenn’s schon eine relativ harmlose Nebenwirkung gibt, wer weiß dann, welche es sonst noch gibt).
• Zur grundsätzlichen Existenzberechtigung dieses Skripts: Ob die Bearbeitenlinks rechts außen (Standardfall ohne dieses Skript) oder im „Flattersatz“ stehen, ist m E. eine Frage persönlicher Präferenzen und damit eigentlich ein Fall für ein Gadget. Dieses Skript als lokalen Standardfall abzuschaffen, würde aber mit hoher Wahrscheinlichkeit zu Unmut führen (es gab ja sogar schon eine Art Meinungsbild deswegen, siehe oben). Deshalb und auch weil es Bug 1629 vermeidet und alle anderen Versuche, diesen Bug zu fixen, fehlgeschlagen sind, ist es wohl stressärmer, das Skript zu behalten.
• Struktur der Bearbeitenlinks überhaupt: Dein Vorschlag läuft darauf hinaus, rev:17078 zu revertieren, mit der aber Bug 4525 gefixt wurde. Das geht über den Zweck lokaler Anpassungen hinaus und wäre an anderer Stelle zu klären.
• Leerzeichen im span oder zwischen den spans: Ich hab's, wie zu Beginn gesagt, jetzt auf eine Weise zwischen die spans gesetzt, die es hoffentlich nicht wesentlich langsamer macht, und zwar aus zwei Gründen: Erstens ist das Leerzeichen so (zumindest bei h2 und h3, also in den meisten Fällen) größer, so dass man vielleicht auch ohne margins auskommt, die durchaus Nebenwirkungen haben. Zweitens ist so der Eingriff in die von MediaWiki gelieferte Struktur geringer, und das lässt mich ruhiger schlafen, weil ich lokale Anpassungen dieser Art insgesamt sehr kritisch sehe.

Gruß --Entlinkt 18:38, 14. Jun. 2010 (CEST)

Moment. Standardfall ohne dieses Script sind doch wohl die Links linksseitig der Überschrift, nicht rechts außen. Schreib mal in deine vector.js ein 'var oldEditsectionLinks = true' - damit deaktivierst du ja das script. DAS wäre default (also [Bearbeiten] Überschrift), nicht das rechts-außen (das sollte eh Monobook-Sondertüte sein, oder?)

Der IE versteht das hier anscheinend ganz gut (jedenfalls IE 7 und 8, den 6er teste ich aus Prinzip nicht mehr).

Prinzipiell könnten wir diesen Abschnitt als erledigt ansehen (alles weitere dürfte eh nur noch winzige Vorteile bringen) und an anderer Stelle weiter entschlacken. Hierfür sind gute Vorschläge gern gesehen. --Guandalug 19:12, 14. Jun. 2010 (CEST)

Standardfall ist für alle Skins [Bearbeiten] rechts außen. Wenn du mit Vector "[Bearbeiten] Überschrift" siehst, hast du noch ein altes CSS im Cache.

Die jetzige Version habe ich auch im IE6 getestet, klappt. Älter als IE6 teste auch ich nicht mehr. Gruß --Entlinkt 21:52, 14. Jun. 2010 (CEST)

Konkret steht das float:right in shared.css und der HTML-Code ist genau dafür konzipiert. So wird es auch in den meisten anderen Wikipedien tatsächlich dargestellt. --84.151.10.159 04:53, 15. Jun. 2010 (CEST)

Dass Edits von unangemeldeten Benutzern inzwischen eher unerwünscht sind, ist eine Tatsache, die man als IP neben der ausgeprägten Revertierungstendenz der Eingangskontrolle selbst bei eindeutigen Verbesserungen auch in Diskussionen ständig merkt (siehe dazu nur das aktuelle Vector-Feedback). Natürlich gibt es Ausnahmen, wie löblicherweise hier. Ähnliche Verbesserungsvorschläge von mir bei der Einführung der gesichteten Versionen sind aber weitgehend ignoriert worden, so dass die Implementierung der Hinweise bis zuletzt abartig schlecht war (wobei in solchen Fällen die Position der angemeldeten normalen Benutzer wohl auch nicht besser ist).

Dass der MSIE ein Problem mit redundanten Textnodes hat, kann ich mir gut vorstellen. Wenn er sie ignoriert, wird im Prinzip ein Node durch sich selbst ersetzt. Dieser Fall ist in der DOM-Spezifikation nicht eindeutig definiert, ich würd es aber so interpretieren, dass eine Exception geworfen werden sollte (der Node muss ja zunächst aus dem Baum genommen werden, womit die Referenz nicht mehr existiert). Tatsächlich tun Mozilla und Opera in solchen Fällen aber im Ergebnis gar nichts (was nicht heißt, dass keine Rechenzeit verbraten wird). U.U. wäre ein try/catch (um die ganze Schleife) angebracht, um größeren potenziellen Schaden zu verhindern. Meinen Konqueror (nicht ganz neu) kann ich nicht vernünftig testen, weil er bei Vector ohnehin aussteigt und mich mit Fehlermeldungen überhäuft (Grundfunktionalität ist aber vorhanden; auch das Skript hier funktioniert trotzdem).

Generell würd ich empfehlen, gerade bei solchen relativ riskanten Änderungen erst zu diskutieren und zu testen, und die Sachen erst danach freizuschalten (wobei man bei WikiMedia generell wenig Skrupel hat, alles am lebenden Objekt zu testen; vorher war die Wikipedia deshalb wieder mal ganz kaputt). Die Nebenwirkungen von margin-right sind eigentlich ziemlich klar abschätzbar, abgesehn von Browserbugs, die sich in erster Linie darin erschöpfen dürften, dass das ignoriert wird.

Das unerwünschte Verrutschen der gefloateten Buttons ist in CSS Prinzip. Um das zu verhindern, müsste es möglich sein, Floats mit unterschiedlicher Priorität zu definieren, so dass sie auch dann dargestellt werden können, wenn nachrangige noch nicht bedient worden sind. Das Problem tritt aber fast nur dann auf, wenn es im Artikel ohnehin ein Missverhältnis von Bildern und Text gibt; Fälle bei übergroßen gefloateten Infoboxen und Tabellen könnte man durch sinnvolle Anwendung von clear unterbinden.

Wenn es überhaupt eine Chance gibt, das Skript loszuwerden, dann in der jetzigen Umbruchszeit. Das sollte aber wo angekündigt (und gegebenfalls diskutiert) werden, wo es nicht ganz untergeht. Eigentlich ist es gerade für die, die es tatsächlich betrifft, ganz einfach, das Skript persönlich zu installieren.

Der sematisch korrekte Aufbau der Überschriften würde nicht den alten Stand wiederherstellen, aber natürlich müsste sowas in MediaWiki geklärt werden (was es mir aber nicht wert ist). --84.151.10.159 04:53, 15. Jun. 2010 (CEST)

Im IE 6–8 (ältere Versionen unterstützt MediaWiki selbst nicht mehr wirklich) funktioniert das – „funktionieren“ im Sinne von „das Leerzeichen landet zwischen den spans“, was dann wohl heißt, dass es korrekt als Textknoten erkannt wird, wo sonst sollte es auch herkommen. (Auf manchen Webseiten ist das IE-Fehlverhalten unspezifisch als „ignores whitespace“, auf anderen als „ignores newlines“ oder „ignores newlines and tabs“ beschrieben; wahrscheinlicher ist dann wohl eines der beiden letzteren).

Eine Nebenwirkung von margin-right wäre zum Beispiel, dass bei Überschriften, bei denen die eigentliche Überschrift gerade eben in die Zeile passt, der Umbruch nicht vor dem Bearbeitenlink, sondern vor dem letzten Wort der eigentlichen Überschrift stattfindet. Fehlt der Bearbeitenlink dann auch noch, weil die Seite geschützt ist oder __NOEDITSECTION__ genutzt wird, bricht sie um, obwohl sie es überhaupt nicht sollte, weil das CSS am Anfang immer zuschlägt. Visuell mag das nicht stark auffallen (um so weniger, je kleiner der Wert), aber ich sehe eigentlich nicht, weshalb dieses Skript das Layout von Artikeln beeinflussen sollte, bei denen es eigentlich gar nichts zu tun hat, auch wenn es im Regelfall nur wenig ist (aber bei sehr kleinen Auflösungen evtl. doch auffallen kann). Der geringe Abstand war übrigens gerade eine der Intentionen, die mit dieser Anpassung damals bezweckt wurden: Die Aufhebung der Trennung von Überschrift (Inhalt) und Bearbeitenlink (Bedienelement) sei eine Einladung, den Abschnitt auch wirklich zu bearbeiten (naja).

Bei der Position des Leerzeichens kann man geteilter Meinung sein, je nachdem, was man machen möchte. Möchte man zum Beispiel der eigentlichen Überschrift und dem Bearbeitenlink jeweils Hintergründe geben, würde ich schon erwarten, dass das Leerzeichen weder von dem einen noch vom anderen betroffen ist. Und ich halte diese Variante in dem Fall, dass die Elemente irgendwann einmal in MediaWiki selbst vertauscht werden (wurde mehrfach versucht und immer wieder verworfen), auch für die wahrscheinlichste.

Als Lösung für das Positionierungsproblem mit float:right wurde overflow:hidden versucht (rev:24168), aber wegen Browserbugs (IE/Mac, RTL in Firefox) gleich wieder verworfen. Lokal wäre das vielleicht sogar eine Option, weil wir von RTL nicht betroffen sind und IE/Mac eigentlich eh nicht mehr wirklich unterstützt wird.

Der Aufbau mit mw-headline und editsection im h-Element wurde in Kommentar 2 zu Bug 4525 als semantisch korrekt beschrieben (auch wenn ich nicht ganz sicher bin, ob das wirklich der Beweggrund für die Änderung war oder nur beiläufig fiel).

An konkreten Problemen mit der jetzigen Fassung sind bisher bekannt:

• Inkompatibilität mit MediaWiki:Gadget-Pfeil-hoch.js (gemeldet auf Wikipedia:Fragen zur Wikipedia).
• Die simulierte Überschrift in Vorlage:Dokumentation erscheint links, weil das Skript sie nur teilweise erfasst (CSS schlägt zu, aber Elemente werden nicht vertauscht). Problem der Vorlage?
• [...]

Gruß --Entlinkt 07:30, 15. Jun. 2010 (CEST)

Weil das Script jetzt nur die Überschriften nimmt, werden alle "Überschriftensimulationen" ({{Überschriftensimulation 4}} und dergleichen) ignoriert. Die Vorlage "Dokumentation" hängt aber spezifisch ein Span "editsection" davor....

Das Pfeil-hoch-Gadget scheint bei mir aktuell zu funktionieren.... muss ich noch mal in den Browsern testen. --Guandalug 08:59, 15. Jun. 2010 (CEST)

Das Pfeil-hoch-Gadget scheint auf den ersten Blick zu funktionieren, verhält sich aber anders. (Hätte ich hier den oberpeinlichen Klammerbug nicht eingebaut, würde es sich genau gleich verhalten; die Verhaltensänderung kommt durch die Nutzung von insertBefore statt appendChild.) Die Pfeile stehen nun nicht mehr zwischen Überschrift und Bearbeitenlink, sondern links der Überschrift, weil eben nicht mehr der Bearbeitenlink hinter die Überschrift, sondern die Überschrift mit einem insertBefore vor den Bearbeitenlink geschoben wird. Bei Nutzung des Gadgets erwischt aber erst das zweite insertBefore die Überschrift, das erste erwischt den Pfeil (der deshalb links steht) und für das Leerzeichen ist kein drittes mehr übrig, weshalb bei Nutzung des Gadgets Überschrift und Bearbeitenlink aneinander kleben. Noch lustiger ist es auf Seiten, auf denen es keinen Bearbeitenlink gibt (zum Beispiel die Vorschau, da isses mir gerade aufgefallen), dann steht der Pfeil nämlich plötzlich doch wieder rechts. Wirkt insgesamt extrem buggy.

Ich persönlich halte die Position links allerdings für gar nicht so schlecht, so stehen die Pfeile nämlich alle in einer Linie, sind dort meiner Meinung nach ebenso gut benutzbar, sehen aber ruhiger aus. Das Leerzeichenproblem könnte man ganz leicht umgehen, indem man auch dort insertBefore nutzt. --Entlinkt 18:46, 15. Jun. 2010 (CEST)

Die Überschriftemnsimulation ist allerdings ein Problem der dortigen Vorlage. --84.151.10.159 19:07, 15. Jun. 2010 (CEST)

Die Antwort auf die Frage „Problem der Vorlage?“ oben weiß ich durchaus selbst (natürlich tut die Vorlage etwas, das sie nicht soll und das auch nicht immer funktionieren kann, schließlich weiß sie nicht, ob die Seite, auf der sie eingebunden ist, geschützt ist oder __NOEDITSECTION__ enthält), gelöst werden sollte es aber trotzdem, ich weiß bloß nicht wie. Man könnte eine normale h2 draus machen und alle anderen Überschriften eine Ebene tiefer legen (Nebeneffekt: Neue Überschrift taucht als einzige der Ebene 2 im Inhaltsverzeichnis auf, außerdem Boteinsatz erforderlich). Oder man könnte es auch einfach entfernen. In dem Kasten unten steht ja schon „Diese Dokumentation befindet sich auf einer eingebundenen Unterseite“ mit einem Link auf die Unterseite. Besonders schwerwiegend ist das aber auch nicht. Kann warten, bis es jemandem auffällt, den es mehr stört.

Das Pfeil-hoch-Gadget bereitet mir da schon mehr Sorgen, weil es zeigt, dass der Wechsel von appendChild nach insertBefore mit Annahmen, die andere Skripte gemacht haben, bricht. Bei einem Gadget ist das kein so großes Problem, weil es auffällt oder gemeldet wird und korrigiert werden kann. Benutzerskripte sind da schon eher ein Problem. Einfach nach Monobook kopieren (was im Prinzip, andere Skripte außer vor gelassen, funktionieren würde) würde ich die jetzige Version dieses Skripts deshalb nicht, weil es eine unüberschaubare Fülle an Benutzerskripten für Monobook gibt.

Wenn die Pfeile links der Überschrift akzeptabel wären, wäre das Problem trivial zu lösen, indem man als Textknoten statt " ↑" einfach "↑ " nimmt und ihn nicht hinten, sondern vorn einfügt. Wenn er aber wie bisher zwischen Überschrift und Bearbeitenlink stehen soll, sehe ich eigentlich keine andere Möglichkeit, als ihn in die Überschrift (mw-headline) zu packen (was IMHO nicht ganz sauber, aber bei einem Gadget noch akzeptabel wäre). --Entlinkt 23:17, 15. Jun. 2010 (CEST)

Ich wär' dafür, die Pfeile generell nach "Links von der Überschrift" zu schubsen... --Guandalug 23:29, 15. Jun. 2010 (CEST)

Das eigentliche Problem ist, dass die Gadgets vor dem Hauptskript ausgeführt werden. Damit ist die Ausgangslage grundsätzlich undefiniert und man weiß nie, was man genau macht, wenn man das DOM nicht detailiert untersucht; die logische Reihenfolge ist umgekehrt. Mit appendChild macht man dann auch nicht das, was man eigentlich will. Wobei das Skript hier im Prinzip auch nur ein Gadget ist, das halt standardmäßig allen aufs Auge gedrückt wird. Also sollte man besser gleich ein richtiges Gadget draus machen; dann ist auch die Performance nicht mehr so wichtig, weil jeder selber entscheiden kann, ob er den Preis zahlen will. Für die Masse der unangemeldete Benutzer ist der Button ohnehin bestenfalls sekundär. Und am besten bugzilla:11270 (erneut) fixen. Wobei ohnehin die Frage ist, was die "unresolved issues" konkret sind, wegen denen der Fix revertet worden ist (dieses Skript hier vielleicht?). --84.151.10.159 02:52, 16. Jun. 2010 (CEST)

Dass die Gadgets vor den skinspezifischen Skripten ausgeführt werden, könnte Absicht sein, weil man so weitgehend skinunabhängige Gadgets schreiben kann. MediaWiki:Gadget-Pfeil-hoch.js funktioniert jetzt wieder in allen 9 Skins und packt den Pfeil *in* die mw-headline, um hier nicht zu stören. Warum das Skript hier? 2006 gab es noch keine Gadgets, damals musste man in die allgemeinen Skripte schreiben, was man praktisch findet. 2009 gab’s schon welche, aber dann sollte es andersrum sein. Ich habe das mal wahr gemacht (ein bisschen scherzhaft, aber auch ein bisschen ernst gemeint, denn in Modern sind die Bearbeitenlinks wirklich so herum, und das finden die Benutzer jenes Skins ganz normal und praktisch und bekommen gar nicht mit, dass es sowas wie float- und Performanceprobleme überhaupt gibt). Gruß --Entlinkt 06:01, 16. Jun. 2010 (CEST)

Wenn der MSIE Newlines im DOM ignoriert, arbeitet er u.U. sogar korrekter als Mozilla. Für HTML müsste die nämlich am Anfang und Ende von Elementen schon der Parser gemäß den SGML-Regeln entfernen (siehe z.B. [13]; die Darstellung ist inzwischen überwiegend gefixt, das DOM aber nicht). Bei XML schaut das anders aus, aber MediaWiki deklariert zwar die Seiten als XHTML, liefert sie aber als HTML aus. document.getElementById('toc').firstChild dürfte z.B. keinen Textnode liefern.

Die paar Pixel, ab denen bei margin-right früher umgebrochen wird, sind vernachlässigbar, zumal das Layout ohnehin nicht statisch ist. Potenzielle Hintergründe sind aber tatsächlich ein Grund dafür, das Leerzeichen separat zu haben. Korrekte Semantik für die Überschriften würd im Prinzip so ausschaun (wesentliches CSS inline dargestellt):

<div class="h2-container" style="font-size:1.5em; word-spacing:.25em">
<h2 id=Section style="display:inline; font-size:1em; word-spacing:normal">Section</h2
> <span class=editsection style="font-size:.667em; word-spacing:normal">[...]</span>
</div>

Wobei das Floaten nach rechts in der beabsichtigten Art das Umdrehen von h2 und span erzwingt. (Grad seh ich, dass dieser Code in bugzilla:11270 tatsächlich existiert.)

overflow:hidden wär tatsächlich eine Möglichkeit, war aber früher in CSS 2.1 widersprüchlich definiert, so dass das effektiv nur äquivalent zu einem clear:right in jeder Überschrift sein konnte. Die aktuelle Version von CSS 2.1 ist etwas anders, so dass das gewünschte Verhalten nun wirklich konform ist, wobei aber der Browser weiter freie Wahl zwischen verschiedenen Varianten hat. Außerdem gibt es potenzielle Nebenwirkungen, indem das overflow:hidden tatsächlich zu abgeschnittenen Überschriften führen könnte. --84.151.10.159 19:07, 15. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 21:06, 7. Jun. 2013 (CEST)

Icons oben rechts

Ich begrüße es, dass DerHexer so mutig war, diese Bildchen mit JavaScript einzubauen. Dauerhaft erspart bleiben sie uns realistischerweise nicht, und wenn sie schon sein müssen, ist JavaScript eine sauberere Lösung als position:absolute, das in den anderen Skins benutzt wird. Trotzdem habe ich folgende Dinge auszusetzen:

• Die Umsetzung beansprucht zusätzlichen Raum am Artikelanfang. Auf langsamen Systemen ist visuell wahrnehmbar, wie der Artikel um 15px nach unten rutscht, während das Skript ausgeführt wird. Auf schnelleren Systemen fällt das vielleicht nicht auf, aber der Leerraum vor der Überschrift tut es auf jeden Fall, und zwar unschön.
• Es gibt anscheinend keine Abschaltmöglichkeit.
• Es funktioniert nur bei exzellenten und lesenswerten Artikeln, obwohl es auch andere Vorlagen mit solcherlei Icons gibt, die auch in anderen Namensräumen benutzt werden. Einen Überblick bietet die Kategorie:Vorlage:mit absoluter Positionierung. (Ob wirklich alle diese Icons unterstützt werden müssen, ist natürlich auch eine Frage.)

Ich hätte folgenden Alternativvorschlag, der im Wesentlichen IconesDeTitre() aus fr:MediaWiki:Common.js entspricht:

var dontShowTopicons = false;

addOnloadHook(function() {
	if (dontShowTopicons) return;

	var h1 = document.getElementById("firstHeading");
	var bc = document.getElementById("bodyContent");
	if (!h1 || !bc) {
		return;
	}
	var icons = getElementsByClassName(bc, "div", "topicon");
	for (var j = icons.length; j > 0; --j) {
		h1.parentNode.insertBefore(icons[j-1], h1);
	}
	appendCSS(".topicon, #spoken-icon, #commons-icon { display: block; float: right; margin-left: 3px; }");
});

• Zusätzlicher Raum am Artikelanfang wird so nur beansprucht, wenn das Lemma sehr lang ist.
• Es ist mit .topicon, #spoken-icon, #commons-icon { display: none; } abschaltbar.
• Es unterstützt alle Icons, die in Monobook mit position:absolute funktionieren, aber auf eine andere Weise (mehrere Icons würde Monobook übereinander positionieren, dies hier nebeneinander; der Preis ist eine potenzielle Iconflut, auf die Verwendung der Klasse topicon müsste man entsprechend ein Auge haben).

Vorteile der jetzigen Umsetzung:

• Die Performance hängt nicht von der Länge des Artikels ab.
• Die Einschränkung auf bestimmte Aktionen schont die Performance anderer Aktionen (lange Versionsgeschichten zum Beispiel), erscheint mir aber etwas restriktiv (purge zum Beispiel fehlt, andere wären zu prüfen).

Vielleicht kann man beides irgendwie zusammenführen. Außerdem verweise ich auf Bug 23796 (ein wie auch immer geartetes Skript sollte keine Dauerlösung sein). Gruß --Entlinkt 02:57, 26. Jul. 2010 (CEST)

Vielen Dank für dein Review des Skripts! Die drei angesprochenen Probleme waren mir beim Aktivieren bekannt, dennoch schien es mir realtiv notwendig, ein eben solches zu ergänzen. Da ich selbst Monobook nutze, war mir dies gar nicht aufgefallen; erst als ich am Wochenende in einer Präsentation unter Vector darauf gestoßen bin, ergab sich mir die Notwendigkeit. Nun programmiere ich selbst aber nur hobbymäßig, und damit war es mir zum Beispiel leider nicht möglich, das Icon auf die gleiche Ebene zu setzen. Für dieses bat ich den Kollegen Guandalug um rat, der sich das Skript heute mal anschauen wollte. Ihm fiel dann auch auf, dass eine Abschaltfunktion fehlt – er dachte hier an ein einfaches Gadget, das eine Puffervariable liefert – und dass neben den beiden (in meinen Augen [auch für den Leser]) wichtigsten Bausteinen dort oben rechts noch weitere fehlen; vor allem exzellente Aufnahmen sollten da nicht hintanstehen. Dafür hätte ich mir aber aufgrund der Unkenntnis der Kategorie erst eine Liste machen müssen, was ob der vorangeschrittenen Zeit dann nicht mehr möglich war.
So ganz klar ist mir noch nicht, wann dein Skript genau was ergänzt, dies sollte ich nach dem Frühstück noch nachholen. ;o) Vielen Dank nochmal für deine Ideen, und natürlich kann und soll dies nur eine Übergangslösung sein, die es eigentlich gar nicht hätte geben sollen. Grüße, —DerHexer (Disk., Bew.) 10:44, 26. Jul. 2010 (CEST)

Für eine "Mischung" der beiden Scripte wäre ich wohl zu haben. Da die Icons schon (versteckt) im Text rumliegen, ist die französische Lösung gar nicht mal so unelegant (Verschieben der icons in den Titel, rechtsseitig schwebend). Die Abhängigkeit von der Textlänge ist unschön, aber meines Erachtens zu verkraften. Das "Ausschalten" via CSS halte ich für wenig empfehlenswert, denn es verhindert ja nicht die Ausführung des Codes, sondern nur die Anzeige des Ergebnisses - da wäre die (auch in der Funktion darüber schon praktizierte) Abschaltbarkeit via gesetzter Variable besser. Entweder dann via vector.js oder via Gadget (wobei für letzteres der Support dann auch beim Monobook angepasst werden müsste..... Hmmmmm).

Ich werde im Laufe des Tages mal ein wenig basteln (und die Abschaltbarkeit schon mal direkt einbauen - eigene Scripte testen, solange ein globales Script schon mitspielt, ist wenig erbaulich ;) ) --Guandalug 11:52, 26. Jul. 2010 (CEST)

Die Existenz dieser Icons ist einer Umfrage unter stimmberechtigten Benutzern zu verdanken; Leser wurden dazu nicht befragt. Unter „Sonstige Meinungen“ haben sich trotzdem zwei unangemeldete Benutzer geäußert, denen ich mich anschließen kann (ich persönlich halte sie für die aufdringlichsten, entbehrlichsten und selbstreferenziellsten der Dinge, die sich oben rechts angesammelt haben).

Genug gestichelt: Die Icons mit einer Klasse (solange nur die Lesenswert- und Exzellent-Vorlagen unterstützt werden, könnte es auch eine ID sein) zu versehen, fände ich schon ganz sinnvoll, selbst wenn man die Abschaltbarkeit irgendwie anders regelt. Fast alle Teile der Oberfläche haben Klassen und/oder IDs, auch wenn sie anfangs gar nicht unbedingt benötigt werden. Man weiß nie, welchen Anpassungsbedarf es gibt. Es könnte zum Beispiel sein, dass ein Icon blau auf transparentem Hintergrund ist (Beispiele: Vorlage:Schreibwettbewerb und MediaWiki:Sharedupload-desc-here) und ein Benutzer den Seitenhintergrund auch auf blau stellt; dann wäre eine Klasse nützlich, um den Icons einen weißen Hintergrund zu geben (vgl. Behandlung der Koordinaten im Skin Modern).

Wie stark getElementsByClassName wirklich von der Länge des Artikels abhängt, müsste man sehr genau prüfen. In den Browsern, die es nativ implementieren (alle gängigen außer IE 6 bis 8; der IE 9 wird es nativ unterstützen), sollte es eigentlich sehr effizient sein. Gruß --Entlinkt 23:02, 26. Jul. 2010 (CEST)

Ich habe grade mal noch das mit dem "Ausschalten" eingefügt - da kann man dann mit doShowTopicons = false; ind er eigenen vector.js die Funktion abklemmen. --Guandalug 09:19, 27. Jul. 2010 (CEST)

Sicher, dass das nicht mit var doShowTopicons = true; wieder überschrieben wird? Meine Alternative oben. Grüße, —DerHexer (Disk., Bew.) 09:58, 27. Jul. 2010 (CEST)

Ganz sicher - funktioniert bei 'linkFA' seit Jahren ;) --Guandalug 10:01, 27. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 21:06, 7. Jun. 2013 (CEST)

Bitte #bodyContent in #content ändern

Eingefügt wurde der Teil #bodyContent nach dieser Diskussion, nur leider konterkariert das diese Diskussion. Die Lösung ist glücklicherweise sehr einfach. Weitere Fehlerbehebungen stehen noch aus, siehe Wikipedia Diskussion:Helferlein/Einleitungshelferlein, aber ich will nicht zu viel auf einmal ändern. Das ist erst einmal das Wichtigste. --TMg 23:01, 19. Okt. 2012 (CEST)

Habe das mal geändert. --tsor (Diskussion) 23:09, 19. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 21:06, 7. Jun. 2013 (CEST)

Gadget-editsection-left & right

Mit diesen beiden Gadgets scheint (meiner subjektiven Wahrnehmung) einiges im Argen zu liegen (bzw. keine wirkliche Abstimmung zu hier zu geben), siehe: MediaWiki Diskussion:Gadgets-definition#Proposal for right edit links. Leider antwortet auf den zuständigen Seiten nicht wirklich jemand zuständiges (so dass ich mich nach 2 Jahren hierher durchgeschlagen habe Vorlage:Smiley/Wartung/:o ). -- ΠЄΡΉΛΙʘ 23:11, 5. Nov. 2012 (CET)

Meiner Ansicht nach ist mit den beiden Gadgets alles in Ordnung. Sie sind sehr stark vom verwendeten Skin abhängig und das kann verwirrend sein. Im Vector-Skin ergibt das eine Gadget gar keinen Sinn und das andere erweckt den Eindruck, dass dort links und rechts vertauscht wäre. Man könnte darüber nachdenken, die Beschreibungen anzupassen (also MediaWiki:Gadget-editsection-left und MediaWiki:Gadget-editsection-right), damit sie zum Verhalten passen, das die beiden Gadgets im Vector-Skin zeigen. Seiten verschieben oder Code ändern würde ich aber nicht. --TMg 18:45, 6. Nov. 2012 (CET)

Genau das wäre schon mal ein Anfang. Deine Feststellung des Vector-Skins deckt sich mit meiner. Also (wenn der Code nicht geändert wird) bleibt nur die Erwähnung in der Beschreibung in welchem Skin sie überhaupt (nicht) funzen?!? Die von dir erwähnte Änderung scheint ebenso ursächlich zu sein? (Wobei dieses die Funktionen der Links-Option wiederrum so interpretiert wie sie beschrieben sind - in Vector - daher müsstest du das Script anpassen...) -- ΠЄΡΉΛΙʘ 19:04, 6. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 21:06, 7. Jun. 2013 (CEST)

Unterstützung von Live Preview

Damit dieses Script auch beim Live Preview funktioniert sollte folgende Version übernommen werden:

mw.loader.using( [ 'user' ], function () {
	if ( mw.config.get( 'dontShowTopicons', false ) ) {
		return;
	}
	mw.hook( 'wikipage.content' ).add( function ( $content ) {
		// Remove existing topicons from previous call
		$( '#firstHeading' )
		.siblings( 'div.topicon' )
		.remove();
		// Move topicons from content to #firstHeading
		$content
		.find( 'div.topicon' )
		.insertBefore( '#firstHeading' )
		.show();
	} );
} );

Wenn die Topicons in (prepentTo) statt vor (insertBefore) #firstHeading verschoben werden würde, dann würde das Live Preview die eingefügten Topicons zwar automatisch löschen, aber Topicons im #firstHeading haben den Nachteil, dass sich die Icons verschieben und dass sie beim Selektieren mit einem Dreifachklick mitselektiert werden und beim Kopieren der Beschreibungstext mitkopiert wird. --Fomafix (Diskussion) 08:03, 17. Jan. 2014 (CET)

Erledigt --Fomafix (Diskussion) 17:03, 26. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 17:03, 26. Feb. 2014 (CET)

Toolbar-Hilfe

Hallo, könnten wir bitte die lokale Hilfe ein bisschen umbauen? Wie schon auf WP:FzW#Wikieditor angesprochen, bin ich mit der Einzelnachweis-Hilfe nicht ganz einverstanden. Laut dieser wird nämlich grundsätzlich jedem ref-Tag ein name zugewiesen, und nicht nur wenn es mehrmals vorkommt. Meine Beobachtungen zeigen einen deutlichen Anstieg dieser überflüssigen Attribute. Auf http://usability.wikimedia.org/wiki/Toolbar_customization steht wie man das macht, was hieltet ihr davon?
meint -- ✓ ^Bergi 16:23, 16. Jun. 2010 (CEST)

Mittlerweile gibt es zwei getrennte Punkte „Einzelnachweis“ und „Benannter Einzelnachweis“, anscheinend sogar ohne eine lokale Anpassung. --Entlinkt (Diskussion) 23:38, 25. Mär. 2016 (CET)

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

Lokal angepasste Version von resources/jquery/jquery.mw-jump.js

Aufgrund einer CSS-Regel in MediaWiki:Vector.css kommt es zu Barrierefreiheitsproblemen mit den "Wechseln zu:" Schnellinks (die nicht sichtbar sind). Die Links sollen sichtbar werden wenn sie im Fokus des Benutzers sind, sonst sollen sie unsichtbar bleiben (der Benutzer soll immer sehen können, wo im Moment sein Fokus liegt). Diese Funktionalität wird normalerweise von MediaWikis resources/jquery/jquery.mw-jump.js zur Verfügung gestellt, dieses funktioniert jedoch aufgrund der lokalen CSS-Regel hier nicht. Deshalb schlage ich vor, den folgenden Code zur Vector.js hinzuzufügen. Sollte es keine Einwände geben, werde ich die Änderung in wenigen Tagen selbst vornehmen. (Siehe auch Benutzer_Diskussion:Entlinkt#Barrierefreiheit_und_MediaWiki:Vector.css) Grüße, Hoo man (Diskussion) 21:12, 17. Aug. 2013 (CEST)

/**
 * Lokale Version von MediaWikis resources/jquery/jquery.mw-jump.js
 * Angepasst an unsere spezielle #mw-jump Regel in MediaWiki:Vector.css
 */
jQuery( function ( $ ) {
	$( '.mw-jump' ).on( 'focus blur', 'a', function ( e ) {
		// Confusingly jQuery leaves e.type as focusout for delegated blur events
		if ( e.type === 'blur' || e.type === 'focusout' ) {
			$( this ).closest( '.mw-jump' ).css( {
				top: '-9999px',
				position: 'absolute'
			} );
		} else {
			$( this ).closest( '.mw-jump' ).css( {
				top: 'auto',
				position: 'static'
			} );
		}
	} );
} );

Rückmeldungen:

1. Es ist zwar nicht schädlich, aber auch nicht nötig, die top-Eigenschaft zu setzen. Sie wird ignoriert, wenn position: static gilt. Dieser Teil kann gestrichen werden.
2. Das Problem mit der instabilen Koordinatenposition, weswegen die CSS-Regel in MediaWiki:Vector.css überhaupt existiert, wird hierdurch nicht gelöst, sondern nur verlagert: Jetzt „hüpfen“ die Koordinaten auf und ab, wenn sich der Fokus verschiebt.

Unter diesen Umständen wäre m. E. zu überlegen, ob man nicht doch lieber die Regel aus MediaWiki:Vector.css entfernt und die Koordinaten immer „hüpfen“ lässt. Dadurch wird das Problem für jeden sichtbar und der Druck vergrößert, es endlich ordentlich zu lösen. Es bringt nichts, immer kompliziertere Dinge anzusammeln, die das Problem doch nicht lösen, aber weniger sichtbar machen.

Die einzig vernünftige Lösung ist eine stabile Koordinatenposition. Diese kann nicht durch absolute Positionierung erreicht werden, sondern nur durch softwareseitige Unterstützung (vgl. Bug 23796). --Entlinkt (Diskussion) 15:32, 18. Aug. 2013 (CEST)

So, die „jump“-Links sind nun wieder auf MediaWiki-Standard und stattdessen sind die Koordinaten verschoben, was m. E. schlechter als vorher ist, aber wohl leider nicht anders geht, weil sich in dieser Ecke viel zu viele Dinge tummeln, für die eigentlich überhaupt kein Platz ist.

Es ist ganz klar, dass die Implementierung der „jump“-Links trotzdem totaler Murks ist: Auf ungesichteten Seiten bewirken sie dank unsinniger negativer Abstände, dass sich die Hinweisbox nach oben verschiebt. Daran werde ich aber nichts ändern. --Entlinkt (Diskussion) 21:27, 19. Aug. 2013 (CEST)

Trotz der (kleinen) Kollateralschäden bin ich froh, dass wir das endlich gelöst haben. Grüße, Hoo man (Diskussion) 20:19, 21. Aug. 2013 (CEST)

Mittlerweile ist bugzilla:23796 zu phab:T25796 mutiert und gefixt, aber ob wir das <indicator>-Feature für die Koordinaten nutzen können, ist (u. a. in Anbetracht der Textmenge von Vorlage:All Coordinates und Überlegungen zur Schriftgröße sowie Bedenken wegen zu vieler Icons in einer Zeile) fraglich und wird auf Wikipedia Diskussion:Technik/Skin/GUI/Top-Icons diskutiert.

Wie auch immer: Dieser Abschnitt ist jedenfalls erledigt. --Entlinkt (Diskussion) 23:48, 25. Mär. 2016 (CET)

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