Wir haben noch einen weiten Weg vor uns. Einen sehr weiten…

Im Shop von xt:Commerce gibt es neuerdings ein CSS-basiertes Template, darauf aufmerksam geworden bin ich aber durch ein Posting im Sponsorenbereich (deshalb auch keinen Link dorthin), wo auch noch zwei Alternativen präsentiert werden.

Leider haben alle drei Templates respektive deren Designer eines gemein: Sie haben es nicht verstanden. Man hat irgendwo mal was aufgeschnappt, dass man Layouts mit Tabellen nicht mehr machen würde und stattdessen CSS das Mittel der Wahl wäre und macht es halt jetzt so, weil es hip ist. Ansonsten hat sich an der Arbeitsweise nichts geändert, der Quellcode ist weiterhin völlig unnötig aufgeblasen, nur die Tags haben sich geändert.

Die beiden kommerziell erhältlichen Templates habe ich mir mal näher angesehen:

• GreenVelvet: Anpassungen mit Samthandschuhen
• i24-cssblau: TABLElos sinnlos

Anpassungen mit Samthandschuhen

Beispiel GreenVelvet, das angesprochene, im xt:Commerce-Shop angebotene Template. Die Zitate sind aus dem xt:Commerce-Shop. Die Rechtschreibfehler auch.

Nahezu tabellebloses (CSS basiertes) Template für den xt:Commerce Shop v3.0.4 SP2! Dieses Template basiert (im Gegensatz zu den Standard-Templates des xt:Commerce Shops) auf der Stylesheet Technologie (CSS)

Die Aussage ist per se schon mal falsch. Auch das Standardtemplate von xt:Commerce nutzt CSS. Davon ab: xt:Commerce wirklich von seinen vielen Layout-Tabellen zu entkernen ist eine Lebensaufgabe. Definitiv. Deshalb nehme ich es auch keinem Designer übel, wenn er die ein oder andere Tabelle, die sich in den Untiefen des php-Codes versteckt und einem eben nicht die Flexibilität gibt, die man sich durch den Einsatz einer Template-Engine verspricht und die einem auch durch entsprechende Werbeversprechen suggeriert wird, nicht rausbekommt.
Aber, nehmen wir als Beispiel die Login-Box, auf deren komplettes Markup in boxes/box_login.html problemlos Einfluss genommen werden kann. Nur Tabellenverschachtelungen aufzulösen, um dann doch Tabellen für Layoutzwecke zu mißbrauchen, ist definitiv am Ziel vorbeigeschossen.

Bis zu 70% weniger HTML Quelltext

Ohne das anhand irgendwelcher Berechnungen belegen zu können: Bei konsequenter Vorgehensweise hätten wir wahrscheinlich 90% weniger Quelltext. Vielleicht sogar noch mehr. Ich hab auch keine Ahnung, auf was sich die Zahl bezieht. Auf das Gesamtprodukt wahrscheinlich nicht, denn dann könnte man da was verbindliches hinschreiben. Kein ‘bis zu’. Die Info-Boxen sind damit jedenfalls nicht gemeint.

Große Töne spucken kann jeder, deshalb hier Handfestes:

Das ist der Originalcode aus dem Demoshop.

<table width="100%" border="0" cellpadding="2" cellspacing="0">
	<tr>
		<td class="infoBoxHeading_right"><table width="100%"  border="0" cellpadding="0" cellspacing="0">
			<tr>
				<td class="infoBoxHeading_right">Willkommen zurück! </td>
				<td> </td>
			</tr>
		</table></td>
		</tr>
		<tr>
			<td class="infoBox_right" align="left"> <table width="95%"  border="0" cellpadding="2" cellspacing="0">
		<tr>
			<td class="boxText"><form id="loginbox" method="post" action="http://www.xtc-demo.de/login.php/action/process/"><input type="hidden" name="XTCsid" value="" />
			<table width="100%"  border="0" cellpadding="0" cellspacing="0">
				<tr>
					<td class="main">eMail-Adresse:</td>
				</tr>
				<tr>
					<td><input type="text" name="email_address" size="25" maxlength="50" /></td>
				</tr>
				<tr>
					<td class="main">Passwort:</td>
				</tr>
				<tr>
					<td><table width="100%"  border="0" cellpadding="2" cellspacing="0">
						<tr>
							<td><input type="password" name="password" size="10" maxlength="30" /> </td>
							<td><input type="image" src="templates/xtc4/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " /></td>
						</tr>
					</table></td>
				</tr>
			</table></form></td>
		</tr>
		</table></td>
	</tr>
	<tr>
		<td class="infoBox_right" align="right"><a href="http://www.xtc-demo.de/password_double_opt.php/">Passwort vergessen?</a></td>
	</tr>
