MediaWiki Diskussion:Common.js

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter MediaWiki Diskussion:Common.js/Archiv.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Interwiki-Links kommentieren

Liebe Fachleute, bei Wikisource gibt es eine sehr schöne Funktion, die es über die Vorlage Interwiki-Info ermöglicht,

• Interwiki-Links mit einem Kommentar zu versehen – dort in der Regel der Hinweis auf die Originalversion bei einer Übersetzung; in der Wikipedia könnte man z.B. bei Bedarf auf eine Version mit deutlich mehr Informationen hinweisen, insbesondere, wenn dies einmal nicht die englische Version ist, – sowohl als Service für Leser, die der betreffenden Sprache mächtig sind, als auch als Hinweis für weitere Wikipedianer, dass es sich lohnt, Informationen von dort zu übernehmen (bei "kleineren" Themen gibt es ja in der Regel in keiner Sprache einen "exzellenten Artikel");
• mehrere Interwiki-Links auf dieselbe Sprache durch einen zusätzlichen Hinweis voneinander zu unterscheiden – bei Wikisource dient dies vor allem dazu, verschiedene Übersetzungen des gleichen Werks zu unterscheiden; hier könnte man mit dieser Funktion bei komplexen Themen, die in anderen Wikipedias anders aufgeteilt sind als in der deutschen, mehrere Interwiki-Links auf dieselbe Sprache anlegen und diese für den Leser sichtbar unterscheiden.

