Wikipedia:Technik/Skin/MediaWiki/Änderungen/Archiv/2022

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Hauptseiten-Titel

Letzter Kommentar: vor 2 Jahren14 Kommentare4 Personen sind an der Diskussion beteiligt

In Bezug auf die Hauptseite gab es zuletzt ein paar Neuerungen; Projektneuheiten 9. Dezember: Über die neuen Systemnachrichten MediaWiki:Mainpage-title und MediaWiki:Mainpage-title-loggedin kann der HTML-title (English: HTML element#title) der Wikipedia-Hauptseite definiert werden. Standardmäßig ist kein title definiert (Task 255682, Gerrit:743050). Seitdem bekam ich auf der mobilen Startseite wieder das Willkommen, XanonymusX! zu sehen, das wir 2020 per MediaWiki:Mobile-frontend-logged-in-homepage-notification eigentlich ausgeblendet hatten. Nachdem ich das jetzt für MediaWiki:Wikimedia-mobile-mainpage-title-loggedin übertragen habe, ist die Begrüßung zwar weg, dafür aber Wikipedia:Hauptseite wieder da. Blickt da jemand durch? Mein letzter Stand war, dass wir weder den einen noch den anderen Seitentitel in der Mobilversion sichtbar haben wollen, aber ich habe grad keine Ahnung, was da wie zusammenwirkt. --XanonymusX (Diskussion) 21:10, 10. Jan. 2022 (CET)

Deaktivieren mittels - führt zu einem Fallback auf den Seitentitel, wenn man die Systemnachricht leert, wird die Überschrift ausgeblendet. Ich habe das mal mit MediaWiki:Wikimedia-mobile-mainpage-title-loggedin gemacht, allerdings fehlt jetzt oben etwas margin zum Header. Gruß, -- hgzh 07:54, 11. Jan. 2022 (CET)
Den oberen Abstand habe ich etwas hochgesetzt. In der Desktop-Ansicht dürfte das weniger stören als das Fehlen in der mobilen Ansicht. --Wiegels „…“ 10:57, 11. Jan. 2022 (CET)
Ok, ansonsten muss eben noch eine Extraregel her für eins der beiden. Habe nun den Hauptseitentitel auch für unangemeldete noch mittels MediaWiki:Mainpage-title deaktiviert. -- hgzh 11:57, 11. Jan. 2022 (CET)
Puh, da blick mal einer durch. Schaut für mich jetzt gut aus. Sind die drei bisher deaktivierten Nachrichten damit obsolet? Und muss das jetzt wieder für alle Sprachen einzeln geändert werden (ich meine, ja)?—XanonymusX (Diskussion) 12:56, 11. Jan. 2022 (CET)
Ja, ich habe die Sprachversionen noch entsprechend angelegt. Ob man MediaWiki:Mobile-frontend-logged-in-homepage-notification noch braucht, keine Ahnung, bleibt nur zu probieren. Gruß, -- hgzh 13:04, 11. Jan. 2022 (CET)
Hm, habe mal die vier alten gelöscht und noch ein paar Sprachversionen für die neuen angelegt. Sprachunabhängige Definition scheint leider immer noch nicht möglich zu sein. Gruß --XanonymusX (Diskussion) 17:06, 12. Jan. 2022 (CET)
Grad nochmal getestet: mit einer leeren MediaWiki:Mainpage-title kann das Deaktivieren per firstHeading auf der Hauptseite entfallen, da wird von MediaWiki ein display:none eingefügt. -- hgzh 17:37, 20. Feb. 2022 (CET)
Und mit gerrit:752176 braucht es die Sprachunterseiten auch nicht mehr (würde sagen für Desktop und Mobil), da immer die Inhaltssprache genutzt wird (nl-Version). Der Umherirrende 00:18, 22. Feb. 2022 (CET)
Das war mir auch schon aufgefallen, hatte aber noch nicht ganz drauf vertraut ;) Danke! -- hgzh 07:25, 22. Feb. 2022 (CET)
Hey! ;-) Es funktioniert aber, zum Beispiel auf Wikidata gibt es nur die fa-Unterseite, aber bei allen anderen Sprachen fehlt der Header auch durch das direkte style="display: none" und nicht (nur) über die Common.css Der Umherirrende 20:32, 22. Feb. 2022 (CET)
Achso, versteh's nicht falsch: ich hatte deinen Change nicht gesehen, wohl aber am 20. seinen Effekt bemerkt, aber war mir nicht sicher, ob das nun Zufall war oder nicht. Kein Misstrauen gegenüber deiner Änderung, das wäre sehr anmaßend ;) Ich habe aber nun die Sprachvarianten wieder gelöscht. Gruß, -- hgzh 21:33, 22. Feb. 2022 (CET)
Nein, ich verstehe das nicht falsch, wollte aber auf deinen Smily mit einem Smily reagieren, daher hab ich das so geschrieben, aber da fehlt natürlich der entsprechende positiver Tonfall im geschriebenen um den Smily-Gesichtsausdruck nochmals zu unterstreichen ;-). Außerdem wollte ich dir auch bestätigen, das es kein Zufall ist (der sich nochmals ändern könnte), sondern das neue Verhalten so beabsichtigt ist. Danke für das Löschen der Unterseiten (wobei die bei MediaWiki:Wikimedia-mobile-mainpage-title-loggedin vermutlich auch weg können), damit sieht das für mich hier erledigt aus. Der Umherirrende 23:50, 23. Feb. 2022 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 23:50, 23. Feb. 2022 (CET)

Eingriff in MediaWiki:Common.js erbeten

Letzter Kommentar: vor 2 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Bitte den deprecated Codeblock Zeilen 25-84 ersatzlos löschen. Siehe [1]. Danke, –MBq Disk 12:33, 28. Mär. 2022 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 20:00, 28. Mär. 2022 (CEST)

Mediaviewer CSS

Letzter Kommentar: vor 2 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Gemeldet in Phabricator
Task T305328

Moin!

Glaube sowas ähnliches wie untenstehend wäre hilfreich um den x-overflow bsplw. wegen des Dateinamens ohne Leerzeichen bei Michael_Blume#/media/Datei:MichaelBlumeParlamentVersammlungEuroparat2017.jpg zu verwermeiden: 

.mw-mmv-image-links:not(.mw-mmv-untruncated .mw-mmv-image-links) {
	word-break: break-all;
}

Habitator terrae Erde 10:15, 2. Apr. 2022 (CEST)

Eigentlich würde auch 

.mw-mmv-image-links {
	word-break: break-all;
}

ausreichen nur dann hätten wir ein anderes Verhalten beim Runterscrollen. Es würde aber das leicht den oben schon verhinderten, aber noch kurz bei der Animation aufploppenden x-overflow vermeiden. Habitator terrae Erde 10:19, 2. Apr. 2022 (CEST)

