Home »» IT-Seite

HTML-Tips

Karl Brodowsky

Blog-Eintrag

Es gibt zu dem Thema auch einen Blog-Eintrag, der beschreibt, wie ich berufliche Web-Seite gebaut habe. Dasselbe trifft in etwa für diese Seiten zu.

Für welchen Browser schreiben

Vieles von dem, was man hier früher schreiben konnte, hat sich etwas relativiert, aber die Frage der Browser-Abhängigkeit ist immer noch vorhanden. Da es zur Zeit keinen Browser gibt, der völlig dominiert, ist sowieso ein Seitenlayout erforderlich, das ein gewisses Maß an Browser-Unabhängigkeit bietet. Dabei hat sich die Browser-Abhängigkeit heute mehr in die Bereiche JavaScript und CSS verlagert, während HTML mehr und mehr ein stabiler Standard geworden ist, den man einigermaßen problemlos verwenden kann.

Obwohl HTML, CSS, SVG, PNG, JPG und ECMAScript (das ist der offizielle Name von JavaScript) ja eigentlich als ein herstellerunabhängige Standards gedacht sind, schlichen sich doch früher immer wieder gewisse Erweiterungen ein, indem sie zuerst bei dem einen oder anderen Browser eingeführt werden und dann in dem Standard eventuell irgendwann einmal vorkommen. Auch heute kommt es noch vor, daß die Standards von gängigen Browsern unvollständig oder fehlerhaft unterstützt werden.

Erst nach und nach werden wichtige Features von den jeweils neuesten Browsern korrekt umgesetzt. Oder auch nicht. Als Webseitenautor sah man sich deshalb oft in einem Konflikt. Nimmt man die neuesten Knalleffekte mit in seine Seite herein, kann man da wirklich etwas tolles machen. Aber das kann nur noch derjenige gut finden, der denselben Browser mit denselben Einstellungen verwendet. Oder zieht man sich auf ein stabiles Standard-HTML zurück, vielleicht sogar auf die Teilmenge davon, die auch ganz alte Browser noch können? Heute ist aber die Schnittmenge der Möglichkeiten gängiger Browser so groß geworden, daß man schon sehr viel machen kann.

Es ist seit über 15 Jahren selbstverständlich, daß man davon ausgehen kann, daß die allermeisten Benutzer längst einen Browser haben, der Bilder problemlos anzeigen kann und daß auch die Netzwerkverbindungen gut genug für moderat große Datenmengen sind, so daß kaum noch jemand das Laden der Bilder abschaltet. (Das war zu der Zeit, als dieser Text Mitte der 90er Jahre ursprünglich entstand, natürlich noch nicht so.) Man sollte aber doch daran denken, daß auch Blinde das Web benutzen und deshalb die Seiten zumindest so gestalten, daß sie auch ohne die Bilder funktionieren. Grundlage sollte auch immer bleiben, daß man relativ plattformunabhängig bleibt. Mit der Zeit bekommt man ein gewisses Gefühl dafür, was bei anderen Seiten gut oder schlecht gelungen ist, was man machen kann und was der eigene Stil für die Webseiten wird, den jeder für sich selbst finden muß. Ich halte es in dieser Hinsicht im Moment so, daß ich meine Seiten für Lynx, einen textorientierten Browser lesbar und benutzbar mache. Für die kleinen Extras, die darüber hinausgehen, orientiere ich mich an Firefox, Dieser hat den großen Vorteil, für ein ganz breites Spektrum an Rechnern und Betriebssystemen angeboten zu werden und das auch noch als freie Software. Man bekommt auf http://www.mozilla.org/ sogar die Quelltexte. Zu beachten ist, daß die Browser der Mozilla-Familie (z.B. Firefox) sich heute recht gut an die Standards halten. Mit reinem HTML ist das kein so großes Problem, aber sobald JavaScript ins Spiel kommen, wird die Sache mit den verschiedenen Browsern heikel.

Sporadisch teste ich meine WWW-Seiten übrigens auch mit Internetexplorer und Konqueror und stelle keine Probleme fest. Aber da es über 600 HTML-Seiten sind, ist es unrealistisch, das vollständig zu tun. Ich vertraue daher mehr auf ein einheitliches Design mit solidem HTML bzw. XHTML und CSS und dann sollte es ausreichen, einen Teil der Seiten zu testen.

