HTML-Tipps

Anmerkung: Der folgende Text stammt ungefähr von 2002–2004 und ist inzwischen recht veraltet – während damals viele Browser CSS noch nicht richtig beherrschten (was deshalb nur für Kleinigkeiten wirklich nutzbar war), hat sich inzwischen die Lage geändert. Und nachdem CSS sehr mächtig ist, gibt es unzählige Möglichkeiten, ein Layout zu realisieren – und nicht mehr „den einen richtigen Weg“ wie bei reinem HTML. Darum werde ich diese Seite nicht aktualisieren; wer CSS machen will, suche sich andere Quellen. Die Tipps hier beziehen sich nach wie vor darauf, wie man robustes (und halbwegs standardkonformes) HTML (mit sehr einfachem CSS und JavaScript) schreibt, das von den defekten Engines von IE 4.x und Netscape Navigator 4.x zuverlässig dargestellt wird und auch in w3m und elinks lesbar ist. Generell: Einfacher, sauberer Code ist nicht nur leichter zu schreiben und zu warten, sondern zukunftssicherer und liefert meist auch die übersichtlichsten Webseiten – und die Übersichtlichkeit sollte bei jedem Layout das Wichtigste sein.

Weil ich beim Basteln von Webseiten gerne die volle Kontrolle habe, schreibe ich HTML per Hand. Und weil mir Übersichtlichkeit wichtig ist und weil ich faul bin, kommt nur ganz simples HTML zum Einsatz, garniert mit CSS. Trotz Verzicht auf üble Tricksereien (die nicht immer so funktionieren, wie sie sollten) habe ich gelernt, ein paar Sachen zu beachten.

• Leere Links: Wenn ein Link kein Ziel enthält, z.B. weil er für einen JavaScript-Aufruf via onClick() genutzt wird oder weil die Ziel-Seite noch nicht fertig ist, sollte die Adresse trotzdem nicht leer gelassen werden. Das Verhalten der Browser (bei onClick(): nur wenn kein JavaScript unterstützt wird) ist nämlich unvorhersehbar: manche laden die angeklickte Seite nochmal (was im Frameset dazu führen kann, dass zwei Framesets ineinander sind), andere laden die Seite "/". Statt dessen schreibt man href="#" (d.h. ein Link auf einen nicht definierten Textanker auf der selben Seite), dadurch lädt der Browser garantiert keine neue Seite.

• Frameset: Sehr sinnvoll ist in den Frames die Verwendung von <BASE target="Zielframe">, dann muss man nicht bei jedem einzelnen Link daran denken, den Zielframe anzugeben.
  Und um bei einzelnen Seiten zu erkennen, dass sie nicht im zugehörigen Frameset geöffnet wurden (und dieses evtl. nachzuladen), nimmt man JavaScript:
  if( ( parent.frames.length != 2) || ( parent.frames[0].name != "Frame1Name" ) || ( parent.frames[1].name != "Frame2Name" ) ) ...
  Zum Nachladen des Framesets nimmt man dann ungefähr so etwas:
  window.location.href = "openframe.php?Inhalt=" + document.location.href.

• Navigationsframe: Suchmaschinen sollen einerseits allen Links, die die Navigationsleiste enthält, folgen, andererseits nicht die Navigationsleiste selbst indizieren, weil sie keine eigenständigen Informationen enthät. Dazu macht man einen Hinweis an die Robots, z.B.
  <META name="robots" content="noindex, follow">.

• Bilder: Man kann Bilder zwar mit Hilfe von Tabellen oder CSS-Styles exakt positionieren, aber meist will man das gar nicht. Die Bilder brauchen oft keine absolute Position, sondern sollten nur mit dem Text mitschwimmen und schön von ihm umflossen werden. Das erreicht man mit
  <IMG src="bild.jpg" width="320" height="240" hspace="10" vspace="10" align="left">,
  das in diesem Fall das Bild links ausrichtet und den Text auf 10 Pixel Distanz hält. Damit sich bei zu breiten Fenstern die Bilder nicht nebeneinander stapeln und hässliche Löcher in den Text reißen, empfiehlt es sich, die Bilder immer abwechselnd links und rechts anzuordnen und vor jedem Bild einen entsprechenden clear-Befehl zu schicken:
  <BR clear="right"> <IMG src="bild.jpg" align="right">.
  Auch für Bildergalerien ist die Ausrichtung mit hspace und vspace ideal; dazu lässt man den align-Parameter weg und erhält schön nebeneinander angeordnete Bilder, die sich automatisch so anordnen, dass sie das Fenster gut ausfüllen.

