Definitive Richtlinien für "richtiges" HTML gibt es nicht. Wohl aber gibt es Regeln, wie ein gültiges HTML-Dokument auszusehen hat. Auf jeden Fall ist es empfehlenswert, sich so weit wie möglich an den HTML-Sprachstandards des W3-Konsortiums zu orientieren. Mittlerweile hat das W3-Konsortium auch erkannt, dass seine Aufgabe nicht nur im Ausarbeiten technischer Spezifikationen besteht, sondern auch in deren Vermittlung an "normalsterbliche" Anwender, die kein abgeschlossenes Informatikstudium haben. Wenn Sie sich intensiv und dauerhaft mit dem Erstellen eigener Web-Seiten beschäftigen, sollten Sie deshalb regelmäßig mal auf den Web-Seiten des W3-Konsortiums nach Neuigkeiten und nach aktuellen Trends und Richtlinien umsehen. Es gibt auch ein deutsches Büro des W3-Konsortiums, das wichtige Informationen des W3-Konsortiums in deutscher Sprache anbietet.
Für HTML-Autoren bietet das W3-Konsortium ferner einen Service an, um erstellte Dateien auf syntaktische Korrektheit zu überprüfen: den so genannten Validator. Damit können Sie Ihre Seiten, wenn diese im Web über eine HTTP-Adresse erreichbar sind, überprüfen lassen.
Was die Frage nach "gutem HTML-Stil" betrifft, ist es eigentlich viel besser zu beschreiben, wie man es auf keinen Fall machen sollte. Dazu gibt es eine zwar schon etwas betagte, aber immer noch lesenswerte Anleitung im Web: die Goldenen Regeln für schlechtes HTML von Stefan Karzauninkat.
Wenn Sie Dateien im Web platzieren wollen, sollten Sie zum Testen Ihrer Dateien mehr als einen Web-Browser verwenden. Verwenden Sie die weit verbreiteten Produkte wie Netscape und den Internet Explorer, wenn es irgendwie geht auch in mehreren Versionen, aber auch mal ein älteres Produkt wie etwa Mosaic. Wenn Sie die Möglichkeit haben, auf mehreren Plattformen (MS-Windows, Macintosh, Sun usw.) zu testen, machen Sie unbedingt Gebrauch davon. Und vielleicht schauen Sie sich Ihre Seiten auch mal mit einem Handheld-Computer an oder mit einer Brille, durch die Sie alles undeutlich sehen.
Nun kann Ihnen niemand verbieten, HTML-Dateien zu schreiben, die nur von Netscape oder nur vom Internet Explorer korrekt angezeigt werden. Aber wenn Sie solche Seiten ins Netz stellen, sollten Sie wissen, dass Sie damit letztlich Ihrem Image schaden.
Das Erzwingen von festen Breiten durch Einsatz von verschachtelten Tabellen und "blinden Pixeln" ist mittlerweile so verbreitet im Web, dass manche Homepage-Autoren schon gar nicht mehr wissen, dass einfaches HTML normalen Fließtext erzeugt, der sich der Fenstergröße des Browsers anpasst. Nun hat es keinen Sinn, das Erzwingen von Mindestbreiten völlig zu verteufeln. Tabellen mit mehreren Spalten und entsprechendem Inhalt benötigen nun mal eine gewisse Breite, und HTML ist auch nicht WML (eine Sprache speziell zum Erstellen von Web-Seiten für Handy-Displays). Wenn Sie aber vor der Frage stehen, ob Sie Ihre Web-Seiten für eine 1024er- oder eine 800er-Bildschirmauflösung "optimieren" sollen - dann stehen Sie vor der falschen Frage. Denn viele Anwender surfen mit mehreren Instanzen des Web-Browsers und öffnen Verweise zu anderen Seiten gerne in neuen Browser-Fenstern. Diese Fenster werden oft nicht im Vollbildmodus angezeigt. Auch haben viele Anwender Programme offen, die grundsätzlich einen Teil des Bildschirms einnehmen und immer angezeigt werden - z.B. Instant-Messaging-Programme wie ICQ. All diese Anwender machen Ihnen also ohnehin nicht die Freude, das Browser-Fenster extra wegen Ihren Seiten auf maximale Bildschirmgröße zu bringen. Grübeln Sie daher nicht lange über anzunehmende Durchschnittswerte von Bildschirmgrößen. Ein paar hundert Pixel (also eine sehr unbestimmte Angabe) in der Breite können Sie voraussetzen, aber das ist auch alles.
Verwenden Sie bei Tabellen oder Frames tendenziell eher prozentuale Breiten- und Höhenangaben. Absolute Pixelangaben haben nur dort einen Sinn, wo beispielsweise die erste Spalte einer blinden Tabelle über einem farblich zweigeteilten Hintergrundbild liegen soll. Ansonsten sollten Sie sich nicht zu sehr auf solche Vorstellungen wie die versteifen, dass eine Grafik oder ein Absatz bei jedem Anwender genau 10,8 cm vom linken Rand entfernt beginnt. Wenn das bei Ihnen gut aussieht, bedeutet das noch lange nicht, dass es bei jemand anderem gut aussieht, und in einigen Fällen könnte es auch ausgesprochen schlecht aussehen.
Besonders die logisch-semantischen Elemente von HTML sollten Sie nicht benutzen, um bestimmte Formatier-Effekte zu erzielen. So verwenden einige Leute z.B. das blockquote
-Element, um Absätze einzurücken, nur weil die Mehrzahl der Browser den Text, der in <blockquote>
... </blockquote>
eingeschlossen ist, als eigenen, eingerückten Absatz darstellen. Das blockquote
-Element ist jedoch für Zitate gedacht und sollte auch nur dafür verwendet werden.
Noch häufiger wird mit Überschriften und Tabellen Schindluder getrieben. Überschriften sind nicht dazu da, um Text groß und fett zu machen, sondern dazu, logische Hierarchieverhältnisse zwischen Textabschnitten zu markieren. Tabellen sollten zur Gliederung tabellarischer Daten und nicht für Layout-Zwecke eingesetzt werden. Wenn Sie Text auffällig formatieren oder positionieren wollen, dann benutzen Sie dazu Stylesheets.
Generell gilt: das Ziel eines Verweises sollte das halten, was der Verweis verspricht. Das bedeutet beim Setzen des Verweises: der Verweistext sollte weder zu viel noch zu wenig versprechen. Wenn Sie beispielsweise Information über ein Software-Produkt anbieten, ohne es zum Download anzubieten, ist es unfair, dem Anwender mit einem Verweis auf die Information zu suggerieren, er könne das Produkt auch gleich downloaden.
Verweise können in HTML an jeder beliebigen Stelle im Text stehen. Wenn Sie jedoch einmal Text lesen, in dem jedes zweite Wort ein Verweis ist, werden Sie schnell merken, dass dies den Lesefluss ungemein stört. Der Grund dafür ist, dass Verweise immer gleich die Aufmerksamkeit auf sich ziehen und den Leser von seiner eigentlichen Aufgabe, dem geistigen Erfassen des im Text Gemeinten, ablenken. Um so wichtiger ist es, dass Verweise innerhalb des Fließtextes dem Anwender keine Rätsel aufgeben, sondern sofort erfassbar sind.
Verwenden Sie einen Verweis innerhalb des Fließtextes also nur dann, wenn der Verweistext sinnvoll ist. Und formulieren Sie Sätze, in denen verweis-sensitiver Text vorkommt, so, dass der Verweistext aussagekräftig ist.
Schreiben Sie z.B. nicht:
"Für weitere Information klicken Sie hier",
sondern:
"Weitere Informationen sind ebenfalls verfügbar".
Wenn Sie nicht gerade eine virtuelle Kunstausstellung in HTML erstellen, sollten Sie sich mit großen Grafikdateien zurückhalten. Bedenken Sie bei Dateien, die Sie fürs Web erstellen, dass viele Anwender entweder einen volumenabhängigen Internet-Zugang haben, d.h. sie zahlen dafür, wie viel Daten sie in den Arbeitsspeicher ihres Rechners laden, oder zeitbasiert bezahlen müssen und sich an langen Ladezeiten ebenfalls nicht erfreuen. Zwar erlauben die meisten Browser, das Laden von Grafiken auszuschalten, doch falls der Anwender keinen Gebrauch von dieser Funktion macht, heißt das noch lange nicht, dass er bereit ist, ohne Ankündigung eine 1-Megabyte-Grafik zu laden.
Versuchen Sie es daher lieber mit kleinen, wohlplatzierten Grafiken. Oft genügen 16 Farben statt 256 oder gar 16,7 Mio. Das macht die Grafiken deutlich kleiner.
Andererseits sollten Sie keinesfalls auf den Einsatz von Grafiken verzichten. Reiner Text ist am Bildschirm nämlich wesentlich ermüdender zu lesen als in Printmedien. Deshalb sollten Sie längere Texte möglichst reichhaltig strukturieren und auflockern. Dazu gehört auch die Verwendung von Grafiken.
Ideal sind kleine Grafiken in Icon-Größe. Die sind schnell geladen, und Sie können bedenkenlos mehrere davon pro HTML-Datei referenzieren.
Kleine Grafiken können auch bestimmte Corporate-Identity-Funktionen oder Orientierungsfunktionen übernehmen. Der Vorteil solcher mehrfach verwendeter Grafiken ist, dass die meisten Browser sie nur einmal laden und dann im Speicher halten.
Titel einer HTML-Datei | |
Informationsverteilung und Dateiorganisation | |
SELFHTML/Navigationshilfen HTML/XHTML Allgemeine Regeln für HTML |
© 2007 Impressum