Welcome to Netscape!

Für ein Projekt recherchiere ich gerade die Anfänge des Webdesigns. Wir moderne Webworker leben ja heute im CSS-Zeitalter und haben es dem Internet Explorer zum Trotz recht bequem, denn CSS ist eine feine Sache. Zuvor gab es aber bekanntermaßen die Präsentationsmarkup-Eiszeit, in der Dinge wie <font> und <center> das beherschende, HTML verhunzende Mittel der Wahl waren. Wie kam es dazu?

Tim-Berners Lee ist jedenfalls nicht schuld daran. Seit es überhaupt Auszeichungssprachen gibt, wusste man, dass die Vermischung von Inhalt und Design keine besonders gute Idee ist und entsprechend hatte HTML auch zu Beginn keinerlei Gestaltungselemente. Nur die User-Styles der Browser sollten Einfluss auf das Erscheinungsbild der Dokumente haben, so etwas wie „Webdesign“ sollte es nie geben. Zu dumm nur, dass man da nicht vorher die Webdesigner (bzw. damals noch schlicht „HTML-Autoren“ genannt) gefragt hatte, die auf den gängigen Mailing Lists massives Lobbying für Gestaltungsmöglichkeiten betrieben. Und so kam es wie es kommen musste: ein Browserhersteller nahm sich kurzerhand der Wünsche der Community an.

Die Volkstribunen von Netscape waren es, die uns Elemente wie <font>, <center> und <hr> geschenkt haben. Aus heutiger Sicht mag die Einführung dieser Elemente wie der große Markup-Sündenfall erscheinen, doch nicht zu vergessen – man hatte damals nichts anderes. Und wenn man einen Blick in das aus heutiger Sicht recht unterhaltsame Handbuch von Netscape 1.0 wirft, sieht man, dass man damals auf diese revolutionären Erfindungen absolut stolz war:

<FONT SIZE=value>
Surprise! You can change the font size!

[…]

<CENTER>
You aren’t dreaming, yes you can center your text!

Klar, heute möchte sich fast niemand mehr mit <font> und <center> herumschlagen, aber wer weiß, was aus dem Web geworden wäre, wenn damals nicht auf diese Art und Weise die Web-Gestaltungsfreiheit überhaupt erst eingeführt worden wäre. Ob dazu unbedingt auch <blink> und <marquee> nötig gewesen wären, sei freilich dahingestellt.

Fun Facts zu Doctypes

17. August 2010, 14:09 Uhr 16 Kommentare · Schreiben

Bis letzte Woche konnte ich nur erahnen, wie es ist, Wissenschafts- oder Politblogger zu sein. Diese bedauernswerten Zeitgenossen werden ja auf Schritt und Tritt von abstrusen Gestalten mit originellen Theorien über das Wesen der Welt verfolgt – Esotriker, Kryptofaschisten, Astrologen, 9/11-Besserwisser. Dann aber kam ein HTML5-Verschwörungstheoretiker auf mich zu, der behauptete beweisen zu können, dass der HTML5-Doctype <!DOCTYPE html>) mindestens so schlimm ist wie Handystrahlen und die jüdische Weltverschwörung, denn der HTML5-Doctype löse ja den Quirks Mode aus! Und wenn so ein dahergelaufener Eumel wie John Resig das Gegenteil behauptet, liegt er eben falsch.

Das Problem ist, dass unser HTML5-Verschwörungstheoretiker nicht nur unrecht hat, sondern in etwa so weit daneben liegt, wie ein 9/11-Thruther, der behauptet, die US-Regierung habe am 11. September 2001 nicht das World Trade Center, sondern den Eiffelturm gesprengt. Denn tatsächlich sind Browsern Art und Inhalt eines Doctypes komplett egal. Sofern am Start einer HTML-Seite irgend etwas steht, das grob nach Doctype aussieht, wird jeder Browser die Seite im Standards Mode rendern. Das Folgende ist formal ungültiger, aber wunderbar funktionierender Doctype (hier in Aktion):

