Vorlage Diskussion:Farbindex

Druck

Das Problem dieser Vorlage ist, dass CSS-Hintergrundfarben standardmäßig beim Druck durch den Browser ignoriert werden. Die einzige spontane Idee meinerseits hiergegen wäre, eine besitmmte Anzahl von Farben zu standardisieren und diese entweder in das Print-Stylesheet der Wikipedia oder in das eigenes einzutragen (und entsprechen darauf hinweisen), falls benötigt. Jemand einen besseren Lösungsansatz? --Grüße, Auke Creutz um 12:01, 12. Dez. 2006 (CET)

Das ist ein Browser-Problem. Einige Browser unterstützen optional "print background color" oder sowas. --RokerHRO 14:28, 6. Feb. 2008 (CET)

Parameter-Wirrwar

Die Vorlage arbeitet mit drei unbenannten Parametern:

1. Der erste enthält immer die Farbe, allerdings in bisher zwei, jetzt drei verschiedenen Schreibweisen.
   • Die Hex-Schreibweise ohne # (z. B. FF0000 oder auch kurz F00) ist Standard.
   • Bei der Verwendung von Farbnamen (z. B. red) muss der dritte Parameter auf name gesetzt werden, da das sonst nicht zu unterscheiden ist. Meine Meinung: Das ist schon der erste grobe Fehler dieser Vorlage. Hex-Farben müssten immer mit # angegeben werden, dann würde sich das erübrigen. Ich finde, wenn wir hier etwas umstellen, sollten wir das gleich mit erledigen.
   • Neu eingebaut sind die Hintergrund-Farbnummern, die per h im zweiten Parameter kenntlich gemacht werden. Meine Meinung: Das h müsste entweder in den dritten Parameter, genau wie das name. Oder man verzichtet ganz darauf und wertet den ersten Parameter per Switch aus. Die Eingaben 1 oder auch ausgeschrieben hintergrundfarbe1 sind eindeutig.
2. Der zweite Parameter enthält immer den Text, außer bei den Spezialfällen s und h.
   • Der Spezialfall h ist leicht aufzulösen, siehe oben.
   • Der Spezialfall s ist ganz eigen. Er beeinflusst weder Farbe (Parameter 1) noch Text (Parameter 2) sondern die Größe des Kästchens. Zusätzlich wird der schwarze Rahmen abgeschaltet und man hat keine Möglichkeit mehr, einen Text anzugeben. Meine Meinung: Ideal fände ich einen benannten Parameter |Größe=s (für die kleine Standardgröße) oder |Größe=36px (mit Maßeinheit, damit es ganz flexibel ist). Das bisherige Verhalten könnte man als Kompatibilitätmodus beibehalten oder eine Umstellung forcieren.
3. Der dritte Parameter hat aktuell viele Bedeutungen, siehe oben. Wenn man alle Umstellungen wie oben vorgeschlagen durchzieht, entfällt dieser Parameter ganz.

--TMg 12:27, 6. Aug. 2012 (CEST)

• ja, ich fürchte, dass ist das kernproblem: wenn nämlich die #-syntax geklärt wäre, könnte man endlich Farbindex und Farblegende zusammenlegen, denn sonst sind sie ident (es gibt noch die div vs span-frage, also umbruch danach, aber die lässt sich in den griff kriegen)
• die idee mit benanntem parameter ist natürlich optimal: ich hab schon einen switch statt dem if eingebaut, um das übersichtlicher zu gestalten
• und dann dürfte man ehrlich gesagt die frage rahmen oder nicht auch mit einem schalter machen, gerade bei hellen farben braucht man den meist, die frage ist also von der kästchengröße unabhängig (auch das ein grund für den fork, soweit ich mich erinnern kann)

die zentrale frage ist: wie stellt man die #-syntax am besten um?