Bilder

Abgesehen von den unwichtig gewordenen Ladezeiten gibt es viele Seiten, die so überladen mit bunten und blinkenden Bildern sind, daß man da kaum noch hinsehen kann. Ich verwende zur Zeit absichtlich gar keine Animationen, aber ich habe zum Beispiel bei ein Landkarte mit dezenter Animation ?  gesehen, die ich absolut gelungen finde.

Ich finde es sinnvoll, daß man in normalen Seiten nicht übertrieben viele und übertrieben große Bilder einbaut, damit die Ladezeiten nicht zu lang werden. Ein Bild für heutige Verhältnisse kleines von 256 Pixeln Höhe als jpg braucht etwa 20 kB, das entspricht so ungefähr 400 oder 500 Zeilen Text. Die Frage der Farbtiefe, die früher noch eine Rolle spielte, kann man heute glücklicherweise vergessen. Mitte der 90er Jahre war es noch verbreitet, daß man nicht alle 16777216 gleichzeitig darstellen konnte, was heute nur noch ein absurder Gedanke ist.

Für Leser mit normalem Sehvermögen lohnt es sich auch nicht mehr, die Seite so zu bauen, daß sie auch ohne Bilder funktioniert. Aber man sollte berücksichtigen, daß die Farben nicht von allen Lesern gleich gesehen werden. Eine rot-grün-Schwäche beim Sehen ist zum Beispiel sehr verbreitet. Außerdem gibt es vielleicht blinde Leser, die die Bilder gar nicht nutzen können, die sich aber den Text vom Computer vorlesen lassen können oder die ihn mit Blindenschrift ertasten können.

Wegen der Ladezeiten sollte man sich überlegen, ob man nicht lieber nur kleine Bilder (sogenannte Thumbnails) in die WWW-Seite einbaut oder die großen Bilder als Links hinter den kleinen Bildern versteckt. Ich glaube, daß es sich etabliert hat, daß man auf das kleine Bild klicken muß, um eine größere Ausgabe davon zu erhalten, ohne daß das einer Erklärung bedarf.

Kleine Bilder auf dem Bildschirm kann man natürlich jederzeit bekommen, indem man große Bilder einbindet und im HTML Größenangaben einbaut. Dann werden aber die großen Bilder zuerst übertragen und anschließend von Firefox, Konqueror, Chrome, Internetexplorer, Safari (oder wie der Browser auch heißt) verkleinert. Das bringt also nichts. Man muß die Bilder unbedingt vor dem Ablegen auf dem WWW-Server mit einem geeigneten Programm auf das wirklich benötigte Maß verkleinern. Ich mache das mit Gimp oder Imagemagick. Photoshop eignet sich natürlich auch, aber damit habe ich keine Erfahrung. Die großen Bilder kann man bei Bedarf zusätzlich verfügbar machen, eben z.B. beim Klicken auf das kleine Bild. Mit direkt eingebundenen großen Bildern gibt es aber noch ein anderes Problem. Die Seiteneinteilung funktioniert nach meiner Erfahrung oft nicht mehr so gut. Sobald der Leser einen anderen Font oder eine andere Fenstergröße verwendet als der Autor, gibt es merkwürdige Verschiebungen im Seitenlayout, die plötzlich seitliches Scrollen erfordern, nur um den Text, der sich rechts neben dem Bild drängt zu lesen, und das Bild, das sich etwas weiter unten wieder daneben befindet, anzusehen. Eventuell kann man das aber auch durch geschickten Einsatz von <P> oder <BR> in den Griff bekommen. Oder durch Auslagern der Bilder in eigene Seiten. Oder durch CSS.

Mann kann aber jedenfalls immer noch darauf achten, daß die Seite auch ohne die Bilder funktioniert. Das bedeutet, daß wichtige Links, die unter Bildern versteckt werden, auch noch einmal im Text irgendwo verfügbar sind. Und Bilder, die eine wichtige Information enthalten, sollten einen ALT-Text enthalten, der dem Leser ohne Bilder auch zeigt, worum es so ungefähr geht. Für Bilder, die nur der Verzierung dienen, kann man auf den ALT-Text meiner Meinung nach verzichten. Wenn man das konsequent durchhält, wird der Leser schon merken, wie die Seite auch ohne das Laden von Bildern funktioniert.

