Das könnte dich auch interessieren

Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung

SVGs FTW! Warum ihr keine Icon Fonts einsetzen solltet

    SVGs FTW! Warum ihr keine Icon Fonts einsetzen solltet

#FLICKR#

Um Icons darzustellen, etwa für ein Social-Media-Menü, wird häufig auf eine Icon-Font-Lösung zurückgegriffen. Aus verschiedenen Gründen kämen besser SVGs zum Einsatz – einige davon stellen wir euch hier vor.

Zuerst: Warum keinen Icon Font nutzen?

Das offensichtlichste Problem mit einem Icon Font hat man, wenn er nicht geladen wird. In diesem Fall wird eine Fallback-Schrift eingesetzt, die meist in einem kryptischen Zeichen endet. Und das muss nicht nur aufgrund eines Fehlers beim Laden geschehen: Wie Tyler Sticka in seinem Artikel „Seriously, Don’t Use Icon Fonts“ erklärt, finden viele Personen mit Dyslexie es hilfreich, die Schrift einer Website in etwas für sie einfacher lesbares zu wechseln – dabei gehen Icon Fonts kaputt.

Ein weiterer Nachteil von Icon Fonts ist es, dass beispielsweise mehrfarbige Icons nicht einfach umzusetzen sind. Darüber hinaus ist der Einsatz eines Icon Fonts nicht gerade semantisch. Wenn ihr beispielsweise den typischen Anwendungsfall eines Icon Fonts anschaut, ein Menü aus Social-Media-Links, dann könnte das mit Font Awesome so aussehen:

<ul>
<li><a href="https://twitter.com"><i class="fa fa-twitter"></i></a></li>
<li><a href="https://plus.google.com"><i class="fa fa-google-plus"></i></a></li>
<li><a href="https://facebook.com"><i class="fa fa-facebook"></i></a></li>
</ul>

Es wird also ein Inline-Element genutzt, wie i oder span, und dem dann eine oder mehrere Klassen zugewiesen, die der Icon Font nutzt, um per CSS als Pseudo-Element das entsprechende Symbol einzufügen. Es gibt auch die Möglichkeit, mit CSS nach Links zu den sozialen Netzwerken zu suchen, und das entsprechende Icon einzusetzen – so könnte das i-Element gespart werden, es bliebe ein leeres a-Element übrig.

Das Problem mit der Semantik ist hier aber nicht das größte: Sobald ihr dieses Markup mit einem Screen-Reader oder anderen unterstützenden Technologien erfassen wollt, bekommt ihr zwar vielleicht noch die Rückmeldung, dass es sich um eine Liste handelt, mehr aber auch nicht. Um einen Icon Font also guten Gewissens einzusetzen, muss mindestens noch eine unsichtbare Beschriftung für Nutzer unterstützender Technologien eingefügt werden:

<ul>
<li><a href="https://twitter.com"><i class="fa fa-twitter"></i><span class="screen-reader-text">Twitter</span></a></li>
<li><a href="https://plus.google.com"><i class="fa fa-google-plus"></i><span class="screen-reader-text">Google Plus</span></a></li>
<li><a href="https://facebook.com"><i class="fa fa-facebook"></i><span class="screen-reader-text">Facebook</span></a></li>
</ul>

Und mit SVGs ist alles besser?

SVGs bieten mehr Möglichkeiten, als Icon Fonts. So könnt ihr mehrere Farben für ein Icon verwenden, und das Ganze auch animieren. Zudem ist ein svg-Element alleine aus semantischen Gesichtspunkten deutlich besser geeignet, ein Bild darzustellen, als ein Pseudo-Element oder leeres span. Zudem bringen SVGs theoretisch bereits gute Mittel mit, um es auch barrierefrei zu machen. In einer perfekten Welt, in der alle Browser und Hilfsmittel wie Screen-Reader die aktuellen Accessibility-Standards umsetzen, könnte eine Lösung für das Menü so aussehen:

<ul>
<li><a href="https://twitter.com"><svg class="icon-twitter"><use xlink:href="/social-media.svg#icon-twitter"></use></svg></a></li>
<li><a href="https://plus.google.com"><svg class="icon-google-plus"><use xlink:href="/social-media.svg#icon-google-plus"></use></svg></a></li>
<li><a href="https://facebook.com"><svg class="icon-facebook"><use xlink:href="/social-media.svg#icon-facebook"></use></svg></a></li>
</ul>