(Am ausgiebigsten wird diese Funktion bisher bei der englischen Wikisource benutzt; hier gibt's eine Übersicht der Seiten, die sie verwenden.) Wie mir El Cazangero erklärt hat, wird das bei Wikisource durch die function interwikiExtra() in s:MediaWiki:Monobook.js ermöglicht. Ich fände es schön, wenn man diese Funktion auch in das Wikipedia-JavaScript übernehmen könnte. --Daniel Bunčić 07:20, 31. Jan. 2007 (CET)

PngFix

Bei en:MediaWiki:Common.js gibt es eine Funktion PngFix mit der beim Internet Explorer 6 durch einen Workaround transparente PNGs beigebracht werden. Bisher werden beim Internet Explorer 6 transparente PNGs oder aus SVG erzeugte PNGs immer mit weißem Hintergrund dargestellt, wie bei folgendem Bild zu erkennen ist:

Wäre es sinnvoll diesen Workaround zu übernehmen um damit eine einheitliche Darstellung bei allen Browsern zu erreichen? --Fomafix 09:23, 14. Nov. 2007 (CET)

Der Quelltext sieht ja nach einem ganz seltsamen Hack aus. Aber wenn es funktioniert, auf jeden Fall pro. --Revolus Echo der Stille 09:34, 14. Nov. 2007 (CET)

Hat das hier sonst noch jemand gelesen? Wo sollte das angesprochen werden, damit es jemand liest? --Fomafix 21:59, 25. Nov. 2007 (CET)

Auch hier wird es gelesen.--Τιλλα 2501 ^± 22:01, 25. Nov. 2007 (CET)

Hast du, Admin, vielleicht auch vor das aufzunehmen? --Revolus Echo der Stille 00:27, 26. Nov. 2007 (CET)

Und wie sieht es danach mit dem IE6 aus?--Τιλλα 2501 ^± 00:46, 26. Nov. 2007 (CET)

Danke, bei meinem Internet Explorer 6 mit aktiviertem JavaScript wird das obige Bild nun wie bei den anderen Browsern ohne störenden weißen Hintergrund angezeigt. --Fomafix 09:22, 26. Nov. 2007 (CET)

Die Funktion löst in der Vorlage:Lageplan einen Darstellungsfehler aus. Ich zweifle ohnehin an der Sinnhaftigkeit dieses Hacks einerseits (hat nicht inzwischen fast jeder den Internet Explorer 7?), vor allem aber an seiner Qualität (müssen JavaScript-Quelltextzeilen nicht mit ; abgeschlossen werden?). Ich würde daher empfehlen, die Funktion wieder zu entfernen. Alternativ sollte bitte an der Stelle, wo bereits die fontSize auf 0 gesetzt wird, zusätzlich die Zeile outerSpanStyle.lineHeight = "0"; eingefügt werden. Das behebt den beobachteten Darstellungsfehler. --TM 20:53, 5. Jan. 2008 (CET)

IMO hat nicht jeder Lust von Schrott (IE6) auf Scheiße (IE7) zu updaten (oder kein ausreichend leistungsfähiges System) HardDisk ^{rm -rf} 21:17, 21. Mär. 2008 (CET)

Über ein jahr her, das soltle wohl auch erledigt sein? --Guandalug 08:43, 9. Jul. 2009 (CEST)

Bei en:MediaWiki:Common.js ist das inzwischen durch

    if (navigator.appVersion.substr(22, 1) == "6") {
        importScript("MediaWiki:Common.js/IE60Fixes.js")
    }

auf eine separate JavaScript-Datei für den IE6 ausgelagert worden. Diesen Vorschlag kann ich nur empfehlen. --Fomafix 09:26, 9. Jul. 2009 (CEST)

Sortierschlüssel bei Tabellensortierung

Ich habe eine neue Version der Vorlage:SortKey geschrieben, die in sortierbaren Tabellen verwendet wird (die bisherige Version benutzt ein unschönes, per CSS "verstecktes" <Span>-tag). Allerdings ist dafür eine Änderung des Sortiercodes nötig; eine der Funkionen aus wikibits.js muss überschrieben werden. Der nötige JS-Code und ein Beispiel sind auf Benutzer:Dapete/SortKey/Beispiel zu finden. Bei der Diskussion in der Vorlagenwerkstatt kamen keine Einwände. Falls irgendwas unklar ist, bitte melden. --Dapeteおい 17:24, 20. Mär. 2008 (CET)

Drop down

Ich würde gerne längere Tabellen in Artikeln nur auf Anforderung des Lesers anzeigen. In der en.wp gibt es dazu eine "collapsible" funktion. Könnten wir die hier auch bekommen?--WerWil 14:26, 1. Feb. 2009 (CET)

(Zum Hintergrund zu dieser Anfrage siehe Wikipedia Diskussion:Tabellen#Ausklappbar. --W_I^KImaniac 14:48, 1. Feb. 2009 (CET))

Geht nicht? Oder ist unerwünscht?--WerWil 21:29, 12. Feb. 2009 (CET)

Meiner Meinung nach unerwünscht, da Benutzer-unfreundlich. Stichwort #Screenreader', Stichwort' ausdrucken'. --Guandalug 12:19, 1. Jul. 2009 (CEST)

Gibt's teilweise trotzdem, beispielsweise in Hansa Rostock. --Leyo 15:50, 3. Aug. 2009 (CEST)

Ja, oder bei Episodenlisten. Macht die Sache nicht schöner... oder erwünschter. Wie gesagt, meine Meinung. --Guandalug 15:54, 3. Aug. 2009 (CEST)

Die Benutzerunfreundlichkeit kann ich nicht erkennen. Manche Liste liefert für den Textfluss nicht notwendige Hintergrund- oder Zusatzinformationen, reißt aber den Artikel massiv auseinander. Wenn der Benutzer, dann entscheiden kann ob er sich das ansehen will oder nicht, dann ist das für mich ein erheblicher Komfortgewinn.--WerWil 20:04, 6. Sep. 2009 (CEST)

IE60Fixes.js

Es gibt ein Skript für IE6 um das fehlerhafte Verhalten von pngs zu beheben. Dies wurde unter Wikipedia:WikiProjekt Vorlagen/Werkstatt/Archiv 2009/1#Problem mit der Anzeige von SVG-Dateien angesprochen. Solange es nicht durch MediaWiki selber (bugzilla:12405) gelöst wird, sollte es lokal für die deutschsprachige Wikipedia zu Verfügung gestellt werden. Für das lokale Handling müsste en:MediaWiki:Common.js/IE60Fixes.js importiert/kopiert werden und ein Abschnitt in die Common.js ergänzt werden:

//Import scripts specific to Internet Explorer 6
    if (navigator.appVersion.substr(22, 1) == "6")
    {
        importScript("MediaWiki:Common.js/IE60Fixes.js")
    }

Der Name der Seite kann auch anders gewählt werden. Vielen Dank. Der Umherirrende 20:00, 15. Feb. 2009 (CET)

*Seitenhieb in 3 … 2 … 1* Jens Ihlenfeld: Der IE6 soll sterben. golem.de, 19. Februar 2009, abgerufen am 21. Februar 2009: „Wieder einmal sammeln sich aktuell Webmaster, um dem alten Microsoft-Browser den Todesstoß zu versetzen.“  :-P --Revolus Echo der Stille 02:08, 21. Feb. 2009 (CET)

Ich kann den Webentwicklerfrust auf den IE6 und den Boykottaufruf sehr gut verstehen. Aber das hilft uns hier nicht viel weiter: Der unerfahrene PC-Nutzer ("PC ist ein Gerät wie eine Waschmaschine") hat mit seinem IE6 (bisher) überwiegend keine Probleme, auch nicht, wenn er einfach etwas bei bei Wikipedia nachschlagen will. Bei manchen Seiten (aber nur bei deutschen, hier wieder unser Beispiel) sieht halt dies und jenes sehr merkwürdig aus. Wie soll dieser Nutzer aber ahnen, dass dies an seinem inzwischen veralteten Browser liegt? M.E. gibt es folgende Lösungsmöglichkeiten:

• Wir wollen die Leute vom IE6 wegbekommen. Dann müssen wir (zumindest bei bekannt problematischen Seiteninhalten) eine Anzeige generieren à la "Wenn Sie sich an auf dieser Seite unzulänglich dargestellten Grafiken stören, empfehlen wir Ihnen, einen neueren Browser zu verwenden" mit Link zu "Wie geht das". Genau diesen Ansatz gehen auch die aktuellen IE6-Boykotteure (man betrachte z.B. diese Seite mit dem IE6).
• Alternativ bleibt eigentlich nur die weitere Unterstützung des IE6, zumal für das hier diskutierte Problem die Lösung in Wikipedia bereits umgesetzt wurde, nur eben nicht in der deutschen.

Wenn keine von diesen beiden Lösungsmöglichkleiten gewählt wird, lässt man den IE6-nutzenden Gelegenheitsnutzer mit schlecht angezeigten Seiten im Regen stehen. Nach meinem Verständnis sollte Wikipedia jedoch auch für Nicht-PC-Freaks hilfreich sein. --Igelfleiß 18:38, 24. Feb. 2009 (CET)

ts_parseFloat() wieder an formatnum anpassen

Da formatnum die Zahlen mit einer Leerstelle anstatt eines Punktes ausliefert, muss auch die Funktion ts_parseFloat angepasst werden:

-    num = num.replace(/\./g, "");
+    num = num.replace(/\.|#160;/g, ""); /* auch geschützte Leerstellen aus Tausendertrenner akzeptieren */

Gruß, --Revolus Echo der Stille 04:26, 21. Jun. 2009 (CEST)

Bevor ich es anpasse, würde ich gerne noch auf ein, zwei Meinungen warten… --Leyo 13:28, 21. Jun. 2009 (CEST)

Ich denke, seit rev:42715 ist das lokale Überschreiben der Funktion nicht mehr notwendig. Ich schätze, wenn man die Funktion hier löscht, sollte das ganze auch wieder funktionieren. Gruß --P.Copp 13:51, 21. Jun. 2009 (CEST)

Ah, okay, noch besser :-) --Revolus Echo der Stille 14:10, 21. Jun. 2009 (CEST)

Gut, ich habe die Zeile gelöscht. --Leyo 11:07, 22. Jun. 2009 (CEST)

Fast. ;-) Die ganze Funktion muss raus. Gruß, --Revolus Echo der Stille 11:48, 22. Jun. 2009 (CEST)

Jetzt besser? --Leyo 12:02, 22. Jun. 2009 (CEST)

Unter Hilfe Diskussion:Tabellen#Fehler in der deutschen Sortierfunktion gibt es Hinweise auf ein fehlerhaftes Sortieren in Tabellen. Ich kann nicht sagen, ob dies mit der Entfernung oder der Umstellung von Formatnum zu tuen hat. Wäre gut, wenn jemand das auflösen könnte. Danke. Der Umherirrende 20:57, 21. Jul. 2009 (CEST)

Javascript-Fehler mit Vector-Skin

Wenn ich das Vector-Skin aktiviere, bekomme ich im Firefox einen Javascript-Fehler auf allen Bildbeschreibungsseiten:

Error: talk is null

Source File: http://de.wikipedia.org/w/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=vector

Line: 417

Die betreffenden Zeilen lauten:

	var talk = document.getElementById( 'ca-talk' );
	if( !talk.className.match( /(^| )new( |$)/) ) return;

Das Problem dürfte sein, dass der Diskussionslink bei Vector die ID ca-image_talk und nicht ca-talk hat. Ich habs nicht getestet, aber folgendes sollte auch mit Vector funktionieren:

	var talk;
	if( skin=="vector" ) {
		talk = document.getElementById( 'ca-image_talk' );
	} else {
		talk = document.getElementById( 'ca-talk' );
	}
	if( !talk || !talk.className.match( /(^| )new( |$)/) ) return;

Gruß, dapete 17:51, 31. Jul. 2009 (CEST)

Hi Dapete, hier für dewiki bestätigt. Könntest du es bitte mal im http://translatewiki.net probieren? Das läuft mit der allersuperaktuellsten MediaWiki-Version (dewiki hinkt mal wieder Woooochen hinterher). — Raymond ^{Disk. Bew.} 18:20, 31. Jul. 2009 (CEST)

gefixt [1] -- ∂ 23:55, 31. Jul. 2009 (CEST)

Danke. Sehr kompakter Code :)