Das kannst du gern per Phab dem MMV vortragen.
Der weiß ja, dass er auf dieser Seite tätig wird, und kann global für alle Wikis in dieser Situation dieses CSS einbringen.
Bei uns würde das aber mit der Gießkanne ausgekippt über allen Versionsgeschichten und alle Artikel ganz ohne Bilder und ohne dass jemand sich ein Bildchen genauer angucken wollte.
Genau sowas bauen wir jedoch systematisch zurück und führen es nicht mehr neu ein.
VG --PerfektesChaos 16:14, 2. Apr. 2022 (CEST)

@PerfektesChaos: phab:T305328. Habitator terrae Erde 17:10, 3. Apr. 2022 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:12, 7. Apr. 2022 (CEST)

3× CSS Systemnachricht

Letzter Kommentar: vor 2 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Bitte ergänzen:

VG --PerfektesChaos 17:11, 5. Aug. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. Wnme (Diskussion) 19:15, 6. Aug. 2022 (CEST): Danke!

Fehlgeleitetes Benutzer-CSS

Letzter Kommentar: vor 2 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Bitte mal:

  1. Vorlage:InternetArchiveBot header/styles.css
  2. Linkfix in Benutzer:InternetArchiveBot/header
  3. SLA auf Verschieberest

Danke im Voraus --PerfektesChaos 17:50, 16. Sep. 2022 (CEST)

erledigtErledigt danke dir für's Aufpassen! --Holmium (d) 18:06, 16. Sep. 2022 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 08:03, 8. Okt. 2022 (CEST)

Zuletzt bearbeitet in der Mobilen Ansicht

Letzter Kommentar: vor 1 Jahr11 Kommentare5 Personen sind an der Diskussion beteiligt

In der Mobilen Ansicht steht ganz unten sowas wie Zuletzt bearbeitet vor 19 Stunden von Aka. Das führt dazu, dass neue und unerfahrene Benutzer (und IPs) sich an den letzten Bearbeiter wenden. Sinn dieser Leiste ist ja die Erreichbarkeit der Versionsgeschichte (einfach mal draufklicken), muss da wirklich der Name des letzten Bearbeiters stehen?

Aka will sich daher in Benutzer:Ich habe hier zwar eine Kleinigkeit korrigiert, sonst mit dem Artikel aber vermutlich nicht viel zu tun umtaufen, schließlich taucht er ja in sehr vielen Artikeln als letzter Bearbeiter auf.

Ich schlage vor die Anzeige in dieser Zeile in "Zuletzt bearbeitet vor 19 Stunden" zu ändern. --Wurgl (Diskussion) 16:06, 9. Jan. 2022 (CET)

Es geht um MediaWiki:Mobile-frontend-last-modified-with-user-hours (Translatewiki). Leuchtet ein, ich wäre auch dafür, das lokal um das von {{PLURAL:$5|[$6 $2]|0=einem anonymen Benutzer}} zu kürzen. --XanonymusX (Diskussion) 16:53, 9. Jan. 2022 (CET)
Fänd' ich auch in Ordnung. -- hgzh 08:07, 10. Jan. 2022 (CET)
Ich habe das gerade geändert, sehe zumindest im Moment aber noch keine Auswirkung. -- Gruß, aka 10:54, 10. Jan. 2022 (CET)
Lokal ist das vielleicht nicht so toll oder doch? Es gibt da wohl 7 (oder mehr) Meldungen: translatewiki-Suche. --Wurgl (Diskussion) 11:19, 10. Jan. 2022 (CET)
OK, davon wusste ich nichts. Im Translatewiki habe ich noch nie etwas geändert und kenne da auch die Regeln nicht, nach denen man so etwas abstimmen müsste. Vielleicht möchten andere Wikis ja genau diese Anzeige haben? -- Gruß, aka 11:44, 10. Jan. 2022 (CET)
@Aka nur kurz zur Info: Im Translatewiki bitte immer genau wie das englische Original übersetzen. Anpassungen, wie hier lokal besprochen, auch nur lokal vornehmen, nie im Translatewiki. Wenn eine allgemeine Änderung des Systemtextes sinnvoll erscheint, muss die englische Systemnachricht im Git/Gerrit via Patch geändert werden. --Raymond Disk. 12:06, 10. Jan. 2022 (CET)
Die Meldungen mit den anderen Zeitangaben habe ich jetzt lokal ebenfalls angepasst, weiterhin aber ohne Auswirkung. Dann muss ich eben doch bei WP:BÄ vorstellig werden ;-) -- Gruß, aka 11:48, 10. Jan. 2022 (CET)
Nach etwas Warten funktioniert es jetzt, also war das nur ein Cache-Problem. Bzgl. des Translatewikis müsste sich aber jemand anderes kümmern. -- Gruß, aka 11:54, 10. Jan. 2022 (CET)
Nein, im Translatewiki würde ich das nicht ändern, die Nachricht hat immerhin hours im Titel, das sollten wir als lokale Ausnahme behandeln.—XanonymusX (Diskussion) 11:59, 10. Jan. 2022 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 19:07, 13. Jan. 2023 (CET)

“Desktop” statt “Klassische Ansicht”

Letzter Kommentar: vor 1 Jahr3 Kommentare3 Personen sind an der Diskussion beteiligt

…im mobilen Skin der Wikipedia, wie überall sonst im Internet, meine ich —MBq Disk 07:53, 19. Mär. 2022 (CET)

Da ist was dran; allerdings kann nun wieder ein nennenswerter Teil unterm DACH mit der Vokabel „Desktop“ nix anfangen.
Ergäbe also Doppelnennung; Klassische Ansicht (Desktop) oder Desktop (klassische Ansicht).
Oder mal was mit „PC“, schreibt PC grad: Desktop (PC) oder PC (Desktop).
„Desktop“ ist zweifelsfrei der im letzten Jahrzehnt seit Aufkommen der Smartphones in allen IT-Bereichen global etablierte Ausdruck zur Abgrenzung von kleinen Mobil-HTML-Gestaltungen; allerdings nerdig.
Ausdrücke wie „klassische“, „neue Darstellung“, „alte Darstellung“ funktionieren immer nur ein, drei Jahre um eine Umstellung herum, wenn 99 % des Publikums noch die „andere“ oder „vorherige“ Variante kennen. Ein Jahrzehnt später weiß niemand mehr, was „früher“ oder „alt“ oder „neu“ sein soll.
Aus diesem Gund (und weil ich mich bei MediaWiki beschwert hatte) verwenden die mittlerweile Jahreszahlen (Editor-2017; Vector-2022).
VG --PerfektesChaos 10:39, 19. Mär. 2022 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 19:06, 13. Jan. 2023 (CET)

