marctrix: Icon-System: SVG-Handling

Beitrag lesen

Hej alle,

derzeit überlege ich mir folgendes zu Icons:

Einzelne Icons in das HTML schreiben funktioniert in allen relevanten Browsern (und mehr einschließlich IE ab 9 oder so).

Macht bei Seiten, die wenige Icons einsetzen absolut Sinn, vor allem wenn — wie oft der Fall — auf der Startseite ein Haufen Icons ist, der im ganzen Rest der Site nicht wieder verwendet wird.

Zumindest diese sollten NICHT in ein Sprite (die sind nach dem ersten Aufruf der Startseite mit dem Rest des HTMLs ohnehin im Cache).

Außerdem lassen sich nur inline-SVGs vollständig über CSS kontrollieren. Beispiele und Anregungen dafür, was damit möglich ist (und mit wenig Aufwand) gibt das Video Why Inline SVG is Best SVG von Frontend Center (auch wenn der Typ das Wort accessibility in Zusammenhang mit dem gezeigten Formular besser nicht verwenden sollte — mir geht es hier nur um die technischen Möglichkeiten im Zusammenspiel von CSS und SVG).

Aber in dem Beispiel geht es nicht (nur) um Icons und für den Rest der wiederkehrenden Icons würde ich doch auch ein Sprite einsetzen wollen und dieses dann per use einbinden.

Dadurch verliere ich zwar die Möglichkeit, einzelne Pfade per CSS zu gestalten, aber in der Praxis benötige ich das praktisch nie. Ein fill: currentColor tut es in 98% aller Fälle, ein Überschreiben mit fill: mySpecialColor in weiteren 1,999% aller Fälle. Für den Rest kann man sich dann ein einzelnes Icon ins HTML holen.

Wie immer bin ich also nicht für eine entweder-oder-Lösung zu begeistern, sondern werde einen sowohl-als-auch-Weg gehen, nach folgendem Grundsatz:

Einmalig verwendete Icons und Icons mit besonderem Gestaltungsbedarf (die dadurch wieder individuell werden und selten oder ebenfalls einmalig sind) und SVGs, die gar keine Icons sind (wie die Linie im Video-Beispiel) kommen direkt ins HTML. Abhängig von ihrer inhaltlichen Relvanz mit einem role="image" oder role="presentation".

Alle anderen Icons kommen in ein Sprite.

Das Problem: die werden im IE nicht angezeigt, wenn das Sprite eine externe Datei ist (und nur das macht ja Sinn). Der IE kann das aber, wenn das Sprite direkt ins HTML geladen wird.

Zwar gibt es polyfills (zumindest eines habe ich mir mal genauer angesehen), das scheint mir aber unnötig kompliziert zu sein. Es geht doch nur darum herauszufinden, ob ein Browser mit externen Sprites klar kommt und nur in diese dann das Sprite zu laden und von allen Referenzierungen den Pfad zur Sprite-Datei entfernen.

Für mich persönlich ist für diesen Anwendungsfall auch nur noch der IE11 interessant. Dürfte den meisten so gehen.

Also für den IE11 aus etwas wie src="../path/to/my_sprite.svg#my-icon" folgendes zu machen src="#my-icon".

Für jemanden, der kein JS kann leider nicht möglich, aber es klingt, als wären das nur wenige Zeilen. Kann das jemand schreiben? @Orlok vielleicht oder @Rolf B ?

Wenn es mehr Interessierte an dieser Lösung gibt, kann diese Vorgehensweise ins Wiki oder in einen Blogbeitrag (dieser Post hier ist ja schon ein halber Blogbeitrag).

Wie seht ihr das?

Marc

PS: Icons und Accessibility: nicht jedem ist die Bedeutung eines Symboles klar. Daher sollte es zu jedem Icon mit inhaltlicher Relevanz eine textliche Entsprechung geben. So soll ein Drucken-Symbol niemals ohne das Wort „Drucken“ verwendet werden. Und zwar nicht nur für Blinde, sondern auch für Sehende zugänglich.

Insofern kann ich persönlich damit leben, dass der IE11 keine Icons anzeigt, weil die Nutzer wenige sind und weiter weniger werden und weil die Texte ein Fallback und die #icons in dem Sinne nur progressive enhancement sind. Allerdings bekomme ich solche Dinge nicht immer bei Kunden durch und wenn das ein Blog-Beitrag wird, wird der u.U. auch von Leuten gelesen, die nicht so penibel bei der Umsetzung von Barrierefreiheit sind, wie es bin.