</table>

Übel. Aber soll ja eh nur als abschreckendes Beispiel dienen.

In GreenVelvet sieht das jetzt so aus:

<div class="boxVarianteZweiHeader">Willkommen zurück!</div>
<div class="boxVarianteZweiBody" style="margin-bottom:15px;">
<form id="loginbox" method="post" action="http://www.xtc-demo.de/login.php/action/process/"><input type="hidden" name="XTCsid" value="" />
<table width="100%"  border="0" cellpadding="0" cellspacing="0">
	<tr>
		<td>eMail-Adresse:</td>
	</tr>
	<tr>
		<td><input type="text" name="email_address" size="25" maxlength="50" /></td>
	</tr>
	<tr>
		<td style="padding-top:6px;">Passwort:</td>
	</tr>
	<tr>
		<td><table width="100%"  border="0" cellpadding="0" cellspacing="0">
			<tr>
				<td style="padding-right:4px;"><input type="password" name="password" size="10" maxlength="30" /> </td>
				<td width="100%"><input type="image" src="templates/GreenValvet/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " /></td>
			</tr>
		</table></td>
	</tr>
	<tr>
		<td style="padding-top:8px;"><hr /><a href="http://www.xtc-demo.de/password_double_opt.php/">Passwort vergessen?</a></td>
	</tr>
</table>
</form>
</div>

Ich bin Brillenträger seit Geburt. Es könnte durchaus sein, dass ich den Vorteil des ganzen rein optisch nicht sofort erfasse. Aber was zum Geier will ich mit dem Inline-CSS, das mir bei späteren Designanpassungen nur unnötig Arbeit und Probleme verursacht? Und mit dem unnötigen Blocklevel-Element, mit dem ein anderes Blocklevel-Element eingeschlossen wird? Und was will ich mit dieser Tabelle? Von der nicht vorhandenen semantischen Relevanz der eingesetzten Tags mal ganz zu schweigen.

<form id="loginbox" method="post" action="http://www.xtc-demo.de/login.php/action/process/"><input type="hidden" name="XTCsid" value="" />
	<fieldset>
		<legend>Willkommen zurück!</legend>
		<p>
			<label for="field_email">eMail-Adresse:</label>
			<input type="text" name="email_address" size="25" id="field_email" maxlength="50" />
		</p>
		<p>
			<label for="field_password">Passwort:</label>
			<input type="password" name="password" size="10" id="field_password" maxlength="30" />
		</p>
		<p>
			<input type="image" src="templates/GreenValvet/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " />
		</p>
		<p>
			<a href="http://www.xtc-demo.de/password_double_opt.php/">Passwort vergessen?</a>
		</p>
	</fieldset>
</form>

Man kann jetzt darüber streiten, ob man unter semantischen Gesichtspunkten eine sortiere Liste anstatt der <p>-Tags einsetzt. Aber man kann es auch übertreiben mit Listen.
Den Submit-Button lassen wir mal so. Um mit <button> weitreichendere Gestaltungsmöglichkeiten zu haben und nicht zwanghaft das Bild im Markup platzieren müßten, würde weitreichende Änderungen in der Shopsoftware erfordern.
Die Formatierung wird komplett per CSS geregelt, um aber z.B. den Submit-Button rechts vom Passwort-Feld zu haben, müsste man noch ein paar Klassen zuweisen.

Kommen wir jetzt aber zum Schwanzvergleich:

Der Originalcode liegt bei 1434 Byte, die GreenVelvet-Variante schafft es immer noch auf 1055 Bytes, was π mal Daumen 73,5% der Originalgröße sind (damit liegt das Einsparpotential bei weniger als 30%!). Mein Code kommt auf 756 Bytes. Damit habe ich den kleinsten. Code, wohlgemerkt. Und gleichzeitig mit fast 50% das größte Einsparpotential (47,3% für die Nietenzähler). Und das ist nur ein Beispiel von vielen.

Alle Menüpunkte sind in Listenform abgebildet und können mit wenigen Schritten im Stylesheet angepasst werden

<div id="submenu" style="margin-bottom:15px;">
	<a class="header">Kategorien</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c4_Onlineshops.html/">Onlineshops</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c1_Shopsoftware.html/">Shopsoftware</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c2_Shopsysteme.html/">Shopsysteme</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c3_E-commerce.html/">E-commerce</a>
</div>

Hat jemand die Liste gesehen? Die muss irgendwo auf dem Weg abhanden gekommen sein. Das gilt analog für so ziemlich alle übrigen Navigationen auch. /boxes/box_content.html, /boxes/box_information.html, /boxes/box_best_sellers.html, alles keine Listen, aber optisch auf Liste getrimmt. Die einzige wirkliche Liste ist die Top-Navigation. Aber entweder muss ich das unter Lernresistenz verbuchen oder einfach unter Unwissen.

Das ganze soll, wenn es fertig ist, mal so aussehen:

<ul id="horizontalmenu">
	<li class="link"><a href="http://www.xtc-demo.de/shopping_cart.php">Warenkorb</a></li>
	<li><img src="img/menuspacer.gif" alt="Menabstand" width="2" height="36" style="border:none; padding:0px; margin:0px; line-height:0px; display:block;"/></li>
	<li class="link"><a href="http://www.xtc-demo.de/account.php">Ihr Konto</a></li>
	<li><img src="img/menuspacer.gif" alt="Menabstand" width="2" height="36" style="border:none; padding:0px; margin:0px; line-height:0px; display:block;"/></li>
	<li class="link"><a href="http://www.xtc-demo.de/checkout_shipping.php">Kasse</a></li>
	<li><img src="img/menuspacer.gif" alt="Menabstand" width="2" height="36" style="border:none; padding:0px; margin:0px; line-height:0px; display:block;"/></li>
</ul>

Unnötige Klassenzuweisungen, Inline-CSS und sinnlose Alternativtexte für Platzhalter, bei denen ich mir gar nicht vorstellen will, wie sie ein Screenreader artikuliert. Ich hatte nicht erwartet, heutzutage noch so viel Blödsinn auf so wenig Raum zu sehen…
Dazu kommen dann noch 41 Zeilen CSS, die den Rest der Formatierung übernehmen.

Horizontales Menü mit Originalcode

Man kann das ganze aber auch mit fünf Zeilen Markup und ohne Inline-CSS oder irgendwelche Spacer-Einträgen realisieren:

Modifiziertes Horizontales Menü (aka Horizontales Menü reloaded)

Ich habe die in Pixeln definierte Schriftgröße mal dringelassen, der Vergleichbarkeit wegen. Und ja, ich benutze line-height, um eine vertikal zentrierte Ausrichtung von Text zu erreichen. Denn die vertikale Ausrichtung ist nach wie vor eine der (Kinder-)Krankheiten von CSS.

Inklusive sämtlicher Darstellungs- Bugfixes für den Internet Explorer!

Alle im einen globalen Stylesheet. Realisiert durch den Underscore-Hack. Damit auch die Browser, die diese Hacks nicht brauchen, genötigt werden, sie mit zu laden. Mit Conditional Comments wär’ das nicht passiert.
Und die Hacks hätte man sich wahrscheinlich sogar sparen können, wenn man gleich zu Beginn die Standardwerte der Browser für paddings, margins und borders zurückgesetzt hätte:

* {
	margin: 0;
	padding: 0;
	border: 0;
}