Verschieben der Abkürzungen und Geokoordinaten unter den Seitentitel

Letzter Kommentar: vor 1 Jahr3 Kommentare3 Personen sind an der Diskussion beteiligt

Bei der Verwendung von Vector 2022 überlappen sich Site Notices bzw. Central Notices und Elemente, die durch MediaWiki:Vector.css absolut positioniert werden (z. B. Katla mit Beispielbanner oder WP:K mit Beispielbanner). Ich habe mal in ein paar andere Wikipedia-Wikis (enwiki, svwiki, dawiki, plwiki) nachgesehen und festgestellt, dass dort Geokoordinaten unterhalb des Artikeltitels positioniert werden, was dann auch nicht zu Überlappungen führt. Vielleicht ist das auch für dewiki eine sinnvolle Änderung. Kai Nissen (WMDE) (Diskussion) 15:40, 27. Jun. 2022 (CEST)

Siehe auch: Wikipedia:Meinungsbilder/Darstellung der Seiten-Koordinaten. --XanonymusX (Diskussion) 16:17, 27. Jun. 2022 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 19:06, 13. Jan. 2023 (CET)

Dark Mode Gadget

Letzter Kommentar: vor 1 Jahr12 Kommentare5 Personen sind an der Diskussion beteiligt

Ich würde hier das Dark Mode Gadget vorschlagen, die Dokumentation und die Übersicht sind bereits im meinem ANR und müssen nur noch Implementiert werden. --The Other Karma (Diskussion) 16:31, 7. Aug. 2022 (CEST)

Bedauerlicherweis funktioniert keines dieser „Dark Mode Gadget“ hinreichend korrekt, weil deren Grundprinzip darauf aufbaut, dass eine Webseite nur aus den drei Farben Weiß, Schwarz und ggf. Blau bestehen würde.
Das ist bei Twitter, Facebook, eBay, Google usw. der Fall.
Bei uns können aber Autoren auch gelbe und dunkelblaue Hintergrund- sowie Schriftfarben vergeben. Die erscheinen bei der von dir genannten Methodik dann in weiß auf gelb und sind unlesbar, oder in schwarz auf dunkelblau und sind nicht erkennbar.
Auch eine zyklische Farbvertauschung zur Kontrasterhaltung ist bei uns nicht möglich, weil sonst die „grüne“ Partei in Blau und die Sozialisten vielleicht in Braun erscheinen würden; Fußballvereine wie der BVB Dortmund dann in weißer Schrift auf dunkelrotem Untergrund, die Feuerwehr bekommt Hellblau und die Marine Rosa.
Hinzu kommt, dass wir sehr viele Grafiken wie etwa Icons haben, die darauf aufbauen, dass sie auf einem hellen Hintergrund erscheinen. Bei deiner Methode sind sie dann schwarz auf schwarz und damit nicht mehr erkennbar. Bei Twitter, Facebook usw. können die Inhaltsproduzenten nur Fotos hochladen; dabei ist das egal.
Für dich privat kannst du aktivieren was immer dir gefällt, aber ein von dieser Community bereitgestelltes Gadget muss alle Seiten korrekt darstellen, ansonsten werden wir mit Beschwerden und Änderungswünschen geflutet.
Wenn es dir um einen Einschlaf-, Dämmerungs- oder Augenschon-Modus gehen sollte, kannst du für jede beliebige Webseite jeder Domain den Blau-Anteil und die Bildhelligkeit senken. Dazu bedarf es keiner Gadgets von unserer Seite.
VG --PerfektesChaos 17:54, 7. Aug. 2022 (CEST)
Dürfte ich ein paar Beispiele dazu haben?
Mir sind nur die Fehler der umgekehrten Bilder im Namespace bekannt, dass jedoch mit klicken auf die Bilder annulliert wird, und dass Hintergrundfarben [1], (Schwarzer Text auf Gelb wird zu Weißem Text auf Schwarzem Hintergrund, oder Orange mit Weißem Text (Bubble, lesbar)), die Falschen Farben haben (WikiUI Thema). Das Text dadurch Unleserlich werden sind mir nicht bekannt.
LG --The Other Karma (Diskussion) 10:56, 9. Aug. 2022 (CEST)
Du und auch alle anderen können sich CSS, JS und Add-Ons für sich persönlich aktivieren was immer gefällt.
Als von dieser Entwickler-Community allen anderen empfohlenes Angebot ist dein Vorschlag untauglich, und alle anderen gleicher Richtung ebenfalls.
  • Wir könnten uns nicht mehr retten vor Beschwerden dass auf Seite X der Text oder das Element Y nicht zu erkennen wären.
  • Eine Einführung als offizielles Gadget hätte verheerende Folgen für viele weitere Betroffene.
Das Gesamtkonzept ist für vielfarbige Wikis eine Schnapsidee.
  • Es kann grundsätzlich nicht zu einer akzeptablen Seitendarstellung führen.
  • Farben werden in diesem Konzept lediglich als irgendwie bunte Dekoration aufgefasst. Bei uns sind sie aber bedeutungstragend.
  • Die Farbinvertierung führt dazu, dass warnendes Gelb als harmonisches Braun erscheint.
  • Die Farblegende zu einer Grafik ist Bullshit. Eine Grafik behält ihre Farben, also Sozialisten Rot, Kommunisten dunkleres Rot, Grüne Grün und Nazis Braun. Die Farbinvertierung nach Grundfarbe oder Helligkeit für den Wikitext-Anteil macht daraus völligen Schwachsinn. Siehe Sitzverteilung und Regionalkarte in Reichstagswahl 1930 oder aber Regentag. Bei letzterem beachte auch das Symbol im Seitenkopf.
VG --PerfektesChaos 23:50, 9. Aug. 2022 (CEST)
Ich verstehe was gemeint ist, eines der mir bekannten Fehler, das sich bei Mehrfarbigen Wikis/Seite nicht so einfach umgehen lässt.
Ich werde mal überlegen und mich Informieren ob es evtl. andersweitig möglich ist diese Funktion umzusetzen, durch z. B. eine Infoseite das man diese Funktionen nutzen kann, sie aber nicht als Gadget umgesetzt wird, bzw. Frage an dich, ist sowas möglich?
LG --The Other Karma (Diskussion) 11:36, 10. Aug. 2022 (CEST)
@PerfektesChaos --The Other Karma (Diskussion) 21:00, 15. Aug. 2022 (CEST)
Siehe auch die Anfragen hier und hier, und https://phabricator.wikimedia.org/T252904 —MBq Disk 07:25, 10. Aug. 2022 (CEST)
Machst du zum Bleistift Terri Lyne Carrington auf, gehst zum Abschnitt Einzelnachweise und dort dann EW 3, 4 und 5. Das Wort "Memento" ist wahrscheinlich unsichtbar. --Wurgl (Diskussion) 11:49, 10. Aug. 2022 (CEST)
Warum sollte das Unsichtbar sein? --The Other Karma (Diskussion) 18:17, 10. Aug. 2022 (CEST)
In der App ist es bei Darkmode unsichtbar. Probier es aus. --Wurgl (Diskussion) 18:24, 10. Aug. 2022 (CEST)
Ich verstehe was du meinst, das der Text unsichtbar ist, ist bei mir nicht der Fall. --The Other Karma (Diskussion) 18:46, 10. Aug. 2022 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 19:06, 13. Jan. 2023 (CET)

