Calendar 1.3 (beta) published

[cmb]

Hallo snafu,

Ein schwerer, farblicher, Mängel traf mich schon in der ersten Minute.
Das mit dem grünen "sichern" im roten Feld ist sicher gut gemeint, aber für mich war da erstmal gar nichts erkennbar.

vielen Dank für diesen Hinweis. Ich habe bislang auch gar nicht an dieses Problem gedacht, aber es sollte von Entwicklern keinesfalls ignoriert werden.

Die Farbgebung des Sichern-Buttons hängt aber wohl zumindest auch mit dem Template zusammen. Bei meiner Testinstallation (1.4.2 Standard-Template) habe ich weiße Schrift auf rotem Hintergrund, genau wie bei den meisten anderen Buttons auch (Sichern der Einstellungen, Suchen usw.). Und wie ich gerade festelle, hat der Schalter auch die Klasse .submit, wie der entsprechende bei Pagemanager. Ist es da genauso?

Christoph

[snafu]

Pagemanager ..... Ist es da genauso?

Nein. rotes Feld mit weisser Schrift, also gut lesbar. Template egal.
wobei ich gerade kontrolliert habe, beim default Template ist der speichern Button von Calendar auch rotes Feld mit weisser Schrift, also eher ein "Problem" des von mir umgeänderten getfluid neutralXH. Wobei dann immer noch seltsam ist, dass sich bei deinem Pagemanager (oder auch beim Suchen) die Farben nicht ändern, aber bei Calendar schon.
Ganz unabhängig davon ist es natürlich generell wünschenswert, wenn im bunten Web auf Farbfehlsichtige Rücksicht genommen wird.

anhang:
gerade mal in die css datei gesehen, meine Lösung ist nicht elegant aber funktionabel
es gibt 2 Einträge mit " color:green;"
die hab ich jetzt einfach auskommentiert
lüppt für mich

[cmb]

Hallo snafu,

das sieht dann wirklich nach einem CSS-Clash aus. Irgendwo wird noch eine übergeordnete Klasse oder ID die Finger im Spiel haben.

Ganz unabhängig davon ist es natürlich generell wünschenswert, wenn im bunten Web auf Farbfehlsichtige Rücksicht genommen wird

Auf jeden Fall! Ein bisschen Farbe kann ja nicht schaden, aber manchmal wird's mir im Web einfach zu bunt!

Christoph

PS: Hab's gerade gesehen. Das Problem ist:

Code: Select all

.calendar_input input.submit {
    min-width: 100px;
    letter-spacing: .2em;
    color: green;
    font-weight: bold;
}

Die andere sollte eigentlich nicht stören. Wieso dieses Styling allerdings beim Default-Template unwirksam ist Eine generelle Verbesserung wäre es vielleicht, da noch ein background:was-auch-immer hinzuzufügen.

[snafu]

Eine generelle Verbesserung wäre es vielleicht, da noch ein background:was-auch-immer hinzuzufügen.

RÖCHEL
also generell wäre ich ja dafür, dass Plugins überhaupt keine eigenen Farben ins Spiel bringen, sondern einfach die Farben übernehmen, die das Template vorlegt.

Beispiel: In meiner Galerie gibt es (für verified user) einen Theme Switcher. Gleichzeitig gibts dann auch noch ein Plugin, dass es auch Mitgliedern erlaubt das Tagging System zu benutzen (also selber Tags anzulegen und Bilder damit zu versehen). Tolles Teil, der Programmierer meinte es designtechnisch aber auch zu gut. Er selbst benutze wohl ein farblich eher helles Theme und beglückte sein Plugin mit einem vollumfänglichen css in dem alles abgedeckt wurde. Es auf das von mir bevorzugte dunkle Template anzupassen war echt mühsam, mit dem Ergebniss, dass alle Benutzer von hellen Templates dann das Plugin nicht mehr benutzen konnten. Glücklicherweise hatte der Programmierer irgendwann ein Einsehen und inzwischen läuft das Plugin unter jedem Template, egal welche Farben und Fonts man benutzt (die css Datei ist auch nur noch ein Bruchteil so groß).

