Vorlage Diskussion:MediaWiki-Button

Unterschiedlicher Klickbereich des Buttons?

@Inkowik, Mps: Vielen Dank für das Hinzufügen dieses Buttons. Mir ist aufgefallen, dass ein Klick auf den Button an verschiedenen Positionen nicht immer die gleiche Wirkung hat. Ich habe das mal den "Klickbereich" genannt. Vergleichen wir den blauen Button "Anmelden" auf Spezial:Anmelden mit dem blauen Button "Stelle deine Frage zur Wikipedia" auf Wikipedia:Fragen zur Wikipedia, so fällt ein Unterschied auf: Beim ersten Button kann man überall hinklicken, sowohl auf den Link als auch irgendwo auf das blaue, und man kann sich anmelden. Beim zweiten Button muss man auf den Link klicken um eine Wirkung zu erzielen; ein Klick auf den blauen Bereich hat keine Wirkung. Wisst ihr, woran das liegt? Ist das so gewollt? Vielen Dank und beste Grüße, --Soluvo (Diskussion) 03:56, 30. Dez. 2016 (CET)

• Deine Beobachtung ist richtig.
  • Auf den nur vom Server generierten Seiten steht das HTML-Element <button>.
  • Dieses ist tatsächlich auf dem gesamten Feld anklickbar.
  • Wenn es von MediaWiki nicht einheitlich umdekoriert würde, wäre die Getaltung dem Browser überlassen und könnte so oder so aussehen.
• Die umseitige Vorlage simuliert dies durch einen ganz normalen Link.
  • Das ist das HTML-Element <a>.
  • Tatsächlich ist wie bei jedem Link nur der Schriftzug anklickbar.
  • Das Blau drumrum ist hier nur die Dekoration auf dem Schnitzelteller und wird nicht mitgegessen.
• Es gibt noch mehr Unterschiede; und zwar, wenn der Mauszeiger über dem Dingens schwebt:
  • Beim Textlink wird im Allgemeinen (je nach Browser und persönlicher Konfiguration) eine Unterstreichung des Textes sichtbar, und das Linkziel (URL) erscheint ggf. in einer Statuszeile des Browsers.
  • Beim echten Button gibt es sowas nicht. Dafür hat der MW-Button einen Wechsel des Blautons hineingespielkindert bekommen.
  • Beiden gemeinsam ist, dass sie einen Tooltip zeigen können; beim Link auf eine Wiki-Seite ist das der Name der Wiki-Seite. Für Buttons kann das gesondert konfiguriert sein.
• Gewollt ist es nicht wirklich, jedoch praktisch unvermeidlich.
  • Aus Sicherheitsgründen sind die HTML-Elemente <a> und <button> im Wikitext nicht erlaubt.
  • Auch wenn ich das, wie gerade eben, in den Quelltext hineinschreibe, wird es vom Wiki-Server unwirksam gemacht.
  • Theoretisch könnte man für alle Benutzer ein Gadget schreiben, das in allen Seiten nach dem Format wie umseitig benutzt sucht und die Textlinks nachträglich in Buttons umschreibt. Das wird aber niemand machen, und schon aus Performance-Gründen niemand für alle Benutzer aktivieren.

VG --PerfektesChaos 09:32, 30. Dez. 2016 (CET)

Man kann das ändern ich weiß, dass ich diese Frage auch schon einmal gestellt hatte.

Vorher	Nachher
nur im Bereich des weißen Textes klickbar Hierhin klicken zum Bearbeiten!	kompletter Buttonbereich aktiv Hierhin klicken zum Bearbeiten!

Das war bei dem Intro der Spielwiese und dort wurde es dann angepasst damit man den kompletten Button anklicken kann. --Liebe Grüße, Lómelinde Diskussion 11:59, 30. Dez. 2016 (CET)

Reschpekt, Reschpekt.

Das „Nachher“ ist zwar immer noch nur ein <a>, aber integriert das blaue Drumrum in die Textdekoration der Linkbeschriftung und macht dadurch alles anklickbar.

Die umseitige Programmierung ist ja schon längst und wohl von vornherein in diesem Sinne geschrieben.