Neues Gadget:searchResultLight

Letzter Kommentar: vor 1 Jahr5 Kommentare2 Personen sind an der Diskussion beteiligt

WP:FZW #Thumbs in der Cirrus-Suchergebnis-Liste

  • Die sind ja wirklich nervig. Ich unterdrücke ohnehin schon seit Jahren diese Bildchen bei Dateibeschreibungen.
  • Der Wunsch wird wohl häufiger geäußert werden; danach Kurier/rechte.
  • Kostet auch traffic. Ungefragt 20 uninteressante Bildchen durchs Netz zu jagen sollte hoffentlich von schlauen Browsern für ausgeblendete unterdrückt werden. Kommen bei limit=500 etwa 500 Bildchen?
  • Das Gadget sollte nicht auf thumbs beschränkt sein, sondern auch zukünftige Zumutungen, Mobilkram berücksichtigen können und deshalb kein thumb im Namen führen. Wer weiß was die sich noch so einfallen lassen.
  • view Opt-In
  • Zunächst als CSS. Vorstellbar späteres JS mit Aktionen, etwa ein PortletLink zum Wiedereinblenden der Bildchen, konfigurierbare Features usw. Triviale Realisierung.
  • Internationalisierbar.

VG --PerfektesChaos 08:03, 8. Okt. 2022 (CEST)

So wie ich den Task lese, ist da noch ein bisschen Bewegung drin in der Sache und die eher mangelhafte Umsetzung des Ganzen wird sowieso kritisch gesehen. Vielleicht lohnt es sich, noch etwas mit lokalen Überschreibungen abzuwarten? -- hgzh 20:34, 10. Okt. 2022 (CEST)
Yep; Datum/Uhrzeit mit den Posts bei Phab/FZW vergleichen.
Mal sehn, vielleicht bekommt MW selbst was auf die Reihe, ich würd mal denken due date für die Ankündigung einer Implementierungsabsicht bzw. Patch auf Ende Oktober, sonst wir ab Anfang November.
So wie es ist, ist es nett gemeint für normale Kundschaft, und bei manchen Themen hilfreich, aber katastrophal für Content-Erstellung und Analysen zur Pflege.
VG --PerfektesChaos 22:09, 10. Okt. 2022 (CEST)

Mit Einstellung für angemeldete wohl erstmal erledigt; die anonymen wurden bislang schlicht vergessen. Insgesamt ein aus einer Froschperspektive ohne Kenntnis aller Use Cases für irgendein Ideal von zwei Dutzend Treffern mit signifikanten Bildchen auf Wikipedien lieb gemeinte Menschheitsbeglückung und sämtlichen WMF-Wikis aufgezwungen, aber nur in Wikipedien und nicht im Wiktionary überhaupt sinnvoll, und nicht bei Hunderten von Treffern, und bei Textanalysen zu Wartungszwecken will niemand minutenlang auf Hunderte von nichtssagenden Bildchen warten und Traffic konsumieren. Auf Mobil weiterhin übertragen, aber nicht dargestellt, falls der Browser dusslig ist. VG --PerfektesChaos 17:43, 18. Okt. 2022 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 19:06, 13. Jan. 2023 (CET)

Gadgets aktionsabhängig

Letzter Kommentar: vor 1 Jahr23 Kommentare2 Personen sind an der Diskussion beteiligt

Wenn es bis Februar kein rollback gab, sollte wie nachstehend umgesetzt werden.

  • Damit wird vermieden, dass mit jedem Seitenaufbau unnötig Gadgets gestartet werden, die erst anlaufen, und dann feststellen dass es nichts zu tun gibt, und sofort wieder beenden.
  • Ggf. auch entsprechende Ausgründungen aus Common.js als hidden und damit deren weitere Verschlankung und höhere Performance.
  • Neu ist actions= für MediaWiki:Gadgets-definition.
  • Bitte meine nachstehende freihändig aufgesetzte Liste schon mal durchgehen, auf Erfassung aller sinnvoller actions checken, ggf. weitere eingrenzen:
    • Vorlagenmeister|actions=edit
    • wikEd|actions=edit
    • HotCat|actions=view
    • editMenus|actions=edit,upload?
    • editMenusDef|actions=edit,upload?
    • mediawiki.toolbar|actions=edit,upload?
    • LegacyToolbar2006|actions=edit,upload?
    • Extra-Editbuttons|actions=edit,upload?
    • Suchfokus-Hauptseite|actions=view
    • Pfeil-hoch|actions=view,edit
    • editsection-align-end|actions=view,edit
    • Personendaten|actions=view,edit
    • old-diff-style|actions=view,diff,edit
    • ReferenceTooltips|actions=view,edit
  • Stolzer geistlicher Vater: phab:T204201

VG --PerfektesChaos 11:20, 7. Jan. 2022 (CET)

Scheint recht stabil zu sein, würde das die Tage umsetzen. supportsUrlLoad gibt es ja inzwischen auch, aber einen Anwendungsfall sehe ich nicht. -- hgzh 08:23, 9. Feb. 2022 (CET)
Fein, dann bitte gemäß folgendem Schlachtplan immer abwechselnd für die neuen hidden:
  1. Du legst alle Ressourcenseiten mit den Schnipseln an.
  2. Ich schreibe alle Dokus (dafür brauche ich die Ressourcen).
  3. Wenn ich fertig, dann legst du die Beschreibungstexte an, die auf die Doku-Seiten verlinken; also solche Dinger
  4. Danach die MediaWiki:Gadgets-definition ganz unten um alles auf einmal erweitern. Die Dokus enthalten zusätzliche spezifische Infos dafür.
  5. In den Stunden danach die JS und dann die CSS Stück für Stück zurückbauen und auf ruckelfrei erhaltene Funktionalität prüfen.
