Vorlage Diskussion:Farbe

<onlyinclude><span style="background: {{#switch:{{{HG|{{{HEX|{{{1|}}}}}}}}}
  |0=black/* schwarz */
  |1=rgb(97%, 97.5%, 98%)/* neutral */
  |2=white/* weiß */
  |3=rgb(100%, 100%, 25%)/* leuchtend gelb */
  |4=rgb(100%, 62.5%, 0%)/* leuchtend orange */
  |5=rgb(92%, 92.5%, 94%)/* wikitable */
  |6=rgb(70%, 72%, 100%)/* blass blau */
  |7=rgb(100%, 80%, 80%)/* blass rot */
  |8=rgb(100%, 98.5%, 68%)/* blass gelb */
  |9=rgb(72.5%, 100%, 77%)/* blass grün */
  |#default={{{HG|{{{HEX|{{{1|#ABCDEF}}}}}}}}}
}};<!--
-->{{#if: {{#invoke:TemplUtl|faculty|{{{Kreis|0}}}}}|border-radius: {{{B|{{{width|0.85em}}}}}};}}<!--
-->{{#if: {{{Rand|{{{border|}}}}}}
     |border: {{#switch:{{{Rand|{{{border|}}}}}}
       |0=none
       |1=1px solid rgb(63.5%, 66.25%, 69.5%)/* wikitable */
       |2=1px solid rgb(91.75%, 92.5%, 94%)/* weißgrau */
       |3=1px solid rgb(47%, 0%, 0%)/* rot */
       |4=1px solid rgb(53.3%, 53.3%, 66.7%)/* graublau */
       |5=1px solid black/* schwarz */
       |dünn|auto=thin solid {{{VG|{{{color|{{{3|black}}}}}}}}}
       |dick=thick solid {{{VG|{{{color|{{{3|black}}}}}}}}}
       |gestrichelt=1px dashed {{{VG|{{{color|{{{3|black}}}}}}}}}
       |gepunktet=1px dotted {{{VG|{{{color|{{{3|black}}}}}}}}}
       |#default={{{Rand|{{{border|}}}}}}
     }};<!--
-->}}<!--
-->{{#if: {{{Text|{{{2|}}}}}}
     |color: {{{VG|{{{color|{{{3|black}}}}}}}}}; padding: 0 0.15em; line-height: 1.15em;
     |/*Box:*/ color: transparent; width: {{{B|{{{width|0.85em}}}}}}; line-height: {{#if: {{{H|{{{height|}}}}}}|{{{H|{{{height|0.85em}}}}}}|{{{B|{{{width|0.85em}}}}}}}};
   }}<!--
-->display: inline-block;">
{{#if: {{{Text|{{{2|}}}}}}|{{Str replace|{{{Text|{{{2|}}}}}}|#|&#35;}}|_}}
</span>
</onlyinclude>

— Christoph Päper 14:31, 30. Apr. 2020 (CEST)

Änderungen durch Benutzer:Crissov heute

1. Du hast auf einen vorhandenen Parameter mit der Bedeutung „Hex-Code der Farbe“ eine zusätzliche Bedeutung draufgepfropft: „Nummer des Standard-Schemas in der deutschsprachigen Wikipedia“.
   • Sowas ist immer eine ganz ganz ganz schlechte Idee.
   • Erstmal ist das nicht ganz konfliktfrei, denn die resultierenden Werte sind in manchen Umgebungen gültige Hexcodes, bloß halt nicht sechsstellig: #8 ist #888 ist #888888.
   • Dann macht es die Erklärung des Parameters, die Erkennung durch Skripte verwirrender, und es für Syntaxchecks der Vorlageneinbindungen und auch für die Autoren verworren, was genau welcher Parameter meint, wenn du da lauter Doppelbedeutungen und Mehrfach-Aliasse draufdrückst.
   • Weiterhin ist die Vorlage auch für den internationalen Austausch konzipiert. Hier mag man die Namen von Variablen auf Kyrillisch oder Japanisch umschreiben, aber die Bedeutung muss internationalisierbar sein. Da kann keine Bedeutung reingemischt werden, die nur in der deutschsprachigen Wikipedia funktioniert.
2. Bitte baue deine Idee so um, wenn überhaupt Konsens bestünde, dass dafür separate Parameter mit eigener Doku verwendet werden: deHG und deVG; ein Parameter, der gleichbedeutend HEX heißt, enthält nur den Hexcode und niemals etwas anderes.
3. Es gibt keinen Mangel an Parameternamen; es ist mir unbegreiflich, warum du Namen von Parametern einsparen musst und Namen doppelt für unterschiedliche Dinge belegst??? Es sind unendlich viele Namen möglich; wo war dein Problem?
4. Weiterhin hast du die Notation rgb() eingeführt, und das ohne jeden Grund.
   • In Hilfe:Farbe steht doch zu jedem Standard-Schema der Hexcode mit bei, warum musstest du die erst umständlich in die rgb()-Prozentwerte umrechnen???
   • Wir verwenden in der deutschsprachigen Wikipedia die rgb()-Notation grundsätzlich nicht. Unsere Autoren sind technische Laien, müssen zumindest mit geringstmöglichen technischen Hürden enzyklopädische Artikel bearbeiten und Vorlagen pflegen können. Dafür verwenden wir traditonell und einheitlich die sechsstelligen Hexcodes, vielleicht noch ein halbes Dutzend englischsprachiger Farbbnamen, und mehr muss man nicht verstehen.
   • Es gibt keinerlei Grund, die Autoren zu verwirren durch dreistellige Hexcodes, und noch weniger durch Unix-Nerd-Farbnamen, und noch viel weniger durch rgb()-Notation, die kaum ein enzyklopädischer Autor oder normaler Vorlagenpfleger jemals gesehen hat.
   • Das kann man bei SVG-Erstellern und HTML-Programmierern machen, aber unsere Hauptaufgabe ist die Erstellung enzyklopädischer auf möglichst einfachem technischem Niveau.
5. Bitte verwende für dieselbe Bedeutung nicht so viele Aliasse. Je mehr Aliasse du definierst, desto schwerer wird es für einen Autor, der die Vorlageneinbindung im Artikel antrifft, sich all diese Aliasse zu merken und auswendig zu lernen, welche dieselbe schon bekannte Wirkung hätten und was dann aber völlig andere Parameter sind.
6. Wir gehen tendenziell zu benannten, also selbsterklärenden Parametern über.
   • Deshalb ist praktisch immer der benannte Parameter der Standardname, und für tippfaule Bearbeiter könnten wir auch noch den unbenannten als Abkürzung anbieten. Dann ist aber immer der unbenannte der Alias; du hast jetzt unabgesprochen diese Reihenfolge umgekehrt.
7. Das Syntaxelement <source> ist bereits seit 2012 veraltet, wird demnächst nicht mehr unterstütztwerden, weshalb Reparatur nötig wurde.
   • Wobei der Quelltext ja in jeder Version nachlesbar ist, und eine Rettung der Programmierung hier auf diese Seite nicht viel bringt.
8. Insgesamt hast du dich so verhalten, wie das vielleicht vor einem Jahrzehnt mal Vorlagenbastler gemacht hatten. Wir müssen aber längst ein stabiles Qualitätsmedium pflegen, und da sind solche kryptischen unabgesprochenen Husarenritte nicht mehr zeitgemäß; und viele organisatorische Fehler, die die Vorlagenbastler von 2008 mal gemacht hatten, haben wir mittlerweile in ihren Auswirkungen schmerzlich zu spüren bekommen und eliminieren sie nach und nach unter riesigem Aufwand; wir lassen sowas aber sicher nicht mehr neu herein.
9. Bitte verwende vor einer größeren Änderung an Vorlagenprogrammierungen oder Hilfeseiten zunächst die Diskussionsseite und stelle deine Absicht vor; das vermeidet schmerzliche Reverts.

VG --PerfektesChaos 15:18, 30. Apr. 2020 (CEST)

Der für technische Laien völlig unverständliche und unnötigerweise großgeschriebene Parametername HEX für die Hintergrundfarbe akzeptiert prinzipbedingt jeden möglichen CSS-Farbwert. Die RGB-Notation mit Prozentwerten hat den Vorteil, dass sie etwas verständlicher und lesbarer ist als hexadezimale Werte und höhere Präzision (10+ Bit) ermöglicht. Die Ziffern 1 bis 9 sind dabei nicht belegt und #8 (mit Raute davor) wurde zwar mal als Kurzschreibweise von #888 und #888888 vorgeschlagen, aber abgelehnt, und so gibt es nur 3-, 4-, 6- und 8-stellige Hexcodes. Außerdem kann die Raute in der Vorlagenprogrammierung manchmal problematisch sein, wenn sie am Zeilenanfang ungewollt als nummerierte Liste interpretiert wird.

Lokalisierte Parameternamen, selbst wenn es nur Abkürzungen sind, machen Vorlagen im Quellcode benutzbarer. Die Vorlagenprogrammierung wird dadurch zwar etwas länger, aber nicht komplizierter. Außerdem werden Vorlagen von deutlich weniger (und von deutlich versierteren) Autoren bearbeitet als verwendet. Ich hätte ehrlich gesagt lieber die englischen Aliase ganz entfernt, das nur aus Kompatibilitätsgründen nicht getan. Ob man Nummer oder Name als primären Alias nimmt, ist mir ziemlich egal, aber einheitlich sollte es sein.

Die angeblich verminderte Internationalisierbarkeit gerade dieser Vorlage ist ein Scheinargument, denn sie wird ja gerade durch bereits vorhandene Sonderwege der deutschen WP hervorgerufen, die dann auch in Vorlagen berücksichtigt werden müssen.

Für viele Vorlagen sind benannte Parameter unnötig, weil die Reihenfolge aussagekräftig genug ist. Für andere sind Abkürzungen hilfreicher als ausgeschriebene Namen (vor allem für die geläufigsten Parameter), weil sie sonst im Quelltext den Textfluss zu sehr stören.

Bis auf Rand=1 (für rahmenfarbe1 statt schwarz) haben meine Bearbeitungen das bisherige Verhalten der Vorlage überhaupt nicht geändert. Daher habe ich sie vorher nicht angesprochen. Außerdem habe ich alles vernünftig und (hoffentlich) vollständig dokumentiert. Das einfach komplett zurückzusetzen, ist frech und widerspricht dem Wiki-Grundgedanken. — Christoph Päper 13:19, 2. Mai 2020 (CEST)

Wir verwenden in der deutschsprachigen Wikipedia die rgb()-Notation mit Prozentwerten grundsätzlich nicht, nirgends.

Unsere Autoren sind technische Laien, müssen zumindest mit geringstmöglichen technischen Hürden enzyklopädische Artikel bearbeiten und Vorlagen pflegen können.

Die einzige Notation, die unsere Autoren verstehen, kennen und mühsam erlernt haben, und überall antreffen, sind die sechsstelligen Hexcodes, womöglich noch eine Handvoll englischsprachiger Farbbnamen.

Es steht dir nicht zu, dem Projekt jetzt urplötzlich eine zusätzliche Notation aufzuzwingen, und jedem anderen Wikipedianer, der kein Techie ist, aufzuzwingen sich mit deiner Lieblingsnotation zu beschäftigen, wenn er auf deine Verwendungen stößt.

Es ist völlig egal, was du persönlich für dich persönlich als einfacher empfindest.

Du hast aus heiterem Himmel, ohne die geringste Vorankündigung, sowohl eine Hilfeseite wie auch die umseitige Vorlage umgeschrieben, um nach bald zwei Jahrzehnten deine neue private Mode einzuführen. Als uralter Wikipedianer weißt du, dass vor gravierenden Änderungen die Diskussionsseite aufzusuchen, das Anliegen vorzustellen und ausreichende Zeit zur Reaktion abzuwarten, und somit vorher Konsens zu suchen ist. Wenn du das grob missachtest, brauchst du über Reverts keine Krokodilstränen zu zerquetschen.

Deine Denke und dein Handeln sind noch aus der Kindergarten-Wikipedia, so um 2007, als alles neu und alles Experiment war und jeder mal so eben irgendwelche unbelegten Brösel als enzyklopädischen Artikel ins Netz stellte und jeder mal unter irgendwelchen kryptischen Namen irgendwelche Vorlagen erschuf und mit konfusen kryptischen Parametern versah und in die Gegend schoss. Das ist aber heute anders.

Deine Bearbeitungen lassen befürchten, dass sie von irgendwem angewendet werden und wir zukünftig verworrene unverständliche Einbindungen nach deinem Geschmack antreffen und sowohl die Autoren wie auch die Werkstattmitarbeiter mit kryptischem Zeugs rumplagen müssen.

Wir haben heute nicht mehr ein paar Hundert Vorlagen, wie 2010, sondern 70.000, und heutzutage liegt der Vorrang auf selbsterklärenden Namen der Vorlagen, benannten und die Funktion erklärenden Namen der Parameter, und einem selbsterklärenden Quelltext. Irgendwelche Abkürzungen für einen möglichst kurzen Quelltext sind nicht mehr zeitgemäß; unbenannte Parameter sind nicht mehr erwünscht. Früher mal gab es einige wenige Vorlagen, und da konnte man sich sowas noch irgendwie merken; heutzutage haben wir irrsinnig viele Vorlagen mit massiv mehr Parametern, und da gibt es solches Gebastel nicht mehr. Ein Rätselraten, was die Bedeutung unbenannter Parameter sein möge, wird nicht mehr toleriert. Hier umseitig ist das maximal einer, und das ist der Hexcode der Farbe. Der einzige, der die Bedeutung solcher unbenannter Parameter kapiert, ist regelmäßig derjenige der sie sich ausgedacht hatte. Alle anderen Wikipedianer sind dann angeschissen und müssen jedesmal in der Doku nachschlagen, was das kryptische Gewürge soll. Auch die Prozentwerte findet nur derjenige toll,der gewohnt ist damit umzugehen. Für mich persönlich kein Problem, ich bin damit vertraut und einige SVG-Maler und CSS-Experten auch. Wir arbeiten hier jedoch mit und für Nicht-Techies.

Die Vorlagenwerkstatt ist seit fast einem Jahrzehnt dabei, die Jugendsünden und Irrtümer der frühen Basteljahre zurückzubauen und alle Einbindungen entsprechend umzuschreiben, und jetzt kommst du daher, wie aus einer Zeitkapsel, und führst alle alten Sünden wieder ein.

Deine Idee mit den Standard-VG und -HG kannst du von mir aus umsetzen, wobei ich aber überhaupt keinen Anwendungsfall kenne, wo das im Anwendungsbereich dieser Vorlage mal erforderlich sein würde. Dies aber nur in separaten Parametern; die Doppelbelegung desselben Parameterwertes mit mehreren völlig verschiedenen Bedeutungen ist ein bodenloser Schwachsinn und wird nicht geduldet. Andere Farbcodes als Hexcodes auch nicht.

P.S. Noch während ich diese Antwort schreibe, muss ich feststellen, dass du ohne eine Antwort abzuwarten in der laufenden Diskussion deinen Mist erneut eingebaut und sogar noch durch einen vierten unbenannten Parametern noch weiter verschlimmert hast. Ich werde deine Änderung nunmehr erneut zurücksetzen. Weiterarbeit erst nach Konsens hier auf dieser Diskussionsseite.

VG --PerfektesChaos 14:47, 2. Mai 2020 (CEST)

Die Hexnotation ist höchst intransparent, etwa auf dem Level mystischer Runen. (Ihr einziger Vorteil und Grund für die Verbreitung unter Programmierern ist, dass sie Strings fixer Länge ohne interne Leer- und Sonderzeichen verwendet.) Wer diese Notation Laien vorsetzt oder gar aufzwingt, handelt grob nutzerfeindlich. RGB ist aus farbtheoretischer Sicht nicht viel besser, aber immerhin ein bisschen einfacher zu verstehen. Nichtsdestotrotz hatte ich die festen Werte in der Vorlage, die einfachen Vorlagennutzern ohnehin nie begegnen, auf die entsprechenden Hexadezimal-Tripel geändert, weil das nicht der zentrale Punkt dieser Vorlage ist (vom schwachsinnigen Parameternamen HEX abgesehen, den sicherlich manche Nutzer treffend mit Hexerei assoziieren).

Ich habe keine einzige gravierende Änderung an dieser Vorlage vorgenommen und sie daher vorher auch nicht abgesprochen. Die einzige nennenswerte Änderung des Verhaltens mit existierenden Parametern gibt es für border=1, was statt zu einem schwarzen Rand zu einem mit rahmenfarbe1 führt. Bei meinen Stichproben in Artikeln, die diese Vorlage verwenden, habe ich keinen Fall gesehen, in dem das relevant wäre, aber natürlich mag das vorkommen. @Lómelinde:

Ich bin kein großer Freund der Klassennamen, die in Hilfe:Farben vorgestellt werden, und auch nicht unbedingt der konkreten Farbwerte, aber ich begrüße es, wenn projektweit möglichst wenige und möglichst dieselben Farben verwendet werden. Darum habe ich sie ergänzt. Man könnte sie auch über class einbinden, um auf unwahrscheinliche Änderungen an den zentralen Stylesheets vorbereitet zu sein, nur ist es nicht ideal, zwei verschiedene Parameter zu haben, welche die Hintergrund- bzw. Rahmenfarbe festlegen können.

{{Farbe|Klasse=hintergrundfarbe7}} finde ich ähnlich kryptisch wie {{Farbe|HG=7}} o.ä., weshalb ich .../blau/grün/gelb/rot als Aliase für .../6/7/8/9 eingeführt hatte.

Es gibt und gab unbestritten viele schlechte Vorlagen. Deswegen versuche ich, diese zu verbessern statt noch eine ähnliche einzuführen.

Wir können gerne über die konkreten Parameternamen diskutieren, aber wer sich die momentane Kopiervorlage ansieht: {{Farbe |HEX= |Text= |color= |border= |Kreis= |width= |height= }}, dem muss doch klar sein, dass da ein unsinniger Mix aus Deutsch und Englisch herrscht. Außerdem gibt es in TemplateData die Trennung von Schlüssel, label, aliases und description doch gerade dafür, anonyme und abgekürzte Parameter, die den Quelltext lesbar halten, in der GUI dokumentieren zu können.

Es könnte übrigens sinnvoll sein, Vorlage:Farbkreis als Weiterleitung mit Kreis=1 anzulegen. — Christoph Päper 13:28, 4. Mai 2020 (CEST)

• Deine persönlichen Ansichten zu Hexcodes kommen anderthalb Jahrzehnte zu spät.
  • Das hättest du noch 2007 erörtern können, heute ist es sinnfrei.
  • Wir verwenden einheitlich sechsstellige Farbcodes, überall, und nur damit müssen sich unsere Autoren enzyklopädischer Artikel herumplagen.
  • Siehe etwa diese Suche im ANR und viele analoge Recherchen.
  • Die Autoren haben es schon schwer genug mit Syntax; jetzt haben sie nach anderthalb Jahrzehnten diese eine, die recht kurzen Quelltext liefert, mühsam erlernt, und damit ist das jetzt so. Ende.
  • Es kommen oft genug verwirrte Rückfragen: Da steht das jetzt in Kleinbuchstaben – funktioniert das auch? Da sind jetzt nur drei Zahlen – was bedeutet das? Da stehen englische Wörter – kann man die auch verwenden, und jedes englische Wort?
• „Wer diese Notation Laien vorsetzt oder gar aufzwingt, handelt grob nutzerfeindlich.“
  • Das ist ziemlich dreist.
  • Wer nach anderthalb Jahrzehnten auf einen Kreuzzug geht, um Tausende von Autoren nach seinem persönlichen Geschmack umzuerziehen, handelt projektschädigend.
  • Es gibt genau eine Notation, die die Autoren mühsam erlernt haben, und jedes Lamentieren, das hätte man damals aber auch anders machen können, ist im Jahr 2020 für die Parkuhr.
  • Noch schlimmer sind Aktionen, jetzt noch deutschsprachige Farbnamenwörter einführen zu wollen; wir landen dann bei hilflosem style="background:grün" und der verwirrten Frage, warum das nicht funktioniert. Auch ein privates Farbnamensystem mit himmelblau kapiert immer nur der Vorlagenprogrammierer, der sie einführt.
  • Nochmal zum Mitschreiben: Hier werden einheitlich und überall die der Autorenschaft vertrauten sechsstelligen Farbcodes verwendet, und zwar in Großschreibung; wo das im ANR zufällig mal irgendwoher anders reinkopiert wurde, wird das gelegentlich angeglichen, und Ende. Hilfe:Farbtabelle liefert hinreichend Auswahl. Schon die englischen Farbnamen führen dazu, dass mache Autoren dann glauben, sie könnten sich irgendwelche Farbnamen ausdenken, und wundern sich dann, dass die nicht funktionieren.
• Wir legen keine Dubletten von Vorlagen mit gleicher Funktion an, die sechs von sieben Parametern duplizieren, sondern wir reduzieren generell die Anzahl und Vielfalt an Vorlagen.
  • Vor März 2006 konnte man noch nicht nach Parameterwerten verzweigen, und damals wurde für die allerersten Vorlagen für jeden Parameterwert eine neue Vorlage gebastelt. Das hat zu einer völlig verwirrenden Vielzahl an Vorlagen und einem undurchdringlichen Dschungel geführt.
  • Seit bald einem Jahrzehnt bauen wir all diese Sackgassen-Methodik von 2009 mühsam und mit Eliminierung und Anpassung aller Bestandseinbindungen wieder zurück.
  • Von wenigen begründeten Ausnahmesituationen abgesehen reduzieren wir die Anzahl unterschiedlicher Vorlagennamen, genauso die Aliasnamen für Parameter. Mit je mehr unterschiedlichen Bezeichnern ein und dieselbe Funktionalität spezifiziert werden könnte, desto undurchschaubarer wird das alles für Außenstehende, die nicht rein zufällig der Programmierer genau dieser Vorlage wären – nur diese sind in der Regel die einzigen Leutchen, die durch dieses Wirrwarr noch durchsteigen.
• Du scheinst mir wirklich aus einer Zeitkapsel entstiegen zu sein; ich fühle mich lebhaft an meine Wikipedia-Kindergartenzeit erinnert.

VG --PerfektesChaos 14:00, 4. Mai 2020 (CEST)

Scheinbar verstehst du Christoph hier etwas falsch, es geht nicht darum den Quelltext kurz zu halten sondern darum, dass man erkennen kann was ein Parameter bewirkt. Aus {{Farbe|HG=7}} mag man alles mögliche raten, so etwas möchte ich auf gar keinen Fall in dieser Vorlage haben. Die Namen der Parameter sind eher an der gängigen Bezeichnung orientiert.

{{Farbe |HEX= |Text= |color= |border= |Kreis= |width= |height= }}

|color= |border= |width= |height= finden sich in vielen Stylezuweisungen sind also auch vielen Benutzern geläufig.

|HEX= |Text= |Kreis= hingegen haben solche Pendants nicht, daher setzen sie sich durch Großschreibung des ersten Buchstaben davon ab. Gerade Laien sollen auch mit den Quelltextparametern klarkommen, ein kryptisches {{Farbe |1= |2= |3= |VG= |HG= |B= |H= }} ist absolut unbrauchbar. Eine Vorlagenweiterleitung halte ich für unsinnig, denn diese Vorlage dient ja nicht im eigentlichen Sinne dazu Kreise zu erzeugen, es ist lediglich aune Alternative Darstellungsform. Ich möchte dass auch die Notation #ABCDEF beibehalten wird, denn sie passt zu den Styleattributen. Wenn du also eine eigenständige Vorlage haben möchtest, die dazu dienen soll, Kreise zu zeichenen, dann verwende dafür eine eigenständige Entwicklung. Die Vorlage erfüllt genau die Funktion, für die ich sie entworfen habe. Vorlage:Farbkreis ehrlich da würde ich an so ein kreisförmiges Farbschema denken. Ud es braucht auch keine Klassen für Hintergrundfarbe oder Rahmenfarbe. Die Farbwerte kann man auch aus der Tabelle Hilfe:Farbe#Farben verwenden entnehmen, wenn man sie benötigt. Eine Verkompliziertung durch unhandliche und für Laien unverständliche Kürzel braucht diese Vorlage ganz sicher nicht. --Liebe Grüße, Lómelinde Diskussion 14:12, 4. Mai 2020 (CEST)