XH 1.7, Pagemanager 3, Icon-Font

[frase]

Jetzt könnte ich mich tasächlich in den H... beißen.
Die Examples-Seite ist mir zu diesem Zeitpunkt einfach nicht in den Sinn gekommen.
Was soll's. Du hast natürlich in jedem Punkt Recht.
Trotzdem bleibt das Thema. Haben die Beispiele deine Entscheidung beeinflusst?

[cmb]

Haben die Beispiele deine Entscheidung beeinflusst?

Genau habe ich mir diese noch nicht angeschaut. Werde ich aber möglichst bald nachholen.

[cmb]

Werde ich aber möglichst bald nachholen.

Ja, das ist wirklich nett!

Als Pluginentwickler finde ich, es bringt mir nicht allzu viel. Ob ich nun ein <i> Element oder ein background-image verwende, macht bei Plugins keinen zu großen Unterschied, und ich bin flexibler, falls nötig. Wenn's dann auf einem Retina-Display nicht gut aussieht, dann ist das nicht mehr unbedingt mein Problem, sondern das des Webdesigners/-masters.

Aber für manche Webdesigner/-master wäre eine Integration von Font Awesome natürlich klasse. Nicht nur im Template können die Icons verwendet werden, sondern auch im Content, und es gibt sogar hilfreiche Plugins für TinyMCE 4 und CKEditor. Wären diese integriert – großes Plus!

Als Core-Entwickler bin ich skeptisch bezüglich der "Dateigröße" und vor allem bezüglich der Zukunftsträchtigkeit von Icon-Fonts im allgemeinen, und Font Awesome im besonderen. Schließlich müsste die gewählte Lösung ja doch vermutlich wenigstens ein paar Jährchen gewartet werden.

Wie wäre es also, wenn der komplette Font Awesome Support per Standard-Plugin realisiert wird, ganz ähnlich wie bei jQuery4CMSimple?

[frase]

Als Pluginentwickler finde ich, es bringt mir nicht allzu viel. Ob ich nun ein <i> Element oder ein background-image verwende, macht bei Plugins keinen zu großen Unterschied, und ich bin flexibler, falls nötig. Wenn's dann auf einem Retina-Display nicht gut aussieht, dann ist das nicht mehr unbedingt mein Problem, sondern das des Webdesigners/-masters.

Bis auf den letzten Satz: Alles richtig.
Aber es gibt entscheidende Vorteile:
Das gesamte "Look&Feel" von CMSimple könnte besser werden - einheitlicher.
Ein "Save"-Icon z.B., ist immer und überall das gleiche.
Requests für "Bildchen" fallen weg.
...

Als Core-Entwickler bin ich skeptisch bezüglich der "Dateigröße" und vor allem bezüglich der Zukunftsträchtigkeit von Icon-Fonts im allgemeinen, und Font Awesome im besonderen. Schließlich müsste die gewählte Lösung ja doch vermutlich wenigstens ein paar Jährchen gewartet werden.

Die Wartung ist simple: Den Font und das zugehörige CSS austauschen ist ein Klacks. FontAwesome wird bei der Weiterentwicklung nicht verändert sondern erweitert. Das bringt keine Nachteile - nur Vorteile.
Dateigröße: Ja, der Download wird etwas größer. Das ist bei Modernisierungen nun mal so. Die Benutzer wollen moderne Features und nehmen das sicher gerne hin.
Zukunftsträchtigkeit: Wir könnten mit der Modernisierung ja noch ein paar Jährchen warten. Vielleicht wird noch was neues Besseres erfunden ... ???

Wie wäre es also, wenn der komplette Font Awesome Support per Standard-Plugin realisiert wird, ganz ähnlich wie bei jQuery4CMSimple?

Und da ist er wieder - der wahre, gute, vorausschauende Christoph! Das scheint möglicherweise die beste Lösung. Leider traue ich mir die Umsetzung nicht zu. Schätze aber, dass es kein Hexenwerk ist.

[lck]

Wie wäre es also, wenn der komplette Font Awesome Support per Standard-Plugin realisiert wird, ganz ähnlich wie bei jQuery4CMSimple?

+1

[cmb]

Die Wartung ist simple: Den Font und das zugehörige CSS austauschen ist ein Klacks. FontAwesome wird bei der Weiterentwicklung nicht verändert sondern erweitert. Das bringt keine Nachteile - nur Vorteile.

Ja, solange Font Awesome weiter entwickelt wird. Ich gehe zwar schwer davon aus, dass das zumindest auf Jahre so sein wird, aber letztlich kann man nie wissen. Und wenn es zum GAU käme (Font Awesome wird nicht mehr weiter entwickelt, und läuft dann auf einem neuen Browser nicht mehr), dann müssten wird das ausbaden. https://cmsimpleforum.com/viewtopic.php?f=16&t=2944 war eine garstige Sache, und auch bei Pagemanager_XH sah es mal düster aus, weil die Entwicklung von jsTree in Schräglage gekommen war.

