XH 1.7, Pagemanager 3, Icon-Font

[cmb]

Dabei wollte ich in diesem Thread nur die Einführung eines Icon-Fonts beantragen.
Was ich hiermit offiziell tun möchte!

Steht ja schon auf der Roadmap, und wird für XH 1.7.0beta1 berücksichtigt werden (sprich, es wird demnächst drüber abgestimmt).

Wie soll Manu denn die ganzen verteilten Meldungen finden und behandeln?

Ich denke, das beste ist ein Issue im Repo einzureichen (ggf. mit Link zum relevantesten Post). Dann geht das Thema nicht vergessen, und andere bekommen auch mit, wenn es sich erledigt hat (sprich, das Ticket geschlossen wurde).

Was haltet ihr davon, FontAwesome mit CMSimple_XH auszuliefern?

Grundsätzlich bin ich dafür eine Icon-Font auszuliefern; Font Awesome wäre auf jeden Fall keine schlechte Wahl.

Insgesamt wäre der Download um ca. 1 MB größer. 1 Font-Ordner, […]

Werden alle Dateien in assets/fonts/ benötigt? Sprich, braucht man wirklich 5 verschiedene Font-Formate, und was ist mit dem .svg? Wenn ich bedenke, dass IE 7 und älter gar nicht unterstützt werden, kommen mir diese 5-6 Alternativen doch ein bisschen viel vor.

Für die Material-Icons ist dokumentiert, dass man nur 3-4 Fonts und kein SVG braucht. Und das scheint dann sogar mit IE 6 kompatibel. Kann das vielleicht auf Font Awesome übertragen werden? Was sind die Vor- und Nachteile? Ich habe halt fast keine Erfahrung mit solchen Icon-Fonts, und kann mir auf die Schnelle auch kein umfassendes Wissen draufschaffen, möchte aber halt auch keine schnelle Entscheidung treffen, die sich dann als nicht unproblematisch herausstellt, aber an der aus Kompatibilitätsgründen über Jahre festgehalten werden muss.

Wenn mit einem "unveränderlichen Wurzelknoten" gemeint ist, dass immer von der ersten Seite ausgegangen wird, dann lieber nicht.

Nein, das ist nicht gemeint. Der "unveränderliche Wurzelknoten" würde keine Seite repräsentieren, sondern die "Website" (na ja, eigentlich die jeweilige Sprache der aktuellen CMSimple_XH Installation). Dieser Knoten wäre nicht bearbeitbar (und falls möglich, nicht mal zuklappbar), sondern würde lediglich dazu dienen, darauf Einfüge-Operation (neue Seite, Seite einfügen) durchführen zu können, so dass Einfüge-Operation immer als "als Unterseite einfügen" wirken könnten. Im Prinzip wäre der "unveränderliche Wurzelknoten" vergleichbar mit einem Laufwerksknoten im Windows Explorer. Ich schau mal, dass ich zu Demo- und Testzwecken einen entsprechenden Branch ausarbeite.

[cmb]

Okay, hier mal zum Vergleich eine Alternative zu Franks fa-for-xh.zip, die das Material-Icon-Font verwendet:

mi-for-xh.zip

Vorteile: funktioniert auch unter alten IE und ist deutlich kleiner (228 KB vs. 608 KB gezippt). Beides könnte wohl aber auch bei der Font Awesome Variante verbessert werden.

Nachteil: Font Awesome scheint zumindest für den Pagemanager eher passende Icons anzubieten.

Vor-/Nachteil: bei der Material-Icon-Font werden die Icons per Character-Entity eingebunden (aus Kompatibilitätsgründen), bei Font Awesome per CSS-Klasse. Letzteres ist sicher intuitiver, ersteres spart einiges CSS und funktioniert auch unter alten IEs.

Völlig unklar: Accessibility. Die Font Awesome Doku geht detailliert darauf ein, wie man die Icons durch aria-* Attribute für moderne Screenreader accessible macht; der Material Icons Guide scheint das Thema nicht mal zu erwähnen. Grundsätzlich erscheinen mir aber die per Character-Entity direkt eingebunden Glyphen schon eher accessible, wenn auch nicht für Screenreader.