Manche Inhalte sind in Bildern viel besser zu fassen als in reinem Text, zum Beispiel Landkarten. Diese Inhalte sind für Benutzer textorientierter Browser, wie z.B. lynx, nicht gut zugänglich. Lynx konnte aber schon vor langer Zeit solche Bilder mit einem externen Hilfsprogramm anzeigen, wenn so etwas zur Verfügung stand, aber wenn man Bilder sehen will, wird man wohl kaum noch einen textorientierten Browser verwenden.

Wenn ein Hintergrundbild verwendet wird, dann sollte man die Hintergrundfarbe so einstellen, daß sie der Hauptfarbe des Hintergrundbildes entspricht. Ich achte auch darauf, meine Hintergrundbilder so weit abzuschwächen, daß sie den Text nicht zu sehr stören. Wenn dann die Schriftfarbe vernünftig gewählt wird, dann hebt sie sich auf jeden Fall gut von dem Hintergrund ab, egal ob die Bilder geladen wurden oder nicht. Allerdings überlege ich mir gerade, meine Hintergrundbilder komplett abzuschaffen.

Bei Bildern trifft man hauptsächlich drei Formate an: JPG, PNG und GIF. Diese Formate haben sehr interessante Eigenschaften, die man sich beim richtigen Umgang mit ihnen zunutze machen kann. Weil aber jedes Grafikformat seine Vor- und Nachteile hat, muß man jeweils im Einzelfall entscheiden, welches man verwendet. Bei GIF gab es früher einige Bedenken wegen der komplizierten Patentlage, aber das hat sich mit dem Auslaufen des Patentes (2003) erledigt. Es scheint auch, daß diese Angst vor GIF-Patenten ein bißchen als Panikmache zu Propagandazwecken funktioniert hat. Mir ist kein Fall bekannt, in dem ein WWW-Seiten-Betreiber für die Verwendung von GIFs zu Lizenzzahlungen gezwungen wurde oder Ärger bekommen hat. Anscheinend sind diese Patente in Europa sowieso kein Problem gewesen.

Weil inzwischen praktisch alle Browser PNG unterstützen und PNG meistens eine etwas bessere Komprimierung als GIF bietet, wenn man das Bild auch indiziert (mit maximal 8 Bit Farbtiefe) speichert, braucht man GIF heute sinnvollerweise nur noch, wenn man alte GIF-Bilder weiterverwenden will oder wenn man die Transpararenz benötigt. Die kann PNG zwar auch, aber diese Eigenschaft wird leider von einigen heutigen Browsern für PNG noch nicht so gut unterstützt wie für GIF. Es empfiehlt sich ansonsten, gleich auf das modernere PNG-Format zu setzen. In meinen Seiten habe ich noch GIF im Einsatz, weil diese Seiten zu einer Zeit entstanden, als viele Browser PNG noch nicht beherrschten. GIF kann natürlich auch Animationen, aber die mag ich ja sowieso nicht so sehr.

JPG ist dagegen ein phantastisches Format für Fotos und foto-ähnliche Bilder, weil es eine enorme Kompression erreicht, die zwar nicht ganz verlustfrei, doch in der Regel völlig unproblematisch ist.

 

FormatVorteileNachteileVerwendungszwecke
PNG speichert Bilder verlustfrei mit guter Kompression (meistens besser als GIF)
erlaubt zwei Arten der Speicherung: indiziert und RGB
ist nicht durch Patente tangiert		 wird von sehr alten Browsern nicht unterstützt
ist in der Regel größer als JPG
Transparenz funktioniert nicht so gut wie bei GIF		 Zwischenspeicherung beim Verarbeiten der Bilder
Grafiken, kleine Bilder, Zeichnungen, Icons, Symbole u.ä.
JPG speichert Fotos mit enormer Kompression
ist nicht durch Patente tangiert		 Kompression ist nicht verlustfrei
kann keine Transparenz darstellen
komprimiert manche Grafiken schlechter als PNG		 Fotos und Bilder mit vielen Farben für WWW-Seiten
GIF speichert Grafiken mit mäßiger Kompression
kann Animationen darstellen (wenn man das wirklich will)
ist nicht mehr durch Patente tangiert		 Kann nur 256 Farben darstellen
Komprimiert weniger gut als PNG oder JPG		 transparente Bilder