Zukunftsträchtigkeit: Wir könnten mit der Modernisierung ja noch ein paar Jährchen warten. Vielleicht wird noch was neues Besseres erfunden ... ???

Das ist natürlich ein sehr guter Punkt!

Wie wäre es also, wenn der komplette Font Awesome Support per Standard-Plugin realisiert wird, ganz ähnlich wie bei jQuery4CMSimple?

Und da ist er wieder - der wahre, gute, vorausschauende Christoph! Das scheint möglicherweise die beste Lösung. Leider traue ich mir die Umsetzung nicht zu. Schätze aber, dass es kein Hexenwerk ist.

Na ja, ein bisschen ist das ein fauler Kompromiß, weil halt der Core das Plugin nicht verwenden könnte (zumindest sollte der Core idealerweise nicht von Plugins abhängen). Das finde ich jetzt aber nicht soo schlimm, und eine Core-Integration ist bei einem viel genutzten Plugin ja später immer noch möglich.

Ich schau mal, dass ich möglichst zeitnah einen ersten Entwurf für ein Font Awesome Plugin erstelle, und dann können wir weiter sehen.

[frase]

Du bist der Beste!
Danke!

[cmb]

Du bist der Beste!

Na, ja.

Jedenfalls habe ich mal einen allerersten Entwurf auf Github eingestellt. Einfach irgendwo oben im Template folgendes ergänzen:

Code: Select all

<?php fa_link()?>

und Font Awesome sollte im Template verfügbar sein. Man kann den entsprechenden Plugin-Aufruf auch auf einer Seite eingeben:

Code: Select all

{{{fa_link}}} 

Dann klappt's auch im Content (allerdings nicht in der Bearbeitungsansicht, da müssten erst noch die Editor-Plugins integriert werden).

Und Plugins können die Funktion ebenfalls aufrufen, wenn sie Font Awesome verwenden wollen. Na ja, zumindest wenn ihr Name alphabetisch nach "fa" kommt. Da lass ich mir noch was einfallen.

Auf jeden Fall ist mir noch ein Vorteil der Pluginlösung aufgefallen: das Plugin könnte auch unter älteren CMSimple_XH Versionen genutzt werden, so dass Plugins gar keine Fallbacks einbauen müssten.

Ich bin mir ziemlich sicher, dass .otf und .svg lediglich Fallbacks für besondere und alte Browser sind.

Du hattest völlig recht. Ich habe mir das noch mal genauer angeschaut, und es geht vor allem um iOS Safari; der kennt WOFF erst seit 5.1, TTF seit 4.3 aber SVG-Fonts schon mindestens seit 3.2. Gemäß caniuse.com ist aber der Markanteil von iOS Safari < 4.3 geringer als von IE 6; ich denke darauf kann man verzichten, oder?

[frase]

Großartig!

In Zeitnot nur kurz angetestet.

Problem:
Im Template eingefügt: <?php fa_link()?>
Bringt überhaupt nichts ???

Auf einer Seite eingefügt: {{{fa_link}}}
Bringt im Quelltext @font-face { ...
Und: <link rel="stylesheet" type="text/css" href="./plugins/fa/css/font-awesome.css">
Das Verzeichnis muss aber "fa_xh" heißen - oder?

Und am Ende könnten wir die min-Version nehmen. Ohne SVG.

Später mehr.

[cmb]

Großartig!

In Zeitnot nur kurz angetestet.

Prima, danke!

Problem:
Im Template eingefügt: <?php fa_link()?>
Bringt überhaupt nichts ???

Der Code muss vor <?php echo head()?> stehen, sonst bewirkt er tatsächlich nichts. Im Zweifel also ganz oben im Template eingeben (direkt vor oder nach dem Doctype).

Das Verzeichnis muss aber "fa_xh" heißen - oder?

Nein, fa ist schon richtig. Allerdings hatte ich vergessen zu erwähnen, dass beim Github-Download das Verzeichnis fa_xh-master in fa umbenannt werden muss. Ist übrigens bei allen meinen Plugins so, wobei -master auch anders lauten kann: alles inklusive des ersten Unterstrichs bis zum Ende muss weg.

Und am Ende könnten wir die min-Version nehmen. Ohne SVG.

Ja, sollte eigentlich so sein. Andererseits nehmen sich die beiden Varianten nicht viel (30 vs. 37 KB), und so ist es leichter bei Bedarf noch etwas anzupassen. Und falls https://github.com/cmsimple-xh/cmsimple-xh/issues/82 umgesetzt wird, dann wäre es sowieso egal.