• Bildunterschriften: Eine Möglichkeit sind die Tooltips, die die meisten Browser anzeigen. Dazu muss der Text im alt-Parameter stehen; weil Mozilla (ganz regelkonform) diesen Parameter nicht als Tooltip zeigt, muss man für diesen Browser den Text nochmals im title-Parameter angeben (dieser funktioniert übrigens nicht nur bei Bildern, man könnte also beliebigen HTML-Elementen Tooltips verpassen).
  Für längere Bildunterschriften muss man dagegen Tabellen verwenden. Diese kann man genauso anordnen wie die Bilder selbst – d.h. man verwendet typischerweise eine einspaltige zweizeilige Tabelle, in deren ersten Zeile das Bild und in der zweiten Zeile der Text steht. Die ganze Tabelle wird dann mit dem align-Parameter ausgerichtet. Leider ist man auf diese Ausrichtung angewiesen, d.h. obiger Trick für Bildergalerien funktioniert nicht – wenn man den align-Parameter weglässt, stehen alle Bilder untereinander statt nebeneinander. Hier ist eine Beispielseite.

• Eingerückter Text: Mit CSS kann man wunderschöne Texteinrückungen machen; z.B. text-indent:1cm; rückt die erste Zeile eines Absatzes um 1 cm ein. Wenn man es dagegen umgekehrt machen will, nämlich die erste Zeile ausrücken (d.h. dass alle weiteren Zeilen eingerückt sind), muss man tricksen:
  text-indent:-1cm;margin-left:1cm;.

• Tabellen: Viele Browser lassen leere Tabellenzellen weg. Gegenmittel: ein &nbsp; in die Zellen reinschreiben. Und damit bei Tabellen, die sich über die gesamte Breite erstrecken, die Browser keine horizontalen Scrollbalken anzeigen, hilft es angeblich, die Breite auf 99% statt 100% zu setzen.

• Absolute Schriftgrößen sind schwer zu erreichen, weil die voreingestellte Auflösung, d.h. die Umsetzung von Schriftgröße auf Pixelanzahl, abhängig vom Betriebssystem ist. Windows benutzt 96 dpi, MacOS 72 dpi (daher erscheinen die Schriften dort kleiner), und bei Linux kann man es einstellen. Daher entweder die Schrifthöhe relativ definieren (1.2em entspricht 120%), oder gleich die absolute Pixelanzahl angeben. Relative Maße wie x-large sind dagegen nicht so toll, weil jeder Browser sie unterschiedlich darstellt – beim einen ordentlich, beim anderen fast unlesbar.

• Ein CGI-Programm, das etwas tut, aber nicht den Bildschirminhalt ändern soll, gibt am besten Folgendes zurück:
  Status: 204 No Content\n\n.

• Bei einer einsprachigen Webpräsenz, bei der man sich um die Kodierung von Sonderzeichen keine Gedanken machen will, ist es am einfachsten, folgenden Eintrag (oder so ähnlich) in die Datei .htaccess zu machen:
  AddType text/html;charset=iso-8859-1 .html

• Wenn man von einer Seite einen Link auf die logisch übergeordnete Seite setzt (d.h. die Seite ist per Navigation nur durch die übergeordnete Seite zu erreichen) und letztere ziemlich lang ist, sollte man dort einen #-Anker setzen und darauf verlinken. So landet der Benutzer nicht irgendwo auf der übergeordneten Seite, sondern im thematisch passenden Gebiet rund um den Link auf die Seite, die er vorher besucht hat.

• Netscape: Weil die ziemlich defekten Netscape-4.7x-Versionen mit CSS Probleme haben, kann man schreiben:
  <LINK rel="stylesheet" type="text/css" href="netscape-stylesheet.css"><STYLE type="text/css"> @import url(stylesheet.css);</STYLE>
  Damit wird zuerst ein Netscape-Stylesheet definiert und anschließend umdefiniert, was aber nur die anderen Browser kapieren.

  Per CSS mit Hintergrundfarbe unterlegte Absätze zieht Netscape auch nicht über die volle Breite, wie es sein sollte. Helfen tut:
  width:100%; margin:0px; border:none;.

  Ein weiteres Problem ist Netscape-Nutzern unter Linux bekannt: wenn man den Browser per CSS anweist, eine serifenlose Schrift zu nehmen, bringt dieser eine Bitmap-Schrift. Diese hat eine ziemlich niedrige Auflösung und sieht entsprechend krätzig aus, wenn sie hochskaliert wird (z.B. in Überschriften). Statt einfach nur font-family:sans-serif; zu schreiben, kann man etwas konkreter werden und Netscape den richtigen Weg weisen:
  font-family:Helvetica,Arial,sans-serif;

• Mozilla wendet die CSS-Link-Formatierungen via A:hover oder A:focus auch auf Textanker (d.h. <A name="foobar">) an. In meinen Augen etwas verunglückt, weil man auf diese nicht klicken kann; wie ein Link soll nur das aussehen, was sich wie einer verhält. Da kann man nur die entsprechenden Stellen umdefinieren – z.B. setze ich Textanker gerne in H2-Überschriften, und definiere entsprechend:
  H2 A:hover { text-decoration:none; ... und so weiter... wie es halt aussehen sollte }

• Internet Explorer: Unverständlicherweise zeigt dieser Fehlermeldungsseiten („404“) nur dann an, wenn sie größer als 512 Bytes sind.

• Oft heißt es, dass die Webseite doch das Änderungsdatum enthalten sollte. Das schickt jeder Webserver mit, nur kein Browser zeigt es an – daher ist es in meinen Augen etwas Overkill, wenn man statisches HTML nur deshalb zu aktivem Inhalt macht, um sein Änderungsdatum auch in Textform anzuzeigen. Mit JavaScript geht das recht elegant:
  <SCRIPT type="text/javascript" language="JavaScript">
  <!--
  document.writeln( ' <HR>' );
  document.writeln( ' <DIV align="right">last update: ' + document.lastModified + '</DIV>' );
  // -->
  </SCRIPT>

• Zur Formatierung von 1 Pixel breiten Bereichen braucht man angeblich 1x1 Pixel große Bild-GIFs, weil es ansonsten die Browser nicht auf die Reihe kriegen.

• Viele Browser stellen HTML-Seiten unterschiedlich dar, je nachdem, welcher DOCTYPE im Header gesetzt ist (z.B. transitional oder strict). Ausführliche Erläuterung von Kai Pahl

• Maßnahmen zur Barrierefreiheit (c't 19/2004):

  • Daten und Layout trennen, d.h. CSS verwenden, semantisch sinnvolle Tags (z.B. <strong> statt <b>, Dinge wie <address>, <cite> usw. verwenden), keine Layout-Tabellen => die Struktur des HTML lässt auf die Struktur des Inhalts schließen.

  • einheitliches Layout

  • Bilder mit alt-Attribut versehen, das einen Ersatztext enthält; wenn das Bild ohne inhaltliche Bedeutung ist, ein leeres alt-Attribut verwenden (nicht weglassen!). Lange Erklärungen nicht in das alt-Attribut packen, sondern dafür das longdesc-Attribut verwenden.

  • Kontrastreiche Farben, Achtung bei Rot-Grün-Kontrasten, Skalierung der Schriftgröße erlauben (d.h. Größen in relativen statt absoluten Einheiten definieren).

  • Keine zu speziellen Techniken verwenden; z.B. funktionieren JavaScript-Menüs oft nicht mit Screen Readern oder alternativen Eingabegeräten. Automatische Weiterleitungen, Bewegung von Inhalten, Animationen, blinkende Inhalte, Popups können ebenfalls behindern.

  • Links per tabindex-Attribut und/oder accesskey-Attribut erreichbar machen (bei Letzterem empfiehlt es sich, wegen der Browser-Tastenkürzel nur die Ziffern 0-9 zur Navigation zu verwenden; außerdem muss man auf den Accesskey hinweisen, z.B. in einem title-Attribut). Durch sinnvolle Beschriftung das Ziel des Links kenntlich machen.

  • Abkürzungen durch acronym-Tag erklären bzw. mit abbr-Attribut einen Ersatztext bieten (damit Screen Reader richtig buchstabieren können bzw. den abgekürzten Begriff komplett aussprechen können).

  • Tabellen: summary-Attribut, in dem der Inhalt der Tabelle zusammengefasst wird, außerdem Spalten- und Zeilenüberschriften kennzeichnen.

  • Möglichst Text-Alternativen zu allen graphischen Elementen. Client-Side-Imagemaps statt Server-Side-Imagemaps.

  • Sonstiges: sinnvolle Verwendung von Metadaten, Navigationslinks gruppieren und als solche kennzeichnen, Feedback darüber wo man sich befindet, klar verständliche Sprache, verständliche Grafiken, prägnante Einleitungen für zusammengehörige Informationsblöcke, Aufteilung der Information in handliche Blöcke usw.

Achja, noch was: Während es in den Anfangsjahren des Internet zum guten Ton des Webdesigns gehörte, aufwändige Layouts mit den wüstesten Tricksereien (verschachtelte Tabellen, blinde GIF-Abstandhalter) hinzubasteln, zeichnet sich jetzt im Mozilla-Zeitalter ein gegensätzlicher Trend ab: alles muss zwangsläufig standardkonform sein, am besten XHTML. Kurz gesagt, ich sehe das nicht so eng; wichtig ist, dass es funktioniert, und zwar überall. Mir geht Einfachheit und Kompatibilität vor Standardkonformität, d.h. es soll in möglichst vielen Browsern funktionieren (v.a. die alten Netscape 4.x kann man nicht einfach vernachlässigen; Lynx ist für Masochisten, aber w3m ist ein Textmodus-Browser, den ich gerne verwende), es soll simpel sein (statisch statt dynamisch, darum mag ich Frames statt kompliziert via PHP eingebauten Navigationsleisten, auch wenn Frames nicht standardkonform sind) und auch für den Entwickler gut durchschaubar. Manches davon bedingt sich gegenseitig. Wenn ich ein simples Layout mache, ist die Wahrscheinlichkeit hoch, dass es sehr weit kompatibel ist, auch wenn es den neuesten Standards nicht entspricht. Immer noch besser, als eine was-weiß-ich-wie validierte Seite zu machen, die dann in älteren Browsern verhackstückt aussieht (auch wenn die Browser schuld sind). Mit alten Seiten kommen dagegen moderne Browser gut klar; warum sollte man das nicht ausnutzen? Das Internet lebt schließlich davon, dass die Informationen überall und mit jedem Gerät abrufbar sind.