Deswegen: Definition von eigenen Farben, Schriftarten/Größe haben in Plugins, so eine Überschneidung mit dem Grundsystem möglich ist, meiner Meinung nach, nichts verloren.

[Gert]

also generell wäre ich ja dafür, dass Plugins überhaupt keine eigenen Farben ins Spiel bringen, sondern einfach die Farben übernehmen, die das Template vorlegt.

Genau so versuche ich es in meinen Plugins zu handhaben, und auch bei den Sachen, die ich für CMSimple_XH mache.

Persönliche Noten haben im Backend eigentlich nichts zu suchen, das Backend ist ein Arbeitsplatz, nichts weiter. Und der admin hat sich ja ein Template herausgesucht, das ihm gefällt, also sollte ihm dann auch der Arbeitsplatz im Stil seines Templates gefallen

Wobei sich bei meinen Plugins kaum einer einmischt diesbezüglich, aber was CMSimple_XH betrifft, gibt es da immer mal wieder Diskussionen.

[cmb]

Hallo snafu,

ich selbst bin diesbezüglich eher faul, und verzichte deshalb auf umfangreiches Styling. Aber es kommt natürlich auch auf die Plugins an. Bei einem Galerie-Plugin z.B., das sich einfach nur auf das Template verläßt, wird die Erscheinung wohl recht nüchtern ausfallen -- gelinde gesagt. Und beim Kalender benötigt die Darstellung der Veranstaltungsliste und des Kalenders wohl schon eigene Schriftarten und Farben.

Und ein Grundproblem bleibt: die Templates bieten keine einheitlichen Styles für verschiedene Zwecke. Mal ist es so, mal ganz anders. Und da sehe ich leider auch keine einfache Lösung für die Pluginentwickler Vielleicht sollte das mal in Open Development thematisiert werden?

Christoph

[Gert]

Und beim Kalender benötigt die Darstellung der Veranstaltungsliste und des Kalenders wohl schon eigene Schriftarten und Farben.

Warum?

Das Problem ist: Wenn ich die gesamte Ausgabe des Plugins oder Teile davon in ein div packe und einen Hintergrund definiere, muss ich ALLES durchformatieren, z. B. auch die verschiedenen Linkzustände (was gerne vergessen wird), Text, hr, die Überschriften usw.

Sonst gibt es mit Sicherheit Probleme mit verschiedenen Templates, auch im Frontend. Und eigene Schriftarten? Wozu? Wenn sich einer für eine Serifenschrift entschieden hat, dann will er die bestimmt auch in der Plugin Ausgabe haben.

Ein häufiges Beispiel sind durchformatierte Kommentarausgaben in Blogs. Wenn dann der Kommentar eine ganz andere Schriftart und vor allem Schriftgrösse hat als der Artikel, kann ich mir als Leser die Schriftgrösse nicht ordentlich einstellen. Jedesmal, wenn ich einen Kommentar lese, mache ich strg+, wenn ich im Artikel nachlese, wieder strg- (wenn z. B. der Kommentar eine viel kleinere Schriftart hat). Genauso wäre das mit den Terminen im Calendar Plugin.

Ich halte nichts davon, Plugin Ausgaben zu stylen (naja, paddings und margins schon), das KANN nicht gut gehen in verschiedenen Templates. Man kann ja die wichtigsten Dinge konfigurierbar machen, wie bei FotoGalerie_XH (z. B. backgrounds, borders und paddings der Thumbs und Bilder), das geht dann aber nur mit inline CSS - mag auch nicht jeder.

[cmb]

Hallo Gert,

