MediaWiki Diskussion:Vector.js

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)

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.

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

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)