Die obige Begrenzung der bereits existierenden ist davon nicht betroffen.
Ich habe grad noch zwei neue hinzugefügt.
Bis dann --PerfektesChaos 17:34, 9. Feb. 2022 (CET)
@Hgzh: Spezial:Diff/220105290 historysubmit ist eigentlich seit vielen Jahren veraltet, kann kaum einer in einer wirksamen URL nutzen, aber history muss unbedingt sein. Beide mit Komma schadet nichts. VG --PerfektesChaos 22:51, 11. Feb. 2022 (CET)
Ja, das war ein Test, da nach wie vor auf mw:Action präsent. Scheint aber identisch mit view zu sein. -- hgzh 22:57, 11. Feb. 2022 (CET)
So, ich bin erstmal durch und habe alles einmal durchgetestet. Ein paar Abweichungen zu deiner Liste oben gibt es, da z.B. wikEd auch Diffs beeinflusst. Wirklich relevant sind eigentlich nur edit, history und view. Mal sehen, ob Probleme auftreten. Die hidden-Gadgets kommen dann ein andermal dran. -- hgzh 23:44, 11. Feb. 2022 (CET)
Ja, das sollte jetzt erstmal eine Woche ruhen und auf FZW-Proteste warten.
MediaWiki:Gadgets-definition sollte bis dahin möglichst nicht angefasst werden, um Fehlerberichte nicht zu verfälschen.
Gleichwohl können die Ressourcen-Schnipsel der hidden bereits angelegt werden, ohne sie zu aktivieren, damit ich die Dokus darauf aufbauen kann.
VG --PerfektesChaos 17:12, 12. Feb. 2022 (CET)

Verschiedene hidden Gadgets

Zum Rückbau der MediaWiki:Common.css etc. schlage ich nunmehr die Auslagerung nachstehender Mini-Gadgets vor.

  • Sie sollten in der Regel hidden sein; eine Konfiguration durch Benutzies ist kaum sinnvoll, wäre nur verwirrend und hamwajanochniejemacht.
  • Möglichst alle auf einen Streich und im Zusammenhang mit der Februar-Aktion. Müssen wir nur einmal denken und brauchen uns nur einmal damit befassen.
  • Ich übernehme die Dokus, sobald die CSS-/JS-Seiten angelegt wurden.
  • hidden sollten später en bloc unterhalb der Admins geschrieben werden.

 Info:

  • >99 % der Seitenabrufe sind view.
  • Damit wirkt sich Auslagerung von edit deutlich auf die Masse des Publikums aus.
  • Umgekehrt hätte eine Beschränkung auf view allein fast keine Wirkung. Jedoch ist namespaces= in der Pipeline, und in Kombination damit lässt sich was anfangen.
  • CSS führt nicht zu allzu gravierenden Belastungen; auf ein paar Regeln mehr oder weniger käme es nicht an. Hingegen bewirkt der Start einer JavaScript-Anwendung immer eine deutlich messbare Verzögerung, und hierfür sollte mittelfristig jede vermeidbare Ausführung unterdrückt werden.

Anmerkung:

  • /* Ist hier erstmal geändert, dauert es dank Cache eine Weile, bis die Änderungen bei allen Nutzern sichtbar oder, bei Fehlern, korrigiert sind. */
  • Dieser Satz ist seit 2011 Nonsens. Eigentlich sogar vorher schon, aber da war tatsächlich noch ein Cache für CSS aktiv gewesen.
  • Seit 2011 sorgt der RessourceLoader binnen rund einer halben Minute für Auslieferung und sofortige Wirksamkeit aktueller JS- und CSS-Ressourcen.

Disclaimer:

  • Alle Codes (definition und auch JS) freihändig ungetestet.
  • Unabhängiger Vorab-Test auf BETA empfohlen.

Hinweis zu winwr Scharfschaltung im Februar:

  • Wegen enthaltener JS-Anteile zu wenig frequentierter Nachtstunde innerhalb einer Minute Definitionen aktivieren und gleichzeitig aus MediaWiki:Common.js löschen; weil sonst auf Hauptseite zwei Sprachlink-Geschichten. Dann besser eine Minute lang kein umstilisierter.

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET)

Nur kurz durchgeschaut, möglich wäre wohl noch old-movepage|actions=move. Kann ich gern Anfang bis Mitte Februar umsetzen. Gruß, -- hgzh 08:04, 10. Jan. 2022 (CET)
Jo, jo, soll erstmal ein paar Wochen zur allgemeinen Begutachtung hier stehenbleiben.
Wobei mir in Sachen Upload inzwischen nicht mehr so ganz klar ist, ob es das überhaupt gibt, wann es action ist und wann Spezialseite.
  • Ich lade alle halbe Jahre mal einen Icon hoch, das nur auf Commons und dann gibt es da irgendeinen Wizard und ich weiß nicht so genau welche Konstellationen in Frage kämen.
  • Es gibt mehrere TEXTAREA-Felder, und die sollen mit Sonderzeichen-Service usw. ausgestattet werden.
  • Kann aber ggf. trotzdem bereits in MediaWiki:Gadget-uploadtools.js integriert werden, selbst wenn momentan noch view erforderlich. Das würde ich dann dahingehend neu schreiben, dass es synchron mit der benutzerdefinierten Abschaltmöglichkeit der Sonderzeichenfunktion, LegacyToolbar2006, Extra-Editbuttons diese ebenfalls bleibenlässt, sonst zuschaltet usw.
  • Auf Phabricator hat man Blut geleckt, und sowohl mit namespaces=-1 wie auch irgendwann specialpages , das inzwischen auch herbeigesehnt wird, können die Konstellationen vom massenhaften ANR-view abgegrenzt werden.
  • MediaWiki:Gadget-spezialBeo.js wäre danach der nächste Kandidat.
Ach ja, und in MediaWiki:gadgets-prefstext kann die Verlinkung mit „Weitere Helferlein vorschlagen“ raus. Erstens haben wir seit vor 2009 schon keine Gadgets mehr erfolgreich auf derartige Vorschläge aus dem allgemeinen Publikum hin neu eingerichtet, und außerdem wäre die Zielseite mittlerweile diese hier.
VG --PerfektesChaos 17:52, 10. Jan. 2022 (CET)
Angelegt:
Erstmal nicht angelegt:
  • Prettytable: kann mE die zwei Jahre noch dort verbleiben, der Aufwand lohnt sich da doch nicht mehr wirklich
  • specialInfo: das würde doch höchstens von vier, fünf Leuten genutzt, die sich für die Lintfehler interessieren. Meiner Meinung nach ein Fall für ein selbst einzubindendes Userskript, das nicht jeder bei actions=view bereitgestellt braucht.
Gruß, -- hgzh 17:59, 20. Feb. 2022 (CET)
Danke bis hierhin; ich mach mich im Verlauf der kommenden Woche dann mal auf die Strümpfe mit meinem nächsten Schachzug. VG --PerfektesChaos 18:41, 20. Feb. 2022 (CET)

sourceEditing

// <nowiki>
/* global window: false                                                */
/* jshint bitwise:true, curly:true, eqeqeq:true, latedef:true,
          laxbreak:true,
          nocomma:true, strict:true, undef:true, unused:true           */
( function ( mw, $ ) {
   "use strict";
   $( function() {
      $( "#wpSummary" ).val( function( i, s ) {
            var re;
            if ( s.length > 3  &&
                 s.substring( 0, 2 ) === "/*" ) {
               re = "\\{\\{[\\s_]*:?[\\s_]*(?:(?:Template|Vorlage)[\\s_]*:[\\s_]*)?Anker[\\s_]*\\|[^}]*\\}\\}\\s*";
               re = new RegExp( re, "gi" );
               return s.replace( re, "" );
            }
                                              } );
                 } );
}( window.mediaWiki, window.jQuery ) );
// </nowiki>

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET) ed. 17:52, 10. Jan. 2022 (CET)

desktopHauptseite

.page-Wikipedia_Hauptseite h1.firstHeading,
.page-Wikipedia_Hauptseite #contentSub,
.page-Wikipedia_Hauptseite #contentSub2,
.page-Wikipedia_Hauptseite #catlinks,
.page-Wikipedia_Hauptseite #p-wikibase-otherprojects {
	display: none;
}
  • Kommt von: /* +++++ 3. [[Wikipedia:Hauptseite|HAUPTSEITE]] +++++ */
  • desktopHauptseite[ResourceLoader|default|hidden|actions=view]|desktopHauptseite.js desktopHauptseite.css
  • Erst dann Entlastungswirkung wenn namespaces=4 aktiv.
  • Richtig knallt das, wenn auch transcludes= – damit ist die seitengenaue Fokussierung möglich.
  • Hinweis: Die Desktop-Elemente des Portalrahmens liegen außerhalb des Inhaltsbereichs und sind TemplateStyles damit nicht zugänglich.
  • MediaWiki:Gadget-desktopHauptseite.js
// <nowiki>
/* global window: false                                                */
/* jshint bitwise:true, curly:true, eqeqeq:true, latedef:true,
          laxbreak:true,
          nocomma:true, strict:true, undef:true, unused:true           */
( function ( mw, $ ) {
   "use strict";
   if ( mw.config.get( "wgIsMainPage" ) ) {
      mw.loader.using( [ "mediawiki.util" ],
                       function() { $( function () {
                         mw.util.addPortletLink( "p-lang",
                         mw.util.getUrl( "Wikipedia:Sprachen" ),
                                         "Alle Sprachen",
                                         "interwiki-completelist",
                                         "Liste aller Sprachversionen von Wikipedia"
                                       );
                                                   } );
                                  }
                     );
   }
}( window.mediaWiki, window.jQuery ) );
// </nowiki>

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET)

prettytable

.prettytable {
	background-color: #f8f9fa;
	border: 1px solid #a2a9b1;
	border-collapse: collapse;
	color: black;
	margin: 1em 0;
}
table.prettytable > * > tr > th,
table.prettytable > * > tr > td {
	border: 1px solid #a2a9b1;
	padding: .2em .4em;
}
table.prettytable > * > tr > th {
	/* background-color: #eaecf0; */
	text-align: center;
}
table.prettytable > caption {
	font-weight: bold;
}
  • prettytable[ResourceLoader|default|hidden|actions=view,edit]|prettytable.css
  • Erst dann richtig sinnvoll, wenn namespaces=1,2,3,4,5,100,101
  • Der Abschrecker ist auf 2022/23 ausgelegt und sollte bis dahin für den ANR aktiv bleiben; dann kann der Spaß weg und das letzte Fossil müsste mal was seit 2008 dazugelernt haben.
  • Längerfristig sollte prettytable aber komplett aus dem aktiven Projekt verschwinden.

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET)

mobileHauptseite

VG --PerfektesChaos 17:34, 9. Feb. 2022 (CET)

specialInfo

VG --PerfektesChaos 17:34, 9. Feb. 2022 (CET)

Reif für die Umsetzung

Auf den folgenden drei Seiten

gibt es:

  1. ein Rotlink, für Special:Gadgets auszufüllen,
  2. eine Kopiervorlage für die jeweilige einzufügende Zeile in der Definitionsseite.

Mit deren Aktivierung müsste der entsprechende Part aus den bisherigen Seiten eliminiert werden.

  • Ggf. in den Minuten zuvor.
  • Zweimal CSS schadt nix, aber zweimal JS mag seltsame Effekte haben.
  • Wenn beide aktiv sind, kann man nicht sehen, ob das neue Gadget korrekt wirkt.

Danach kann hier die Schließung bis auf Weiteres erfolgen, viel Spaß --PerfektesChaos 17:06, 7. Apr. 2022 (CEST)

Mach ich, wahrscheinlich entweder heute oder morgen abend. Gruß, -- hgzh 17:22, 7. Apr. 2022 (CEST)
Ist live, scheint erstmal so zu laufen wie erwartet. -- hgzh 00:08, 9. Apr. 2022 (CEST)
Für's Protokoll: eine nächtliche Notkorrektur war noch nötig, ansonsten ist wohl alles gut gelaufen. -- hgzh 12:06, 9. Apr. 2022 (CEST)

Nachdem prettytable in die Tabellenstile-Vorlage gewandert ist und SpecialInfo inzwischen nativ von MediaWiki bereitgestellt wird, setze ich hier mal auf erledigt. -- hgzh 18:22, 24. Feb. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:22, 24. Feb. 2023 (CET)

Änderungen in Syntax der Medieneinbindung

Letzter Kommentar: vor 11 Monaten9 Kommentare3 Personen sind an der Diskussion beteiligt

s. mw:Parsoid/Parser Unification/Media structure/FAQ - Da kommt eine weitere Mammutumstellung auf uns zu. Einige Klassen, die auch produktiv im ANR oder in Vorlagen verwendet werden, sind wohl von Umbenennung betroffen (thumbinner, tleft, tright), zudem ändert sich die komplette Struktur der Medieneinbindung, sodass sicherlich einige Selektoren in Skripten und Stildateien anzupassen sind. Womöglich müssen wir die Klassendefinitionen erst einmal lokal weiterbetreiben, um nicht signifikant Artikelbestand zu zerschießen. -- hgzh 14:07, 30. Nov. 2022 (CET)

Some of these concerns are addressed in the FAQ
https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Media_structure/FAQ/de#Wie_wurde_dies_getestet?
We don't expect there to be any visual differences after this change.
https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Media_structure/FAQ/de#What_about_templates_that_mimic_the_parser_output?
The old styles will continue to be shipped until content that depends on them can be migrated away.
Sorry for the English. --Arlolra (Diskussion) 17:27, 1. Feb. 2023 (CET)
English is absolutely fine within this page.
Regular community might complain, but this is technical environment and software development here.
Greetings --PerfektesChaos 01:01, 2. Feb. 2023 (CET)

