Meine Freunde, die HTML-Tags

Die Primitivitäten, die einen an den Rand des Wahnsinns treiben können, sind es, welche einerseits die scharfe Würze unseres Lebens darstellen und uns andererseits den schönsten Tag verderben können. Aber der Mensch läßt sich ja bekanntlich nicht so leicht entmutigen und rennt weiterhin wie ein sturer Bock auf diese imaginäre Mauer oben genannter Primitivität (oder auch des Wahnsinns) mit dem Schädel voran hinzu, um schließlich eins der beiden zu zerbrechen. Wovon rede ich überhaupt? Von dem primitivsten und ersten HTML-Tags, und . [Und jetzt kommen wir zum uninteressanten Teil...]

Zuerst einmal war da dieses bekannte Problem, daß Voyager 2.92 bei aufeinanderfolgenden Absätzen (...), die aus Start- und End-Tags bestanden, keine Abstände einfügte, was jedoch sein sollte, um ein von einem <DIV [ALIGN = LEFT | CENTER | RIGHT]> zu unterscheiden. Nennen wir die Kombination "Text" "I", die Anordnung "Text" "II" und "Text" "III". Bei Anordnungen von "I" ergaben sich keine Abstände, fügte man eine Anordnung "II" oder "III" ein, ergaben sich welche, zB: "I" "II" erzeugte einen Abstand vor "II" und keinen vor "I". Umgekehrt jedoch funktionierte dies nicht immer, also ein "II" "I" machte zwar einen Abstand, ein "III" "I" hingegen nicht, dafür aber erzeugte "III" "II" gleich zwei davon.

Seltsamerweise funktionierte einiges wieder, wenn man zum Beispiel ein -Tag zuwenig eingebaut hatte, desweiteren ergaben sich noch unterschiedliche Konstellationen, wie etwa: ein "I" nach einem Table erzeugte keinen Abstand, eine "II" schon (eine "III" natürlich nicht). Dies zeigt, daß bei Voyager das "vorwärtswirkend" auf das nächste wirkt und diesem den Abstand zu sich selbst "stiehlt". Löscht man dieses , so ergibt sich wieder der gewünschte Abstand wie von Geisterhand.

Aber auch "rückwirkend" ergaben sich ähnliche Effekte: Während ein Standalone- immer einen Abstand im Text erzeugte, tat es dieses nicht mehr, wenn danach ein folgte, aber auch, wenn davor ein Absatz mit abschließendem war (siehe oben). Kurz gesagt: Jeder Auftritt des -Tags vermasselte mir mein Konzept und ich war gezwungen, umzudisponieren. Nachfolgend noch eine kurze Aufzählung der Probleme in übersichtlicher Form.

 .... - hier kein abstand - .... .... - hier kein abstand - .... [ ....] .... - hier schon - .... [ ....] .... - hier noch mehr - .... [ ....] .... - hier schon - .... [ ....] .... - hier nicht - .... .... .... - hier auch nicht - .... ....

Aber um eben ganz sicher zu gehen, beschloß ich, das ganze Konzept der Absätze zu verwerfen. Es boten sich 2 Alternativen an: Tags ohne End-Tags zu verwenden, was jedoch nicht SGML-konform wäre und deshalb für mich ausschied. Die zweite Alternative war, bei den Images, die zum Weiterscrollen da waren, einen künstlichen Abstand (im Bild selbst) zu erzeugen und überhaupt keine Absätze in HTML zu erzeugen, mit dem Vorteil, daß die Abstände bei allen Browsern pixelgenau gleich wären (abgesehen von eventuellen Font-Abständen, die durch den Font bestimmt sind und eventuell unterschiedliches Font-Rendering). Auch diese Methode verwarf ich, denn eine Veränderung der Images in diesem Sinne hätte in alten Ausgaben einen viel zu großen Abstand zur Folge gehabt (dort bestanden ja noch diese Abstandstags).