Und die zugehörige social-media.svg so – die verschiedenen Optimierungsmöglichkeiten sind einem Artikel von sitepoint.com entnommen:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" style="display: none;">
<symbol id="icon-twitter" viewBox="0 0 512 512" role="img" aria-labelledby="title">
<title id="title">Twitter-Account</title>
<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"/>
</symbol>
<symbol id="icon-facebook" viewBox="0 0 512 512" role="img" aria-labelledby="title">
<title id="title">Facebook-Account</title>
<path d="m292 159l74 0l-9 81l-65 0l0 235l-97 0l0-235l-49 0l0-81l49 0l0-49c0-35 8-61 24-79c17-18 44-26 81-26l65 0l0 81l-40 0c-8 0-14 0-18 2c-5 1-8 3-10 6c-2 4-3 7-4 10c0 3-1 8-1 14z"/>
</symbol>
<symbol id="icon-google-plus" viewBox="0 0 512 512" role="img" aria-labelledby="title">
<title id="title">Google-Plus-Account</title>
<path d="m504 236l-45 0 0-45-45 0 0 45-45 0 0 45 45 0 0 45 45 0 0-45 45 0m-338-45l0 54 90 0c-4 22-27 67-90 67-54 0-97-45-97-98 0-54 43-99 97-99 32 0 52 13 63 25l43-41c-27-27-63-42-106-42-88 0-158 69-158 157 0 87 70 156 158 156 90 0 151-62 151-152 0-11 0-18-2-27z"/>
</symbol>
</svg>

Die symbol-Elemente enhalten jeweils ein Symbol und werden mit einem role- sowie einem aria-labelledby-Attribut angereichert, um Screen-Readern und anderen unterstützenden Technologien zu signalisieren, dass es sich erstens um ein Bild handelt und zweitens der Titel in dem Element mit der ID title zu finden ist. Problem: Das funktioniert nicht wirklich gut. Ich habe den Screen-Reader NVDA mit Firefox getestet, der den Titel immer doppelt ausgegeben hat. In anderen Kombinationen wäre das noch das geringste Problem.

Es bleibt also nichts anderes übrig, erst einmal wie bei dem Icon Font einen beschreibenden Text durch ein weiteres Element einzufügen, das per CSS versteckt wird. Damit sieht die Liste so aus:

<ul>
<li><a href="https://twitter.com"><svg class="icon-twitter"><use xlink:href="/social-media.svg#icon-twitter"></use></svg><span class="screen-reader-text">Twitter</span></a></li>
<li><a href="https://plus.google.com"><svg class="icon-google-plus"><use xlink:href="/social-media.svg#icon-google-plus"></use><span class="screen-reader-text">Google Plus</span></svg></a></li>
<li><a href="https://facebook.com"><svg class="icon-facebook"><use xlink:href="/social-media.svg#icon-facebook"></use></svg><span class="screen-reader-text">Facebook</span></a></li>
</ul>

Die SVG-Datei kann dann wie folgt erstellt werden:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" style="display: none;">
<symbol id="icon-twitter" viewBox="0 0 512 512">
<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"/>
</symbol>
<symbol id="icon-facebook" viewBox="0 0 512 512">
<path d="m292 159l74 0l-9 81l-65 0l0 235l-97 0l0-235l-49 0l0-81l49 0l0-49c0-35 8-61 24-79c17-18 44-26 81-26l65 0l0 81l-40 0c-8 0-14 0-18 2c-5 1-8 3-10 6c-2 4-3 7-4 10c0 3-1 8-1 14z"/>
</symbol>
<symbol id="icon-google-plus" viewBox="0 0 512 512">
<path d="m504 236l-45 0 0-45-45 0 0 45-45 0 0 45 45 0 0 45 45 0 0-45 45 0m-338-45l0 54 90 0c-4 22-27 67-90 67-54 0-97-45-97-98 0-54 43-99 97-99 32 0 52 13 63 25l43-41c-27-27-63-42-106-42-88 0-158 69-158 157 0 87 70 156 158 156 90 0 151-62 151-152 0-11 0-18-2-27z"/>
</symbol>
</svg>