Please make changes like the following to MediaWiki:Common.js,

https://ca.wikipedia.org/wiki/Especial:ComparePages?page1=MediaWiki%3ACommon.js&rev1=24309161&page2=Usuari%3AArlolra%2Fsandbox%2FMediaWiki%3ACommon.js&rev2=31054319&action=&unhide=

https://ca.wikipedia.org/wiki/Especial:ComparePages?page1=MediaWiki%3ACommon.js&rev1=31055727&page2=Usuari%3AArlolra%2Fsandbox%2FMediaWiki%3ACommon.js&rev2=31058458&action=&unhide=

For more information, see mw:Parsoid/Parser_Unification/Media_structure/FAQ

Thanks, --Arlolra (Diskussion) 20:29, 31. Jan. 2023 (CET)

Hi @Arlolra, thanks for the notification, I applied the changes in Special:Diff/230416921. Regards, -- hgzh 08:11, 1. Feb. 2023 (CET)
Und was macht dieses Feature auf mobil?
Ggf. lieber Anlage eines galleryTemplate default hidden.
  • Mag dann irgendwann auch fokussierter nach action und Namensraum passieren. Wobei, >99,9 % sind ANR und view.
  • Jedenfalls wäre eine Gadget-Einheit besser dokumentierbar und hat eine hübschere Versionsgeschichte; und lässt sich später im spezifischen Kontext diskutieren. Dieser heutige Abschnitt kann dann die Disku eröffnen.
VG --PerfektesChaos 09:21, 1. Feb. 2023 (CET)
Mobil sind das bloß untereinander angeordnete Bilder und Common.js pfuscht dort dann nicht rein. Aber mittelfristig sollte das, wie (fast) die ganze Common.js, ein Gadget werden, da bin ich bei dir. -- hgzh 09:33, 1. Feb. 2023 (CET)
Insbesondere falls es mal eine kontext-sensitive Auslösung gäbe; heißt: Nur Seiten mit Einbindung template:Galerie lösen die Lieferung des Gadgets für genau diese Seite aus. VG --PerfektesChaos 10:04, 1. Feb. 2023 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 17:31, 29. Nov. 2023 (CET)

MediaWiki:Vector.css coordinates hacks

Letzter Kommentar: vor 6 Monaten21 Kommentare5 Personen sind an der Diskussion beteiligt

Hello, apologies fro writing in English.

The following fragment of MediaWiki:Vector.css has caused conflicts with the MediaWiki software several times, most recently in T315700 and previously in T283427:

/*
 * Die folgenden Regeln ändern den Bezugsrahmen für absolut positionierte
 * Elemente von .mw-body-content nach .mw-body und gleichen in diesem Sinne den
 * Vector-Skin an den Monobook-Skin an, um die von dort „bewährte“ Koordinaten-
 * position über der SiteNotice zu ermöglichen.
 * Dies hat schädliche Auswirkungen, unter anderem bewirkt es, dass der Bereich
 * des Moduls „mw.notify“ für „bubbles“ viel zu weit unten angezeigt wird, vgl.
 * [[phab:diffusion/SVEC/browse/master/skinStyles/mediawiki.notification.less]]
 */
.mw-body {
	position: relative;
	z-index: 0; /* [[phab:T40848]] */
}
#bodyContent {
	position: static;
}

I rely on automatic translation to read German, but the code comment seems to also complain about software issues it causes (added by @Entlinkt in 2016: [2]).

I am wondering what would be needed to allow this code to be removed? --Matma Rex (Diskussion) 01:48, 9. Nov. 2022 (CET)

German native speaker here :)
The edit following up to latest comment made the possible negative impact even toned down. Before it said, that phab:T40848 would be impacted more by the rules (I can't access that restricted task myself).
Given the many extensions possibly impacted by setting `z-index` and not be tested in dewiki, I would strongly advise to remove such general layout rule in just this language wiki. The rule might have made more sense in the shift from Monobook to Vector years ago, but I doubt the benefits with most development being based around Vector-first. – Volker E. (WMF) (Diskussion) 02:27, 9. Nov. 2022 (CET)
Hi, it is planned to remove the absolute positioning of coordinates completely, cf. Wikipedia:Meinungsbilder/Darstellung der Seiten-Koordinaten - however, work on this hasn't started yet as it probably requires changes in a lot of articles. Removing the mentioned code earlier would also require changes to the coordinate positioning section following in Vector.css to prevent interferences with lead elements such as infoboxes. Regards, -- hgzh 07:48, 9. Nov. 2022 (CET)
@Volker E. (WMF) phab:T40848 is public now, by the way, if you wanted to know what it was about. --Matma Rex (Diskussion) 01:55, 30. Nov. 2022 (CET)


I think it's possible to keep the current design for coordinates etc. without the problematic styles.

My suggestion is to replace as follows:

Before After 
/* +++++ Anpassungen für absolut positionierte Objekte: [[phab:T40848]] +++++ */

/*
 * Die folgenden Regeln ändern den Bezugsrahmen für absolut positionierte
 * Elemente von .mw-body-content nach .mw-body und gleichen in diesem Sinne den
 * Vector-Skin an den Monobook-Skin an, um die von dort „bewährte“ Koordinaten-
 * position über der SiteNotice zu ermöglichen.
 * Dies hat schädliche Auswirkungen, unter anderem bewirkt es, dass der Bereich
 * des Moduls „mw.notify“ für „bubbles“ viel zu weit unten angezeigt wird, vgl.
 * [[phab:diffusion/SVEC/browse/master/skinStyles/mediawiki.notification.less]]
 */
.mw-body {
	position: relative;
	z-index: 0; /* [[phab:T40848]] */
}
#bodyContent {
	position: static;
}

/*m
 * Koordinaten und diverse andere Anzeigen oben rechts, siehe
 * [[:Kategorie:Vorlage:mit Seitenindikator#Textelemente]].
 * Beachte, dass diese Elemente im Wikitext an beliebigen Stellen auftreten und
 * deshalb allerhand Eigenschaften erben können. Das gilt insbesondere für die
 * Schriftgröße.
 * Der folgende Darstellungsfehler ist bekannt: Wenn die Fensterbreite kleiner
 * als 982px ist und die Schriftgröße des Wurzelelements wie üblich 16px ist,
 * überlappen sich die 17px hohen Icons der Gadgets „WikiMiniAtlas“ und
 * „OpenStreetMap“ mit der SiteNotice.
 */
