Warum Websites ohne JavaScript zu funktionieren haben

Veröffentlicht am 9. November 2010

Ich habe noch einen halbfertigen Rant auf Halde, in dem ich am Beispiel eines gewissen, aus unerfindlichen Gründen populären E-Commerce-Systems (dessen Name mit M anfängt und mit agento aufhört) auf Websites schimpfe, die ohne JavaScript nicht funktionieren. Da ich mir aber ziemlich sicher bin, dass ich mich dort gleich mehrfach im Ton vergriffen habe, lösche ich diesen Text jetzt und lasse Jenn Lukas sprechen. Die gute Frau bringt die wichtigsten Gründe nämlich in wesentlich zivilisierterer Form vor, als ich mir das gelingen würde und liefert uns einen schönen kurzen Vortag, den man wunderbar als Munition gegen die meine-Website-muss-ohne-JS-nicht-funktionieren-Fraktion verwenden kann:

Jenn Lukas - JSConf 2010 auf Blip.tv

Alle guten Gründe hin und her – was mich an JS-untauglichen Webseiten mehr als alles irritiert, ist dass es sie überhaupt gibt. Wenn man nur kurz überlegt, bevor man draufloshackt, passieren ohne JS benutzbare Websites wie von selbst. Unobtrusive JavaScript ist kein Hexenwerk, sondern, sofern man seine Auszeichnungs- Gestaltungs- und Script-Schichten sauber trennt, fast unvermeidlich. Um Seiten zu bauen, die nur mit JavaScript funktionieren, muss man sich richtiggehend anstrengen. Und mir ist nicht wirklich klar, was in den Köpfen jener vor sich geht, die sich diese Mühe machen und derartiges HTML an die Öffentlichkeit lassen:

<button type="button" class="button" onclick="productAddToCartForm.submit()"><span><?php echo $this->__('Add to Cart') ?></span></button>

Klar, wenn man ein hyper-dynamisches neues Webapp rund um neueste JavaScript-Features herum konstruiert und das Projekt ohne JS prinzipbedingt nicht funktionieren könnte, wäre das etwas anderes. Aber eine herkömmliche Website oder einen Onlineshop mutwillig oder fahrlässig fest an JS zu binden, ist, als würde man über das Schiebedach in ein Auto einsteigen. Das kann man sicher so machen, aber wenn vorher nur kurz nachdenkt und entsprechend plant, kommt man ohne zusätzliche Mühen auch anders in die Karre – und sieht dabei dann auch nicht aus wie ein Vollhonk.

Keine Angst vor minimalem HTML(5)!

Veröffentlicht am 8. November 2010

Nach all den Jahren, in denen sich XHTML 1 größter Beliebtheit erfreute, sieht für viele Webworker so etwas aus wie ein einziger Syntaxfehler:

<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<p class="welt">Hallo Welt!
<ul>
    <li>Lorem
    <li>Ipsum
    <li>Dolor
</ul>

Da fehlen zwar einige Start- und End-Tags, aber tatsächlich ist das ein absolut gültiges HTML(5)-Dokument. Man kann das gleiche Dokument natürlich auch so schreiben …

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta charset="utf-8" />
        <title>Hallo Welt!</title>
    </head>
    <body>
        <p class="welt">
            Hallo Welt!
        </p>
        <ul>
            <li>Lorem</li>
            <li>Ipsum</li>
            <li>Dolor</li>
        </ul>
    </body>
</html>

… aber hat man etwas davon? Der Browser (jeder Browser) baut aus beiden HTML-Schnipseln das exakt gleiche DOM und damit die exakt gleiche Website zusammen. Tags wie <body> und </li> werden vom HTML-Parser auf eigene Faust an den richtigen Stellen eingebaut, so dass es im Endeffekt völlig egal ist, ob man HTML in der Spar-Variante schreibt, das XHTML-Lookalike nimmt oder sich seine eigene Mischform zusammenkombiniert. Welche Tags man unter welchen Umständen auslassen kann erklären unter anderem die HTML5-Spezifikationen.