Ich hab auf translatewiki.net nachgesehen, da hat das doch wieder die ID ca-talk - wenn wir die Version die da läuft auch bekommen, kann die Unterscheidung wohl im Prinzip wieder wegfallen. --dapete 09:40, 1. Aug. 2009 (CEST)

Die Unterscheidung kann wieder ausgebaut werden, da gestern die neue Version live gegangen ist. Der Umherirrende 17:27, 18. Sep. 2009 (CEST)

Weitere Suchmaschinen

Benutzer:Pmartin hat netterweise MediaWiki:SpezialSuche.js repariert und dann in der Commons.js wieder aktiviert.

Dies habe ich rückgängig gemacht, weil das auch im einfachen Suchformular erscheint. Das einfache Suchformular heißt aber einfach, weil es so wenig Elemente wie möglich enthalten soll. Dies geht auf Untersuchungen der Usability-Initiative der Wikimedia Foundation zurück.

Nun mag es Benutzer geben, die die weiteren Suchmaschinen benötigen/mögen/wasauchimmer, diese dürften jedoch in der Minderheit sein, so dass es meiner Meinung nach vertretbar ist, wenn die weiteren Suchmaschinen nur im erweiterten Suchformular erscheinen. Kann das Code in MediaWiki:SpezialSuche.js entsprechend angepasst werden? — Raymond ^{Disk. Bew.} 15:11, 3. Aug. 2009 (CEST)

