Vorlage Diskussion:Hinweisbaustein

Heute neu eingefügter Parameter ICON.width

Die unabgesprochenen Einfügungen min-width: 50px und ICON.width scheinen mir auf einem Denkfehler zu beruhen.

• Eigentlich müssten mobile genauso wie Desktop-Anwendungen sich die Breite des Icon-Bereichs selbst justieren, und müssten das ja auch schon seit 2020 korrekt gemacht haben, sonst hätte sich da längst jemand beschwert.
• @Hgzh, XanonymusX: Könntet ihr bitte mal verifizieren, ob das überhaupt sinnvoll ist, ggf. in TemplateStyles mobilgerecht konfiguriert werden müsste, und bei Nichtgefallen revertieren und vollschützen?
• Bei einer Vorlage mit 928.363 Einbindungen sehe ich solche unkoordinierten Spontan-Aktionen extrem kritisch.
• Diese Diskussionsseite fand ich als Rotlink vor. Sowas ist zwingend zuallererst hier oder in der VWS vorzuschlagen und angemessene Zeit für Reaktionen abzuwarten.

VG --PerfektesChaos 21:11, 29. Okt. 2023 (CET)

Ohnehin gibt es Icons, die deutlich schmaler als 50px sind, oder dies dürfen. Die eingefügte feste Mindestvorgabe 50px für sämtliche Icons Desktop und mobil ist auf alle Fälle Bockmist, weil sie grundlos das linke Feld übermäßig verbreitert und den Text wegschiebt. --PerfektesChaos 21:19, 29. Okt. 2023 (CET)

Und Vorlage:Gesundheitshinweis beispielsweise sind es 25px, und die würden durch diese unqualifizierte Mindestbreite jetzt sinnlos aufgebläht.

Ich werde diese Bastelei deshalb in Kürze revertieren.

Wenn etwas in fast eine Million Seiten eingebunden ist, dann werden möglicherweise in irgendeiner Konstellation auf irgendeinem Gerät mit irgendeinem Browser auftretende Darstellungsprobleme erstmal mit konkreten Angaben geschildert, etwa hier auf der zuständigen Disk oder in WP:VWS oder WP:TWS. Und nicht mal so eben hemdsärmelig ein nicht zu Ende gedachter spontaner Rappel in die produktive Version eingepflegt. Wenn wir etwas erproben wollen, dann geschieht das per WP:BETA. Mag ja durchaus sein, dass irgendwas tatsächlich 2023 in irgendeiner Konstellation verunglückt, nachdem es seit 2020 offenbar unbeanstandet lief. Dann wird die Ursache analysiert und eine geeignete allgemeine Lösung im Konsens erarbeitet. min-width:50px ist es jedoch definitiv nicht. Und auch sonst ist es Nonsens, dass man bei jeder von >200 Anwendungen des Hinweisbausteins jetzt nochmals extra eine Pixelbreite eingeben müsse, und diese mit der Icon-Einbindung manuell synchronisiert in einem unabhängigen Parameter doppelt angegeben werden müsse. Korrekte Browser richten die Breite dieses div nach der resultierenden Breite der Icon-Einbindung (die auch aus Text-Elementen ohne Pixel erreicht werden kann) automatisch aus, und brauchen keine Extra-Anforderung. Ggf. muss anderweitig für seltsame Situationen etwas verfeinert werden.

VG --PerfektesChaos 00:41, 30. Okt. 2023 (CET)

Nur zur Info: der Gesundheitshinweis hat →|ICON.nomobile=1 da wird mobil kein Icon angezeigt. --Liebe Grüße, Lómelinde Diskussion 09:32, 30. Okt. 2023 (CET)

War nur ein Beispiel gewesen, dass es Icons in jeder Breite gibt, und das spontane Experiment mit festen Mindest-50px keine wohldurchdachte Aktion war. VG --PerfektesChaos 16:30, 31. Okt. 2023 (CET)

@CyberOne25: Sodele, würdest du dann bitte mal endlich die präzise Schilderung nachreichen, auf genau welchem Endgerät mit genau welchem Betriebssystem und welcher Browserversion genau welche Fehldarstellung aufgetreten sein soll?

• Das wird jetzt seit drei Jahren unbeanstandet auf Mobilgeräten genutzt, auch von hgzh und XanonymusX, und entspricht allen bekannten HTML-Regeln.

Deine Einführung eines neuartigen Parameters ICON.width= ist offenkundig überflüssig, und fehlerträchtig wegen erforderlicher Synchronisation mit der Angabe bei ICON=.

• Sofern du keine fundierte Begründung nachweist, dass dies überhaupt erforderlich sei und deine spontane Idee die optimale Lösung für ein möglicherweise nicht existierendes Problem wäre, werde ich dies revertieren.
• Das Mal-eben-Herumexperimentieren an einer Vorlage mit fast einer Million Einbindungen ist ohnehin verantwortungslos; die Server sind etwa zwei Tage nur mit der Aktualisierung dieser Seiten beschäftigt.

VG --PerfektesChaos 16:30, 31. Okt. 2023 (CET)

iPhone mit iOS 17 mit Safari. Das benutzen wahrscheinlich sehr sehr viele. Ohne min-width ist das Icon viel zu klein (1mm aufm Bildschirm). min-width ist doch genau für solche Zwecke gedacht. Für das 50px entschuldige ich mich, aber jetzt wird es überall (wenn man ICON.width mit der Breite des Bildes setzt), auf Desktop und Mobil, korrekt angezeigt. Übrigens wurde es vorher auf ALLEN mobilen Seiten zu klein/gar nicht angezeigt, also auch wenn man aufm PC unten auf „Mobile Ansicht“ klickt.

Sowas wie die Synchronisation des Icons mit dem Bild ist auch auf anderen Vorlagen wie z.B. bei Vorlage:QS-Medizin. Da zwar etwas anders aber es geht halt um Synchronisation. Der Parameter „ICON.nomobile“ kann ja auch als „Synchronisation“ betrachtet werden – wenn‘s nicht gut auf Mobil aussieht, dann einfach ganz weg. Stattdessen einfach mit ICON.width die Breite angeben und das Bild wird korrekt angezeigt. Wenn der Parameter ICON.width nicht angegeben wird, passiert nichts außer dass es auf der mobilen Seite nicht richtig dargestellt wird. --CyberOne25 (Diskussion) 16:52, 31. Okt. 2023 (CET)

Ah, ich kann mich entfernt an das Phänomen erinnern, ja! Meine Lösung war eigentlich immer, das Icon mobil ganz auszublenden, dann ist ja auch mehr Platz für Text. --XanonymusX (Diskussion) 17:03, 31. Okt. 2023 (CET)

Ja, das ist die Grundidee, und genau dazu ist der ICON.nomobile-Parameter da: Das Icon ist nur redundante Dekoration, das kurz die Botschaft zusammenfasst, die ohnehin dann im Text erklärt wird.

• Wenn ein Icon nicht schon in sich vor Bedeutung und Aussage übersprudelt, dann kann es per ICON.nomobile gecancelt werden. Auf dem Desktop ist es eine nette Dekoration, und leitet den Gedanken schon mal auf den Typus der folgenden Botschaft.

Was auch immer da in Anzeigegrößen passieren mag, und auf welchen Geräten auch immer: Das min-width-Konstrukt ist nur ein Hack, das per Nebeneffekt irgendwas ausnutzt.

• Wenn es sich reproduzierbar so verhält wie geschildert, dann muss ggf. per TemplateStyles unter Mobil-Bedingungen eine allgemeine Lösung gefunden werden, oder der Code für Desktop und mobil bekommt irgendeine mir grad nicht ersichtliche Klarstellung. Ist aber dort korrekt, das Darstellungsproblem liegt mobilseitig.
• Also wäre zuallererst aufzuklären, aus welchen Gründen das Verhältnis Schriftgröße-Pixelmenge auf Mobilgeräten nicht passen soll, und wie das allgemein ohne Hacks zu lösen wäre. Schrift ist in em, das Bildchen in px, aber min-width auch in px und müsste bei korrektem Darstellungssystem genau das Gleiche liefern.

Auf jeden Fall werden wir nicht Hunderte von Anwendungen mit einem fehlerträchtigen redundanten Hack ausstatten, der bei Symbolen nur aus Text auch überhaupt nicht funktioniert.

VG --PerfektesChaos 17:32, 31. Okt. 2023 (CET)

Ich würde in der Tat auch eine allgemeine Lösung per TemplateStyles empfehlen. Vermutlich ist es das gleiche Phänomen, das bei langen Tabellen mit Bildern (Denkmallisten etwa) dazu führt, dass die Bilder auf Mobilgeräten während des Scrollens winzig klein werden. --XanonymusX (Diskussion) 18:28, 31. Okt. 2023 (CET)

Also, ich hab mal die Seite m. analysiert (via Desktop).

• Es ist ein <img> mit width="25px" wie zu erwarten, und so auch in der Pixel-Element-Analyse.
• Wenn das in einem <div> dargestellt werden soll, dann müssen da die gleichen 25px als erforderliche Breite herauskommen.
• Wenn angefordert wird min-width:25px dann würde die identische Breite des <div>-Blocks herauskommen.
• Korrektes HTML vorausgesetzt, kann diese Zuweisung keinen Unterschied ergeben.
• Wenn doch, dann wird irgendwo ein Bug ausgetrickst. Wir schreiben aber grundsätzlich Wikitext nicht so, dass wir in irgendwelchen Browserversionen deren momentane Bugs hacken.
• Schriftgröße und Icongröße em/px stehen in angemessenem Verhältnis.

Wer kommt als Übeltäter in Frage?

• MediaWiki liefert irgendwelche für mich im HTML-Dokument nicht auffindbare CSS-Deklarationen; zumindest für echte Endgeräte.
• iOS hat einen Bug, oder Safari.

Nächste Schritte:

• Wir können IN EINER SIMULATION als BNR-Seite den resultierenden HTML-Code der Vorlage für irgendeine Anwendung ggf. in mehreren Varianten fest speichern.
  • Dabei könnte das fragliche <div> mit schlauen Attributen versehen werden.
  • Ein Kandidat wäre: style="display:table-cell"
• Hintergrund-Infos zum Box-Modell in HTML/CSS lesen und dabei auf Ideen kommen.

Erbitte Rückmeldung der Untersuchungsergebnisse. --PerfektesChaos 22:26, 31. Okt. 2023 (CET)

mE liegt das Problem darin, dass Minerva das Überlaufen von großen Bildern zu umgehen versucht, indem deren Maximalbreite auf 100% des Parents gesetzt wird, was im Tabellenkontext mit automatischem Ausgleich zwischen den Zellbreiten dazu führt, dass diese 100% auch sehr klein werden können. Verhindern kann man dieses Verhalten bei Bildern, die nicht Gefahr laufen, jemals overflow zu erzeugen (also diesen kleinen Dekorationsbildchen hier) per .noresize, vgl. mw:Manual:Interface/IDs_and_classes#class-noresize. Mein Vorschlag wäre, diese Klasse dem Icon-Div zuzuweisen, dann könnte ICON.width auch wieder entfallen, da die feste Größenvorgabe aus der img-Einbindung wieder greift. -- hgzh 13:14, 1. Nov. 2023 (CET)

Ah, vielen Dank.

Irgendwie hatte ich sowas im Blasentee, aber absolut null mit Minerva am tun und kein Gerät zur Hand (Handy-Muffel; 4k Festnetz).

Mag mal wer eine BNR-Seite oder auf BETA mit dem HTML-Code der Vorlage aufmachen und dann die Wirkung testen?

Für alle class="noresize" ist natürlich hier und bei der Schwestervorlage optimal, wenn das dann auch die beschriebene Wirkung haben sollte.

VG --PerfektesChaos 13:40, 1. Nov. 2023 (CET)

Ja, kann bestätigen, dass es am Skin Minerva liegt. Ich habe mit dem Quelltext-Tool das CSS Stück für Stück entfernt und dann festgestellt, dass beim CSS von Minerva folgendes problematisch ist, wie hgzh schon angedeutet hat:

.content a > img,.content noscript > img {

max-width: 100% !important;

height: auto !important

}

Wenn man das entfernt und der Hinweisbaustein kein min-width mehr hat, wird es genau wie in der Desktop-Version mit der korrekten Breite angezeigt.

Wenn ich stattdessen class="noresize" verwende, wird es ebenfalls ohne min-width korrekt angezeigt. Daher schlage ich ebenfalls vor, meinen eingefügten Parameter ICON.width zu entfernen, und stattdessen class="noresize" hinzuzufügen. --CyberOne25 (Diskussion) 16:28, 1. Nov. 2023 (CET)

Anker

Bitte den Parameter ändern, damit keine identischen IDs entstehen oder ganz entfernen → Lint-Fehler: Doppelte IDs Allein die mehrfache Verwendung der Vorlage:Autoarchiv, beispielsweise in der Vorlagenwerkstatt, erzeugt so mehrere Fehler 2× #Vorlage-Autoarchiv, 2× #Vorlage_Portalschließung, 2× #Vorlage-Autoarchiv-Tage. Schere, Stein, Papier 2 Bausteine Vorlage:Begriffsklärungshinweis + Vorlage:Weiterleitungshinweis = 2× #bksicon Bitte auch alle anderen gesperrten Vorlagen prüfen [1] und mit zugrordneten Ankern versehen beispielsweise bksiconDA dieser Artikel bksiconB Begriffsklärung bksiconBH BKL-Hinweis bksiconWH WL-Hinweis --Liebe Grüße, Lómelinde Diskussion 10:31, 27. Sep. 2024 (CEST)

Ich bin ja willig, aber umseitig kann da nix für.

• Es ist der Bote; der kann nicht für die Nachricht geprügelt werden.

Das Problem sind die jeweils umseitig anwendenden Vorlagen, die mehrfach eingebunden werden, aber trotzdem sich von umseitig eine ID wünschen.

• Die sollten vor Jahrzehnten mal einen privaten CSS-Stil oder eine Ausblendung über einen solchen Selektor ermöglichen.
• Hatte aber eh fast niemand gemacht.
• Um für CSS einen Selektor anzubieten, soll nur noch class="vorlage-dingsbums" benutzt werden; id= nur noch wenn tatsächlich als Sprungziel vorgesehen.

Ich schau mal bei einigen Kandidaten.

LG --PerfektesChaos 10:39, 27. Sep. 2024 (CEST)

Ja aber wo hätte ich es denn sonst „zentral“ schreiben können. Ich kann viele dieser Vorlagen nicht bearbeiten, das können nur Admins und ich hoffe doch dass er auch diese Seite auf der BEO hat. --Liebe Grüße, Lómelinde Diskussion 11:14, 27. Sep. 2024 (CEST)

Autoarchiv, Begriffsklärungshinweis, Weiterleitungshinweis in Umstellung.

dieser Artikel bksiconB Begriffsklärung bksiconBH BKL-Hinweis bksiconWH WL-Hinweis sind ja wohl eindeutig; Wiederholungsgefahr sehe ich da erstmal nicht.

LG --PerfektesChaos 12:57, 27. Sep. 2024 (CEST)

Mit eindeutigen IDs sehe ich da auch kein Problem, nochmals Dankeschön, komplizierter werden andere wie Denkmallisten und Koordinatenvorlagen. --Liebe Grüße, Lómelinde Diskussion 14:55, 27. Sep. 2024 (CEST)

Nachtrag, nein es ist doch komplizierter Ford Modell T hat zweimal WL-Hinweise es müsste einen zusätzlichen Parameter geben, der die ID im zweiten unterdrückt. Ich kann die auch nicht zusammenlegen, weil sie unterschiedliche Textanhänge haben. --Liebe Grüße, Lómelinde Diskussion 15:27, 27. Sep. 2024 (CEST)