Serendipity Forums

Moin!

An diesem - hier etwas trüben - Wochenende treiben mich zwei bis drei Fragen um:

1. Das Markdown-Plugin ermöglicht es, Fußnoten zu setzen.

Per default sehen diese folgendermaßen aus: https://www.dropbox.com/s/18lfn1kn3vxtd ... 1.png?dl=0

Optisch finde ich diese Form gefälliger: https://www.dropbox.com/s/pip9alwv4que8 ... 4.png?dl=0

(Klammer hinter der Fußnotenziffer, Trenner Text/Fußnote etwas weniger auffällig, Fußnotenziffer in der Fußnote ebenfalls hochgestellt und fett)

Bin das nur ich oder ist das verallgemeinerbar?

2. Falls es verallgemeinerbar sein sollte:

Gehört CSS, das nur für bestimmte Plugins relevant ist, in das Theme (hier dann zunächst: 2k11) oder in das Plugin?

Pro Plugin: Das CSS wird nicht überfrachtet und bleibt kleiner und schlanker.
Pro Theme: Das CSS lässt sich passend zum Theme gestalten und muss nicht "one CSS fits all" sein.

3. Falls das CSS ins Plugin gehören sollte:

Wie?

-thh

thh wrote:Bin das nur ich oder ist das verallgemeinerbar?

Ich predige schon immer™, dass Plugins grundsätzlich nach Möglichkeit nur das unbedingt nötige CSS ausgeben sollten. Es ist völlig klar, dass es Plugins gibt, die spezifisches CSS benötigen (z.B. das Lighbox-Plugin), aber es sollte so wenig wie möglich, so neutral wie möglich und vor allem noch überschreibbar (Stichwort: Spezifität) sein. Ansonsten kommen wir zu grottigem, uralten Plugin-CSS, das von zeitgemäßen Themes nicht mehr überschrieben werden kann, und das hatten wir lange genug (und haben es in etlichen Plugins noch).

Diese Einstellung hat in der Vergangenheit aber nicht jeder Pluginentwickler geteilt.

So gesehen neige ich dazu, hier nur die Hochstellung der Fußnotenziffer zu befürworten, würde aber auch das über  lösen (was aber ggf. noch CSS braucht, glaube ich).

thh wrote:Gehört CSS, das nur für bestimmte Plugins relevant ist, in das Theme (hier dann zunächst: 2k11) oder in das Plugin?

Schwierig. Einerseits gehört das, was unbedingt nötig ist, um eine vernünftige Darstellung zu gewährleisten, unbedingt ins Plugins. Beispiel: Gäbe es ein Plugin, um in Blogeinträgen Akkordeon-Elemente zu verwenden, würde das dafür nötige CSS (und JS) ins Plugin gehören, aber eben nur das „funktional notwendige“, nicht das „optisch anpassende“, falls das verständlich ist.

Das ist der Punkt, wo Pluginautoren durchaus mal anderer Meinung waren, weil die Ausgabe mit rein funktionalem CSS halt meistens etwas unfertig aussieht und viele Themes eben gar keine Styles für bestimmte Plugins haben. Und zugegeben, es ist auch irgendwie unschön, Plugin-Styles ins Theme zu packen, weil es zig Nutzer gibt, die bestimmte Plugins gar nicht verwenden, aber dann deren Styles mitschleppen. Zudem haben wir ja ausdrücklich diesen Mechanismus, Plugin-Styles sauber ins dynamisch erzeugte CSS einzubinden, wenn das Plugin verwendet wird; auch das spricht für „Styles ins Plugin“.

So gesehen neige ich zu: Styles ins Plugin, aber bitte nicht „übertreiben“ und vor allem aufpassen, dass sich die Styles bei Bedarf über Theme und/oder user.css noch überschreiben lassen.

thh wrote:Falls das CSS ins Plugin gehören sollte: Wie?

Lustigerweise gibt es mehrere Wege.

• Plugins, die eigene CSS-Dateien haben, z.B. serendipity_eventcal_cal
• Plugins, die Inline-CSS im Plugin-Code haben, z.B. serendipity_event_freetag
• Plugins, die die Funktion addToCSS() nutzen, z.B. auch serendipity_event_freetag
• ich meine, es gibt noch eine weitere Methode mit einem <style>-Element im Plugin-Code, aber mir geht jetzt akut die Zeit aus, danach zu suchen

Generell gibt es Hooks wie frontend_header, über den man z.B. zusätzliche Stylesheets einbinden könnte (ungünstig), es gibt einen weiteren CSS-Hook, über den man in die serendipity.css einbinden kann (ich weiß gerade nicht, wie der konkret heißt) und eben addToCSS, was ganz pfiffig ist, weil es meines Wissens nur in die serendipity.css einbindet, wenn die entsprechenden Klassen nicht in der style.css des Themes stehen.

Hoffe, das hilft weiter. Grep mal über die commit-Messages von additional_plugin, da könntest Du auch fündig werden.

YL

yellowled wrote:

thh wrote:Bin das nur ich oder ist das verallgemeinerbar?

Ich predige schon immer™, dass Plugins grundsätzlich nach Möglichkeit nur das unbedingt nötige CSS ausgeben sollten.

Das entspricht dem, was ich vermutet habe, war aber noch gar nicht spezifisch die Frage.

Das Plugin benötigt kein CSS, um Fußnoten anzuzeigen. Man könnte sie nur schöner anzeigen - und ich frage mich jetzt, ob wir das jedem Nutzer selbst überlassen oder einen "schönen" Default mitliefern sollten. (Und wenn ja, wo - Plugin oder Theme.)