Inzwischen funktioniert LuenceSearch zuverlässig und erkennt auch Ähnlichkeiten usw. Ich sehe deshalb auch keinen Grund mehr für eine externe Suchoption. Sollte die WP-eigene Suchmaschine mal streiken, kann man es mal kurzfristig einschalten. Aber damit rechne ich nicht. Merlissimo 15:23, 3. Aug. 2009 (CEST)

Bearbeitenlink für Commonslink

Auf Bildseiten, die lokal vor neuanlage geschützt sind, bekommt das Skript einen Fehler. Beispiel File:Flag of Germany.svg. Hier muss eine andere id abgefragt werden (ca-viewsource). Zusäzlich könne man den Text "Quelltext betrachten" auch noch umändert. Für beide Links sollte aber der Tooltip (title=) noch angepasst werden, damit sich der Benutzer nicht wundert, warum er beim Klick auf Bearbeiten auf Commons landet. Danke. Der Umherirrende 16:22, 3. Aug. 2009 (CEST)

hab erstmal den scriptfehler umgangen, ich schau mir das später nochmal an. -- ∂ 18:38, 3. Aug. 2009 (CEST)

Danke schonmal. Möchtest du noch mehr Ändern? Ansonsten setz einfach den Erledigt-Baustein. Mich stört es nicht weiter. Der Umherirrende 16:37, 14. Aug. 2009 (CEST)

hast du 'nen guten vorschlag, wie man die links belabeln könnte? "bearbeiten" gefällt mir z.b. nicht besonders, denn womöglich ist die commons-seite ja gesperrt.. tooltips kann ich auch noch ändern, was würdest du da reinschreiben? -- ∂ 17:33, 14. Aug. 2009 (CEST)