Die Spielwiese sollte danach im Gegenzug auch mit dieser Vorlage ausgestattet werden, damit es einheitlich zu pflegen ist. Irgendwie müssten sich über die Klassen diejenigen blauen „Buttons“ finden lassen, die noch nicht die Vorlage benutzen, und bei denen der beanstandete Nur-Schriftzug-Effekt auftritt.

LG --PerfektesChaos 12:48, 30. Dez. 2016 (CET)

@PerfektesChaos: „Die umseitige Programmierung ist ja schon längst und wohl von vornherein in diesem Sinne geschrieben.“ Worauf beziehst Du dich hier bzw. was meinst Du mit "diesem Sinne"? Beste Grüße, --Soluvo (Diskussion) 01:48, 2. Jan. 2017 (CET)

HNY.

• Die Programmierung sah auf den ersten Blick für mich danach aus, als ob es schon so gemacht worden sei.
• War aber bisher nur die halbe Miete.
• Ich habe es soeben geändert.

VG --PerfektesChaos 10:34, 2. Jan. 2017 (CET)

HNY 4 U 2 :) (nachdem ich herausgefunden habe, dass HNY in diesem Kontext wohl nicht "honey" bedeutet)

• Jetzt funktioniert es, vielen Dank! Beste Grüße, --Soluvo (Diskussion) 17:55, 2. Jan. 2017 (CET)

Was mir gerade aufgefallen ist: Wenn man auf Vorlage:MediaWiki-Button auf den Button klickt, so funktioniert das Klicken auch auf dem farbigen Bereich. Bei der Wikipedia:Fotowerkstatt funktioniert es wie bisher nur auf dem Link. Bei WP:Fragen zur Wikipedia ist es so ein Zwischending. Weißt Du, woran das liegt? Schließlich verwenden alle die gleiche Vorlage. Vielen Dank und beste Grüße, --Soluvo (Diskussion) 17:55, 2. Jan. 2017 (CET)

Ja, weiß ich.

Weil die sich überflüssige Extrawürste gebraten haben. Damit klappt der heute neu installierte Kniff halt nicht.

VG --PerfektesChaos 18:52, 2. Jan. 2017 (CET)

Liegt es am <span/>-Attribut? --Soluvo (Diskussion) 19:06, 2. Jan. 2017 (CET)

Habe es gerade ausprobiert, es liegt nicht am span-Attribut. Woran liegt es dann? --Soluvo (Diskussion) 19:09, 2. Jan. 2017 (CET)

An der Freitext-Option und diversen Formatierungswünschen.

Die Vorlage kann den blauen Bereich nur dann klickbar machen, wenn sie die volle Kontrolle darüber hat; auf den fraglichen Seiten greift man aber mit Sonderwünschen ein – genauer: Die haben geschrieben, das sie das alles selbst regeln wollten. Bis heute machte das ja auch keinen Unterschied.

Es ist egal, es hat jetzt wohl über ein Jahr lang auch so funktioniert, und es haben alle irgendwie hinbekommen, und mir war bis vor drei Tagen der Unterschied noch nicht mal aufgefallen, weil ich gewohnheitsmäßig sowieso immer die Schrift anklicke.

VG --PerfektesChaos 19:20, 2. Jan. 2017 (CET)

Alles klar, Danke für Deinen Hinweis. Vielen Dank und beste Grüße, --Soluvo (Diskussion) 19:57, 2. Jan. 2017 (CET)

Parameter "constructive" kann aus der Vorlage entfernt werden

@Inkowik, Hgzh, PerfektesChaos, Mps, Patrick87: Guten Abend! Mit der Hilfe von Petscan (siehe hier) habe ich gerade alle 298 Suchtreffer, die die Vorlage:MediaWiki-Button enthalten, auf die Verwendung des Parameters constructive geprüft. Sechs Einbindungen konnte ich noch finden und habe "constructive" jeweils durch "progressive" ersetzt (Vergleich: Spezial:Beiträge/Soluvo). Jetzt sollte der Parameter "constructive" kein einziges Mal mehr in Verwendung sein, sodass er komplett aus der Vorlage:MediaWiki-Button entfernt werden kann. Vielen Dank und beste Grüße, --Soluvo (Diskussion) 23:51, 8. Mär. 2017 (CET)

Ja, schönen Dank, ich kümmere mich heute abend drum, bin grad unterwegs. LG --PerfektesChaos 15:42, 9. Mär. 2017 (CET)

Bitte Parameter "Freitext" aus der Vorlage entfernen

@Inkowik, Hgzh, PerfektesChaos, Mps, Patrick87: Mit derselben Suche über Petscan (siehe hier) habe ich ebenfalls alle 298 Suchtreffer nach der Verwendung des Parameters "Freitext" durchsucht. Sieben Einbindungen konnte ich finden, von denen ich bei fünf den Parameter "Freitext" durch "Link" o.ä. ersetzt habe. Bei den restlichen zwei Verwendungen handelte es sich um Archive (hier und hier). Dort war ich mir nicht sicher, ob ich das Archiv verändern soll und habe es erstmal nicht gemacht. Soll ich auch diese beiden Einbindungen anpassen? Der Parameter "Freitext" kann nun komplett aus der Vorlage:MediaWiki-Button entfernt werden. Beste Grüße, --Soluvo (Diskussion) 15:38, 9. Mär. 2017 (CET)

Ja, schönen Dank, das wird die Programmierung bald deutlich vereinfachen; ich kümmere mich heute abend drum, bin grad unterwegs.

Für erstaunte Mitleser: Beim Parameter Freitext= war nur der Schriftzug und nicht die (meist blaue) Fläche drumherum anklickbar.

LG --PerfektesChaos 15:42, 9. Mär. 2017 (CET)

Zwei Buttons nebeneinander nicht mehr möglich?

Kann es sein, dass es durch eine Änderung an dieser Vorlage nicht mehr möglich ist, zwei oder mehrere dieser Buttons auf der x-Achse nebeneinander zu platzieren? Man schaue sich zum Beispiel die Wikipedia:Kartenwerkstatt an. Der blaue und der weiß-graue Button waren, wenn ich mich richtig erinnere, mal auf einer Achse positioniert. Nun sind sie untereinander. Entweder ich liege falsch oder diese Funktion ist durch eine Änderung an der Vorlage deaktiviert worden. Wer weiß genaueres? Vielen Dank und beste Grüße, --Soluvo (Diskussion) 17:17, 27. Aug. 2017 (CEST)
PS: Unter anderem Ping @PerfektesChaos. --Soluvo (Diskussion) 17:18, 27. Aug. 2017 (CEST)

Geht schon, aber dann müsste das in der Tabelle von Wikipedia:Kartenwerkstatt/Intro auch entsprechend strukturiert sein.

Ds momentane Layout ist ein Drei-Spalten-Layout, mit einer zwischen Bild links und Box rechts eingequetschten Überschrift und Textspalte, das ist ohenhin befremdlich.

Auf normalen Bildschirmfenstern und Mobilgeräten ist die mittlere Textspalte ohnehin zu schmal für zwei Buttons nebeneinander.

Das gesamte Layout dieses Kastens sollte überarbeitet, modernisiert und flexibilisiert werden.

VG --PerfektesChaos 17:25, 27. Aug. 2017 (CEST)

Alles klar, danke für Deine Antwort. Ich werde mal schauen, was sich da machen lässt. Kannst Du mir einen Link zu einem Kasten schicken, der technisch "gelungen" bzw. gut umgesetzt ist? Dann kann ich mich daran ein wenig orientieren. Danke, --Soluvo (Diskussion) 11:14, 5. Sep. 2017 (CEST)

Wir hatten das schon mal, vielleicht vor einem Jahr: Einleitungsabschnitt wie bei einem Artikel, kein Kasten drumrum, Thema in Fettschrift, kein Willkommen. Gibt Hunderte von Metaseiten nach diesem Schema. Ein Überraschungs-Beispielbild ist nur entbehrliches Extra-Gimmick und solllte nicht die allerprominenteste Aufmacher-Stelle links oben einnehmen, sondern käme hinten unten unter ferner liefen. LG --PerfektesChaos 11:19, 5. Sep. 2017 (CEST)

Ok, ich werde mich mal versuchen. Danke auf jeden Fall. --Soluvo (Diskussion) 20:58, 18. Sep. 2017 (CEST)

MediaWiki.UI ist deprecated

