Ich schreibe diesen Artikel, weil unser neuer Klient unzufrieden mit den Entwürfen mehrerer Mitbewerber war. Ich dachte zunächst, dass er das Design der anderen nicht mochte. Nach einem Gespräch stellte sich aber heraus, dass der Klient glücklicherweise schon einmal in der HTML/CSS-Materie Fuß gefasst hat und sich bereits im Vorfeld über gängige Webdesignpraktiken informiert hat. Ihm gefiel an den Entwürfen der anderen nicht, dass sie nicht nach bestem Wissen erstellt wurden.

Ich bin immer wieder erschrocken, was (auch etablierte) Firmen, die sich auf’s Webdesign spezialisiert haben, an Arbeit abliefern. Niemand ist perfekt – aber wer eine Dienstleistung anbietet, sollte schon alles wichtige über seine Tätigkeit wissen. Wir bringen unser Auto ja auch nicht in die Werkstatt, um nachher vom Meister eine qualitiv schlechte Arbeit zu erhalten.

Ich stelle nachfolgend nicht nur qualitativ schlechte Arbeit anderer Webdesignagenturen vor, sondern führe auf andere Dinge auf, die ich beim überfliegen von fremden Quelltext gesehen habe.

JavaScript / CSS wird inline implementiert

Ich habe auf mehreren Webseiten etwa folgendes gesehen:

   <a onclick="bildwechsel()" href="seite.html">...</a>

Oder wie wärs hiermit?

<div style="border: 2px dashed #ccc; padding: 5px">...</div>

Hierbei möchte ich klarstellen: CSS Styles werden nicht direkt formatiert und Javascript gehört in den Header oder an das Ende vom body. Funktionieren tut es natürlich auch mit inline-Deklarationen. Irgendwie. Aber ist es wartbar? Ist es saubere Arbeit? Oder anders gesagt: Wärt ihr zufrieden, wenn euer kaputter Keilriemen in der Werkstatt mit einem Damenstrumpf repariert wird?

Schöner wäre diese Lösung (Javascript-Beispiel):

    <a id="wechsler" href="seite.html">...</a>

    <script type="text/javascript">
          document.getElementbyId('wechsler').onclick = "bildwechsel()";
     </script>

Oder mit jQuery:

   <script type="text/javascript">
     $('#wechsler').click(function() {
          bildwechsel();
          return false;
     });
    </script>

Hier noch eine Verbesserung für die inline-CSS-Deklarationen (dürfte eigentlich klar sein):

<div class="niceborder">...</div>

In Verbindung eines externen Stylesheets:

.niceborder {
    border: 2px dashed #ccc;
    padding: 5px
}

Warum?

Man sollte das Markup klar vom Rest trennen. Das bedeutet: Stylesheets und Scriptdateien sollten in externe Dateien ausgelagert werden. Das erhöht die Wartbarkeit und sorgt dafür, dass in einem HTML-Dokument wirklich nur HTML steht. Ich nehme die CSS-Deklaration als Beispiel: Was ist, wenn wir die Definitionen auch in einer anderen HTML-Datei benutzen möchten? Copy & Paste ist dann sicherlich nicht die richtige Wahl. Eine einfache Klassenzuweisung löst unser Problem. Genauso verhält es sich auch mit JavaScript. Events wie onclick sollten nie innerhalb von HTML-Struturelementen stehen – entweder, man schreibt seine Scriptfunktionen in den Headbereich bzw. an das Ende vom HTML-body, oder man verwendet eine externe .js-Datei, die bei Bedarf eingebunden wird.

CSS-Sprites sind ein Fremdwort