PNG sollte man auf jeden Fall verwenden, um auf der eigenen Platte die Bilder zu speichern, die man verarbeitet und dann auf die WWW-Seiten packt. Ob man PNG in der WWW-Seite selbst verwenden will, muß man einmal grundsätzlich entscheiden, aber es spricht heute eigentlich nichts mehr dagegen. Schon neuere Netscape-Versionen konnten PNG anzeigen, nur sehr alten Versionen (z.B. 3.0) fehlte diese Fähigkeit. Ich verwende auch mehr und mehr PNG, weil ich inzwischen keine ernsthaften Bedenken mehr dagegen habe. Entsprechend muß man sich einmal entscheiden, ob man wegen der Patente GIF vermeiden will. Ich verwende hier trotzdem GIF-Bilder und mir scheint das auch kein Problem zu sein. Nun sollte man das Bild in verschiedenen Formen abspeichern und die Ergebnisse vergleichen, z.B. GIF mit 2 Farben, GIF mit 4 Farben, GIF mit 8 Farben u.s.w., dann JPG mit 90% Qualität, JPG mit 80% Qualität u.s.w., dann PNG indiziert (mit verschiedenen Anzahlen von Farben wie GIF) und PNG mit voller 24-bit-Farbtiefe (RGB). Von diesen Bildern sucht man sich das aus, das gerade noch akzeptable Qualität aufweist und die wenigsten Bytes braucht. Mit der Zeit bekommt man dafür ein Gespür.

Wie gehe ich damit um? Auf meinem Rechner habe ich die Bilder meistens als PNG-Datei oder sogar als XCF-Datei mit viel mehr Pixeln gespeichert und ich mache für die WWW-Seiten eine Verkleinerung davon. Wenn es dann kleine Bilder sind oder wenn es Strichzeichnungen oder so etwas sind, dann kommen sowieso nicht so viele Farben vor, aber ich möchte wenigstens das bißchen an Auflösung noch ausnutzen. Das wird also mit PNG (früher GIF) gemacht. Bei Fotos, die auf dem Bildschirm richtig groß erscheinen sollen, spielt die Sache mit den Farben eine Rolle. Aber der Informationsverlust von JPG ist nicht so schmerzhaft, weil JPG speziell für Fotos gemacht wurde. Der Informationsverlust fällt normalerweise gar nicht auf. Natürlich muß man für eventuell spätere Verarbeitungen die PNG-Datei verwenden, damit man nicht bei jedem Speichern eine Qualitätseinbuße hat. Selbstverständlich kann man das richtige Bild auch als TIFF-Datei speichern, wenn die Software das besser kann als PNG. Mir ist allerdings noch nicht ganz klar, was man im TIFF-Format an Information unterbringt, die sich nicht in einer PNG-Datei genausogut unterbringen ließe.

Eine Spezialität im Zusammenhang mit Bildern sind die Icons, die bei manchen Browsern, z.B. Netscape7, neben der URL erscheinen. Dies wird durch eine Datei favicon.ico geliefert, die im Rootverzeichnis des Servers abgelegt ist, oder durch eine Zeile wie 

<LINK REL="SHORTCUT ICON" href="http://myserver/myicon.ico">
im HTML-Header. Leider verwendet man hierfür ein sehr spezielles Bildformat, das von Bildverarbeitungsprogrammen oft nicht gekonnt wird. Die Idee dahinter ist, daß man theoretisch dasselbe Bild mit mehreren Auflösungen in derselben .ico-Datei speichern könnte. Es gibt aber Möglichkeiten, png-Bilder in ico-Bilder zu konvertieren, z.B. mit png2ico. Außerdem gibt es für Gimp ein Plugin, zu finden unter "registry" auf den GIMP-Seiten, das es ermöglicht, Bilder als .ico-Datei zu lesen oder zu schreiben. Oder man sucht die icons auf einer Seite mit freien icos.

Tabellen, Frames, u.s.w.

Tabellen und Frames zur Seitengestaltung sind völlig veraltet. Heute verwendet man dafür <div> und CSS. Ich stelle gerade meine Seiten entsprechend um.

Ich bin schon lange zu der Überzeugung gekommen, daß die Aufteilung eines Browserfensters in mehrere Frames extrem unvorteilhaft ist und ich hatte nie vor, so etwas zu machen. Frames verwende ich ausschließlich (und in geringem Umfang) in der Form, daß ich weitere Browserfenster öffne und getreu der WWW-Philosophie es dem Benutzer und dessen Fenstersystem überlasse, wie er die auf dem Bildschirm anordnen will. Ich halte Frames aber vor allem für unpraktisch, was die Navigation, Bookmarks und Links betrifft. Außerdem funktionieren sie schlecht in Verbindung mit Suchmaschinen. Ich verlinke auch ungern Frame-Seiten, weil es dort schwieriger ist, automatisiert zu überprüfen, ob der Inhalt noch mit dem übereinstimmt, was ich üblicherweise verlinken möchte.

Die Erfahrung zeigt, daß professionelle Seiten meistens von Frames und Tabellen weggekommen sind und stattdessen DIVs verwenden, um die Frames sozusagen auf der Serverseite zusammenzusetzen. So wird es auch hier sein. Wenn Frames verwendet werden, dann kann man eventuell dem Benutzer die Wahl lassen, stattdessen eine framefreie Version der betreffenden Seite zu lesen. Oft kann man einfach die Seite mit dem Navigationsframe hierfür verwenden. Außerdem empfiehlt es sich in diesem Fall, für Links, die aus der Seite herausgehen, das TARGET-Feld geeignet zu setzen, denn es gilt auch für Frame-Seiten nicht als wünschenswerte Praxis, die verlinkten Seiten nur in einem Frame aufzurufen, abgesehen von der Problematik von immer unübersichtlichen Framekonstrukten, wenn man das noch schachtelt. Ich habe sogar in diesen Seiten überall TARGET="_top" eingetragen. Wenn jemand dann von einer Frame-Seite aus auf meine Seiten stößt, wird er spätestens mit der zweiten Seite wieder den ganzen Bildschirm in Anspruch nehmen und nicht nur den einen Frame.

Tabellen gibt es natürlich schon lange, und ich gehe heute davon aus, daß die Browser das können. Aber ich würde die ganzen Tabellen nicht zu kompliziert machen, also von Tabellen innnerhalb von Tabelle und ähnlichen unübersichtlichen Konstruktionen möglichst Abstand nehmen. Man bekommt so etaws leider oft, wenn man HTML automatisch aus LaTeX oder OpenOffice oder MS-Word-Dokumenten generiert. Zu beachten ist in diesem Zusammenhang auch, daß viele Blinde mit spezieller Hard- und Software WWW-Seiten lesen können, daß dies aber bei komplizierten Tabellenstrukturen nicht mehr funktioniert. Das gilt natürlich erst recht für komplizierte Frame-Konstruktionen.

Editieren von HTML

Ich editiere alle meine WWW-Seite mit dem GNU-Emacs. Ich könnte wohl genausogut ein anderes Programm verwenden, das ist eher eine Frage der Gewohnheit. Umlaute gemäß ISO-8859-1 kann man in den WWW-Seiten einfach so verwenden, wie immer. Es ist nicht nötig, immer &auml; statt ä zu schreiben, wenn Euer Rechner schon mit ISO-8859-1 arbeitet, wie dies z.B. bei Unix, Linux und sogar bei Windows(NT/2000/XP) und MacOS X üblich ist, aber noch nicht bei DOS, MacOS 9, NeXT oder OS/2. Für einige wenige Seiten habe ich statt ISO-8859-1 explizit ISO-8859-2 oder utf-8 spezifiziert, wenn ich etwa im selben Text Umlaute und kyrillische Zeichen verwenden will.

Wie HTML geht, habe ich aus dem Buch von Musciano/Kennedy gelernt. Es gibt natürlich noch andere gute Bücher, aber auch einige sehr gute Einführungen im WWW, wovon wohl insbesondere SelfHTML bekannt ist. Wenn ich das einmal genauer gesehen habe, kommen hier vielleicht noch mehr Links zu dem Thema herein.

Wenn ich eine Datei editiert habe und sie veröffentlichen will, lasse ich ein kleines Perl-Skript laufen, das die verschiedenen Variante für die verschiedenen Web-Server erzeugt (ein paar Links sehen halt anders aus) und ich unterziehe die Seiten auch einer Verwaltung durch SubVersion, erkennbar an der Revision Nummer hinter der URL am Ende der Seiten. Das bedeutet, daß ich auch später noch eine ehemalige Version der Seiten zurückgewinnen kann, wenn Rückfragen dazu kommen. Dieser Fall ist allerdings in den Jahren, seit ich RCS oder SubVersion verwende, noch nie vorgekommen, es geht also eher darum, mißlungene Änderungen auch lange nach deren Speicherung wieder rückgängig machen zu können. Das ist mir schon passiert.

Wenn man es sehr schön machen will, dann sollte man noch darauf achten, gezielt die richtigen Leerzeichen einzusetzen. Es gibt nämlich zwei gleich aussehende Leerzeichen in den Positionen 32 und 160. Der kleine Unterschied macht sich bemerkbar, wenn man die WWW-Seiten liest und der Browser Zeilenumbrüche passend zum Bildschirmformat einbaut. Wo ein normales Leerzeichen ist, wird bei Bedarf ein Zeilenumbruch gemacht. In den hoffentlich seltenen Fällen, wo das Zeichen 160 steht, werden die beiden Wörter zusammen gelassen und wandern notfalls beide in die nächste Zeile. Ich benutze das zum Beispiel für Maßangaben wie "3 km", die echt komisch aussehen, wenn die "3" in einer Zeile und das "km" am Anfang der nächsten Zeile steht. Hier verwende ich zur besseren Erkennbarkeit gelegentlich auch &nbsp; statt des Zeichens 160.

Bevor ich es hier vergesse: Ins WWW gehören Texte natürlich in HTML-Gestalt. Jedenfalls sollte man sich bemühen, Texte für das WWW in HTML umzuwandeln. Das ist gar nicht so schwierig, denn es gibt viele Filter für HTML-Konvertierungen. Textdateien wandelt man ganz einfach um, indem man erst einmal darauf achtet, daß der Zeichensatz ISO-8859-1 (oder mit entsprechenden Vorkehrungen ein anderer gängiger Zeichensatz) verwendet wird (bei Unix und sogar bei NT in der Regel schon gegeben), dann am Anfang und am Ende den ganzen Kram einfügt, der bei jeder WWW-Seite dabei ist (mit View Document Source im Netscape kann man das sehen). Damit die Gliederung erhalten bleibt, kann man nach jeder Leerzeile ein <P> einfügen, sonst wird die Leerzeile ignoriert. Und Überschriften markiert man mit <H3> und </H3> (oder H1, H2, H4,...). Wie das geht, kann man leicht anhand von anderen Seiten im WWW sehen. Ich halte es jedenfalls für unvorteilhaft, stattdessen PDF-Dateien zu benutzen. Die sind nämlich groß und deshalb mit langen Ladezeiten verbunden. Außerdem sind sie in der Regel am Bildschirm schlecht zu lesen, weil das ganze Layout für den Ausdruck auf Papier optimiert ist. Zuletzt haben PDF-Dateien noch den Nachteil, daß es nicht so leicht möglich ist, automatisiert zu überprüfen, ob der Inhalt noch mit dem übereinstimmt, was ich überlicherweise verlinke. Deshalb lege ich sehr selten Links auf Seiten, die den Text als PDF enthalten.

Abkupfern

Überhaupt empfehle ich es, die HTML-Quelltexte von einfachen Seiten anzusehen, um einmal einen Anfang zu finden. Wenn im Web-Design eine besondere Leistung steckt und man beabsichtigt, massiv darauf zuzugreifen, muß man natürlich prüfen, ob der Autor der Seite damit einverstanden ist. Dasselbe gilt für Bilder und für Textausschnitte, die man aus anderen Seiten übernimmt.