[frase]

Werden alle Dateien in assets/fonts/ benötigt?

Ich bin mir ziemlich sicher, dass .otf und .svg lediglich Fallbacks für besondere und alte Browser sind.
Ich konnte aber keine konkreten Angaben dazu finden.
Sei es, wie es sei. Während der Arbeit ist das egal - denn der jeweilige Browser lädt sich ja nur die Schrift, die er braucht.
Es wird ja nicht immer alles übertragen. Oder?
Also wäre nur das XH-Downloadpaket etwas größer.

Grundsätzlich erscheinen mir aber die per Character-Entity direkt eingebunden Glyphen schon eher accessible, wenn auch nicht für Screenreader.

Das wird wohl immer ein Problem bleiben. Das eine ist nicht lesbar, das andere verlangt viel Tipparbeit.

Okay, hier mal zum Vergleich eine Alternative zu Franks fa-for-xh.zip, die das Material-Icon-Font verwendet:

Siehst du, jetzt hast du das Widget auch geändert.
Im Prinzip ist es nichts anderes und sieht genauso gut aus. (Außer, dass du immer gruppieren willst )
Mit FontAwesome und deinem Widget sähe das "Speichern" so aus:

Code: Select all

'save' => '', 

Also, alles nur eine Entscheidungsfrage.
Ich neige jetzt allerdings doch mehr zu FontAwesome. Es ist schon im Einsatz.

[cmb]

Es wird ja nicht immer alles übertragen. Oder?
Also wäre nur das XH-Downloadpaket etwas größer.

Nein, übertragen wird nur was gebraucht wird. Aber 1 MB für das Downloadpaket finde ich mehr als nur "etwas größer". Na gut, 1 MB wird's nicht wirklich sein, aber ich bin da lieber etwas konservativ.

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

Mich stört vor allem das SVG (ist ja riesig); kann es sein, dass das eigentlich nur gebraucht wird, wenn man die Icons direkt einbinden will (also nicht wirklich als Font)?

Im Prinzip ist es nichts anderes und sieht genauso gut aus. (Außer, dass du immer gruppieren willst )

Am Gruppieren hängt mein Herz nicht; ich habe bei dieser Variante einfach nur die minimalen Änderungen durchgeführt.

Ich neige jetzt allerdings doch mehr zu FontAwesome. Es ist schon im Einsatz.

Das ist ein gutes Argument. Trotzdem würde ich nicht ungerne minimalistisch bleiben. Vielleicht wäre es eine Option, per Default nur ein minimales Font Awesome wirklich einzubinden (vergleichbar mit dem CSS der Material-Icons), und optional das "Gesamtpaket"? Pluginentwickler sollten kein großes Problem damit haben Character-Entities zu verwenden, und Webdesigner und Webmaster bliebe dann immer noch das opt-in zur "Vollversion". Vielleicht ist das aber auch völlig übertrieben, und das normale CSS ist kein echtes Problem. Müsste man im Zweifel mal ausprobieren (sprich, messen).

Ein Vorteil der Character-Entities wäre halt wohl, dass sie auch unter älteren IEs prima funktionieren, was vielleicht nicht unbedingt wichtig ist, aber doch ganz nett wäre.

Also: die alte Variante wieder herstellen, oder einen unveränderlichen Wurzelknoten hinzufügen, oder?

Okay, der "unveränderlich Wurzelknoten" scheidet aus, weil es damit im Prinzip das gleiche Problem gibt: die Reihenfolge der Unterseiten kann nicht beliebig geändert werden (außer per Drag&Drop). Vielleicht wäre eine "Move"-Operation (mit fiel bisher kein passenderer Name ein), die eine Seite in die vorherige Seite verschiebt, und zwar dort ans Ende. Das entspräche bei der klassischen Editor-Seitenverwaltung der Erhöhung des menu_levels der Seite um 1. Ich habe das mal im move-node Branch ausgearbeitet; wer will, kann es sich ja mal herunter laden und anschauen (der Ordner pagemanager_xh-move-node/ muss in pagemanager/ umbenannt werden).