Ich weiss nicht, wann der erste auf die Idee kam, Sprites auch für CSS-Deklarationen zu nutzen. Es ist aber nicht erst gestern passiert. CSS-Sprites beinhalten mehrere Grafiken, die dann von der Webseite eingebunden werden: Selbst wenn der Klient bzw. der Webdesigner keinen Wert auf die Ladegeschwindigkeit (HTTP-Requests) legt: Für einen Besucher ist es extrem störend, wenn z.B. bei Mousehover ein Bild erst nachgeladen werden muss – die Folge: Erst nach einigen Sekunden wird das anzuzeigende Bild geladen. Ich habe hier einen deutschsprachigen Artikel darüber gefunden, der bereits über zwei Jahre alt ist. CSS Sprites sollten also jedem Webdesigner bekannt sein – es sei denn, die Blogs und Artikel anderer Webdesigner werden ignoriert.

Warum?

Die Vorteile liegen auf der Hand: Weniger HTTP-Requests und keine Latenz beim Bildwechsel. Auch für die, die nicht rechnen möchten gibt es keine Entschuldigung: Es gibt genügend CSS-Sprite-Generatoren im Web, so dass man sich kaum die Finger krumm machen muss. Ein Kunde darf ruhigen Gewissens erwarten, dass schnelle Bildwechsel mit Sprites realisiert werden – alles andere ist nicht weit genug gedacht.

Moderne Techniken werden ignoriert

Keine Frage: CSS3 und HTML5 sind für Webdesigner ein Segen. Das größte Manko war bisher die fehlende Unterstützung des wohl meist genutzten Browsers: Der Internet Explorer. Doch das darf kein Hindernis sein – denn dank Progressive Enhancement kann man die Techniken jetzt schon nutzen. Für HTML5 und viele CSS3-Features gibt es IE-Workarounds. Auch hier bietet das Internet eine Fülle von CSS3 Generatoren und HTML5-Skeletten und -Tutorials: Wer suchet, der findet.

Warum?

Skeptiker würden jetzt sagen: “Ich code nur dass, was derzeit W3C-Standard ist”. Doch das ist keine Begründung – oder verzichten diese Menschen dann auch auf CSS 2.1? Richtig gehört: CSS 2.1 ist ein sog. “Candidate Recommendation” – also lediglich ein Kandidat für eine Empfehlung des W3Cs. CSS3 ist in vollem Gange – und mit dem Internet Explorer 9 wird auch der letzte bekannte Browser HTML5 und CSS3 beherrschen. Wer sich also noch nicht mit diesen Themen auseinandergesetzt hat, scheint den Anschluss zu verlieren. Bei der Nutzung dieser Techniken sollte man aber auch eines nicht außer Acht lassen:

Verzicht auf Progressive Enhancement

Progressive Enhancement ist das Zauberwort, wenn es um Barrierefreiheit geht. Durch die neuen genialen Möglichkeiten von CSS3 und HTML5 verliert man schon mal schnell den Blick für die Abwärtskompatiblität. Doch das ist ein großer Fehler.

Warum?

Nicht jeder Browser interpretiert CSS3 Deklarationen und HTML5-Code. Der Submit-Button im Warenkorb funktioniert nicht, weil JavaScript vom Benutzer deaktiviert wurde? Die Navigation auf der Seite ist unmöglich, weil CSS3-Pseudoklassen verwendet wurden? Die Webseite ist mit einem Textbrowser unbrauchbar, weil sie komplett in Flash erstellt wurde? Das Layout ist im Eimer, weil der Browser kein HTML5 kann?

An all diese Sachen muss ein Profi denken – und es ist nicht schwierig, für die Abwärtskompatibilität Lösungen zu finden.

HTML-Elemente werden mißbraucht

Der Klassiker für die falsche Verwendung von HTML-Elementen: Ein Seitenlayout wird mit Tabellen realisiert. Diese Vorgehensweise war vor zehn Jahren noch mißbilligt, als nur wenige Browser float- und width-Angaben richtig beherrschten. Auch immer wieder dabei: Unmengen von verschachtelten div’s, um eine simple Navigation zu realisieren, em-Elemente um die Schrift kursiv darzustellen und das gute alte hr-Element, um eine Linie zu erzeugen. Es wird in Foren immer und immer wieder gepriesen: Trennt Markup und Design! Semantik? Wohl nie gehört.

Warum?