Mit [1] wurde MediaWiki.UI offiziell als deprecated markiert (inoffiziell ist MediaWiki.UI ja schon seit Jahren deprecated). Es ist also damit zu rechnen, dass über kurz oder lang die entsprechenden Stile nicht mehr geladen werden und in der Folge diese Vorlage so nicht mehr funktionieren wird. –Schnark 10:48, 3. Nov. 2017 (CET)

Tjo, deshalb sind alle verstreuten Direkteinbindungen und Alternativvorlagen einkassiert worden und auf die bald 5.500 einheitlichen Einbindungen dieser Vorlage konzentriert worden.

Wenn du grad im OOUI-Thema sein solltest, kannst du ja mal eine Gegenüberstellung der bisher verwendeten und zukünftigen Klassen-ID hier reinschreiben.

Ansonsten erforsche ich die bei Gelegenheit; wird ja noch ein paar Monate Zeit haben.

Eine Doku-Seite der robust dauerhaft verwendbaren Klassenbezeichnungen und ihrer Wirkung gibt es bei MediaWiki nicht zufällig?

VG --PerfektesChaos 11:46, 3. Nov. 2017 (CET)

OOjs UI ist – wie schon der Name sagt – nicht rein deklarativ, eine einfache Umstellung daher nicht möglich. Irgendwann, möglicherweise ohne Vorankündigung, werden halt die CSS-Dateien nicht mehr geladen, was dann insbesondere bei den Schaltflächen mit weißer Schrift dazu führt, dass diese gar nicht mehr lesbar sind. Eine Liste mit existierenden Klassen und IDs gibt es: mw:Manual:Interface/IDs and classes#Content und ich würde mich ehrlich gesagt auf nichts verlassen, was dort nicht drin steht. –Schnark 12:08, 3. Nov. 2017 (CET)

Die Liste kenne ich, aber das sind keine OOUI.

Solange die Klassen noch auf dem Server sind, können wir sie als zweite Gnadenfrist bedarfsweise per JS nachladen, wie wir das bei dem zwischenzeitlich eliminierten jquery.ui auch gemacht hatten.

Irgendwo werden sich die Klassen finden lassen, die Spezialeffekte für die paar Vorder- und Hintergrundfarben liefern.

Blanke Farben lassen sich auch per Inline-style als Rückfallposition sicherstellen, und von geladenen Stilen verfeinert überschrieben mit aktuellen Farbnuancen, Luxus-Design und Hover-Effekt.

Der Speichern-Button meines Quelltextedits behauptet: .oo-ui-buttonElement-framed .oo-ui-widget-enabled .oo-ui-flaggedElement-primary .oo-ui-flaggedElement-constructive > .oo-ui-buttonElement-button

VG --PerfektesChaos 12:25, 3. Nov. 2017 (CET)

Die Struktur von OOjs-UI-Elementen kann sich aber jederzeit und ohne Vorwarnung ändern. Auch kann es passieren, dass eine Klasse direkt am <a>-Element erwartet wird, was mit Wikitext nicht möglich ist. Ein OOjs-UI-Button wird per new OO.ui.ButtonWidget() erstellt, nicht, indem man irgendwelches HTML von Hand zusammenbastelt.

Ein Nachladen per JS ist in diesem Fall höchst problematisch, weil Schaltflächen in weiß auf blau für Leute mit altem Browser/deaktiviertem JS zu weiß auf weiß führen würden (weil die Textfarbe als Inline-CSS angegeben ist). Bei jquery.ui waren die immerhin ohne die vorgesehenen CSS-Dateien lesbar. –Schnark 10:46, 4. Nov. 2017 (CET)

• Die Button-Definition sollte nur auf statischer HTML-Ebene erfolgen und nichts dynamisch generieren.
  • Damit sieht es mit oder ohne aktives JS für alle Benutzer immer gleich aus.
  • Probleme durch Software-Änderungen fallen dadurch auch den Techies schnell auf, die mutmaßlich alle mit aktivem JS unterwegs sind.
• Für den Fall, dass gar keine Klassen geladen wurden, sollte es ein Inline-Fallback geben.
  • Gibt es im Prinzip heute schon, aber noch nicht für alle Parameter.
  • Die generieren mit Schriftfarbe, Hintergrundfarbe und Schriftgröße ein erstmal ähnliches, wenn auch etwas plumperes Minimal-Design.