Schließlich gab es noch die Möglichkeit, das -Tag einzusetzen. Daß es ein Standalone-Tag ist, vereinfacht vieles, so können nun auch Tabellen direkt in Absätze eingebaut werden, was normalerweise nicht funktioniert, da ein Tabellenende in einem Absatz ein impliziert und das eigentliche überflüssig macht. Entfernt man jedoch dieses , ist der ganze Absatz eigentlich nicht mehr schön SGML-konform. Diese Probleme hat man bei nicht. Und dann ist da noch die Gewißheit, daß der Abstand genau einer Leerzeile entspricht, also sozusagen "fontsensitiv" ist. Auch mit "aligned" Images hätte man nicht mehr so seine Probleme, wie man sie mit Tags hat (wenn das Bild auf genau gleicher Höhe wie der Absatz dargestellt werden soll - ich half mir damals mit dem Trick, im Bild selbst die oberen Pixelreihen transparent zu machen, somit schien das Bild weiter unten zu liegen).

Hier begegnete ich auch noch einigen Kuriosa, wie zB: AWeb wollte partout nicht einen Abstand machen, wenn auf ein </TABLE> ein folgte. Alle anderen Browser machten jedoch eine Leerzeile. Fügte ich nun ein hinzu, so stimmte bei Aweb alles, aber bei Voyager und IBrowse waren 2 Leerzeilen. Ein ähnliches Problem ergab sich, wenn man nach einem <IMG></CENTER> noch einen Absatz mit am Anfang einfügte: Hier war es wieder AWeb, der zuwenig Space erzeugte. Nun sah ich schon fast keine Möglichkeit mehr, die Seite auf allen Browsern exakt gleich aussehen zu lassen, doch dann bekam ich plötzlich einen Geistesblitz:

Zunächst ersetzte ich "<IMG></CENTER> Text..." durch "<IMG> </CENTER> Text...", was dazu führte, daß jetzt alles überall identisch angezeigt wurde. Also mußte es einen Unterschied machen, ob man textsteuernde Elemente wie gleich nach abgeschlossenen Strukturen einfügt, oder noch kurz vor deren Ende. Dann löste ich das Tableproblem mit "</TABLE>  Text...", welches bei allen Browsern eine Zeile mit einem Leerzeichen erzeugte und keine Leerzeile, da ja nur ein vorhanden war. AWeb "dachte" sich eben, daß ein nur dann eine Leerzeile erzeugen sollte, wenn davor ein Text(absatz) oder ein anderes steht. Also besserte ich auch das "<IMG> </CENTER>" aus in ein "<IMG></CENTER> " (da ein </CENTER> möglicherweise von manchen Browsern wie ein </CENTER> gerendert werden könnte) und noch an vielen anderen Stellen ersetzte ich abstandserzeugende Strukturen durch die sichere "  " - Kombination. Geschafft...

Warum man solche Prinzipien nicht in Büchern nachlesen kann, ist mir immer noch ein Rätsel, stattdessen erklärt man lieber proprietäre Tags und Funktionen die bunte multimediale Ereignisse auf den Bildschirm zaubern, vorausgesetzt der User verwendet genau dieselben Browser wie derjenige, der sich als Ersteller seines "Kunstwerkes" rühmt. Dies sind jedoch nur die Spitzen des Eisbergs, denn ein ganz anderes Kapitel sind zum Beispiel Kommentare in HTML: Hier liest man sogar in Büchern, die bereits in der 2. oder 3. Auflage erschienen sind, daß man Dinge wie  ... --> durchaus basteln darf (und sogar sollte (!)) und dergleichen Schwachsinn mehr, vor allem aber auch in diesen unheimlich vielen schlechten HTML-Kursen, die das WWW "bereichern". Und wer bis hierher aufmerksam alles(!) durchgelesen hat, ist wohl mindestens genauso krank wie ich.

Bernhard Lukas ...........

SelfHTML

BestViewed

....