Ein guter Vorschlag fällt mir auch nicht ein. Die Commonsseite kann natürlich gesperrt sein, genauso, wie die Diskussionsseite schon vorhanden sein kann. Bem Tooltip würde ich auf jeden Fall einen Hinweis geben, das man auf Commons landet, den das ist ja das verwirrende für den normalen Benutzer. Man kann auch dazu schreiben, das es dort mehr Sinn macht, als lokal, da dort mehr Personen das ganze beachten. Der Umherirrende 18:39, 14. Aug. 2009 (CEST)

Diese Funktionalitaet ist ohne weitere Aenderung des linktextes eirsteinmal "ueberraschend". Und "ueberraschend" heist wenn es um usability geht "schlecht". Ich musste in mehrere Bildbeschreibungsseiten das ExzelentesBild template einfuegen, was durch dieses Script erschwert wurde. Jedem kann mans natuerlich nicht recht machen, aber man sollte den user irgendwie vorwarnen. --Dschwen 20:15, 14. Aug. 2009 (CEST)

ich bin nicht wirklich überzeugt, daß wir die links überhaupt ersatzlos umbiegen sollten. die lokalen seiten existieren nun mal, und da erwarte ich eigentlich, daß die tabs so funktionieren wie bei allen anderen seiten auch. vielleicht läßt sich eine bessere lösung finden, den normalnutzer auf die commons-seiten zu schicken? -- ∂ 13:30, 15. Aug. 2009 (CEST)

css-Klasse für "Nur im Edit-Modus sichtbar"

Aus "Nur_im_Edit-Modus_sichtbar" WP:WVW:

Was würdet ihr von der Idee halten? Eine css-Klasse mit display:none, die durch Javascript in Commons.js im Edit-Modus aktiviert wird. Es gibt gerade mehrere Baustellen, wo man gerne einen Hinweis im Edit-Modus hätte (z.B. Vorlage:Belege fehlen). Auch gibt es mehrere Vorlagen, die bestimmte Hinweise, Fehlermeldungen, usw. nur für Projektmitarbeiter anzeigen, die das in ihrer eigenen css aktiviert haben. Viele dieser Meldungen könnte/sollte man im Edit-Modus auch für alle sichtbar machen. Implementierung analog zur Admin-CSS. Merlissimo 12:25, 26. Jul. 2009 (CEST)

Bug 19499 ist eventuell gefixed (bis jetzt noch nicht live), danach könnten wir auch wieder mit REVISIONID arbeiten. Das Problem ist aber immer, das der Benutzer auf Vorschau klicken muss, damit er die Hinweise sieht, das macht auch nicht jeder. Aber man könnte einen Teil erreichen. Welche Vorlagen haben bestimmte Hinweise für Projektmitarbeiter? Ich kenne aktuell keine (nur damit man ein Beispiel hat) --Der Umherirrende 16:18, 26. Jul. 2009 (CEST)

Vorlage:§/Wartung und Verwandte (§§,§§§,Art.) stammt von mir, ist aber auch nur von woanders geklaut übernommen. Bin aber schön öfters über sowas gestolpert - aber mehr Beispiele habe ich spontan auch nicht im Kopf, da müsste ich nochmal suchen. Wäre aber vielleicht auch bei veralteten Vorlagen als Alternative sinnvoll. Merlissimo 17:35, 26. Jul. 2009 (CEST)

Finde die Idee gut. Am besten auf MediaWiki:Common.js oder MediaWiki:Onlyifediting.js fragen? --Revolus Echo der Stille 11:50, 5. Aug. 2009 (CEST)

MediaWiki:Common.js/watchlist.js

Siehe Wikipedia Diskussion:Schiedsgericht/Wahl/November 2009#Beteiligen. Gerade eingebaut. Merlissimo 20:37, 8. Nov. 2009 (CET)

Vielleicht sollte man eine eigene Seite in MediaWiki:Watchlistfor einbinden, damit man eine getrennte Versionsgeschichte hat. Der Umherirrende 20:33, 9. Nov. 2009 (CET)

Gute Idee. Name? MediaWiki:Watchlist-message? Merlissimo 20:53, 9. Nov. 2009 (CET)

Du hast fragen … Dein Vorschlag hört sich aber gut an, da die Nachrichten ja bereits so benannt wurden. Der Umherirrende 20:56, 9. Nov. 2009 (CET)

Ok, ;-). Übersetungen brauchen wir doch nicht, oder? Ich binde die Seite dann direkt ein anstatt {{INT:}} zu benutzen. Merlissimo 21:02, 9. Nov. 2009 (CET)