• Geladene Klassen verfeinern das dann nur und liefern aktuelle Moden zu; hover-Effekt, Rahmen, Rundungen, Farbnuancen usw.
• Wenn Klassen explizit nur für <a> spezifisch sind, kann ich es auch nicht ändern und müsste ggf. auf diese verzichten; hab aber irgendwie noch keine gesehen.
• Was anderes als sicherzustellen, dass alle 5.500 offiziellen Anwendungen über diese eine Vorlage geleitet werden, und erforderlichenfalls diese eine Vorlage kurzfristig nachzuführen, können wir ohnehin nicht tun. Oder wir stellen sämtliche Buttons auf Browser-Style (im Wikitext nicht verfügbar) oder ein abgekoppeltes dewiki-Privat-Design um.
• Es scheint so, dass die OOUI-Klassen in jeder Seite bekannt sind.
  • Ob das explizite Vorgabe ist (pre-emptive?), oder ob irgendeine dependency irgendeines Moduls das jeweils auslöst, ist kaum festzustellen.
  • Falls sich herausstellen sollte, dass die auf Seiten bestimmter Typen fehlen, kann man immer noch mit JS derartige Seiten auf Existenz des Buttons durchsuchen und aktiv nachladen.
  • Benutzer mit deaktiviertem JS können davon nichts mitbekommen, da sie auch kein MW:Common.js bekommen.
  • Alte Browser (welche, mit welcher Einschränkung?) interessieren mich nicht die Bohne. Ich wüsste keine unterstützten, die ein Problem hätten.
• Ich beabsichtige das Fallback in zwei Ebenen zu strukturieren, wie oben bereits angedeutet:

  • <div> oder <span> mit style=
    • <span> mit class=

  • Falls die Klasse ausfällt, wirkt nur Inline-Style.
  • Falls die Klasse geladen ist, mag sie überschreiben, was immer sie für richtig hält. Müsste ja in etwa wie der Inline-Style aussehen.
  • Fies wäre nur, wenn einzelne Klassennamen nicht mehr gültig wären und die noch gültigen andere Bedeutungen bekämen. Dann könnte theoretisch weiß-auf-weiß auftreten. Das würde aber freitags um zwei Uhr morgens auf FZW aufschlagen.
  • Löschung zerstörerischer Klassennamen bringt erstmal wieder den Fallback-Modus.
• Du kannnst dich ja mal auf Phab für einen standardisierten garantierten dokumentierten Minimal-Satz an Klassen stark machen.

VG --PerfektesChaos 13:05, 4. Nov. 2017 (CET)

Inzwischen per templatestyles (seit Frühjahr 2018) eine robuste lokale Kopie vorhanden.

• Damit sind wir zwar von serverseitiger Aktualisierung abgekoppelt, aber die wäre für eine deprecated ohnehin nicht mehr zu erwarten.
• In der optischen Wirkung entspricht das zumindest einer Teilmenge von OOjs.ui, nur die Klassen heißen anders und OOjs.ui kennt noch ein Dunkelblau. Uns interessieren aber in erster Linie die königsblauen Knöppe, und gut ist.
• Bis sich das Designschema mal wieder fundamental ändert und psychologisch auf bonbonrosa in popelgrün umgestellt wird, mag es also so bleiben.

VG --PerfektesChaos 11:05, 6. Dez. 2018 (CET)

Weiße Schrift auf weißem Hintergrund (progressive-Buttons im Timeless-Skin)

Die Vorlage generiert im Timeless-Skin Buttons mit weißer Schrift auf weißem Hintergrund, augenscheinlich immer dann wenn der Button-Typ progressive genutzt wird. Kann das irgendwie verändert werden? —MisterSynergy (Diskussion) 17:01, 5. Dez. 2018 (CET)

Vermutlich, aber meine böse Vermutung wäre, dass diese Skin standardmäßig nicht die Klasse für blau-Effekt lädt.

Es gibt allerdings eigentlich eine inline-style-Rückfallposition für diesen Fall, zumindest in einigen solcher unserer Programmierungen.

LG --PerfektesChaos 17:04, 5. Dez. 2018 (CET)

Siehe ein Abschnitt drüber von vor einem Jahr. Wird dann wohl auch hier fällig. LG --PerfektesChaos 17:08, 5. Dez. 2018 (CET)