<!DOCTYPE html public "Browsern ist völlig egal was im Doctype steht."
	"Solange da irgendwas steht, was grob nach Doctype-Syntax aussieht, wird Standards Mode verwendet.">

Warum aber ist dem Browser der Doctype so egal? Sehen wir uns einmal einen richtigen Doctype an:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Dieser Doctype besteht aus dem Syntax-Pflichtprogramm (<!DOCTYPE html ...), der Deklaration der hier verwendeten HTML-Variante (XHTML 1.0 Transitional) und einer URL. Diese URL enthält alle Informationen, die der Browser zum Verarbeiten der genannten HTML-Variante braucht. Theoretisch wäre das sehr wichtig, denn threoretisch ist HTML eine SGML-Anwendung. SGML ist so etwas wie der Urahn von XML und HTML stünde demnach in einer solchen Beziehung zu SGML, wie XHTML in Beziehung zu XML steht – das Letztere dient jeweils dazu, Ersteres umzusetzen. In der Theorie müsste man dem Browser als wirklich mitteilen, wo genau er nachlesen kann, wie er die Tags in einer HTML-Seite mit seinem SGML-Parser zu verarbeiten hat. Dieser Informationen findet der Browser unter der im Doctype angegeben URL; die .dtd-Datei enthält eine Liste aller HTML-Tags für den jeweiligen Doctype.

Die Praxis sieht allerdings anders aus. Kein Browser hat je so gearbeitet. Kein Browser hatte je einen SGML-Parser. Kein Browser hat je Doctypes verarbeitet und die .dtd-Dateien heruntergeladen. Es herrschte schließlich in der Anfangszeit des Webs Browserkrieg und man hatte dringenderes zu tun, als korrekte Parser zu implementieren –mit Standards nahm man es schon damals nicht so genau. So entwickelte sich HTML statt zu einer SGML-Anwendung zu einer ganz eigenen Auszeichnungssprache, die eigentlich gar keine Informationen aus Doctypes mehr brauchte. Alle Regeln zu HTML waren und sind auch noch heute fest in die Browser eingebaut.

Und so kommt es, dass Browsern die Inhalte von Doctypes völlig egal sind – Hauptsache es ist überhaupt einer vorhanden. Und folgerichtig funktioniert natürlich der HTML5-Doctype genau so gut wie alle anderen.

Das <wbr>-Element in HTML5

9. August 2010, 12:02 Uhr 23 Kommentare · Schreiben

Das <wbr>-Element ist, soweit ich feststellen konnte, eine Erfindung aus Netscape 4. Was es in HTML5 zu suchen hat weiß ich nicht (es ist nicht nur archaisch, sondern auch recht nutzfrei), aber der Chronistenpflicht wegen habe ich es letzte Woche mal erforscht. Das <wbr>-Element repräsentiert eine Möglichkeit zum Zeilenumbruch, d.h. da wo es steht, kann der Browser einen Zeilenumbruch einfügen, wenn er das brauchen sollte.

Beispiel:

<h1>Mit <code>&lt;wbr&gt;</code></h1>
<p style="width:100px; border:1px solid red;">
	Donau<wbr>dampf<wbr>schiff<wbr>fahrts<wbr>gesellschaft
</p>
<h1>Ohne <code>&lt;wbr&gt;</code></h1>
<p style="width:100px; border:1px solid red;">
	Donaudampfschifffahrtsgesellschaft
</p>

Ergebnis:

Das WBR-Element in HTML5

Der Browsersupport ist recht medium, in Opera und Internet Explorer 8 funktioniert <wbr> nicht, wohl aber in allen anderen Browsern inklusive IE7 und IE6. In Opera lässt sich das Problem relativ einfach fixen, indem man per CSS hinter jedem <wbr> ein Zero-Width-Space einfügt:

wbr:after {
	content: "\00200B"
}

Dieses Leerzeichen ist unsichtbar, trennt aber das Wort auf und ermöglicht so einen Zeilenumbruch wie ein normales Leerzeichen. Im IE8 kann man das gleiche mit JavaScript erreichen:

var wbrs = document.getElementsByTagName('wbr');
var num_wbrs = wbrs.length;
if(num_wbrs > 0 && HTMLTextElement && wbrs[0] instanceof HTMLTextElement){
	for(var i = 0; i < num_wbrs; i++){
		wbrs[i].insertAdjacentHTML('afterEnd', '&#x200b;');
	}
}

Hier ist vielleicht noch bemerkenswert, dass die im JS-Code verwendete insertAdjacentHTML()-Methode seit HTML5 auch erstmals Standard ist, was natürlich nicht heißt, dass sie in einer nennenswerten Anzahl Browser funktioniert.

Das <wbr>-Element ist recht nutzlos, da es zwar Wörter trennt, aber keine Trennstriche einfügt. Das Entity &shy; macht genau das und ist daher vermutlich in vielen Fällen die bessere Wahl:

<h1>Wbr</h1>
<p style="width:100px">
	Donau<wbr>dampf<wbr>schiff<wbr>fahrts<wbr>gesellschaft
</p>
<h1>Shy</h1>
<p style="width:100px">
	Donau&shy;dampf&shy;schiff&shy;fahrts&shy;gesellschaft
</p>

Ergebnis:

Das Shy-Entity und WBR im Vergleich

Allerdings weiß ich aus dem Stand gerade nicht, wie aktuell die Browserunterstützung für &shy; aussieht – was ich aber mal vor Jahren ausprobiert habe, war die Suchmaschinenfrundlichkeit. Hier gibt es keine großen Probleme zu berichten, bis auf die Produkte aus dem Hause Microsoft ignorieren alle Suchmaschinen &shy; und finden auch Keywords, die im HTML entsprechend getrennt sind.

Fazit: auf jeden Fall für mögliche Zeilenumbrüche &shy; verwenden und sich angesichts von <wbr> einfach nur fragen, was die HTML5-Jungs und -Mädels in ihren Pausen eigentlich so rauchen.

Element, Tag, Attribut

Anders als bei der Causa HTML5 gibt es hier keine Ausreden. Wenn das da oben durcheinander gebracht wird, sind Missverständnisse und Chaos vorprogrammiert. So gehet nun hin und lehret den Unwissenden, auf dass man nie wieder rätseln muss, was jemand mit der Strong-Tag überhaupt meint.

« Neuere Artikel  ·  Ältere Artikel »

Hallo!

Dies ist das Blog von Peter Kröner, Webworker aus der Nähe von Osnabrück. Hier geht es um alles rund um Webdesign und Webentwicklung.

Kauft mein Buch!

Das HTML5-Buch
Bei Amazon kaufen

Mehr Infos auf html5-buch.de/

Unterstützt mein Blog!

Wenn dir gefällt was du hier liest, wirf einen Blick auf Flattr und klick‘ die kleinen orangenen Buttons unter den Artikeln an!

Neue Kommentare

Klaus

Zitat Michael ↑: Zitat Klaus ↑: Solche Aussagen sind es die Tür und Tor öffnen für Lohndumping. Man läuft bei allzu flexiblen (vorallem nach unten) Gehaltsvorstellungen Gefahr, dass...

Robert

Da saß ich wirklich verwundert vor der Mashi-Seite, und habe mich gefragt was der Shit soll, bis mir aufgefallen ist, dass das ganze im FF4b nicht läuft, im FF3.6 hingegen...

Axel

Er hat in dem Video fast wörtwörtlich behauptet, dass “Threads in Java eine schlechte Idee waren”. Wie soll man das sonst interpretieren? Das mit den NaNs hat er in...

Axel

Jetzt behauptet er auch noch, dass Threads in Java eine schlecht Idee waren und man sowieso alles mit einem Event Loop ersetzen kann. Der sollte mal dringend über seinen...

Axel

Klar, aber ich habe das Gefühl, er sollte mal bissel zurückschrauben mit seinem Ego. Bei HTML5 hat er übrigens sehr gute Punkte vorgebracht. Aber jetzt ist das Kind eh schon in den...