Das ist zwar nicht die hübsche Standard-Lösung, tut der semantischen Auszeichnung der Symbole durch das svg-Element aber keinen Abbruch. Und so seid ihr schon mal auf dem richtigen Dampfer und könnt einfach die Attribute und Elemente der Standard-Lösung nachrüsten, wenn der Standard von genug Tool-Kombinationen unterstützt wird. Ihr müsst SVGs natürlich nicht so einbinden, wie vorgestllt, sondern könnt beispielsweise alles direkt inline in den HTML-Code einfügen. Auch das Einfügen per CSS, wenn es sich um ein rein dekoratives Element handelt, ist natürlich möglich.

Browser-Support

Der Browser-Support für die Einbindung externer SVGs mit dem use-Element ist im Bereich der Internet Explorer nicht allzu gut – das Polyfill svg4everybody rüstet diese Möglichkeit für die Internet Explorer 9 bis 11 nach. Wer noch ältere Versionen berücksichtigen muss, dem helfen PNG-Fallbacks, die mit einer Legacy-Version des Polyfills umgesetzt werden können. Sonst sieht der Browser-Support für SVGs gut aus, es sei denn, Android 2.3 und älter sollten noch unterstützt werden.

Fazit

In vielen Bereichen sind SVGs die bessere Wahl gegenüber Icon Fonts, wenn es nicht gerade um den Browser-Support in älteren Internet Explorern geht. Und einen weiteren Aspekt führt Ian Feather in seinem Blog-Beitrag „Ten reasons we switched from an icon font to SVG“ auf: „[…] font-face für Icons zu verwenden hat sich für mich immer wie ein Hack angefühlt. Ein brillianter Hack, keine Frage, aber es ist immer noch ein anderer Datei-Typ, der zu etwas größerem gemacht wird“. Alleine das reicht doch fast schon als Grund aus, zu einer Lösung zu wechseln, die für die Darstellung von Symbolen gedacht ist. Wenn ihr also das nächste Mal vor dem Einsatz eines Icon Fonts steht, dann zieht doch mal in Erwägung, stattdessen SVGs zu nutzen – es fühlt sich irgendwie gut an :)

Falls ihr noch mehr Argumente sucht: Es gibt viele Gegenüberstellungen von Icon Fonts und SVGs im Web, wie beispielsweise in einem Artikel von Sven Wolfermann oder tabellarisch als schnelle Übersicht bei CSS-Tricks.

Finde einen Job, den du liebst zum Thema Social Media, Redakteur

12 Reaktionen
Harry
Harry

Mit Ligature Icon Fonts lassen sich die angesprochenen Probleme lösen. Sobald die Schrift nicht geladen wird, rendert der Browser den Namen des Icons. Mehr Coding-Aufwand ist es auch nicht uns SEO-freundlich ist es noch dazu! Leider unterstützen nur die neueren Browser dieses Feature...

Antworten

thomas_
thomas_

Ein durchaus (teilweise) interessanter Artikel (aus Dev. Sicht). Jedoch weit weg von der Realität, Ein simpler Menüpunkt, oder was auch immer, wird zu einem komplexen Element.
Die Dynamik des Netzes lässt solche Lösungen (leider), auch wenn es der besser Weg wäre, nicht zu. Erst recht nicht in einem CMS Kontext.

Wie hat hier mal jemand treffend bemerkt:
"Kompliziert kann jeder. Um es einfach zu halten bedarf es eines Genies!"

Antworten

lvl3
lvl3

Vorab: mit Font Awesome zu arbeiten hat sowieso immer einen Haken. Die meisten Adblocker entfernen die Icons wenn sie in den Class Namen oder anderstwo irgendein Anzeichen von Facebook und Co erkennen. Da bedarf es ohnehin eine andere Lösung damit die Links nicht entfernt werden. ;)

Zum Thema:
Wäre es nicht einfacher mit Media Query (speech) zu arbeiten?
Darauf sollten Screenreader eigentlich reagieren und dann ist es auch ein leichtes CSS (:not) entsprechend für den jeweiligen Typ anzupassen. Kombiniert man dies nun noch mit einfachen jQuery und lässt Inhalte von Javascript generieren steht nichts mehr im Weg und der "hardcoded" Semantic Teil bleibt auch erhalten.

Antworten

Dom
Dom

Aber hauptsache ihr verwendet bei t3n selbst icon-fonts in eurer Share-Leiste unterm Artikel ;)

Antworten

Andreas
Andreas

Schön, dass Zugänglichkeit Einzug in die Argumentation hält! Danke!

