Warum wir die Finger vom i lassen sollten

Man kann Themen wie Semantik ernst nehmen. Oder es lassen. Erfahrungsgemäß bringt semantische Sinnhaftigkeit aber nur Vorteile mit sich. Ich nehm das Risiko in Kauf, dass dieser Artikel kleinkariert wirken könnte. Doch solche Themen halte ich für die Essenz von Frontend-Developement. Und sie sorgen dafür, dass der Fachbereich oft missverstanden wird.

Bootstrap hat es jahrelang vorgemacht und allzu häufig ist es im Web so, dass der stete Tropfen den Stein höhlt. Nun wird eine Aussage aber nicht durch die Anzahl ihrer Wiederholungen wahr und eine technologische Entscheidung wird nicht klug, nur weil sie von vielen ungefragt geteilt wird. Das lässt sich sicher in der Form 1:1 auf viele Bereiche der Webentwi… ach was sag ich, auf viele Bereiche des Lebens erweitern, aber mir soll es im Speziellen um einen Usecase in Frontends der letzten Jahre gehen.

Die Piktogramme

Natürlich – und zu Recht – haben sich Piktogramme tief in unserem UI-Alltag verwurzelt. Die kleinen, hilfreichen Grafiken als Ergänzung zum Kontext oder gar alleinstehend funktionell erklärend sind nicht mehr wegzudenken und damit integraler Bestandteil jeder User Experience. Nun gibt es aber doch erstaunlich viele Möglichkeiten, mit Icons umzugehen. Generell kann ich mich zwischen Rastergrafiken, Vektorgrafiken und Icon-Fonts entscheiden. Und auch hier gibt es wieder viele Ansätze, wie man diese dann wiederum ins eigentliche DOM des Frontends integriert.

Eine beliebte Taktik sieht in etwa so aus:

<i class="icon icon-danger"></i>

Das i-Tag ist wirklich schon sehr schnell getippt. Da gibt es eigentlich kein HTML-Element, welches noch weniger Zeichen hätte (…) und man kann sich natürlich einbilden, dass das i für Icon steht. Nun sind wir alle gut darin uns selbst zu belügen und uns unsere eigenen Coding-Entscheidungen schön zu saufen. Doch damit haben wir eine Generation Entwickler gezüchtet, die das wirklich glaubt. Denn die Geschichte des i-Tag ist eine traurige Geschichte voller Missverständnisse, Ignoranz und Obsoleszenz.

Die Geschichte vom kleinen <i>

Ähnlich wie die Pizza (und das verzeihe man mir) ist das <i> italic. Der eigentliche Zweck des <i> war also, Schrift kursiv zu stellen und damit eine Texthervorhebung vorzunehmen, die zwar hervorhebt, aber nicht ganz so doll wie Fettung (der fette Vetter vom <i> ist übrigens der <b>). Der geneigte Leser wird sich jetzt denken: Dafür hat man uns doch das em und das strong geschenkt, und ja, das ist ganz richtig. Allzubald stellte man nämlich fest, dass <i> und <b> zwar funktionieren und die Browser diese auch als kursiv bzw. fett auszeichneten, aber eigentlich war das gar nicht so richtig. Denn damit gab man eine Designentscheidung im Markup vor: “Wie will ich eine Betonung im Text aussehen lassen?”

Nun geht den Herrn Markuper es aber herzlich wenig an, ob eine Emphase <em> oder eine starke Emphase (<strong>) letztendlich fett, rot blinkend oder mit Textschatten ausgezeichnet werden. Und damit waren <i> und <b> plötzlich arbeitslos, da sie zu übereifrig waren. Sie haben einen Job erfüllt, der gar nicht in ihren Aufgabenbereich fiel. Zwar zeichnen Browser heute standardmäßig <em> kursiv und <strong> fett aus, aber semantisch ist das okay, lässt sich überschreiben und führt zu keinen merkwürdigen Brüchen, wenn man es denn eben mit eigenem CSS überschreibt.

Und so geriet das kleine <i> für ein paar Jährchen in Vergessenheit.

Und warum kam es zurück?

Eine hervorragende Frage. Eigentlich nur aus den zwei Gründen, die ich oben nannte. Es ist schnell getippt. Und Icon fängt mit i an. Dass das <i>-Tag eigentlich einen Inhalt erwartet sei verziehen, dass sein semantischer – und überholter – Zweck allerdings ist, dass es diesen Inhalt italic darstellen soll, ist das Argument, welches die Benutzung meiner Meinung nach verbieten sollte.

Warum nicht… einfach trotzdem machen?

Gegenfrage: Warum nicht einfach nicht machen? Es gibt einfache Varianten das <i> zu Umgehen, die keinen Nachteil bieten und semantisch korrekt sind. Nimmt man ein einfach span, gibt ihm eine role="img" und ein aria-label und man hat ein vollwertiges Icon. Natürlich hat span ganz drei Buchstaben mehr als <i>. Dafür ist span halt einigermaßen semantisch bedeutungslos. Man kann sogar noch weiter gehen. Muss man keinen IE unter 10 bedienen, erschafft man sich halt ein <icon>, das ist semantisch korrekt, auch nicht ganz so kurz wie <i>, aber wenigstens kein Unfug und dennoch valides HTML.

<span role="img" aria-label="Gefahr im Verzug!" class="icon icon-danger"> </span>

Aber die W3schools sagen das <i> ist lieb als Icon!

Jein, sie sagen, dass es “widely used” ist. Mehr nicht.

Ist das nun alles wichtig?

Joa, ne. Für sich genommen nicht. Aber da liegt der Hund begraben. Fast jede unserer kleinen alltäglichen Codeentscheidungen führt im Regelfall erstmal zum Ziel. Aber nicht immer zu gutem Code. Warum also schlechte Angewohnheiten mitschleifen, wenn sie keine Notwendigkeit haben? Lasst das olle <i> einfach weg und in Ruhe sterben. Tut nicht weh. Macht euren Code ein kleines bisschen semantisch korrekter. Und das ist per se erstmal besser.

2 Comments Warum wir die Finger vom i lassen sollten

  1. ben_ 21. Januar 2020 at 7:55 am

    Es gibt eine weitere sinnvolle Verwendung des i-Tags, nämlich dann, wenn die Information, dass es sich um kursiven Text (und nicht nur irgendwie hervorgehobenen) handelt, relevant ist, wie z.B. in Zitaten.

    Und dann: Wo-hooow! Manchmal lohnt es sich echt, einen RSS-Feed lange, lange, lange Jahre nicht aus dem Reader zu werfen. Welcome back!

    Reply
    1. Chris 21. Januar 2020 at 3:58 pm

      Wow, das kam überraschend. 😀 Verrats aber noch niemanden, ich bin noch gar nicht offiziell live! 😀

      Reply

Leave A Comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.