#mw-content-text #coordinates,
#mw-content-text #editcount,
#mw-content-text #shortcut,
body.ns-special #mw-content-text .specialpage-helplink {
	display: block;
	font-size: x-small;
	line-height: 1.5;
	position: absolute;
	right: 1.6em;
	text-align: right;
	text-indent: 0;
	top: .2em;
	white-space: nowrap;
}
@media screen and (min-width: 982px) {
	#mw-content-text #coordinates,
	#mw-content-text #editcount,
	#mw-content-text #shortcut,
	body.ns-special #mw-content-text .specialpage-helplink {
		right: 2.4em;
	}
}

/*
 * Koordinaten und diverse andere Anzeigen oben rechts, siehe
 * [[:Kategorie:Vorlage:mit Seitenindikator#Textelemente]].
 * Beachte, dass diese Elemente im Wikitext an beliebigen Stellen auftreten und
 * deshalb allerhand Eigenschaften erben können. Das gilt insbesondere für die
 * Schriftgröße.
 * Der folgende Darstellungsfehler ist bekannt: Wenn die Fensterbreite kleiner
 * als 982px ist und die Schriftgröße des Wurzelelements wie üblich 16px ist,
 * überlappen sich die 17px hohen Icons der Gadgets „WikiMiniAtlas“ und
 * „OpenStreetMap“ mit der SiteNotice.
 */
#mw-content-text #coordinates,
#mw-content-text #editcount,
#mw-content-text #shortcut,
body.ns-special #mw-content-text .specialpage-helplink {
	display: block;
	font-size: x-small;
	line-height: 1.5;
	position: absolute;
	right: 0;
	text-align: right;
	text-indent: 0;
	top: -9em;
	white-space: nowrap;
}

.skin-vector-legacy #mw-content-text #coordinates,
.skin-vector-legacy #mw-content-text #editcount,
.skin-vector-legacy #mw-content-text #shortcut,
body.ns-special.skin-vector-legacy #mw-content-text .specialpage-helplink {
	top: -7em;
}

This places the coordinates in almost exactly the same location (and also corrects the positioning on Vector 2022). Matma Rex (Diskussion) 18:49, 28. Nov. 2022 (CET)

@Matma Rex: Hi, on this page here English is fully okay.
Thanks for your efforts, but we already decided to discontinue CSS hacks and insert regular HTML DOM instead, as soon we are triggered to do so.
Positive reasons:
  • Better visibility for persons with bad eyes, typing data into other device.
  • Multiple “page coordinates” possible, e.g. city center narrowed and also surroundings with 50 pins of landmarks, or dealing with two relevant locations within one page.
  • Longer and unlimited texts, remarks.
  • Possibility to offer not only one tool link, but perhaps multiple services for this location.
  • Works on App as well.
  • Link to “page coordinates” still in top region via <indicator> and giving the classic feeling and functionality.
  • Robust solution, no maintenance efforts any longer.
Negative reasons:
  • More and more difficult to find sufficient gap on various skins each and mobile etc.
  • Out of content clipboard.
  • Always afraid to be forced to maintain.
  • Not available on mobile interface, out of content clipboard, no predictable gaps.
Greetings --PerfektesChaos 17:55, 29. Nov. 2022 (CET)
@PerfektesChaos I saw the discussion that @hgzh linked above (Wikipedia:Meinungsbilder/Darstellung der Seiten-Koordinaten), and I agree that it would be better to avoid absolute positioning here (one way or another), but if I'm reading it correctly, the vote has been closed in March 2021; it is almost 2023 now, and yet this code is still there. I'd still like to replace the current version with my proposal, even if someone is going to delete it for good soon. --Matma Rex (Diskussion) 19:40, 29. Nov. 2022 (CET)
@Matma Rex your code would change positioning of the link when a CentralNotice is displayed. Not sure if a jumping coordinates link while showing/hiding CNs is a considerable disadvantage and leads to a significant amount of misclicking etc. But I think that is the reason why the current code was originally implemented. -- hgzh 13:05, 30. Nov. 2022 (CET)
@hgzh Thanks, I didn't realize that; but now that I tested it, I think it looks good enough: before, after (testing on [3]). I even like having the coordinates more "connected" with the article. --Matma Rex (Diskussion) 14:44, 30. Nov. 2022 (CET)
So… Would anyone oppose replacing the current styles with my proposal? If no one objects, I will make the changes later this week. (I'm a global interface editor and I can edit the page myself.) --Matma Rex (Diskussion) 19:52, 11. Dez. 2022 (CET)
I'm fine with the change, we'll see if there will be some reactions because of the points I mentioned in my previous statement. Considering the disadvantages the current code has, for me, it seems acceptable. -- hgzh 14:55, 13. Dez. 2022 (CET)

I applied the changes. Matma Rex (Diskussion) 12:01, 15. Dez. 2022 (CET)

Seems like we need a slightly higher y pos moving (10em) for vector-2022, the coordinates are currently unaccessible due to the language switcher. -- hgzh 17:09, 15. Dez. 2022 (CET)
To me it looks fine, where do you see the problem? But overall it is a pretty counterintuitive position for anything related to the article content, so we really should find a better way of dealing with the coordinates soon. --XanonymusX (Diskussion) 17:28, 15. Dez. 2022 (CET)
Ritchie Point, but seems to be Firefox specific, Edge has correct positioning and I guess Chrome too. In Firefox, positioning is correct if there are page indicators. And you're right, we need an alternative solution here. -- hgzh 19:51, 15. Dez. 2022 (CET)
This is very surprising, this only happens on Firefox and only on some pages (e.g. I don't see the issue on Berlin, where I did most of my testing). It seems to be affected somehow by the FlaggedRevs interface? I reverted the change for now, I will figure it out tomorrow. --Matma Rex (Diskussion) 20:37, 15. Dez. 2022 (CET)
I tracked down the browser inconsistency and reported it as https://bugs.chromium.org/p/chromium/issues/detail?id=1401690 (it turns out to be a Chrome bug after all; Firefox's rendering was correct, and my styles only worked correctly on articles with an audio version or good article badge). --Matma Rex (Diskussion) 14:22, 16. Dez. 2022 (CET)
I applied the changes again, with an extra addition to fix this problem. Hopefully everything works correctly this time. Thank you for testing. --Matma Rex (Diskussion) 15:13, 16. Dez. 2022 (CET)
(I also filed T325391 about the previous problem, since it turns out that it also affects several other Wikipedias.) --Matma Rex (Diskussion) 21:02, 16. Dez. 2022 (CET)
Mit Vector-Zebra fliegen uns die Koordinaten wieder um die Ohren, da der vertikale Weißraum zwischen Header und Inhalt reduziert wurde. Einfachster fix wäre wohl, diesen wieder um 1em hochzusetzen. -- hgzh 08:21, 12. Dez. 2023 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 11:34, 7. Mai 2024 (CEST)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Skin/MediaWiki/Änderungen/Archiv/2022&oldid=245189227“