Die Präsentation des ersten HTML-Schnipsels sorgt manchmal für erhebliches Gruseln, doch wenn man mal die ersten Abwehrreflexe sieht unaufgeräumt aus und kenne ich nicht überwunden hat, wird klar, dass minimales HTML durchaus seine Vorteile hat: man tippt schließlich weniger und transferiert weniger Bytes zum Browser des Users. Das Einzige, auf das man manchmal aufpassen muss, sind die Inhalte an den Grenzen ausgelassener Tags. Angenommen dies wäre unser HTML:

<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<script>alert("Hello World!")</script>
<p class="welt">Hallo Welt!
<!-- Saluton Mondo! -->

Wo werden hier </head> und </body> eingefügt? Landen der Kommentar und das <script>-Element außerhalb oder innerhalb des Bodys? Die Antwort: das Script landet im Head und der Kommentar als letztes Element im Body. Der Parser schließt den Head erst, wenn er das erste Element antrifft, dass keinesfalls im Head vorkommen kann, was in diesem Fall das <p> wäre. Gleiches gilt beim Kommentar, denn der könnte zwar auch erst nach dem Body kommen, aber der Parser hat keinerlei Anlass, den Body vor dem Kommentar zu schließen. Wenn es bei solchen zweideutigen Elementen wie Scripts und Kommentaren mal wirklich wichtig ist, was in solchen Grenzgebieten wo landet sind die optionalen Tags von unter anderem <html>, <body> und <li> das Mittel der Wahl, aber sonst? Kann man machen, muss man nicht.

Update: Lest das hier um zu verhindern, dass euch fehlende Body-Starttags im IE in den Hintern beißen.

Zur „HTML5-ist-noch-nicht-fertig-Debatte“

Veröffentlicht am 11. Oktober 2010

Im Moment werden aus mir unbekannten Gründen an allen Ecken und Enden des Webs Traktate darüber geschrieben, ob/wann/inwiefern HTML5 „fertig“ oder „einsetzbar“ ist. Dabei ist die Lage eigentlich ganz simpel: HTML5 (was immer man darunter auch versteht) ist in der Tat nicht „fertig“ im Sinne eines Webstandards wie etwa HTML 4.01. Es ist allerdings auch nicht vorgesehen, dass HTML5 je in diesem Sinne „fertig“ sein wird! Der momentane Plan ist, dass es nie ein HTML 6 geben wird, sondern dass alle Neuerungen, die sich die Browserhersteller so ausdenken, nahtlos in HTML5 einfließen – in dem Maße, in dem einige Teile von HTML5 stabiler werden, werden also immer wieder neue Baustellen aufgemacht. HTML5 ist prinzipbedingt nicht „fertig“ und wird es nie sein! Ob und wann man es in Teilen einsetzt, sei jedem selbst überlassen, aber klar ist: vom Abwarten wird es auf keinen Fall besser, stabiler oder fertiger.

„Chroma Corners“ – Fast perfekte runde Ecken im Internet Explorer

Veröffentlicht am 4. Oktober 2010

Ein Gastbeitrag von Christian „Schepp“ Schaefer

Runde Ecken im Internet Explorer – das ist ein Thema, das uns jahrelang beschäftigt hat, um das es aber nahezu still geworden ist, da sich mittlerweile einige Techniken zur Simulation derselben als Best-Practices herausgeschält haben. Heute stelle ich Euch eine neue Technik vor.

Welche Techniken stehen denn bisher zur Auswahl?

Ignorieren

Man zieht sich auf den Standpunkt des „Progressive Enhancements“ zurück und kümmert sich erst gar nicht um eine Lösung für den IE.

Die „Mountaintop Corners“

Vorteil: Schnelle Farbänderungen am Objekt selbst sind problemlos möglich
Nachteil 1: Keine Eckentransparenz, funktioniert also nicht auf texturierten Seitenhintergründen, sondern nur auf flächigen, einfarbigen.
Nachteil 2: Für jede Farbänderung des Hintergrunds müssen neue Eck-Grafiken erstellt werden

„Sliding Doors“ Verfahren

Vorteil: Volle Eckentransparenz, funktioniert also auf texturierten Seitenhintergründen
Nachteil 1: Für jede Farbänderung am Objekt selbst müssen neue Grafiken erstellt werden
Nachteil 2: Nicht in zwei Achsen gleichzeitig flexibel dimensionierbar

VML Image Replacement

Dieses Verfahren ist das Jüngste von allen, und erfährt gerade in der letzten Zeit durch JavaScript-Extensions à la CSS3-PIE eine hohe Aufmerksamkeit. Hierbei wird per JavaScript oder IE-Behavior/.htc-Datei ein Script in die Seite eingebunden, das nach dem Laden der Seite die Stylesheets nach border-radius-Anweisungen durchforstet und HTML-Elemente mit dieser Eigenschaft durch on-the-fly-berechnete VML-Vektorgrafiken ersetzt (vergleichbar mit sFIR oder cúfon).

Vorteile:

  • Eckentransparenz, funktioniert also auf texturierten Seitenhintergründen
  • Hintergrund des Objekts muss nicht einfarbig sein
  • Flexibel dimensionierbar
  • Schnelle Farbänderungen möglich

Nachteile:

  • Arbeitete in den ursprünglichen Implementierungen statisch, reagiert also nicht auf Farb- oder Dimensionsänderungen beim Hover-Zustand, geschweige denn durch dynamisches Scripting.
  • Zieht die Renderperformance des Browser stark in den Keller.
  • Und weitere Nachteile

Wir stellen fest: Jede Technik für sich hat ganz spezifische Vor- und Nachteile. Die VML-Methode bedeutet für uns Webentwickler die wenigste Arbeit, fügt sich aber nicht in den bekannten Seitenkontext ein, bleibt unberechenbar und unperformant. Die Arbeit mit Grafiken dagegen ist berechenbarer und performant (wenn man mal HTTP-Requests ausblendet), ist jedoch unflexibel und arbeitsintensiv.

Müssen wir uns damit zufrieden geben? Haben wir keine besseren Methoden?

Doch, die haben wir! Wir bedienen uns dazu des mehr oder minder im Dornröschenschlaf befindlichen proprietären IE-Chroma-Filters.

Greenscreening im Browser

Den Chroma-Filter muss man sich wie einen Color-Keyer vorstellen, der alle Bereiche eines Objekts, die in einer speziellen Farbe eingefärbt sind, aus diesem herausstanzt. Das Ganze ähnelt also den Bluebox- oder Greenscreen-Verfahren bei Film und Fernsehen, bei denen Darsteller vor einfarbigen Leinwänden agieren, die dann transparent gemacht werden und eine virtuelle Szenerie durchscheinen lassen.

Green Screen Tutorial Video

Mit folgendem Code können wir veranlassen, dass alle cyanfarbenen Teile eines Objekts transparent werden:

filter: progid:DXImageTransform.Microsoft.Chroma(color='cyan'); /* IE 6/7 Syntax */
-ms-filter: "progid:DXImageTransform.Microsoft.Chroma(color='cyan')"; /* IE 8 Syntax */

Anstatt „cyan“ könnte man auch #00FFFF schreiben, und Cyan wurde als Farbe gewählt, weil kein Mensch mit klarem Verstand diese Farbe auf seiner Seite einsetzen würde.

Das Interessante am Chroma Filter ist, dass er auch solche Farbflächen beim Ausstanzen berücksichtigt, welche von Kindelementen des den Chroma-Filter-tragenden Elements stammen.

Deshalb könnte man ein Art roten Rahmen mit 10px Breite mit folgendem HTML erzeugen:

<!DOCTYPE html>
<html>
<head>
	<meta charset="utf-8">
	<title>Chroma Demo</title>
	<style>
	.foo {
		width: 120px;
		background-color: red;
                filter: progid:DXImageTransform.Microsoft.Chroma(color='cyan'); /* IE 6/7 Syntax */
		-ms-filter: "progid:DXImageTransform.Microsoft.Chroma(color='cyan')"; /* IE 8 Syntax */
	}
	.bar {
		height: 100px;
		margin: 10px;
		background-color: cyan;
	}
	</style>
</head>
<body>
	<div class="foo">
		<div class="bar"></div>
	</div>
</body>
</html>

Die komplette Fläche von .bar würde aus dem Filter-tragenden .foo herausgestanzt, da vollständig cyanfarben, und man könnte in der Mitte durchgucken.

Das wollen wir nun für unsere Runden Ecken weiter ausbauen. Wir erstellen eine Hintergrundgrafik von 2048 × 2048 in Photoshop, die voll transparent ist, bei der nur die Bereiche in den vier Ecken cyanfarben eingefärbt sind, welche den Bereich außerhalb der runden Ecken liegend darstellen (also das, was ich später ausstanzen will):

Dann erstelle ich das Objekt, dessen Ecken ich gerne rund hätte, indem ich einige DIVs ineinander verschachtele…

<div class="chroma_base">
	<div class="chroma_topleft">
		<div class="chroma_topright">
			<div class="chroma_bottomright">
				<div class="chroma_bottomleft">Drag me!</div>
			</div>
		</div>
	</div>
</div>

…um dann meine Hintergrundgrafik .chroma_topleft bis .chroma_bottomleft zuzuweisen, jeweils mit unterschiedlicher Positionsverankerung:

.chroma_topleft,
.chroma_topright,
.chroma_bottomright,
.chroma_bottomleft {
	background-image: url(chroma14px.gif);
	background-color: transparent;
	background-repeat: no-repeat;
}
.chroma_topleft {background-position: left top;}
.chroma_topright {background-position: right top;}
.chroma_bottomright {background-position: right bottom;}
.chroma_bottomleft {background-position: left bottom;}

(Anmerkung: Die obigen Anweisungen sollte man per Conditional Comments ausschließlich den IEs <= 8 servieren)

Der aktuelle Zwischenstand (rechte Seite zu Illustrationszwecken abgedunkelt):

.chroma_base bekommt als Root-Element den Chroma-Filter und ein position: relative; (oder absolute), damit alles in den älteren IEs sauber funktioniert. Dazu all die Styles, die mein Objekt abseits der Runden Ecken noch so haben soll, zum Beispiel Ausmaße und ein Hintergrundbild:

.chroma_base {
	position: relative; /* Needed for IE 6/7 */

	width: 200px;
	line-height: 50px;
	text-align: center;
	background: #600118 url(gradientdark.png) repeat-x left top;
	color: #FFF;

	-moz-border-radius: 14px;
	-webkit-border-radius: 14px;
	border-radius: 14px;

	filter: progid:DXImageTransform.Microsoft.Chroma(color='cyan'); /* IE 6/7 Syntax */
        -ms-filter: "progid:DXImageTransform.Microsoft.Chroma(color='cyan')"; /* IE 8 Syntax */
}

Fertig ist die Laube und heraus kommt dies:

Das Schöne dabei ist: nun kann man jederzeit hingehen und nicht nur die Ausmaße sondern auch den Hintergrund ändern, alles ausschließlich per CSS, ohne Rückgriff auf Photoshop. Desweiteren beobachte ich, dass wenn Seiten einen border-radius einsetzen, dass dieser aus Konsistenzgründen meist seitenweit denselben Radius hat. Ergo erschlägt man möglicherweise mit dieser einen Photoshop-Grafik direkt alle Fälle von border-radius auf seiner Seite.

Die Lösung funktioniert sogar, wenn sowohl Seitenhintergrund als auch Objekthintergrund strukturierte Texturen sind. Und sie beißt sich auch nicht mit dynamischen Effekten à la Hover.

Funktioniert das denn auch mit einem Border?

Ja, das tut es! Dazu muss man allerdings die Grafik anpassen, wie auch noch ein paar Styles hinzufügen. Und wir verlieren etwas an Flexibilität und Eleganz.

Legen wir mal einen soliden Border von 2px Breite in der Farbe #808080 zugrunde. Die Grafik müssen wir dann an den Ecken folgendermaßen ergänzen:

Dem Root-Element geben wir diesen Border per CSS:

.chroma_base {
	border: #808080 2px solid;
}

Darüber hinaus müssen wir dem ersten Kind-Element noch Styles überbügeln, die es über den, das Root-Element umgebenden Rahmen schieben lässt.

Für alle IE (per Conditional Comments):

.chroma_topleft {
	margin: -2px; /* root border-width * (-1) */
}

Und zusätzlich für IE6 und IE7 (ebenfalls per Conditional Comments):

.chroma_base * {
	position: relative; /* Needed so that border-overlaping works in IE 6/7 */
	width: 204px; /* root width + (2 * root border-width) */
}

Zusammen mit einem helleren Hintergrund ergibt das folgendes Resultat:

Ebenfalls kann man hier jederzeit nicht nur die Ausmaße sondern auch den Hintergrund ändern, ohne Photoshop starten zu müssen. Die Bildbearbeitung müssen wir allerdings dann bemühen, wenn wir die Border-Farbe ändern wollen, da sie in der Chroma-Grafik fest „verdrahtet“ ist. Wir verlieren in der Border-Variante zudem die Option, dem Element eine fluide (%) Breite zu verpassen, zumindest wenn sie in IE6 und 7 funktionieren soll.

Ich nenne die Technik die „Chroma Corners“ und habe Euch ein Live-Beispiel unter folgender Adresse abgelegt:
http://www.peterkroener.de/test/chroma/ (Download ZIP).

Desweiteren habe ich das Ganze in ein kleines Softwarepaket gegossen, das aus einer proprietären IE-Behavior (.htc) und einem PHP-Script zur automatischen Generierung der Eckgrafiken besteht, die sich zusammen um all das Beschriebene kümmern – für Euch also kein Handschlag mehr zu tun als dies (mit angepastem .htc-Pfad):

-moz-border-radius: 14px;
-webkit-border-radius: 14px;
border-radius: 14px;
behavior: url(chromacorners.htc); /* relative path from HTML-file! */

Und zu guter letzt liegt darauf basierend auch schon ein Turbine-Plugin bereit, das in das nächste Release hineinwandern wird.

Über den Autor

ScheppChristian Schaefer ist Jahrgang '78, hat seine Wurzeln bei Köln, lebt seit 2004 unbehelligt in Düsseldorf, und wird von jedermann außer den Eltern „Schepp“ genannt. Und das ist auch gut so. Es verschlug ihn 1998 ohne Studium direkt in eine 3D-Firma in Köln. Dort entwickelte er virtuelle Figuren für Messen und TV. Selbstständigmachung Anfang 2004 und Verlagerung des Fokus' auf die Webentwicklung. Sieht seine Schwerpunkte bei der Frontend-Entwicklung, hat aber auch kein Problem mit Backends und dem Architekten großer Sites in PHP und MySQL. Fertige CMSe nerven ihn. Frameworks sind OK. Nebenbei unterstützt er technisch den Kölner Multimediatreff, hat gerade ein Videotraining biblischen Ausmaßes fertiggestellt. Er twittert unter dem Account derSchepp und mag alles was sich um Essen dreht.