im Monats-Kalender werden verschiedene Farben verwendet, u.a. um die Wochenendtage hervorzuheben. Und in der Veranstaltungsliste werden zumindest unterschiedliche Schriftformatierungen (style, weight, size) gebraucht. Unterschiedliche Schriftarten wohl nicht wirklich.

Und ich persönlich mag es eigentlich nicht wirklich, wenn die Styles in der Konfig landen. Solange es sich in Grenzen hält: okay. Aber ich fürchte, dass es dann bald heißt: kann man nicht auch noch dieses oder jenes Styling konfigurierbar machen Andererseits ist es für Endanwender schwierig, die entsprechenden Anpassungen im Stylesheet selbst vorzunehmen. Vielleicht ist es auch eine Idee, wenn der Plugin-Autor nur minimal style't, und dann umfangreichere Stylings als "Theme"-Packs separat zum Download anbietet?

Christoph

[snafu]

.... Bei einem Galerie-Plugin z.B., das sich einfach nur auf das Template verläßt, wird die Erscheinung wohl recht nüchtern ausfallen -- gelinde gesagt.

Wenn eine Galerie der primäre Inhalt des CMS sein soll, dann werde ich wohl das Template genau unter diesem Aspekt aussuchen: es passt zur Galerie und erfüllt den Zeck Bilder attraktiv darzustellen (oder was ich darunter verstehe). Wenn die Galerie nur eines von mehreren, gleichwichtigen Themen darstellt, spricht auch wenig dagegen, daß sie harmonisch ins Gesamtbild passt. Wobei gegen "nüchtern", so wir dann mal genau definieren was das ist, auch nicht generell etwas einzuwenden ist.

Und ein Grundproblem bleibt: die Templates bieten keine einheitlichen Styles für verschiedene Zwecke. Mal ist es so, mal ganz anders.

Versteh ich jetzt nicht. Ein Template bietet genau das, womit ich als Endanwender meine Inhalte verpacken möchte (oder bietet zumindest eine gute Ausgangsposition um mit wenigen kleineren eigene Anpassung dahinzukommen, wo ich hinwill). Für mich ist das dann die einheitliche Grundlage dem sich alles andere zu unterwerfen hat.
Wenn ich also mit viel Mühe den Font "gputeks" eingebunden habe, weil ich den nunmal geil finde, betrachte ich es als echt kontraproduktiv, wenn ein Pluginentwickler in seinem css einen eigen Font definiert .
Wenn ich also die für mich gefälligen Farben und Fonts gefunden habe, möcht ich mich nicht noch mit Plugins rumschlagen müssen, die da ihr eigenes Süppchen kochen, zumindest dann nicht wenn die Präsentation des Contents dadurch berührt wird.

Vielleicht ist es auch eine Idee, wenn der Plugin-Autor nur minimal style't, und dann umfangreichere Stylings als "Theme"-Packs separat zum Download anbietet?

das klingt interessant

[Gert]

Hallo Christoph,

das ist ja, wie so oft, eine Grundsatzdiskussion. Grundsätze sind dazu da, um an passender Stelle davon abzuweichen

Der kleine Kalender in der Sidebar kann natürlich durchgestylt sein, muss wohl sogar. Und da kann man sicher auch ein paar "Themes" mitliefern.

Aber hier: http://frankziesing.de/cmsimple/?Erweit ... staltungen wird es dann eben kompliziert mit den unterschiedlichen Templates. Da gibt es dann wohl auch kein generelles, allgemeingültiges Rezept.

Ich würde das wohl eher unformatiert ausgeben (Vielleicht mal was fett oder Kursiv, mit <hr> getrennt), aber die Klassen und id's im Programmcode anlegen, vielleicht auch schon leer in der stylesheet.css, so dass ein versierter Anwender sich das dann entsprechend seinem Template stylen kann.

Das kann er dann selber tun, oder im Forum nachfragen und Du machst es ihm dann

Oder er nimmt ein paar EUR in die Hand und lässt es von einem Dienstleister machen, ich hätte da schon einen