Wirklich überzeugt bin ich von dieser Variante auch nicht, aber vielleicht ist das Move auch für andere Anwendungsfälle sinnvoll? Es ist natürlich auch denkbar ein umgekehrtes Move zu ergänzen, das eine Unterseite eine Ebene nach oben schiebt.

[cmb]

Grundsätzlich bin ich dafür eine Icon-Font auszuliefern; […]

Jetzt habe ich noch mal ein bisschen nachgelesen, und bin nicht mehr sicher. https://css-tricks.com/icon-fonts-vs-svg/ lässt sich über die vielen Vorteile von inline-SVGs gegenüber Icon-Fonts aus, https://cloudfour.com/thinks/seriously- ... con-fonts/ empfiehlt keine Icons-Fonts zu verwenden, und https://benfrain.com/seriously-use-icon-fonts/ argumentiert dagegen. Nun bin ich völlig verwirrt – warum muss immer alles so kompliziert sein. Seufz.

[frase]

Nun bin ich völlig verwirrt – warum muss immer alles so kompliziert sein. Seufz.

Was meinst du wohl, warum ich so "relativ ruhig" bin und nicht heftig Druck mache?
Mir geht es ganz genau wie dir.
Ich hatte schon gelesen:t3n.de/news/svgs-ftw-keine-icon-fonts-678232 mit Link zu den anderen Artikeln.

Andererseits habe ich auch keine Lust auf Zeilen wie diese:

Code: Select all

<path d="m481 117c-13 18-28 34-46 47c0 3 0 7 0 12c0 25-3 50-11 74c-7 25-18 49-33 71c-14 23-32 43-52 61c-21 17-45 31-74 41c-29 11-60 16-92 16c-52 0-99-14-142-42c7 1 14 2 22 2c43 0 81-14 115-40c-20 0-38-6-54-18c-16-12-27-27-33-46c7 1 13 2 18 2c8 0 16-1 24-4c-21-4-39-15-53-31c-14-17-21-37-21-59l0-1c13 7 27 11 42 11c-13-8-23-19-30-32c-8-14-11-29-11-44c0-17 4-33 12-47c23 28 51 51 84 68c33 17 69 27 107 29c-2-8-3-15-3-22c0-25 9-47 27-65c18-18 40-27 66-27c26 0 49 10 67 29c21-4 40-11 59-22c-7 22-21 39-41 51c18-2 35-7 53-14z"/>

Dennoch: Ich denke, die Vorteile eines Icon-Fonts liegen auf der Hand. Für Plugin-Entwickler und Template-Designer wird manches leichter (nach Gewöhnung). Wenn mir nur jemand sagen könnte, ob man svg aus dem Font einfach entfernen kann? Ich denke schon, trau' mich aber nicht. Das wären dann als Font gezippt ca. 360k. Geht gerade noch. Und man kann einiges damit anstellen (z.B. spinning usw.)
Was sagt denn unser Ludwig zum Thema?

[lck]

Ich habe das mal im move-node Branch ausgearbeitet; wer will, kann es sich ja mal herunter laden und anschauen (der Ordner pagemanager_xh-move-node/ muss in pagemanager/ umbenannt werden).

Wirklich überzeugt bin ich von dieser Variante auch nicht ..

Ich auch nicht, aber danke für die Ausarbeitung! Da verliert man schnell den Überblick, wo den nun die Seite geblieben ist . Ohne Maus ist die Seitenverwaltung eh nicht bedienbar. Was sagt Frank dazu?

Dennoch: Ich denke, die Vorteile eines Icon-Fonts liegen auf der Hand. Für Plugin-Entwickler und Template-Designer wird manches leichter (nach Gewöhnung). Wenn mir nur jemand sagen könnte, ob man svg aus dem Font einfach entfernen kann? Ich denke schon, trau' mich aber nicht. Das wären dann als Font gezippt ca. 360k. Geht gerade noch. Und man kann einiges damit anstellen (z.B. spinning usw.)
Was sagt denn unser Ludwig zum Thema?

Tja, ich bin in diesem Thema noch Novice , ich kann also noch viel von euch lernen.
Grundsätzlich gefällt mir, vom optischen her, Font Awesome besser als die Material-Icons. Das mit den svg*s weglassen würde ich einfach mal testen.

Nachtrag: Um das Ganze noch verwirrender zu machen, hier noch ein Artikel zum Thema.

[cmb]

Wenn mir nur jemand sagen könnte, ob man svg aus dem Font einfach entfernen kann?

Ich habe mir mal font-awesome.css angeschaut, und da wird die SVG-Variante nur am Anfang in folgender Regel referenziert:

Code: Select all

@font-face {
  font-family: 'FontAwesome';
  src: url('../fonts/fontawesome-webfont.eot?v=4.7.0');
  src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.7.0') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff2?v=4.7.0') format('woff2'), url('../fonts/fontawesome-webfont.woff?v=4.7.0') format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.7.0') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.7.0#fontawesomeregular') format('svg');
  font-weight: normal;
  font-style: normal;
} 

Anscheinend kann eine SVG-Datei auch als font-face verwendet werden; und dazu sagt caniuse.com:

Method of using fonts defined as SVG shapes. Removed from SVG 2.0 and considered as a deprecated feature with support being removed from browsers.

Nun verstehe ich halt nicht, warum das im aktuellen Font-Awesome noch verfügbar ist – scheint nirgends unterstützt, wo nicht auch Woff unterstützt wird. Ich kann mir nur vorstellen, dass SVG-Fonts besser rendern (eben ohne Antialiasing); aber für die wenigen Browser, die SVG-Fonts unterstützen, könnte man wohl auch drauf verzichten.

Ich auch nicht, aber danke für die Ausarbeitung! Da verliert man schnell den Überblick, wo den nun die Seite geblieben ist .

Ich habe schon überlegt, die Seite in die verschoben wurde automatisch aufzuklappen – es wäre sogar möglich, die verschobene Seite automatisch auszuwählen. Das macht es vermutlich besser, ist aber immer noch fraglich. Die alte Variante gefällt mir aber auch nicht besser.

Ohne Maus ist die Seitenverwaltung eh nicht bedienbar.

Es geht auch ohne Maus, ist aber wirklich Friemelei. Per TAB erst mal das Tree-Widget fokusieren, dann mit den Pfeiltasten die gewünschte Seite ansteuern, per ENTER auswählen, und dann das Kontextmenü per Taste aufpoppen lassen, etc. Immerhin werden auch ein paar gängige Tastaturkürzel unterstützt (wie z.B. F2 für Umbenennen).

[frase]

Ich auch nicht, aber danke für die Ausarbeitung! Da verliert man schnell den Überblick, wo den nun die Seite geblieben ist . Ohne Maus ist die Seitenverwaltung eh nicht bedienbar. Was sagt Frank dazu?

Oh ja, das hätte ich beinahe vergessen.
Also, obwohl das Verschieben per Knopfdruck erstmal gar nicht so schlecht wirkt (danke für den Branch), hilft es nicht wirklich. Eine Ebene höher verschieben geht ja auch nicht.

[cmb]

Also, obwohl das Verschieben per Knopfdruck erstmal gar nicht so schlecht wirkt (danke für den Branch), hilft es nicht wirklich. Eine Ebene höher verschieben geht ja auch nicht.

Die Verschiebe-Operation war zunächst mal gedacht, damit es möglich ist, eine Seite in eine andere Seite, die noch keine Unterseiten hat, anzulegen (oder die Zwischenablage einzufügen). Das ging halt bei Version 3 bisher nur per Drag&Drop. Bei Version 1&2 gab es daher extra "Seite einfügen (auf gleicher Ebene)" und "Seite einfügen (als Unterseite)" (analog bei Paste), was ich aber nicht wirklich gut finde. (Ich musste immer zweimal nachdenken, welches ich nun wählen soll, und in der Praxis habe ich fast immer "Seite einfügen (auf gleicher Ebene)" gewählt.)

"Eine Ebene nach oben verschieben" wäre prinzipiell leicht machbar (und auch verschieben nach oben und unten auf der gleichen Ebene). Ich bin halt nicht sicher ob diese Funktionen in der Praxis wirklich relevant sind. Hängt vermutlich auch davon ab, ob und wie gut das Drag&Drop auf Touchscreens funktioniert.