Hgzh

NavFrame.js

Tipp:

• Das mw in Bytes 3+4 der ersten Zeile wird erst mit function ( mw, $ ) am Ende der ersten Zeile definiert.
• Die Kapselung muss immer um alles gehen, und dann gilt auch use strict für alles.
• Du könntest wahlweise den .hook oder init() zur Erfolgsfunktion des .using machen. Ersteres wäre schlauer, denn das nutzt die Wartezeit, in der parallel das DOM aufgebaut würde, und nach fertigem DOM ist dann auch gesichert, dass diese Standard-Module und makeCollapsible dann auch einsatzbereit sind.
  • Allerdings müsste showDefaultCount dann aus dem FRAME raus.
  • showDefaultCount wäre nachzutragen, etwa in init(), oder könnte gleich lokale Variable innerhalb von init() werden weil nirgendwo sonst und in FRAME nicht benötigt.

Ansonsten sehr sauber, sehr übersichtlich, Anpassung an screengrabbing leicht möglich.

• Habe ich auf Anhieb verstanden.
• Wird leicht zu pflegen sein.

Ein Denkanstoß noch:

• Statt <a href="#"> ein <button> oder noch besser <span> verwenden und mit role="button" plus ggf. Luxus aria-label="" und CSS-cursor usw. ausstatten und jQuery-dekorieren (blaue Schrift im TOGGLE).
• <a href="#"> beeinflusst die URL der dargestellten Seite und ist die althergebrachte Technik; neuere Implementierungen gehen davon ab und sparen sich damit auch preventDefault() als Gegen-Hack. Und die URL # ist HTML-syntaktisch auch etwas umstritten.
• onClick bleibt ansonsten unverändert.
• Ginge auch mit Icons.

Weiter so --PerfektesChaos 09:45, 30. Nov. 2023 (CET)

Merci! Hgzh (Diskussion – Beiträge) 20:22, 1. Dez. 2023 (CET)

mw-collapsible erzeugt <button type="button" aria-expanded="true" tabindex="0"></button> und bastelt den Rest mit CSS drum. mE würde es Sinn ergeben, umseitig das selbe machen zu lassen, und falsch sieht das nach kurzer Durchsicht von ARIA in HTML nicht aus. Hgzh (Diskussion – Beiträge) 23:14, 1. Dez. 2023 (CET)

Ich schrub ja: <button> oder noch besser <span>

<button> könnte Browser oder Skripte oder CSS dazu animieren, dort hineinzugrätschen.

<span role="button" style="cursor:pointer"> simuliert funktional einen Button, auch barrierefrei, ist aber völlig abgekoppelt von Browser-Stilen und dekorativen Ansichten von wem auch immer.

So ziemlich jedes sichtbare HTML-Element lässt sich zur anklickbaren Schaltfläche machen.

VG --PerfektesChaos 11:02, 2. Dez. 2023 (CET)

Hm, ja, da wursteln wirklich irgendwelche anderen Stile mit rein. Ok. Benutzer:Hgzh/NavFrame.css hat noch ein bisschen CSS bekommen. Ich würde das gern wie mw-collapsible aussehen lassen, macht ja das Gleiche und diese winzige Schrift im Bestand ist auch nicht so dolle. Hgzh (Diskussion – Beiträge) 12:19, 2. Dez. 2023 (CET)

Fein, fein. Einige Tücken gäbe es noch:

• Der Bezeichner müsste zukunftsweisend neu gewählt werden und sollte nur aus Kleinbuchstaben bestehen.
  • Im Prinzip ist es ja ein dewiki-collapsible oder klappbar oder so.
  • Dementsprechend die CSS-Klassen gadget-dewiki-collapsible-toggle-text bzw. gadget-klappbar-toggle-text oder so.
  • Dass das 2006 mal für unsere Navileisten gedacht war, muss aus heutiger Perspektive nicht mehr in alle Ewigkeit konserviert werden. Gibt ja seit langer Zeit die verbreiteten Nicht-Navileisten-Ausklapp-Inhalte. Vielleicht bekämen die irgendwann sogar andere Klassenbezeichner.
  • Großbuchstaben in Klassenbezeichnern sind tückisch weil undefiniert und Interpretation browserabhängig. Machen wir nicht mehr neu.
  • data-navframe-hidden und buttonClass linkClass wären betroffen.
  • Der Gadget-Bezeichner sollte in die globale Konfiguration aufgenommen werden.
  • Die Klassenbezeichner können dann damit komponiert werden.