yellowled wrote:So gesehen neige ich dazu, hier nur die Hochstellung der Fußnotenziffer zu befürworten, würde aber auch das über  lösen (was aber ggf. noch CSS braucht, glaube ich).

Die Fußnotenziffer im Text ist bereits hochgestellt ...

yellowled wrote:

thh wrote:Gehört CSS, das nur für bestimmte Plugins relevant ist, in das Theme (hier dann zunächst: 2k11) oder in das Plugin?

Schwierig. Einerseits gehört das, was unbedingt nötig ist, um eine vernünftige Darstellung zu gewährleisten, unbedingt ins Plugins. Beispiel: Gäbe es ein Plugin, um in Blogeinträgen Akkordeon-Elemente zu verwenden, würde das dafür nötige CSS (und JS) ins Plugin gehören, aber eben nur das „funktional notwendige“, nicht das „optisch anpassende“, falls das verständlich ist.

Funktional notwendig ist hier IMHO kein weiteres CSS.

Ich sehe drei Möglichkeiten, das von mir präferierte "hübschere" CSS zu publizieren:

1. Einbau ins Plugin
2. Einbau ins Theme
3. Ich schreibe einen Blogbeitrag dazu, wie man sich das ins user.css einbauen kann.

Was der gegebene Weg ist, hängt einerseits davon ab, ob das CSS überhaupt mehrheitsfähig ist - vielleicht finde ja nur ich es hübsch - und zum anderen, wo solches CSS hingehört.

yellowled wrote:Das ist der Punkt, wo Pluginautoren durchaus mal anderer Meinung waren, weil die Ausgabe mit rein funktionalem CSS halt meistens etwas unfertig aussieht und viele Themes eben gar keine Styles für bestimmte Plugins haben. Und zugegeben, es ist auch irgendwie unschön, Plugin-Styles ins Theme zu packen, weil es zig Nutzer gibt, die bestimmte Plugins gar nicht verwenden, aber dann deren Styles mitschleppen. Zudem haben wir ja ausdrücklich diesen Mechanismus, Plugin-Styles sauber ins dynamisch erzeugte CSS einzubinden, wenn das Plugin verwendet wird; auch das spricht für „Styles ins Plugin“.

So gesehen neige ich zu: Styles ins Plugin, aber bitte nicht „übertreiben“ und vor allem aufpassen, dass sich die Styles bei Bedarf über Theme und/oder user.css noch überschreiben lassen.

Okay.

yellowled wrote:

thh wrote:Falls das CSS ins Plugin gehören sollte: Wie?

Lustigerweise gibt es mehrere Wege.

• Plugins, die eigene CSS-Dateien haben, z.B. serendipity_eventcal_cal
• Plugins, die Inline-CSS im Plugin-Code haben, z.B. serendipity_event_freetag
• Plugins, die die Funktion addToCSS() nutzen, z.B. auch serendipity_event_freetag
• ich meine, es gibt noch eine weitere Methode mit einem <style>-Element im Plugin-Code, aber mir geht jetzt akut die Zeit aus, danach zu suchen

Generell gibt es Hooks wie frontend_header, über den man z.B. zusätzliche Stylesheets einbinden könnte (ungünstig), es gibt einen weiteren CSS-Hook, über den man in die serendipity.css einbinden kann (ich weiß gerade nicht, wie der konkret heißt) und eben addToCSS, was ganz pfiffig ist, weil es meines Wissens nur in die serendipity.css einbindet, wenn die entsprechenden Klassen nicht in der style.css des Themes stehen.

Hoffe, das hilft weiter. Grep mal über die commit-Messages von additional_plugin, da könntest Du auch fündig werden.

Das hilft sehr! - Wenn, dann also über addToCSS(). Die Frage ist mithin nur noch, ob.

thh wrote:Man könnte sie nur schöner anzeigen - und ich frage mich jetzt, ob wir das jedem Nutzer selbst überlassen oder einen "schönen" Default mitliefern sollten. (Und wenn ja, wo - Plugin oder Theme.)

Theoretisch im Theme, denn „schöner“ hängt vom Theme ab. Das Problem ist, dass die meisten Themes aus nachvollziehbaren und guten Gründen nur Styles für weit verbreitete Plugins mitbringen. Deshalb praktisch im Plugin, aber möglichst „neutral“ und überschreibbar (keine IDs, kein !important, möglichst nur über Klassen).

thh wrote:Das hilft sehr! - Wenn, dann also über addToCSS().

Wie gesagt: Wenn ich mich nicht total täusche, ist das die Funktion, die eigentlich für meinen Geschmack ideal ist, weil man eben Plugin-Styles bauen kann, die aber nicht eingebunden werden, wenn das Theme eigene hat.

Wobei die Stolperfalle halt ist, dass das Theme exakt die gleichen Selektoren bzw. – glaube ich – Klassen nutzen muss, damit das funktioniert. Und es gibt halt meistens mehrere Selektoren, die zum Ziel führen, aber das wäre dann ein Problem des Themes, nicht des Plugins.

YL

yellowled wrote:Theoretisch im Theme, denn „schöner“ hängt vom Theme ab. Das Problem ist, dass die meisten Themes aus nachvollziehbaren und guten Gründen nur Styles für weit verbreitete Plugins mitbringen. Deshalb praktisch im Plugin, aber möglichst „neutral“ und überschreibbar (keine IDs, kein !important, möglichst nur über Klassen).

Okay. Danke für die Tips!

https://github.com/s9y/additional_plugins/pull/64