Da hat sich einer wirklich Mühe gegeben. Die hätte er sich aber auch sparen können. So ist das Template um keinen Deut besser als das standardmäßig beiliegende…

TABLElos sinnlos

(Ja, die Überschrift ist geklaut)

Die Idee, die Layout-Tabellen aus xt:Commerce zu verbannen ist ja nicht neu. Auf die YAML-Implementierung für xt:C hatte ich ja schon hingewiesen. Und natürlich haben auch andere Anbieter fertiger xt:C-Templates entsprechende Pferde im Stall. i24-cssblau ist so eines.

Vom Ansatz her wirkt das ganze vielversprechend. Die Überschriften der Boxen sind dank <h3>-Auszeichnung auch als solche zu erkennen, Navigationselemente in den Boxen sind beispielsweise als Liste ausgezeichnet und die notwendigen Styles für den Internet Explorer werden über Conditional Comments eingebunden. Die Benamung und der Aufbau der Stylesheets legt den Schluss nahe, dass das ganze auf YAML basiert, steht nur nirgends. Sollte es aber, wenn es denn so ist.

Schaut man gezielt unter die Haube, fallen dann aber doch einige Ungereimtheiten ins Auge.

Das fängt mit der zentrierten Ausrichtung des Layouts an, die mit einem

<div align="center">
</div>

direkt nach dem Body erreicht wird, im CSS findet sich für #hauptrahmen aber auch die übliche Vorgehensweise mittels

#hauptrahmen {
	margin: 0 auto;
}

Doppelt gemoppelt hält besser…

Auch die Überschriften sind nicht wirklich logisch aufgebaut. So sind zwar die Boxen-Überschriften als </h3> ausgezeichnet, Überschriften erster Ordnung werden mehrfach verwendet (was zumindest vom Validator nicht bemängelt wird, der prüft ja aber auch auf Syntax, nicht auf Logik), dafür fehlen Überschriften zweiter Ordnung gänzlich.

Die Navigation in den Boxen ist, wie schon erwähnt, mit Listen gelöst. Allerdings werden die Unterkategorien nur optisch eingerückt, die Listen sind nicht korrekt ineinander verschachtelt. Wie das geht, steht hier. Die Top-Navigation wurde dabei glatt vergessen:

<div id="topmenu">
<a href="http://www.shop.xtc-services.de/account.php">Ihr Konto</a> | <a href="http://www.shop.xtc-services.de/shopping_cart.php">Warenkorb</a> | <a href="http://www.shop.xtc-services.de/checkout_shipping.php">Kasse</a>
</div>

Bis zu 70% weniger HTML Quelltext, dadurch sind Wesentlich geringere Ladezeiten der Shopseiten möglich.

Wieder die Loginbox als Vorlage nehmend kommen wir hier nur noch auf 718 Bytes, was in etwa 50% der originalen Größe sind (das hidden-Feld wurde für die Vergleichbarkeit hinzugefügt). Ich bin geschlagen, kann damit aber leben.

<div class="box_header_right"><h3>Willkommen zurück!</h3></div>
<div class="box_center_right">
	<form id="loginbox" method="post" action="http://www.shop.xtc-services.de/login.php?action=process"><input type="hidden" name="XTCsid" value="" />
		eMail-Adresse:<br />
		<input type="text" name="email_address" size="25" maxlength="50" /><br />
		Passwort:<br />
		<input type="password" name="password" size="10" maxlength="30" /><br />
		<input type="image" src="templates/i24-cssblau/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " /><br />
		<span style="text-align: right;"><a href="http://www.shop.xtc-services.de/password_double_opt.php">Passwort vergessen?</a></span>
	</form>
</div>

Es wird keinerlei Zuordnung der Label-Texte zu den zugehörigen Feldern vorgenommen, Inline-CSS sorgt für eine rechtsbündige Ausrichtung des Textes und das Blocklevel-Element <form> steht nach wie vor in einem <div>-Container und auch die Überschrift ist unsinnigerweise in einem solchen eingeschlossen. Dieses zwanghafte Verschachteln erinnert an Tabellenlayouts, ist unnötig und zieht sich konsequent durch das gesamte Design.

Apropos Tabellen, die sucht man in der Tat vergebens.

Das Template ist ein reines CSS Template ohne eine Tabelle.
Es wurden aus allen Template Dateien alle Tabellen entfernt.

Das kann man wörtlich nehmen. Es wurden rigoros und ohne Rücksicht auf Verluste alle Tabellen entfernt. Auch dort, wo sie durchaus Sinn machen. Wir erinnern uns: Tabellen nutzt man zum Darstellen tabellarischer Inhalte. Und die gibt es beispielsweise im Warenkorb. Ohne Tabellen sieht das dann so aus:

<span style="width:10%; display: block; float:left;"><strong>Anzahl</strong></span>
<span style="width:44%; display: block; float:left;"><strong>Artikel</strong></span>
<span style="width:20%;  display: block;float:left;"><strong>Einzelpreis</strong></span>
<span style="width:20%;display:block;float:left; "><strong>Summe</strong></span>
<span style="width:5%;display:block; float:left;"><strong>X</strong></span>
<span style="clear: both;"></span>
<br />
 
<div class="cartbg1">
	<span style="width:10%; display: block; float:left;"><input type="text" name="cart_quantity[]" value="1" size="2" /><input type="hidden" name="products_id[]" value="1" /><input type="hidden" name="old_qty[]" value="1" /></span>
	<span style="width:44%; display: block; float:left; ">
		<strong><a href="http://www.shop.xtc-services.de/Individual-Designs/Individual-XTC-Template-Light::1.html">Individual XTC Template Light</a></strong>
		<br />
 
	</span>
 
	<span style="width:20%;  display: block;float:left;"> 95,00 EUR</span>
	<span style="width:20%;display:block;float:left; "> 95,00 EUR</span>
	<span style="width:5%;display:block;float:left; "><input type="checkbox" name="cart_delete[]" value="1" /></span>
	<span style="clear: both;"></span>
	<br />
 
</div>

Das ist, gelinde gesagt, der größte Schwachsinn, der mir in 10 Jahren CSS je untergekommen ist.

Und als ob das noch nicht genug wäre kommen unverzeihliche Usability-Fehler hinzu. So lassen sich die Produktbeschreibungen und zusätzliche Bilder erst durch einen Klick einsehen, über Javascript wird dabei das jeweilige Element auf sichtbar geschalten. Bei deaktiviertem Javascript schaut man in die Röhre. Darüber hinaus ist die angedeutete Tabnavigation mit Bildern gelöst. Warum sich der Mauszeiger beim Überfahren eben dieser in einen Hilfe-Cursor wandelt, erschließt sich auch nicht.

Dabei ist eine Tabnavigation mit CSS wirklich kein Hexenwerk, zumal wenn es um stinknormale, eckige Tabs geht.

Wenn das die Antwort auf tabellenbasierte Layouts sein soll, dann wollen wir hoffen, das sie möglichst schnell ungehört verhallt. Auf der anderen Seite zeigt es auch, das Seiten wie Webkrauts, Vorsprung durch Webstandards und alle anderen weiter machen müssen mit ihrer Aufklärungsarbeit, um allen Beteiligten nahezubringen, das eine Website nicht zwangsläufig deshalb eine bessere Website ist, weil sie keine Tabellen mehr verwendet. Selbst die Tatsache, das eine Website validiert, ist schließlich kein Qualitätsmerkmal, wie das Beispiel iWeb deutlich zeigt. Zu modernem Webdesign gehört definitiv mehr als Tags in einen Editor zu tippen, die nicht mit <t beginnen.

Ich bin zwar etwas früh dran, aber wenn es etwas gibt, das ich mir 2007 wünsche, dann sind es Webdeveloper, welche die ihnen an die Hand gegebenen Werkzeuge vernünftig einzusetzen wissen und nicht, weil sie irgendwo was aufgeschnappt haben, das alte Chaos mit neuen Tags und Attributen versehen.

[tags]xhtml, css, webdevelopment, webstandards, accessibility[/tags]