Ja, das reicht völlig aus. Der Umherirrende 21:10, 9. Nov. 2009 (CET)

Nach dieser Info könnte man auch MediaWiki:watchlist-summary als Einstiegspunkt nehmen. Ich weiß nur nicht, ob es bei der Spezialseite auch funktioniert. Der Umherirrende 10:54, 14. Nov. 2009 (CET)

Tatsache (gerade im Testwiki getestet). Das kannte ich auch nicht. Erscheint dann direkt über dem Kasten. Ich verschiebe ich die Nachricht dorthin und lösche WatchlistFor. Merlissimo 11:38, 14. Nov. 2009 (CET)

Durch das Löschen von MediaWiki:Watchlistfor fehlt aber das div mit der id zum ausblenden. Der Umherirrende 11:47, 14. Nov. 2009 (CET)

Ja, bitte wieder herstellen, damit

#watchlistfor {display:none}

wieder funktioniert. --Fomafix 11:58, 14. Nov. 2009 (CET)

Danke, für’s wiederherstellen von MediaWiki:Watchlistfor. --Fomafix 08:58, 16. Nov. 2009 (CET)

Links zu gerenderten PNG-Grafiken von SVGs: Optimierte Funktion

Auf meinen Vorschlag hin, gibt es in der en-WP ebenfalls Links auf gerenderte PNG-Grafiken. Die Funktion auf Commons wurde darauf hin ebenfalls angepasst. Ich denke, wir könnten die optimierte Version ebenfalls übernehmen. Meinungen? --Leyo 19:07, 30. Nov. 2009 (CET)

Hallo Leyo, änder mal bitte die Zeile

var l = new Array( 200, 500, 1000, 2000 )

in

var l = [200, 500, 1000, 2000];

Gruß, --Revo Echo der Stille 19:46, 30. Nov. 2009 (CET)

Inkl. ; am Ende? --Leyo 20:33, 30. Nov. 2009 (CET)

Ja. --Revo Echo der Stille 21:52, 30. Nov. 2009 (CET)

Auf Commons geändert. Was ist mit de-WP? --Leyo 18:13, 8. Dez. 2009 (CET)

Scheint nichts dagegen zu sprechen. --Revo Echo der Stille 18:22, 8. Dez. 2009 (CET)

Momentan wird nach http und https unterschieden. Dies sehe ich in der Commons-Funktion nicht. Oder ist es „versteckt“? --Leyo 18:27, 8. Dez. 2009 (CET)

Das Skript auf Commons benutzt einen anderen Einstiegspunkt, um die gerenderten Bilder abzuholen. Die Unterscheidung ist deshalb unnötig. Als Nebeneffekt würde es (wahrscheinlich) nicht auf nicht-Wikimedia/Wikia-Installationen funktionieren. Aber eigentlich sollte man das als „Verbraucher“ nicht weiter merken. --Revo Echo der Stille 18:35, 8. Dez. 2009 (CET)

Done. Scheint zu klappen. --Leyo 18:47, 8. Dez. 2009 (CET)

Der Funktionsname SVGThumbs könnte eingespart werden, indem addOnloadHook eine anonyme Funktion übergeben wird. --Fomafix 20:16, 8. Dez. 2009 (CET)

So war's vorher. Falls der Funktionsname keine Vorteile mitbringt, kann der von mir aus auch wieder entfernt werden. --Leyo 20:25, 8. Dez. 2009 (CET)

Navileisten-Abschnitt

Ich habe mit gerade den Code angeschaut, der für das Einklappen der Navileisten zuständig ist. Dabei ist mir etwas aufgefallen, was man „heutzutage“ besser machen könnte: Anstatt über alle divs zu iterieren und manuell die NavFrames zu suchen, könnte man direkt die Funktion getElementsByTagName MediaWikis verwenden, die genau das, bloß besser (da, wenn möglich, optimiert), macht.

Alles von

var indexNavigationBar = 0;