Natürlich dürft Ihr den HTML-Quelltext meiner Seiten verwenden, um daraus eine Formatierung für Eure Seiten zu machen, indem Ihr "nur die Texte austauscht". Ich möchte aber im Sinne von etwas Individualität anregen, doch mindestens ein paar kleine Änderungen, z.B. bei den Farben, vorzunehmen. Wäre ja langweilig, wenn alle Seiten aussehen wie meine.

Einen Link auf die Seite eines anderen zu legen bedarf nach meinem Verständnis keiner Zustimmung, man sollte nur unter Umständen darauf achten, die richtige Einstiegsseite zu erwischen. Viele Seiten werden noch gar nicht so häufig gelinkt. Dann interessieren sich die Inhaber der Seite natürlich für eine Mail, in der so etwas steht wie "Ich habe einen Link auf Deine Seite gelegt." Unter Umständen werdet Ihr dann auch über Umstrukturierungen, die Euren Link betreffen, informiert. Da sind wir aber doch wieder schon fast beim nächsten Thema.

Strukturierung

Spätestens wenn die Seite etwas größer wird, sollte man anfangen, sich einige Gedanken über die Strukturierung zu machen. Recht weit kommt man noch, wenn man in einer HTML-Datei einzelne Punkte mit

<A name="..."> ... </A>

markiert. Dann kann man eine Art Inhaltsverzeichnis machen und diese Punkte dann vom Inhaltsverzeichnis aus anspringen. Das Prinzip habe ich auch bei dieser HTML-Datei verwendet.

Irgendwann lohnt es sich dann auch, die Inhalte auf eine Vielzahl von Dateien zu verteilen, so wie ich es hier zum Beispiel auch gemacht habe. Dann stellt sich ziemlich schnell die Frage, wie man die Navigation zwischen den verschiedenen HTML-Dateien realisiert und welche Dateien man als Einstiegspunkte für Links anderer Seiten empfehlen sollte. Häufig wird das mit Frames gemacht. Dann gibt es eine Seite, in der die Frameeinteilung definiert wird. Genau diese Seite ist dann bevorzugt dafür geeignet, daß die die externen Links darauf zeigen sollten. Die Seiten, die in den einzelnen Frames liegen, eignen sich weniger, weil die ganzen Links zur internen Navigation ja in einem Frame, der sich üblicherweise an einem der vier Bildschirmränder schmal macht, konzentriert sind. Eine andere Möglichkeit ist es, in jeder Datei jeweils die Links auf alle anderen relevanten Dateien irgendwo einzubauen. Das ist der Ansatz, dem ich hier folge. Achtet einfach bei den Seiten, die Ihr im Netz findet, einmal darauf, wie Euch die Navigation und die Strukturierung gefällt. Dann wißt Ihr sicher irgendwann auch, wie Ihr Eure Seiten anordnen wollt. Für Frame-Benutzer ist es sinnvoll, externe Seiten mit

<A HREF="http://www.[bla].[blupp].de/xyz/abc/uvw.html" TARGET="_top">...</A>

aufzurufen, damit die nicht in Euren Frames hängen bleiben.

"Sie" oder "Du"

Im Grunde genommen hat es sich im Internet, vor allem bei Netnews (Usenet) eingebürgert, daß man sich grundsätzlich duzt. Ausgenommen sind hier nur die "Siez-Freunde", Personen, die man halt nicht aus dem Netz, sondern aus dem wirklichen Leben kennengelernt hat. Was bedeutet das jetzt für WWW-Seiten? Es hängt davon ab, wen man damit bevorzugt anspricht. Wenn es eine kommerzielle Seite ist, mit der Kunden angesprochen werden, die einem hoffentlich auch im wirklichen Leben einmal begegnen, dann sind dies heute noch meistens "Siez-Freunde", deshalb wird man als Leser kommerzieller oder auch amtlicher WWW-Seiten noch oft gesiezt. Bei privaten WWW-Seiten sehe ich aber eher die Konvention des Usenets als angemessen an, so daß ich mich hier an das "Du" gehalten habe. Meine "Siez-Freunde", die eventuell diese Seite auch lesen, mögen mir das verzeihen. :-)

Einführungen in HTML und andere Links