Beispiel Layout mit Tabellen: Heutzutage ist es nicht nur schlechter Stil – Nein, es sorgt auch für “bloated code” und verringert die Wartbarkeit der Seite. Oder um auf unser KFZ-Werkstatt-Beispiel zurückzukommen: Es ist so, als würde der Auspuff nicht geschweisst, sondern getaped und verdrahtet werden. Hält sicherlich auch irgendwie – aber saubere Arbeit ist das mit Sicherheit nicht. Würdet ihr dafür Geld bezahlen?

Hier noch ein Beispiel “Gut und Schlecht”:

<div class="wrapper">
    <div id="topnavi">
        <ul class="navi">
            <li class="navpoint">
                <a href="seite.html">Seite 1</a>
            </li>

            <li class="navpoint">
                <a href="seite2.html">Seite 2</a>
            </li>

            <li class="navpoint">
                <a href="seite3.html">Seite 3</a>
            </li>
        </ul>
    </div>
</div>

Und im Vergleich dazu:

<ul id="topnavi" class="navi wrapper">
    <li><a href="seite.html">Seite 1</a></li>
    <li><a href="seite2.html">Seite 2</a></li>
    <li><a href="seite3.html">Seite 3</a></li>
</ul>

Was ist nun besser lesbar und semantisch korrekter?

Verzicht auf W3C-Standards

Viele hören sicherlich das erste mal vom W3C, wenn ein Design in einem Browser nicht so aussieht wie erwartet. Und jetzt sollte es doch klingeln: W3C-Standards sind keine Last, sondern eine Hilfe für Webdesigner, damit die Seite an jeder Stelle gleich aussieht. Natürlich ist das auch heutzutage nicht ganz die Realität: Die Browser tanzen mal mehr, mal weniger aus der Reihe (Hallo, IE). Aber sollte man die Standards deshalb mit Füßen treten? Es hat schon seine Gründe, warum das span-Element in einem paragraph auftreten muss und nicht umgekehrt. Und warum ein img-Element mit dem alt-Attribut bestückt sein muss. Immer wieder sehe ich, dass solche Regeln einfach ignoriert werden – es wird darauf vertraut, dass der Browser “mitdenkt” und die Seite so interpretiert, wie der Designer sich das vorgestellt hat. Geht oft gut – aber sicherlich nicht immer. Wie bitte, das target-Attribut für Anker darf ich nicht im Modus XHTML 1.0 Strict verwenden? Ich muss auf iframes verzichten? Großes Entsetzen bei Webdesignern, die große Diskussionen verpasst oder ignoriert haben.

Warum?

Standards sind gut – nicht nur im Internet. Und wieder klingelt der KFZ-Meister aus unserem Beispiel: Ist es nicht gut zu wissen, dass ein KFZ-Meister in Deutschland nach gültigen Standards geprüft und zertifiziert wurde? Das Wort “Meister” wäre ansonsten sicherlich nichts wert.

Der PHP-Code ist notdürftig zusammengeflickt Das schöne am PHP-Code ist, dass nur ein kleiner, gewählter Personenkreis diesen sehen kann. Der Benutzer am anderen Ende wird höchstens den HTML-Quelltext zu sehen bekommen. Offenbar Grund genug, sich um den PHP-Code nicht groß zu kümmern – getreu dem Motto “Hauptsache, es funktioniert irgendwie”. PHP ist eine wunderbare Sache, aber wenn man es in einer Dienstleistung verarbeitet, sollte man sich auch bestens damit auskennen. Und zwar nicht nur mit PHP 4.x (wie es noch in vielen Tutorials benutzt wird), sondern auch PHP 5.x, bei dem man sich von alten mysql_*-Funktionen verabschiedet hat und die Zukunft in den Händen von mysqli und PDO liegt.

Warum?