Zum Code: Die Icons können auch ohne zusätzliches Markup rein über CSS-Pseudo-Elemente hinzugefügt werden und ein aria-label hilft bereits beim ersten Beispiel dem Screenreader.
Ebenfalls kann man auch gleich den korrekten Inhalt z.B. Twitter, etc. in den Link schreiben und dann per CSS verstecken.

Das bedeutet natürlich, dass FontAwesome anders behandelt werden muss.

Halbwissen: Mit der Schriftersetzung tritt meines Wissens bei Dyslexie auf. Auch bei Legasthenie? Wie sich das bei Pseudo-Elementen ohne zusätzliches Markup verhält muss ich selbst mal testen.

Antworten

Florian Brinkmann

„Halbwissen: Mit der Schriftersetzung tritt meines Wissens bei Dyslexie auf. Auch bei Legasthenie?“
Fehler meinerseits, hab ich korrigiert! Konnte mit dem Begriff nichts anfangen, und nachdem ich beim englischen Wikipedia-Artikel von Dyslexia auf „Deutsch“ geklickt habe, kam Legasthenie …

Antworten

Andreas
Andreas

Es stimmt irgendwie beides:
"Während im englischen Sprachraum der Begriff Dyslexie weit verbreitet ist und sich als Developmental Dyslexia insbesondere auch auf die Lese-Rechtschreibstörung (Legasthenie) bezieht, wird Dyslexie im Deutschen vorwiegend auf erworbene Formen von schriftsprachlichen Problemen bezogen, die z. B. bei Hirnschädigungen aufgrund von Unfällen oder Tumoren auftreten können."
https://de.wikipedia.org/wiki/Dyslexie

Wer's nicht kennt:
http://www.dyslexiefont.com/en/
http://opendyslexic.org/ (leider gerade down)

trgirl
trgirl

Das Argument der Semantik kann man definitv wiederlegen. Font Awesome geht auch über CSS zu nutzen. Ich bevorzuge daher diese Variant statt svg.

Wenns für die ganz alte Browser sein soll... dann png Grafiken.

Antworten

Florian Brinkmann

Genau das ist es ja: Du bindest bei Icon Fonts ein Bild, das beispielsweise im Fall eines Social-Media-Menüs eigentlich nicht rein dekorativ ist, sondern direkt in den Quelltext gehört, über ein CSS-Pseudo-Element ein. Mit SVGs kommt es direkt in den Quelltext.

Antworten

Andreas
Andreas

Eben nicht!
Das Icon muss rein dekorativ sein (braucht daher auch keine weitere Behandlung), aber es muss eben auch echter Inhalt in das Markup. Der "Fehler" ist hier nicht der Icon-Font, sondern das schlechte Markup und die vlt. Unwissenheit, dass - wie oben und unten geschrieben - es auch rein mit CSS geht.

Wenn das Markup passt, dann passt auch die Semantik.

Benjamin Damm
Benjamin Damm

Alle hier genannten Argumente kann ich voll nachvollziehen, es ist ein Hack, es fühlt sich nicht so an. Aber wie schon bereits erwähnt: ein verdammt guter! Ich habe nicht nur einmal versucht statt den Icon-Fonts SVG zu benutzen und muss sagen, dass die Unterstützung in den Browsers grauenhaft ist. Ich habe dann immer wieder neue Hacks finden müssen, damit Webkit und Firefox gleiche Ergebnisse liefern. Genau dieses Problem kann man mit Icon-Fonts ausräumen. Es gibt damit endlich einen Weg der Lage Herr zu werden. Ich habe leider viel zu oft kaputte SVGs in Webseiten gesehen. Und erinnere mich noch lebendig an die Probleme der Positionierung und des responsive Verhaltens von SVG. Daran hat sich bislang leider nicht viel geändert. Was ich peinlich finde. SVG ist wahrlich lang genug auf dem Markt, dass man eine volle Unterstützung erwarten kann. Aber es scheint ein Grundproblem von Webentwicklern zu sein, dass sie gerne in der Zukunft leben.

Antworten

Florian Brinkmann

Hi Benjamin,

„[…] dass die Unterstützung in den Browsers grauenhaft ist“

Hättest du dazu ein konkretes Beispiel? Genau wie hierzu:

„Und erinnere mich noch lebendig an die Probleme der Positionierung und des responsive Verhaltens von SVG.“

Ist echtes Interesse, da ich bisher noch keine solche Probleme hatte, aber beispielsweise auch noch nicht mit Animationen von SVGs gearbeitet habe.

Viele Grüße
Florian

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen