Font Awesome 6

  • App
    WoltLab Suite Core

    Hallo zusammen,


    da mein letzter Wunsch zur Implementierung von Font Awesome 5 leider abgeblockt wurde, versuche ich es gleich nochmal - mit Font Awesome 6.


    Der Release von FA6 ist noch einige Zeit hin und bis zum Release der WoltLab Suite 6 wird sicher auch noch einiges an Zeit vergehen, trotzdem, oder gerade deswegen erstelle ich den Vorschlag jetzt schon, sodass WoltLab genug Zeit hat darüber nachzudenken und die Implementierung schon in der Konzeptionsphase mitberücksichtigen kann.


    Die Gründe für den Wunsch haben sich nicht geändert und können im FA5-Thread nachgelesen werden.


    Ich freue mich auf eure Unterstützung.


    Beste Grüße,

    Daniel

  • Ich glaube, mit FA6 ist das lizenztechnisch schwieriger geworden. Irgendwas war da, komme nur gerade nicht drauf.

  • Ich glaube, mit FA6 ist das lizenztechnisch schwieriger geworden. Irgendwas war da, komme nur gerade nicht drauf.

    "Schwieriger" würde ich es nicht nennen. Eher "anders", da es sich nun um ein Mietmodell handelt. Darüber hinaus gilt das auch nur für die Pro. Die Standard-Lizenz ist weiterhin frei für alle beliebig nutzbar und bietet immer noch alle nötigen Icons.


    Bezüglich Pro könnte WoltLab die Möglichkeit prüfen, ob diese bereits für die jährliche Gebühr in die Suite implementiert werden kann. Falls nicht, wäre dies wieder eine Option für den Forenbetreiber, welcher die Standard-Icons durch die Pro-Icons ergänzen möchte.

  • Zusätzlich würde ich es begrüßen, wenn dies kommen sollte, dass man mit einem Select-Field zwischen den FA-Stilen (pro WSC-Stil) wechseln kann. Derzeit gibt es ja Solid, Regular, Light, Duotone (für Pro-Nutzer)

    • Official Post

    Für Entwickler:

    Wir haben die Integration von Font Awesome 6 bereits vor einigen Wochen abgeschlossen, es sind gegenwärtig keine Änderungen mehr geplant. Die bisherige Icon-Implementierung ist sehr alt (ursprünglich auf Basis von Font Awesome 3 entwickelt) und weist eine Menge an Designschwächen auf. Die neuen Icons sind nicht abwärtskompatibel, es wird daher notwendig sein, alle verwendeten Icons zu modernisieren. Icons werden ausschließlich über dedizierte HTML-Elemente unterstützt, die Verwendung von Icons über CSS ist nicht möglich.


    Im Zuge der Implementierung haben wir begleitend bereits die Dokumentation für die neuen Icons gepflegt und versucht, unsere Beweggründe hinter verschiedenen Entscheidungen zu erläutern, um so ein besseres Verständnis zu vermitteln. Wir freuen uns über Feedback und bitten im Falle von Fehlern in der Dokumentation um eine Issue im Repository.

  • die Verwendung von Icons über CSS ist nicht möglich.

    Ist das sinnvoll? An vielen Stellen, wenn es um Anpassungen geht, werden Icons mal eben per CSS irgendwo angezeigt. Gerade für Benutzer, die das System nicht tiefgreifend kennen. Wie soll hier die Alternative aussehen?

    • Official Post

    Ist das sinnvoll? An vielen Stellen, wenn es um Anpassungen geht, werden Icons mal eben per CSS irgendwo angezeigt. Gerade für Benutzer, die das System nicht tiefgreifend kennen. Wie soll hier die Alternative aussehen?

    Genauso gut kann man auch Elemente ad hoc per JavaScript einfügen, damit lassen sich Icons auch barrierefrei realisieren. Das Einfügen per CSS-Pseudo-Element ist sehr bequem, aber war ehrlicherweise schon immer die schlechteste aller Formen.


    Mit dem <fa-icon>-Element haben wir zudem die Möglichkeit, auf Änderungen seitens Font Awesome zu reagieren und so beispielsweise ein hohes Maß an Vorwärtskompatibilität zu gewährleisten. Die Icons bleiben unverändert per CSS anpassbar und auch Dinge wie eine Schriftfarbe wirken sich wie erwartet aus – Icons haben keine explizite Farbe mehr, sondern passen sich dynamisch an.

  • verstehe ich das richtig, das so ein Codeschnipsel

    Code
    .messageGroupStarter .username span::after {
        font-family: FontAwesome;
        content: "\f040";
        margin-left: 5px;
    }

    dann nicht mehr möglich ist?

    Und was wäre die alternative?

    Linux: Born to Frag 8) :D

  • Wird es eigentlich eine Möglichkeit geben, Gebrauch von seiner Pro-Mitgliedschaft bei FA zu machen? Das wäre das Sahnehäubchen.


    Und der Frage von netrix schließe ich mich an. Nicht selten kommt es vor, dass man evtl. auch Mal ein bestehendes Icon Überschreiben will. Das möchte ich ungerne per JS machen wollen.

    • Official Post

    Wird es eigentlich eine Möglichkeit geben, Gebrauch von seiner Pro-Mitgliedschaft bei FA zu machen? Das wäre das Sahnehäubchen.

    Ja, das habe ich bei der Entwicklung explizit berücksichtigt, auch wenn es dies teilweise recht umständlich mache.


    CSS
    /* Muss auf `html` oder `:root` gesetzt sein. */
    html {
      --fa-font-family: "Font Awesome 6 Pro";
      --fa-font-weight: 300; /* oder 100 für thin */
    }

    Zusätzlich muss man sich noch darum kümmern, dass die Font entsprechend eingebunden wird, aber das war es auch schon.


    Und der Frage von netrix schließe ich mich an. Nicht selten kommt es vor, dass man evtl. auch Mal ein bestehendes Icon Überschreiben will. Das möchte ich ungerne per JS machen wollen.

    Bei <fa-icon> handelt es sich um eine Web Component mit einer eigenen API, über setIcon(name: string, forceSolid = false) lässt sich das Icon zur Laufzeit austauschen. Die Größe des Icons wird über das size-Attribut gesteuert und erlaubt ebenfalls Änderungen zur Laufzeit.


    Ansonsten git, dass die Verwendung von JS zum Ergänzen bzw. Austauschen von Icons zur Laufzeit der vorgesehene und wohl-definierte Weg ist.

  • Also ist es am Ende nach wie vor eine Font, die eingebunden wird? Weil wenn ja, müsste man doch dennoch auf diese Font per CSS zugreifen können? :/

  • Zielgruppe aus den Augen verloren? Icons sollte jeder anpassen können. ?(

    Zur Not gibts für jeden den Javascript Einsteigerkurs bei Udemy zur Version 6.0 dazu ;)


    Also ist es am Ende nach wie vor eine Font, die eingebunden wird? Weil wenn ja, müsste man doch dennoch auf diese Font per CSS zugreifen können? :/

    Der Meinung bin ich auch oder sind besondere Schritte nötig, den Unicode der FontAwesome Icons als content in Pseudo Elementen nutzen zu können?

  • Hallo,


    ist denn komplett FontAwesome 6 implementiert? Also zumindest die Free Icons?


    Wenn ich {icon name='discord'} probiere, steht dann in der Browser-Konsole: TypeError: The icon 'discord' is unknown or unsupported.

    Bei FontAwesome finde ich das Icon allerdings: https://fontawesome.com/icons/discord


    Edit: das type='brand' hat gefehlt. Habe mal wieder die Doku nichts bis zum Ende gelesen.

    • Official Post

    Ja, aber Brand-Icons sind ausschließlich per {icon type='brand' name='discord'} zugänglich. Dies liegt darin begründet, dass wir diese als Inline-SVG einbetten und es so vermeiden können, für eine Handvoll Brand-Icons eine zusätzliche 105 kB-Font (nach Kompression, woff2!) laden zu müssen.

  • Danke, habe ich kurz vor deiner Antwort in der Doku gesehen und meinen Beitrag bearbeitet ^^


    Aber machen 105 kB heutzutage überhaupt noch was aus?

    • Official Post

    Aber machen 105 kB heutzutage überhaupt noch was aus?

    Absolut. Die 105 kB sind eine woff2-Datei, die bereits nahezu maximal komprimiert ist.


    Zum Vergleich: Dieses Thema hier aufzurufen erzeugt mit einem leeren Cache und nach Gzip-Kompression 693 kB Datentransfer. Die 105 kB liegen nach Gzip-Kompression irgendwo bei 100 kB, d.h. du würdest in dem Fall ca. 14% mehr Traffic erzeugen. Und nicht zu vergessen, es ist eine weitere Ressource die vom Browser verarbeitet werden muss.


    Auf einem Desktop mit Glasfaser-Anbindung sicherlich irgendwo nicht weiter problematisch. Mit einem günstigen Smartphone via 3G und gefühlte 293kB-Inklusivvolumen freust du dich hingegen über jede Einsparung, ohne dabei Einbußen hinnehmen zu müssen.

  • Mit einem günstigen Smartphone via 3G und 10kB-Inklusivvolumen freust du dich hingegen über jede Einsparung, ohne dabei Einbußen hinnehmen zu müssen.

    Äh, ist das ein Schreibfehler =O ? 10 kB Inklusivvolumen? Oder eher 10 GB? Ob 10 GB günstig wo zu bekommen sind (Telefonica denke ich?) weiß ich aber nicht.

    Projekte:

    XIVDATA - Eorzea Database


    A red dragon falls from the heavens... Ah, that memory has been lost. A shame. It was a favorite of mine...


  • Ich finde es sehr bezeichnend, dass explizit Feedback zur Dokumentation erwünscht ist, aber offensichtlich nicht zur Implementierung selbst. Das spricht bereits Bände. Denn gerade die Implementierung ist für mich wesentlich wichtiger als irgendeine Dokumentation darüber. Und da finde ich es schade, wie selbige vonstatten ging.


    Da immer noch eine Webfont eingebunden wird, halte ich für eine Fehlentscheidung. Das passt aber in das Bild, wie ihr generell Dinge implementiert: möglichst alles beim ersten Seitenaufruf laden, was möglicherweise vielleicht irgendwie irgendwann irgendwo mal verwendet wird. Warum das nicht sinnvoll ist, hatte ich bereits vor geraumer Zeit hier angemerkt. Gerade für eine solche Neuimplementierung wäre das eine Chance gewesen, sich an aktuellen Best Practices zu orientieren, so auch bei den Icons.


    Wenn ich die Schriften (fa-regular-400.woff2 und fa-solid-99.woff2) der Free-Icons per Gzip lade, habe ich immer noch eine Dateimenge von 176 KiB. Als Vergleich dazu, wenn ich alle SVGs per Gzip lade, komme ich auf 787 KiB. Ja, das ist in der Gesamtheit mehr, aber wie viele unterschiedliche Icons werden pro Seite angezeigt? Vielleicht 50, wenn es wirklich viele sind. Dann wären wir bei ~ 450 Byte Durchschnittsgröße pro Icon immer noch bei 22,5 KiB und damit weit unter der Größe der Schriften. Warum wird das nicht so umgesetzt? Das ist für mich unverständlich.


    Vor allem ist es für mich unverständlich, dass ihr genau solch ein System für die Brand Icons verwendet, aber nicht generell. Warum? Ihr baut ein System, das dynamisch Icons ausgeben kann, aber benutzt das nur für einen Teil der Icons, was aber insgesamt zu einem geringeren Datenverbrauch beim Seitenaufruf führen würde.


    Und wie sieht es aus, wenn man Pro-Icons verwenden will? Muss man sich selbst dann darum kümmern, dass die Free-Icons nicht mehr geladen werden? Wenn ja, wie macht man das? Geht das überhaupt?


    Ich freue mich auch schon auf die ersten Berichte, wenn das JavaScript nicht schnell genug geladen wird und Icons dementsprechend erst nach kurzer Zeit angezeigt werden.


    Und generell: warum werden hier Fragen nur selektiv beantwortet? Weil nur Feedback zur Dokumentation erwünscht ist? So kommt es mir zumindest vor.


    Warum ich mich an so etwas so aufhalte: Gerade im Hinblick darauf, das Stilsystem auch grundlegend zu überarbeiten, verringern solche Aktionen, die für mich nicht nachvollziehbar und zumindest performancetechnisch nicht an heutige Best Practices angelehnt sind, meine Hoffnung auf ein Stilsystem, das auf Augenhöhe mit anderen Lösungen ist und auch performancetechnisch herausragend, dramatisch.


    Aber auch Feedback zur Dokumentation soll es geben:

    Quote

    It is strongly discouraged to apply CSS classes to icons themselves.

    Warum? Es gibt dort keinerlei Begründung und ich sehe auch keinen Grund, warum ich bestimmten Elementen keine Klassen geben soll, wenn ich das für richtig halte. Die Alternative, noch ein Element drumrum zu bauen, halte ich für umständlich und nicht sinnvoll. Warum hier die Benutzer explizit einengen, nur weil man es selbst so handhaben will? Das sind Design-Entscheidungen, die ich nicht mitgehe.


    Warum dürfen auch nur bestimmte Größen angegeben werden? Warum darf man das nicht selbst definieren, wie groß man ein Icon haben möchte? Und was, wenn man es an irgendeiner Stelle wirklich so braucht? Dann muss man da umständlich drumrum arbeiten.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!