Es ist natürlich nicht egal, was “unter der Haube” einer Anwendung steckt. Ob Gefahren wie XSS, SQL-Injection & Co oder Hürden wie alte mysql_*-Funktionen – all dies kann Entscheidend für die Zukunft des Projekts sein. Es sollte im Interesse des Entwicklers sein, seinen PHP-Code stets auf dem neuesten Stand zu halten. Ich versuche mir manchmal auszumalen, wieviele Webseiten nicht mehr funktionieren wenn PHP 4 von allen Servern der Welt verschwindet und durch PHP 5 ersetzt wird. Meiner Meinung nach ist es nicht nur veralteter Code, den Profis vermeiden sollten, sondern auch lustige Code-Konstrukte (if/else für eine 50-Seiten-Includestruktur – alles schon gesehen, leider) , Spaghetti-Code und überflüssige Einsätze von Frameworks.

Verzicht auf ausgiebige Tests

Der Kunde ist verärgert, weil euer perfektes Design nicht im IE6 funktioniert? Kunden einer großen Webapplikation melden ständig Fehler? All das wäre mit ausgiebigen Tests nicht passiert.

Das Problem daran ist, dass man erst einmal (fälschlicherweise) davon ausgeht, dass keine Fehler gemacht wurden. Doch erstens arbeit der Mensch nie perfekt, und zweitens muss man die Eigenheiten der Kundenkonfigurationen kennen. Desweiteren steht ein Webdesigner oft unter einem solchen Termindruck, dass er keine Zeit hat, sein Projekt zu testen.

Fehler bei Programmanwendungen können durch sogenannte Unit-Tests unter Kontrolle gebracht werden – und das, bevor der Endanwender es bemerkt.

Das Entlarven von Darstellungsfehlern in verschiedenen Browsern stellt einige Webdesigner vor ein Problem: Es ist nicht ohne weiteres möglich, mehrere IE-Versionen auf einem Betriebssystem parallel laufen zu lassen. Und so scheint es, dass viele Webdesigner einfach den Internet Explorer 8 zum Testen der IE-Umgebung nutzen – er macht schließlich auch am wenigsten Probleme. Dank einer großen Auswahl an entsprechenden Tools ist es für Entwickler aber kein Problem, mehrere IE-Versionen auf einem Betriebssystem zu testen. Man kann nie wissen, wie ein antiqutierter IE6 eine Webseite anzeigt – selbst einfachste margin-Anweisungen scheinen ein Problem darzustellen. Hier hilft nur eins: Testen, testen, testen.

Auch sollte man die Webseite auf unabhängigen Plattformen testen. Der Entwurf eines Mitbewerbers sah prima auf einem 26″ Mac-Bildschirm aus. Der Otto-Normal-User mit einer Auflösung von 1024 x 768 schaut aber in die Röhre. Da wurde beim Design nicht weit genug gedacht.

Warum?

Man darf nicht davon ausgehen, dass Benutzer immer die Eingaben tätigen, die der Entwickler erwartet hat. Oder auf Englisch: Never trust a user input. Auch Darstellungstechnisch darf man nicht erwarten, dass der Benutzer immer mit der allerneuesten Version seines Lieblingsbrowsers surft. Man muss sich dann einfach mal die Mühe machen und mit Hilfe von Conditional Comments einige Umwege für alte Browser implementieren.

Fazit

Oh ja, der Webdesigner kann sichtlich viele Dinge falsch machen. Der Webdesigner darf auch viele Dinge falsch machen – solange er kein ausgiebiges Honorar für seine Arbeit verlangt.

Denn wenn man nicht essentielle Dinge im Webdesign berücksichtigt, wäre jeder verlangte Euro genau ein Euro zuviel. Ich finde es schade, dass ich immer wieder sehe, wie große Firmen viel Geld für das Erstellen einer Webseite haben und dort viele wichtige Dinge einfach nicht berücksichtigt werden. Diese Dinge werden von den Kunden allerdings meist nicht entlarvt, da hier das nötige Fachwissen fehlt. Vielleicht hilft dieser Artikel ja weiter.

Und ich wiederhole mich gerne nochmal: Niemand ist perfekt. Aber die Perfektion sollte man zumindest anstreben – erst Recht, wenn man viel Geld für die Arbeit verlangt.