Der letzte Teil meiner kleinen AAL-Aktion. Und wieder merke ich, dass noch viel Aufklärungsarbeit betrieben werden muss. Zwar kennt jeder den Begriff Semantik, aber viele haben Probleme, ihn korrekt einzuordnen. Semantik ist nicht das gleiche wie Validität! Und Semantik ist auch nicht unbedingt das Gegenteil von Tabellenlayouts! Mit Browserkompatibilität hat Semantik auch nichts zu tun.

Ich kann eine Seite machen, die perfekt gegen XHTML 1 strict validiert, keine einzige Layottabelle enthält und auf allen Browsern fein aussieht, die aber dennoch keine einzige semantische Information enthält! Meine Frage zielte darauf ab, ob man sich für all die feinen Admin-Tools und Boxen und Listen und Ajax-Auswahl-Dragger und wie auch immer den Kopf zerbrechen soll, wie man nun die Headline-Hierarchie aufsetzt und ob eine Definitionsliste besser ist als eine Datentabelle. Oder ob man einfach verschachtelte div-Container reinklatscht. Zur besseren Pflegbarkeit des Codes brauche ich keine HTML-Semantik, da reichen auch Quellcode-Kommentare, sind sogar deutlich besser geeignet. Für mich ist eine kluge Semantik auf jeden Fall ein gewisser Aufwand, der sich für’s Backend oftmals nicht lohnt – oder wo die semantische Reichhaltigkeit der existierendem HTML-Elemente nicht ausreicht.

Naja, dennoch sind ein paar schöne Antworten aufgelaufen, here we go:

Die besten »pro«-Antworten

Gero Z.

Ja. Dergestalt, dass das Admin-Backend auch mit zukünftigen Browsergenerationen bedienbar bleibt. Darüber hinaus ist es in der Vergangenheit schon allzu häufig vorgekommen, dass Admin-Backends später um alle möglichen Funktionen erweitert werden mussten, wobei unsauberer »das reicht erstmal«-Code sich als extremer Hemmschuh herauskristallisierte. Sprich: Etwas mehr Sorgfalt vorher bedeutet deutlich weniger Arbeit hinterher. Oder stereotyper: Vorsicht ist besser als Nachsicht.

Johannes Leers

Aber auf jeden Fall, denn richtige HTML-Semantik ist doch eine Philosophie und keine erzwungene Maßnahme. Wer Webdesign mit ganzen Herzen betreibt, für den stellt sich diese Frage doch gar nicht. Nur weil Admin-Bereiche nicht der ganzen Öffentlichkeit zugängig sind, bedeutet das nicht, dass hier geschlampt werden darf. Außerdem hat man bestenfalls richtige Semantik so verinnerlicht, dass es in den fingern schmerzt, wenn man kauderwelsch schreibt :)

Steffen Voß

Ich finde das mittlerweile einfach total ungewohnt zB eine Liste NICHT als ul/ol zu erstellen. Da fang ich doch nicht an im Backend ne andere Sprache zu sprechen und da dann plötzlich Tabellen zu nehmen. Wenn man dann an einem OpenSource Projekt wie Postnuke arbeitet kann man sich das ohnehin nicht erlauben – immerhin soll das System von verschiedensten Menschen bedient werden können und dann gucken einem auch noch sehr viele Leute auf die Finger.

Oliver Skawronek

Ja. Meistens hat man eh ein CMS Parat, dass man nur noch inidivduell auf den Kunden zuschneidet. Da kann man sich gewiss auch die Zeit für korrekte Semantik des Admin-Bereichs nehmen. Zudem will ein Administrator event. auch seine Einstellungen auf einem portablen Gerät oder Terminal unterwegs vornehmen. Dafür sind Tabellen-Layouts nicht geeignet.

Tilman Schläger

Ja, allein schon der Gewohnheit wegen. Ich sehe keinen Grund warum man auch in Adminbereichen, die vergleichsweise wenige Menschen zu Gesicht bekommen, auf Standards verzichten sollte. Korrekte Semantik – Standardkonformität ebenso – ist nicht gleichbedeutend mit mehr Aufwand. Spätestens bei späteren Fehlerkorrekturen und der Wartung kann das dann zu einem wichtigen Faktor werden.

Sasan Seyfi

Im Prinzip Ja. Grundsätzlich wäre es wünscheswert ein semantisch codiertes, barrierefreies Backend zu realisieren (Papoo geht in die richtige Richtung und der Adminbereich ist zumindest barrierearm) – die Frage ist nur: für wen? Wer kann den Adminbereich nutzen, ohne sich ins Markup einzuarbeiten? Entweder wir bauen eine rein semantisch codierte Adminseite, über die Inhalte ins System gestellt werden und setzen voraus, dass der User Vorwissen mitbringt und im Prinzip html-erfahren ist (Verzicht auf Javascript = Verzicht auf Wysiwyg). Oder aber wir bieten ein flexibles System an, das beim User sehr wenig voraussetzt, intuitiv bedienbar ist, und das bedeutet Elemente wiederum dynamisch (per AJAX) einzubinden.

Die besten »contra«-Antworten

Florian Eckerstorfer

Das ist so eine Sache. Ich schreibe grundsätzlich validen Code, aber in Admin-Bereichen benutze ich keinen Validator um zu überprüfen ob das auch alles valide ist. Sollte sich irgendwo ein Fehler eingeschlichen haben, der aber keine Auswirkungen auf die korrekte Darstellung/Funktionsweise hat dann ist mir das, nun ja, scheiß egal.

Stephan Schmatz

Ja, HTML-Semantik muss schon stimmen. Wenn es aber nur einen Admin gibt kann man ruhig so coden, dass das HTML evt. nur von Firefox richtig interpretiert wird. Auf Alt-Tags bei Bildern kann man auch verzichten und Barrierefreiheit ist meistens auch kein Thema.

Philipp Naderer

NEIN! Ich arbeite gerade bei einem großem Unternehmen an einem kleinen Slideshow-Tool und da wird bei mir echt auf die Semantik – sorry für das Wort – geschissen. Es muss im IE >5, Firefox und Opera gleich gut aussehen und nicht mehr. Versuch das mal mit CSS in einer ansprechenden Zeit hinzubekommen – Tabellen sind da sehr viel einfacher zu handeln. Da werf ich mir nachher ein paar Zellen dazu, ändere hier etwas, da etwas. Und es schaut einfach noch immer gleich im IE und Firefox aus. Ich möchte hier aber eine Ausnahme ganz klar festlegen: Open Source CMS etc., die einer breiten Öffentlichkeit angeboten werden und nicht einem einzigen Zweck/Firma dienen.