bis zum Ende der Funktion müsste gegen dieses hier ersetzt werden:

   // iterate over all NavFrames
   var NavFrames = getElementsByClassName(document.getElementById("content"), "div", "NavFrame");
   for (var i=0;  i<NavFrames.length; i++) {
       var NavFrame = NavFrames[i];
       var NavToggle = document.createElement("a");
       NavToggle.className = 'NavToggle';
       NavToggle.setAttribute('id', 'NavToggle' + i);
       NavToggle.setAttribute('href', '#');
       NavToggle.onclick = toggleNavigationBarFunction(i);

       var NavToggleText = document.createTextNode(NavigationBarHide);
       NavToggle.appendChild(NavToggleText);

       // add NavToggle-Button as first div-element
       // in < div class="NavFrame" >
       NavFrame.insertBefore(NavToggle, NavFrame.firstChild);
       NavFrame.setAttribute('id', 'NavFrame' + i);
   }
   // if more Navigation Bars found than Default: hide all
   if (NavigationBarShowDefault < NavFrames.length) {
       for(var i=0; i<NavFrames.length; i++) {
           toggleNavigationBar(i);
       }
   }

Getestet auf Opera 10.10. Eine Durchsicht wäre vielleicht trotzdem gut. Gruß, --Revo Echo der Stille 17:17, 8. Dez. 2009 (CET)

Ist eingebaut. Die Performance ist deutlich schneller. Beim IE 6 ohne SP2 kann es laut MW-Entwicklern wohl zu Fehlern führen. In den Fall sind die Navileisten dann immer ausgeklappt. Merlissimo 20:42, 14. Jan. 2010 (CET)

Der Dinosaurier? Wer IE6 ohne SP2 nutzt, ist selber Schuld. Wird Zeit, dass diese Krankheit (ein browser isses ja wohl eher nicht) endlich verschwindet :D --Guandalug 21:06, 14. Jan. 2010 (CET)

Wüsste nicht, warum der IE Probleme machen sollte, Tests im IE5.5 und 6 sehen gut aus. Wo es allerdings nicht mehr funktioniert, ist der Modern-Skin, da er kein Element mit der ID "content" hat, das Ding heißt dort "mw_content" :D. Gruß --P.Copp 14:44, 15. Jan. 2010 (CET)

Erl. Warum wird eigentlich der Skin-Mischmasch so ziemlich als letztes von Browser geladen. Die ganzen Gadgets kommen vorher. Sollte man das nicht vertauschen? Merlissimo 15:22, 15. Jan. 2010 (CET)

Bitte HTML-noscript-Tag mittels einer CSS-Klasse simulieren

• Hierher kopiert von „WP:FZW#Warum geht das HTML-noscript-Tag im Wiki-Quelltext nicht?“ (Permanent-Link)

Warum geht das HTML-noscript-Tag im Wiki-Quelltext nicht? Oder anders vielleicht besser gefragt, was spricht dagegen? MfG, --ParaDoxa 20:31, 9. Jan. 2010 (CET)

Ich wüsste nicht wozu wir das hier brauchen. Scripte sind sowieso nicht erlaubt, und die von der Software erzeugten, haben für uns keine Bedeutung. Daher braucht man eigentlich keinen extra Hinweis bei deaktiviertem Javascript. -- chatter™ 21:59, 9. Jan. 2010 (CET)

„wir“ ganz pauschal „brauchen“ das sicherlich nicht, aber nicht vernachlässigbar wenige von „uns“ mMn ganz gewiss. Zwei (mMn alles andere als ungewöhnliche) Fälle habe ich, wo eine funktionierendes HTML-noscript-Tag sehr nützlich wäre, um bei aktiviertem JavaScript keine überflüssige Hinweise sehen zu müssen: Siehe (a) roten „Standard-Sortierung“-Hinweis und (b) den „JavaScript muss aktiv sein um nach anderen Spalten sortieren zu können“-Hinweis in der vierten Zeile. MfG, --ParaDoxa 02:07, 10. Jan. 2010 (CET)

Eine solche Funktion könnte man auch recht einfach mittels einer CSS-Klasse simulieren. Dazu müsste z.B. auf MediaWiki:Common.js die Zeile

appendCSS('.noscript {display:none;}');

hinzugefügt werden. Statt <noscript></noscript> könnte man dann <div class="noscript"></div> verwenden. Gruß --P.Copp 15:35, 10. Jan. 2010 (CET)

Coole Lösung :) --APPER\^☺☹ 19:45, 10. Jan. 2010 (CET)

Fantastisch! Jetzt wäre es nahezu utopisch ;-) wenn das jemand der kann und will, das auch in die „MediaWiki:Common.js“ einfügen würde, bitteschön… --ParaDoxa 15:42, 12. Jan. 2010 (CET)

MfG, --ParaDox 19:46, 15. Jan. 2010 (CET)