Verstehe nicht recht. Ist das ein Bug im Skin, oder im Code dieser Vorlage? Wo könnte ich einen Skin-Bug melden, und was genau würde fehlen? Der Effekt kann einfach über https://de.wikipedia.org/wiki/Vorlage:MediaWiki-Button?useskin=timeless anhand der Beispiele reproduziert werden, oder in gleicher Weise auf diversen Produktivseiten (FZW, VM, und so weiter). Das Problem besteht im Übrigen schon länger.
Der Abschnitt drüber erfordert tiefgehende Kenntnis der ganzen Mediawiki-Skriptmechanik, das ist auf Anhieb zu komplex für mich. —MisterSynergy (Diskussion) 17:14, 5. Dez. 2018 (CET)

Ich mutmaße ein Veralten der Klassen/Designkonzepte.

Wir hatten jquery.ui, die Vorlage arbeitet mit dem neueren mediawiki.ui, aber momentan ist OOjs.ui in Mode.

Da es aber zwischenzeitlich templatestyles gibt, fasse ich das ins Auge, bin jedoch mit dem Denken noch nicht fertig.

Die mediawiki.ui wird vermutlich nicht mehr wie früher in jede Seite geladen.

Bug ist es keiner, weil jede Anwendungsseite beim Server explizit die Ressourcen anfordert, die sie benötigt; die Vorlage hier simuliert hingegen ein Verhalten auf einer normalen Wikitext-Seite. Die bekamen bislang dieses Modul pauschal mitgeliefert.

LG --PerfektesChaos 19:25, 5. Dez. 2018 (CET)

1. Ich habe Vorlage:MediaWiki-Button/styles bereitgestellt.
   • Damit wären wir zukünftig unabhängig, falls das Modul irgendwann nicht mehr geladen würde.
   • Ist hier aber unschuldig.
2. Es ist offenkundig ein Timeless-spezifischer Bug.
   • Wunderte mich schon etwas, warum sich das je Skin anders im Ladeverhalten ergeben sollte, und warum das in rot funktioniert, und weitere ebenso in Timeless.
   • Problem liegt in: skins.timeless
     • Suche nach: progressive
     • Dort ist definiert: background: #ffffff;
     • Muss unverändert bleiben: background-color: #3366cc;
3. Damit das jetzt erstmal wieder bedienbar wird, habe ich einstweilen unsere templatestyles in der Vorlage aktiviert. Die drängelt sich vor.
4. Bist du in der Lage, einen Bugreport zu schreiben?
   • Quelle ist: forms.less
     • Zeile 125: background: @background;
     • @background kommt aus: variables.less
   • Änderungen sind von 2015 etc.; das Problem muss es schon länger geben. Keine frischen Modifikationen.
   • Es gibt allerdings zwei progressive-Modi, primary (blauer Hintergrund) und normal (hellgrauer Hintergrund).

LG --PerfektesChaos 01:23, 6. Dez. 2018 (CET)

Danke, jetzt passt das alles. Ich drängle mich nicht vor zum Bugreport schreiben, und da ich weiterhin nur sehr oberflächlich das Problem erkenne, wäre ich Dir dankbar, wenn Du das machen könntest. —MisterSynergy (Diskussion) 12:29, 6. Dez. 2018 (CET)

Fehlverhalten in Minerva

Per phab:T294191: Ich versuche mal zu ermitteln, welche Definitionen des Stylesheets dieser Vorlage in Minerva nicht wirken dürfen. In erster Linie sind das min-width:4em; padding:0.546875em 1em; font-size: 1em; line-height: 1.286;. Am besten wäre, wenn das ganze Stylesheet in Minerva schlicht ignoriert würde (Mobilgeräte würde es freuen). Das lässt sich aber wohl nicht einrichten. Möglich wäre dann wohl, den ersten Anweisungsblock im Stylesheet zu doppeln, einmal verkürzt skinspezifisch für Minerva und einmal für die anderen Skins. Gruß --XanonymusX (Diskussion) 20:53, 7. Aug. 2022 (CEST)

Die haben ja eine Skin-spezifische Klasse pro Seite, nur so oft umbenannt dass ich nicht mehr weiß wie die neue minerva frontend heißt, und die kann dann unter den dich interessierenden Umständen irgendeine Größe auf was anderes setzen. TemplateStyles wirken halt auf alle Skins, anders als CSS-Ressourcen. VG --PerfektesChaos 21:20, 7. Aug. 2022 (CEST)