• das erste zeichen strippen, und auf # testen? kann aufwändig werden..
• oder weiter die zwei vorlagennamen als eingabemaske benutzen, aber intern aufeinander wrapen: {{Farbindex|XXXXX}} enthielte dann nur den aufruf {{Farblegende|#{{{1}}}}}, und dort der ganze code

dann müsste man nicht sofort die wikiquelltexte ändern, weil die lösung aufwärtskompatibel ist --W!B: (Diskussion) 14:03, 6. Aug. 2012 (CEST)

PS: die en's arbeiten übrigens mit {{legend|color|label|outline=outline color|border=css border}}, sicher nicht schlecht, auch da an kompatibilität zu denken, von dieser dürften sich viele andere i18s ableiten: die englischen parameter stören da imho nicht, wer ein bisschen CSS denkt, denkt englisch; die syntax ist eingabe mit #

PPS: zu meinen "h": natürlich auf den schalter: für die nicht kolorierte ausgabe, also den alternativtext, dürfte eine angabe der beschreibungen „Sehr auffällig“, „Neutral, abgesetzt“ günstig sein, der text also hilfreich

PPPS: aber die unterschiedlichen eingaben sind nicht relevant, Farblegende nimmt jede innerhalb von CSS gültige Schreibweise, zum Beispiel Farbname, #FF0000, #F00 oder rgb(100%, 0%, 0%) --W!B: (Diskussion) 14:18, 6. Aug. 2012 (CEST)

Hier mein Vorschlag für den Quelltext inklusive Aufgabenliste für die Umstellung. Die Umstellung muss in mehreren Schritten erfolgen.

1. Alle s-Spezialfälle werden durch den neuen Parameter „Größe“ ersetzt (sofern ihr den Vorschlag mit diesem benannten Parameter akzeptiert, versteht sich). Ich denke, das können wir sogar von Hand umstellen, da das scheinbar nur ein paar Navi-Leisten betrifft.
2. Das Einfügen des #-Zeichens sollte wohl eher ein Bot übernehmen. Achtung Bot-Betreiber: Nicht anhand des dritten Parameters entscheiden, ob ein #-Zeichen einzufügen ist, sondern anhand des ersten Parameters, wenn dieser ein gültiger 6- oder 3-stelliger Hex-Farbwert ohne #-Zeichen ist. Es gibt keinen Farbnamen, der gleichzeitig als Hex-Zahl gelesen werden könnte.
3. Im Anschluss daran kann sämtlicher Kompatibilitäts-Quelltext aus der Vorlage fliegen, einschließlich des name-Sonderfalls.
4. Zuletzt kann überall das dann wirkungslose |name entfernt werden. Da das eine reine Quelltextoptimierung ist, die dann keinerlei Wirkung mehr hat, sollte das aber nicht die einzige Bot-Aufgabe sein sondern diversen Bots, die sowieso regelmäßig laufen, als Zusatzaufgabe übergeben werden.

Am Design habe ich ganz bewusst nur sehr wenig geändert (der dünne schwarze Rahmen wird zur Pflicht). Ob man zusätzliche Parameter anbietet, um auch den Rahmen zu beeinflussen, würde ich losgelöst von dieser Umstellung diskutieren. --TMg 18:33, 6. Aug. 2012 (CEST)

Genauer: die 34 Vorlagen Navi-Leiste…Industriekultur. (nicht signierter Beitrag von Sarang (Diskussion | Beiträge) 22:45, 6. Aug. 2012‎)

ja, das sieht sehr gut aus: das "h" hab ich eh grad erst, und nur 3x verwendet (mach ich natürlich), und dass das "s" eine spezialanfertigung ist, dachte ich mir auch

rahmen default ist gut, ein dunkles kasterl mit rand ist besser als ein helles ohne

jetzt ist nurmehr die frage, soll die vorlage nachher unter "Farbindex" oder "Farblegende" stehen: imho zweiteres (wegen den interwikis): damit die beiden kompatibel sind, ist auf Param3 (das hier entfallende "eingabeart") der alternativtext zu stellen, und alles andere werden benannte parameter

vom code her sind sie eh schon weitgehend gleich, hier wär nur die umbruchfrage zu klären: dazu ist mir auch noch nichts schlaues eingefallen --W!B: (Diskussion) 09:13, 7. Aug. 2012 (CEST)

Einige weitere Überlegungen

Die Misere hat damit begonnen dass jemand das "#" unbedingt einsparen wollte – oder wegen der Probleme mit dem Bug 12974 darauf verzichtete. Um dann doch Farbnamen zu ermöglichen wurde der komplizierte Umweg mit dem Parameter "name" eingeführt.

Auch wenn manche die Codierung mit den Farbnamen anschaulich finden (Zitat: Durch die Angabe des Namens erspart sich der Entwickler die hexadezimale Notierung), wäre IMHO die Beschränkung auf Hexadezimalcodes der Einheitlichkeit und Lesbarkeit weit förderlicher.

Jedenfalls können die Farbnamen der verschiedenen Standards und die anderen Varianten für Farbcodierung problemlos verwendet werden.

Die neun Hintergrundfarben könnten ohne weiteres mit ihrem jeweiligen Hexcode angegeben werden, doch ist die Codierung mit einer einstelligen Zahl eine attraktive Vereinfachung.

Eine Zusammenlegung mit Farblegende wäre sehr sinnvoll, wenn der nötige Aufwand angemessen ist. Eventuell ist eine völlig neue Vorlage, auf die diese beiden anderen nach und nach umgestellt werden können, ein gangbarer Weg. Der Umbruch kommt vom div, das wäre dann ohne "div" zu codieren und stattdessen ein gewünschter Umbruch zB mit <br> zu codieren.

Mir erschiene folgende Vorgangsweise sinnvoll:

• Es bleiben die ersten beiden Parameter unbenannt und fakultativ, 1 ist Farbcode, 2 ist Text
  Es bleibt auch das tooltipping, es wird immer die Farbe wie codiert angezeigt, kein Alternativtext und keine Verfälschung wie in Farblegende.
• Alle Hexcodes werden mit dem führenden "#" erweitert, wenn in der Übergangsphase der Parameter "name" gesetzt wird ändert sich nichts. Kann per BOT nach und nach umgestellt werden.
  • Sonderfall "h": Diese Variante kann ohne zusätzliche Parameter unterstützt werden, eine Prüfung auf Einstelligkeit ist unproblematisch mit padleft machbar.
  • Sonderfall "s": Dieses Ausweichkonstrukt wird ausschließlich in den 34 Navi-Vorlagen verwendet; da wird kein Text oder Rahmen benötigt.

Entweder wird es dort direkt codiert (<span style="font-size:.6em;border-left:1.1em solid;border-left-color:#930" title="#930">&#xFEFF;</span> ),

oder es gibt eine eigene neue Mini-Vorlage dafür,

oder es wird in die überarbeitete Farbvorlage integriert; aber bitte keinen Parameter "Größe"! Wenn schon, dann eher "size". Einen Grund das Aussehen völlig zu ändern sehe ich nicht.

Im Wesentlichen erscheinen die Vorschläge in Benutzer:TMg/Baustelle hilfreich. -- sarang♥사랑 12:20, 7. Aug. 2012 (CEST)

ja, da bin ich völlig d'accord

• nur eben bei hintergrundfarbe ja nicht: sinn einer CSS-class-definition ist ja eben genau der, es nicht hardcodiert anzugeben: nein, in jeder skin für die WP, den vorgefertigen nach WP:SKIN ebenso eigenbastelei, stehen die classes "hintergrundfarbe" zur freien gestaltung: und es ist sinnlos, die legende hardcodiert in #E0E0E0 zu codieren, wenn der SKIN-autor mit weißer schrift auf schwarz fährt, und die class "Neutral, abgesetzt" auf dunkelgrün umdefiniert: CSS-classes andernorts erst recht wieder hardzucodieren, führt das ganze CCS-modell ad absurdum (genauso, wie etwa ein bild in diesen farben einzufärben, und zu hoffen, dass sich die mode nie mehr ändert): daher gibt es für diese variante gar keine andere möglichkeit, als sie tatsächlich als reine class einzubauen: und ich hab keinen weg gefunden, sie auf einen rahmen zu legen, also muss sie meiner meinung nach unter einem &nbsp; liegen

dass sonst ein rahmen (zweckentfremdet) koloriert wird, ist ja, weil die usprüngliche variante in den bild-unterschriften (und tooltips) ganz hässliche schwarze blöcke hinterlassen hat): aber die "hintergrundfarbe" wird man eben, wie gesagt, für bilder nie brauchen, daher darfs da ruhig anders codiert sein: die einstellige angabe war keine "abkürzung", sondern explizit ein erfordernis der technologie: ich wollte nur nicht noch einen farb-kästchen-fork eröffnen ;)

• size ist gut

ganz neu anzufangen, würde vieles erleichtern: etwa unter Vorlage:Farb-Legende? die anderen brauchen dann nur wartungslink-parameter für die händisch oder per bot zu machenenden umstellungen, und ein DEPRICATED in die beschreibung --W!B: (Diskussion) 17:22, 8. Aug. 2012 (CEST)

Schrittweise Umstellung

Ich wünsche mir eine schrittweise Umstellung, bei der nicht gleich alles über den Haufen geschmissen wird.

1. Ich möchte keine Zusammenlegung mit der Vorlage:Farblegende. Diese nutzt eine andere Technik und verfolgt dadurch, dass sie auf einem Listenelement aufbaut und noch nie eine Rahmenlinie hatte, ein etwas anderes Ziel.
2. Auch das andere Extrem, mit einem ganz neuen Vorlagennamen neu anzufangen, halte ich nicht für zielführend.
3. Alles in allem bleibe ich bei meinem „sanften“ Umstellungsvorschlag. Der dortige Quelltext wird hierher kopiert. Dann wird die Umstellung wie dargestellt schrittweise durchgeführt.
4. Wie man den „s“-Sonderfall behandelt (Auslagerung in eigene Vorlage, hartkodiert in den Navi-Vorlagen oder per Größen-Parameter wie in meinem Vorschlag), spielt für die Umstellung kaum eine Rolle. Mir ist das Detail wichtig, dass nicht mehr stur von Pixeln ausgegangen wird sondern CSS-Größenangaben wie „1.5em“ möglich sind.
5. Was ihr gegen einen deutschsprachig benannten Parameter „Größe“ habt, verstehe ich nicht. Wir können von mir aus „size“ als Option zulassen, aber worin besteht da der Vorteil?

--TMg 16:23, 27. Aug. 2012 (CEST)

Der oben erwähnte Bug 12974 scheint mir hier gar nicht zuzutreffen. Ich hätte ja schon mit der Umstellung angefangen, da wir uns offenbar alle einig sind, nur bei der Benennung des Parameters „Größe“ vs. „size“ vs. ganz weglassen bin ich mir unsicher. Kompromissvorschlag: {{{Größe|{{{size|}}}}}}, also optional beides zulassen. --TMg 21:12, 19. Okt. 2012 (CEST)

Zeilenumbruch vor Farbquadrat

@Mps, W!B:, W like wiki, Sarang:
hallo, ich hab die vorlage in Elektrolytkondensator#Allgemeines_Impedanz/ESR-Verhalten_von_Elkos im bild Polymer-ESR-Elko-Kurven.svg verwendet
vor dem farbquadrat wird offensichtlich ein zeichen eingefügt, das den zeilenumbruch erlaubt
d.h. bei mir stellt es sich so dar, dass die öffnende klammer vor dem farbquadrat am ende der einen zeile und das farbquadrat in der nächsten zeile steht
lässt sich das zerreissen iwie verhindern - ggf durch ein zeichen, das keinen zeilenumbruch erlaubt?
--Mrmw (Diskussion) 22:51, 14. Dez. 2017 (CET)

@Mrmw: jein. denn diesen umbruch erzeugt nicht unsere wikimedia-software, sondern dein browser. wie siehst du das folgende:

! das ist beispiel "farb­index width= 40px" (! mit text in klammer)

! das ist beispiel "farbindex width= 100px" (! mit text in klammer)

! das ist beispiel "farbindex width= 300px" (! mit text in klammer)

mein firefox bricht bei deinem beispiel nicht um, hier auch nicht. der html-code lautet auf:

… (<span style="display:inline-block;  … ></span><span style="display:none">…</span> Hybrid-Al-, …) …

nun könnt man irgendwo mit <span style="white-space:pre;"></span> um die öffnende klammer und das kästchen (welches ein html-rahmen um den platzhalter  ist) machen, aber das wäre einer der workarounds, die browser-bugs sanieren, und das machen wir üblicherweise nicht, weil das bei einem allfälligen update nur altlasten sind. normalerweise sind die umbruch-algoritmen heutzutage schon recht ausgereift, vielleicht wird das  nicht als "text" erkannt, und der browser interpretiert "alleinstehendes klammerzeichen" (was er nicht sollte, da zb im französischen die klammer immer einen abstand dahinter hat, auch das sollte nicht getrennt werden). U+FEFF ist aber ZERO WIDTH NO-BREAK SPACE. es ist also mangelnde unicode-implementation. welchen browser fährst du?

wir könnten ein anderes der dort genannten ersatzzeichen ausprobieren, vielleicht klappt "word joiner" U+2060, der sollte sogar das beiderseits nicht umbrechen explizit erzwingen. allein, haben das alle browser schon implementiert? sähe dann so aus:

ࠌ das ist beispiel "u+2060" (⁠ mit text in klammer)

klappt bei mir nach der klammer auch, bei mir verrutscht da aber beim ersten rahmen zu farbkästchen, offenbar verwirrt der joiner am satzanfang den firefox.

jedenfalls brauchen wir ein zero-width zeichen, sonst lassen sich keine sinnvollen quadrate erzeugen, weil jedes andere zeichen vom schriftschnitt abhängig ist. daher verwenden wir auch kein einfaches   (soweit ich mich erinnern kann). --W!B: (Diskussion) 12:24, 15. Dez. 2017 (CET)

@W!B::

puh, danke für die ausführliche rückmeldung, ganz schön viel für mich

ich bin mir nicht sicher ob wir wirklich vom gleichen sprechen

weil ich jetzt extra beide browser unter win7 (64) auf neuesten stand gebracht habe (feuerfuchs: 57.0.2, chrome: 63.0.3239.108) und die darstellung hier in der diskussion wie im artikel identisch ist

nochmal das problem: es geht darum, dass die öffnende klammer (auf die das farbquadrat folgt) nicht alleine am ende der zeile stehen soll

wenn dass bei dir im artikel nicht der fall sein sollte, wundert es mich sehr und ich weiss nicht wieso das so sein sollte

ich hab mir auch den quellcode (?im browser) angeschaut, konnte aber das zeichen zwischen quadrat und öffnender klammer nicht ausmachen

zu deiner frage wie sich deine beispiele bei mir darstellen (firefox wie chrome - beide gleich):

40px: (quadrat newline ...

100px: (newline quadrat ...

300px: (quadrat newline ... (wie 40px)

genauso wichtig wäre natrülich auch, dass text welches ich per geschütztem leerzeichen hinten an das quadrat hefte genausowenig abgerissen wird, das hab ich aber nicht getestet

@Mrmw: tut mir leid, aber ja, wir sprechen vom selben, und gerade solche mini-problemchen sind oft extrem schwierig zu lösen (die letzten 5% auf 100%ig machen 95% der arbeit, und das letzte % macht 99%.. ;). wenn du auch einen firefox hast, dann liegt es vielleicht doch am betriebsystem, du hast wohl win, ich linux: dann können wir wenig machen. zwischen der öffenenden klammer und dem farbkästchen ist übrigens gar kein zeichen, nichtsdestotrotz machen sich alle möglichen programme gedanken darüber, wo man warum umbrechen sollte oder nicht. welche sie sich machen, ist nicht leicht herauszufinden. und noch viel weniger, eine lösung zu finden, die allen beteiligten programmen passt: und bis eine wp-seite bei dir am bildschirm erscheint, spielen da eine menge mit, von der wikimedia-software bei uns bis zum bildschirmtreiber bei dir.

nach dem kästchen und dem text dazu steht auch kein zeichen, der abstand wird per html erzeugt. trotzdem bricht zb mein firefox hin und wieder um. dieses problem ist bekannt, haben wir aber nie in den griff bekommen: die lösung wäre recht unleidig.

man könnte also andernorts schrauben, etwa schlicht in der bildunterschrift die klammer nicht verwenden: also einfach mit "geht halt nicht" leben. wie wärs, du schreibts:

Typischer Verlauf des ESR in Abhängigkeit von der Temperatur für Elkos je Elektrolyt: ! fest (Hybrid-Al-, Al- und Ta-Polymer-Elkos); ! 'nass' (Al-Elkos)

das wär doch ein eleganter workaround, oder? ;) übrigens darfst du das math aus der bildunterschrift auch noch raustun, etwas übertypographisiert, und macht oft einen unschönen bildkommentar beim drüberhovern oder screanreadern und bei copy&paste, weil math auch seine spleens hat. keep it simple: "schöne" auszeichnung ist für den fliesstext, in den bildunterschriften (weil sie ein nebenelement eines nebenelements eines artikels sind) entstehen eh schnell genug probleme und unschöne wechselwirkungen. wär das für dich akzeptabel? --W!B: (Diskussion) 14:04, 16. Dez. 2017 (CET)

deine lösung und dein workaround gefallen mir sehr - hab es 1:1 übernommen

ist zwar offtopic und nicht deine baustelle, aber deine und meine arbeit sind umsonst, wenn gutgemeinte änderungen am artikel vom 'artikel-besitzer' mit 'ständige weiterentwicklungen' bezeichnet werden und die änderung manuell als edit rückgängig gemacht werden (https://de.wikipedia.org/w/index.php?title=Elektrolytkondensator&type=revision&diff=172015472&oldid=172007724)

das ist schon demotivierend - wenn solche artikel erst dann zur überarbeitung freigegen werden, wenn dessen 'owner' das biologische ende überschreiten

schade weil er wirklich was auf dem kasten hat zum thema aber layouttechnisch in den 80ern stehengeblieben ist

--Mrmw (Diskussion) 19:36, 16. Dez. 2017 (CET)

Mrmw, ja, auch das ist ein "known bug": wir reden zwar immer vom "jeder kann frei editieren" und "der inhalt zählt", tatsächlich aber entsteht die WP in einem komplexen sozialgefüge echter menschen. vulgo, primär durchs miteinander reden. eigentlich ist wikipedieren ein quasseljob ;) und alle artikel präsentieren in erster linie einen zwischenmenschlichen kompromiss. und weil sie inzwischen so groß ist, sind es eben meist nur 2,3 leute, die sich einen artikel untereinander ausmachen. so siehts halt in der praxis aus. wissen ist aber immer eine zwischenmenschliche übereinkunft, war in der steinzeit schon so, war in der antike so, und ists auch heute, sogar in der wissenschaft. auch da bringt forschung nur dann etwas, wenn sie wahrgenommen und übernommen wird. also passt das schon, die WP spiegelt nur die realtität da draussen in der echten welt wieder. heisst, zu jedem edit gehört immer überzeugungsarbeit. so siehts halt in der praxis aus. --W!B: (Diskussion) 10:59, 18. Dez. 2017 (CET) (PS, freut mich, dass der workaround geklappt hat: warum einfach, wenns kompliziert auch geht.. ;)

(PPS: übrigens, Elcap hat recht, das svg ist definitiv kein erstatz für das png, der vector-version-baustein auf commons ist falsch. hier würde die überzeugungsarbeit darin beruhen, dass man sich die arbeit antut, das png sauber und 1:1 zu verktorisieren. dann sieht der autor, der schon früher viel arbeit in den artikel gesteckt hat, dass der andere sich auch arbeit antut / hausaufgaben macht, und dann sieht die gesprächsbasis anders aus. --W!B: (Diskussion) 11:05, 18. Dez. 2017 (CET))

W!B:, schön wie du es beschreibst, wie die wikipedia funktioniert und was sie darstellt

aber ich bin da etwas anderer meinung was das svg angeht

es steht ja beispielhaft für andere

in einer vektorisierung kann mehr stecken, als das reine abpausen des orginals

ich hätte es gut gefunden, wenn kritik geübt worden wäre, was fehlt in der vektor-version?

die kritik war, es sei nicht so anschaulich wie das orginal - und das wiederum ist subjektive wahrnehmung und sollte diskutiert werden

ich würde dann den standpunkt vertreten, dass die wiki kein kompendium für ausnahmslos heranwachsende ist, und dass jeder aus der vektor version die gleichen informationen ziehen kann wie aus der bunten png

ich würde zur diskussion stellen, dass die sehr ausführlichen informationen im artikel durch die bilder nicht zeitgemäß begleitet werden

ich finde es toll wenn jemand wie hier bei den kondensatoren so viel einbringt - ziehe ich ehrlich meinen hut

aber ich fordere kompromisbereitschaft - ich selber wäre auch bereit kompromisse einzugehen

ein gelber hintergrund, der einen großteil der bilder durchzieht?

graphen, bei denen man deutlich erkennt, dass sie in paint&co zusammengeklebt wurden?

textinhalte in bildern? macht eine internationale verwendung unmöglich

ich würde solche arbeiten übernehmen ohne den anspruch mich dafür feiern zu lassen

würde auch mit mir reden lassen in einer runde

mir ist aber meine zeit zu schade eine einzelperson versuchen zu überzeugen, die von seiner arbeit anscheinend so überzeugt ist

dank dir für deine gedanken

--Mrmw (Diskussion) 12:23, 18. Dez. 2017 (CET)

Zusammenfassung von kleinem Farb-Quadrat mit dem direkt folgendem Text (Wort)

Ich habe eine Bild-Legende um kleine Farb-Quadrate ergänzt, also mit Nutzung des Parameters "s".
Wenn ich nach den Template-Eintrag direkt ein "&nbsp;" einfüge, um das folgende Wort daran zu "koppeln", geht das leider im erzeugten HTML-Code verloren.
Beispiel:
Theokratie#Theokratien_heute
Beim Farbwert Orange z. Bsp. wäre diese "Koppelung" mit "&nbsp;" wünschenswert.
--• Jaybear • ...disk.✍ • 00:03, 22. Feb. 2019 (CET)

Schraffierte Flächen

Es gibt nicht wenige Karten oder Diagramme, in denen schraffierte Flächen auftauchen. Es wäre hilfreich, wenn man auch diese mit dieser Vorlage Farbindex darstellen könnte. Beispielsweise besitzt die analoge Vorlage:Legend in den Commons deutlich mehr Optionen in verschiedener Hinsicht. Wäre es möglich, diese Optionen auch hier zu integrieren? --Furfur ^{⁂ Diskussion} 15:26, 14. Jul. 2024 (CEST)