• Es ist möglich, das JS-Gadget außerhalb von MediaWiki:Gadgets-definition zu laden.
  • Sollte deshalb vor .loader.using() ein .loader.load( URL, "text/css" ) bekommen, was beim Laden über Gadgets-definition automatisch erfüllt ist, aber bei anderem Kontext die Dinger nachholt.
  • URL wäre luxuriöserweise über die window. bekannte Domain/Host der aktuellen Seite zu bestimmen, oder müsste in die globale Konfiguration ganz zu Beginn aufgenommen werden. Ggf. das CSS schon vorab in der produktiven WP hinterlegen.
  • Doppel-Ladung von 4 Deklarationen ist verschmerzbar billig.
  • Ich persönlich setze als erste ausführbare Anweisung immer ein mw.loader.state( { "...": "ready" } ) und blockiere damit alle anderen Ladevorgänge.
  • Umgekehrt mache ich die inhaltliche Ausführung von ungeschärftem mw.loader.getState() abhängig und verhindere dadurch mehrfache Ausführung, etwa per Greasemonkey, Benutzer-JS, site Gadgets.
  • Ich könnte mir bei diesem Dingens eine unorthodoxe Mitbenutzung vorstellen.
  • Narrensichere Gadgets zu bauen ist nicht so völlig trivial.
• Schriftgröße 90 % ist legitim, aber ob before-after die automatisch mitbekämen weiß ich grad nicht.

VG --PerfektesChaos 17:52, 3. Dez. 2023 (CET)

Um das nochmal klarzustellen:

• Die Preferences-Option soll ihren Traditionsbezeichner beibehalten.
• Das zugeordnete Gadget soll jedoch einen global/deutschWiki-geeigneten Bezeichner bekommen, also von der normalerweise identischen ID abweichen. Davon auch die neuen Klassen usw. abgeleitet.
• Damit soll der Bruch mit der Navileisten-only-Tradition aus den Nuller Jahren verdeutlicht werden.
• Im Prinzip ist das Teil nicht an ein bestimmtes Wiki gebunden, vor allem wenn auch weitere Klassenbezeichner in den Seiten ermöglicht werden.

Was unser zuvor thematisiertes Sorgenkind angeht, so plane ich in jedem Fall eine Weihnachtsruhe.

• Heißt: Der manuelle Rückbau wird vermutlich im Dezember mit je einem Versuch pro Artikel (bis auf die beiden Themengebiete) abgeschlossen werden.
• Irgendwann im Januar sind nur noch diese beiden plus einige Reverts und Ansprachen übrig.
• Dann komnmt die Aktion Vollschutz und mobil, und dann schaun wir mal.
• Nächste Phase sind dann Infoboxen mit Koordinaten nach neuem flexiblem universellem Parameterformat.

VG --PerfektesChaos 20:35, 3. Dez. 2023 (CET)

Die Klasse zu ändern wird nicht gehen, da noch mehrere tausend Direktverwendungen allein im ANR vorhanden sind. Diese müssten zunächst mal in eine Vorlage überführt werden, was im Prinzip sinnvoll wäre, aber momentan nicht auch noch händelbar ist, und mir ist noch kein griffiger Vorlagenbezeichner eingefallen. Am Ende sollte mE alles inkl. Navileisten nach mw-collapsible überführt werden und das Skript nur noch das Navileisten-Ausklappen nach Präferenz übernehmen. Deshalb auch mein Vorschlag, alles gleich aussehen zu lassen. Der ganze NavFrame-Kram stammt ja aus einer Zeit vor mw-collapsible und sollte langsam auslaufen. Ich stelle mir das in Theorie so vor:

• Vorlage:NavFrameBox (blöder Arbeitstitel)
  • macht die ganzen Späße mit NavHead, NavFrame und NavPic, NavContent etc., die jetzt in der Navileisten-Vorlage stehen
  • Vorlage:Navigationsleiste bindet diese nur noch ein
  • kann auch direkt im ANR verwendet werden als Ersatz des bisherigen div-Geschubse mit NavFrame
  • wird solange das NavFrame-Skript verwenden, bis alle Direkteinbindungen umgestellt sind, danach mw-collapsible
• NavFrame.js kann dann so gut wie entfallen, NavFrame.css ist nur noch TemplateStyles von NavFrameBox

Es hat mE auch keinen Sinn, dieses Gadget für Fremdeinbindung vorzubereiten, warum sollte das jemand tun? Wer klappbares Zeug will, sollte schon jetzt mw-collapsible nehmen. Hgzh (Diskussion – Beiträge) 17:22, 7. Dez. 2023 (CET)

Klassennamen gehen beliebig viele per Komma-Aufzählung an geeigneter Stelle generiert aus Array von Klassennamen.

• Das Problem mit der Klapperei ist, das wohl schon vor 2010 die nur für Navileisten vorgesehenen Mechanismen für beliebige Stellen im Artikel zweckentfremdet wurden.
• Wenn schon neue Vorlage für diesen Kopfbereich, dann sollte die sich explizit von Nav trennen und einen neuen Bezeichner für das Modell 2010+ einführen.
• Der Mechanismus kann sowohl für klapp (mitten in der Seite) wie auch für Nav benutzt werden.
• Die Teile im Inneren migrieren von dem dort verwirrenden Nav weg.
• Die bisherigen Klassennamen mit eingestreuten Großbuchstaben entsprechen nicht dem robusten Standard. Manche machen aus .NavFrame ein .nav-frame und reagieren einheitlich auf letzteren.
• Das neue System löst sich bezeichnungsmäßig von Nav und setzt nach 2010 neu bei einem neutralen klapp auf.
• NavFrame.js bzw. unter anderem Bezeichner wird wohl weiterhin benötigt werden für die bisherige bzw. ggf. neu eingeführte Konfiguration „für mich immer alles initial einklappen“ oder „für mich immer alles initial ausklappen“.

Fremdeinbindung ist mindestens in der Entwicklungsphase und für Funktionstests wichtig. Meine Testversionen kann ich vorab laden, und die blockieren danach die Standardkonfiguration.

• Separates Laden ist ohnehin charmant für flexible Konfiguration nur für bestimmte Situationen oder globale Einbindung.
• Es darf nicht dazu kommen, dass ein solches JS mehrfach ausgeführt wird, weil dann auch mehrere Toggles sichtbar werden.

VG --PerfektesChaos 16:18, 12. Dez. 2023 (CET)

Nochmal zurück hierzu: theoretisch kann ich auch ein neues Set aus dewiki-collapsible, dewiki-collapsible-pic, dewiki-collapsible-head, dewiki-collapsible-content, dewiki-collapsible-toggle, data-dewiki-collapsible-hidden unterstützen. Wie du sagst, ist das selektorenmäßig kein Problem. Ich bin aber nach wie vor nicht überzeugt, dass das nötig ist. Die Überarbeitung soll ja wirklich nur eine Überarbeitung sein, keine Neuentwicklung oder Neueinführung. Mir wäre es lieber, auf ein dewiki-eigenes Collapsible-System komplett zu verzichten und gleich auf mw-collapsible zu migrieren. Vielleicht lässt man besser auch den JS-Code beim Alten und entfernt ihn, wenn das irgendwann umgestellt werden sollte.

Den mw.loader.state-Kram schaue ich mir bei Gelegenheit mal an, da habe ich noch nie etwas mit gemacht. Hgzh (Diskussion – Beiträge) 19:41, 13. Mär. 2024 (CET)

Hier mal, wie ich mir das vorstelle: Vorlage:Klappleiste - Vorlage:Klappleiste/styles.css - Vorlage:Navigationsleiste/neu. Das derzeitige NavFrame-Skript würde dann nur noch auf dewiki-collapsible reagieren und einzig den derzeitigen Einklappmechanismus bei X Vorkommen nachbauen, den Rest macht MediaWiki. Hgzh (Diskussion – Beiträge) 21:09, 13. Mär. 2024 (CET)