ach nee, die Skin-Klasse liegt ja oberhalb von parser-output, dann geht das nicht.

Dann halt @ wie in Phab umrissen.

Viel Spaß --PerfektesChaos 21:25, 7. Aug. 2022 (CEST)

Nee, Mediaqueries bringen nichts, wenn man Minerva auf Desktop nutzt. Man kann TemplateStyles aber problemlos skinabhängig gestalten, die Möglichkeit gibt es schon lange. Im Übrigen sehe ich es nicht als meine Verantwortung, diese Fehler auszubügeln, aber da es wohl unter meine Expertise fällt, werde ich mich mal dran versuchen. Gruß—XanonymusX (Diskussion) 21:37, 7. Aug. 2022 (CEST)

Habe mal eine Korrektur vorgenommen. Die Edit-Icons sind jetzt endlich wieder im alten Zustand. Die line-height:0 ist für die Buttons leider nicht immer verträglich, das muss ich mir noch genauer anschauen. --XanonymusX (Diskussion) 20:41, 8. Aug. 2022 (CEST)

Vorlage:MediaWiki-Button/styles.css

Da ist irgendetwas schief gelaufen, denn nun verschwindet beim Mouseover die Farbe des Textes. Das ist nicht sehr schön.

OOjs-ui progressive

OOjs-ui destructive

Und das wirkt sich auch auf andere Vorlagen aus {{Hilfe/clickbutton|mw=p|alles wird blau}} → alles wird blau Ich möchte aber, dass der Text sichtbar bleibt →der Text soll sichtbar sein Bei so etwas bin ich recht mäkelig. Es betrifft nur „progressive“, soweit ich es gesehen habe. Ich vermute mal das liegt an →Zeile 109,

color: var(--color-progressive--hover,#447ff5);

da müsste

color: var(--color-progressive--hover,#ffffff);

stehen, oder? Ich möchte aber ungern selbst daran herumspielen. --Liebe Grüße, Lómelinde Diskussion 10:38, 14. Mai 2024 (CEST)

Theoretisch sollte es var(--color-inverted-fixed,#ffffff) sein. -- hgzh 11:11, 14. Mai 2024 (CEST)

Wie gesagt, ich möchte da ungern herumprobieren, ohne zu wissen, was ich tue. Es ist aber mit der angesprochenen →Änderung gekommen. --Liebe Grüße, Lómelinde Diskussion 11:26, 14. Mai 2024 (CEST)

Danke für den Hinweis.

Ich war mitten in der Nacht wohl schon zu groggy.

Ich versuche heute Nacht, wenn es kühler ist und ich in besserem Zustand zwischen hundemüde und wiederwach bin, diese Stelle zu reparieren.

Ich probierte, mich den neumodischen variablen Skin-Umgestaltungen vorsorglich anzupassen.

Wobei mich phab:T364685 noch zusätzlich aus der Kurve trug.

Warum --color-progressive--hover ungeeignet für color: progressive:hover sein muss, aber verwendet wird in .cdx-button:enabled.cdx-button--action-progressive:hover brauch ich in diesem Leben nicht mehr zu begreifen.

Ob das serverseitig zukünftig mit irgendwelchem cdx produziert würde, kann uns jedoch egal sein; unsere Vorlageneinbindungen können weiterhin diese zweite Design-Generation verwenden, bis die Chef-Designer mal wieder ihren persönlichen Geschmack voll ausleben und die Systematik komplett auf links drehen.

VG --PerfektesChaos 16:07, 14. Mai 2024 (CEST)

Das eine ist die progressive-Vordergrundfarbe (blau auf weißem Button), das andere die Hintergrundfarbe (weiß auf blauem Button); das jeweils andere ist dann die inverted-Farbe, so habe ich das jedenfalls verstanden. -- hgzh 16:57, 14. Mai 2024 (CEST)

Habe ich jetzt wie korrekt angeregt korrigiert.

• Nun warten wir mal, bis wir rosa Buttons mit mintgrüner Schrift von der Design-Abteilung verordnet bekommen.

Sorry for inconvenience --PerfektesChaos 22:25, 15. Mai 2024 (CEST)