Der späte Siegeszug von Javascript

Der Trend des Jahres 2006 waren in meinen Augen ganz klar Javascript-Frameworks. Die schiere Menge an wirklich gut gemachten Klassensets ist geradezu erschlagend. Neben dem Platzhirsch Prototype haben die "jungen Wilden" wie jQuery, YUI, Mootools und Konsorten kräftig aufgeholt. Inzwischen kann man dank der findigen Framework-Entwickler jedes Webprojekt mit wenigen Handgriffen um viele sinnvolle und natürlich auch sinnfreie Gimmicks anreichern.

Es ist absolut fantastisch zu sehen, wie aus den "Scripts" der letzten Jahre auf einmal Objekt-Orientierte Klassen, mit komplexer Vererbung, Erweiterung und allem was dazugehört, wurden. Eine Sprache, die eigentlich längst als nutzlos und teilweise sogar als böse verstanden wurde, ist auf einmal salonfähig und sogar sehr gefragt. Fast keines der "großen Portale" hat im vergangen Jahr darauf verzichtet, sich, mit Javascript im Allgemeinen und Ajax im Besonderen, eine Frischzellenkur zu verabreichen.

Dieser frische Wind ist einer der treibenden Kräfte des "Web 2.0" und wird wohl (im Gegensatz zu dem Begriff, den schon jetzt keiner mehr hören mag) auch weiterhin für Furore sorgen.

Dirk Ginader

Webstandards mit Frameworks

Der Trend zu Frameworks (Rails, Django, CakePHP usw.), weil dadurch Entwickler eine vollständige Kontrolle über die Einhaltung von Webstandards bekommen. Bei vielen CMS oder deren Plugins war bzw. ist dies häufig nur durch die Modifikation des Cores möglich. Man muss also Code jenseits der Templates modifizieren, um zum gewünschten Ergebnis zu kommen.

Kai Schaper

Websites analysieren mit Firebug

Das mit Abstand wichtigste Tool bei der Entwicklung von Websites ist für mich Firebug geworden, eine spektakuläre Erweiterung für den Firefox-Browser, mit dem man die DOM- und CSS-Struktur unglaublich einfach und schnell analysieren kann. Ein JavaScript-Debugger ist auch mit dabei, und viele weitere nützliche Funktionen wird die Version 1.0 mit sich bringen. Ohne Firebug fasse ich inzwischen keine Website mehr an, und mit dieser Meinung bin ich nicht alleine!

Gerrit van Aaken

Jede Menge

Trend: Web 2.0, AJAX, Weblogs

Ereignis: Webmontag, Barcamp, Geektogether

Produkte: YAML

Buch: Little Boxes von Peter Müller (Jaa, man kann auch interessante, nichttechnische Bücher über Webdesign und CSS schreiben, die trotzdem lehrreich und gut zu lesen sind…und auch noch Spaß machen!)

CD/DVD-Schulungen:

1. CSS for Designers von Andy Clarke und Molly Holzschlag, erschienen bei Lynda.com (Lynda Weinman)
2. Die Kunst des CSS-Designs von Cornelia Lange, erschienen bei Addison-Wesley

Browser: Internet Explorer 7

Arne Kriedemann

It's all so Two-Oh

Im Jahr 2006 besonders beeindruckt hat mich der große Web2Null-Boom an verschiedenen Plattformen und Möglichkeiten. Beispiele wie StudiVZ, die Videocommunitys oder die verschiedensten Webangebote, besonders auch der stetige Ausbau beispielsweise vom Webdienst Google zeigt, dass sich immer mehr Kommunikation und Arbeit ins Web verlagert.

Täglich starten neue Web2Null-Angebote. Im Gegensatz zum Vorjahr für mich eine klarer Angebotssteigerung, die aber manchmal auch die Sicht auf die wirklich guten Dienste versperrt.

Johannes Ries aus Kahl am Main schreibt unter metafakten.de über Netzgeschehen und freie Software

Warten aufs X

Im Bezug auf Webstandards war das besonders die Ankündigung, dass XHTML zugunsten von HTML erst einmal zurückgestellt wird und nun eine neue HTML-Version geplant ist. Das Web ist aufgrund der derzeitigen Browserdominanz durch den Internet Explorer für XHTML einfach noch nicht bereit. Leider.

Markus Wulftange

Besuche in der realen Welt

Webmontage und Barcamps waren eine willkommene Gelegenheit Leute zu treffen, die man eigentlich nur in der virtuellen Welt kennt. Das fand ich beeindruckend, vor allem wenn dies in lockerer Atmosphäre geschieht und nicht zu businesslastig wird. Beeindruckt bin ich außerdem von MacOS, ein Betriebssystem, das fast inspirierend wirkt.

Eric Eggert studiert Medieninformatik an der Uni Wien und schreibt unter yatil.de

Neue Äpfel

2006 ist auch das Jahr des Macintosh. Apple hat es geschafft, in guten halben Jahr die komplette Produktpalette auf x86-Prozessoren umzustellen. Erstaunlich war dabei auch, wie reibungslos der Umstieg geklappt hat. Die meisten PowerPC-Programme funktionieren problemlos auch auf Intel-CPUs und viele Softwarehersteller haben inzwischen schon Universal Binaries veröffentlicht. Hier zeigt sich auch, dass das Festhalten an alten Überbleibseln nicht immer gut ist. Zwar wurde eine gewisse Rückwärtskompatibilität eingebaut (Rosetta), aber letztlich führt doch kaum ein Weg daran vorbei, die Programme an die neue Architektur anzupassen.

Ähnliches würde auch dem Web gut tun. Es lebt vom Fortschritt. Manchmal ist es besser, einen großen, möglicherweise unangenehmen Schritt zu wagen – bereuen wird man nicht, aber man hat Angst davor.

Konstantin Käfer

Zoom to Doom

Der Vergrößerungs-Effekt beim Internet Explorer 7.
Nein, beeindruckt ist vielleicht nicht das richtige Wort: erschüttert trifft es eher. Mit der neuen Version 7 ist der Internet Explorer in Lage, Webseiten zu vergrößern. Soweit so gut. Leider vergrößert er nicht nur die Schriften, sondern auch die Bilder, schlichtweg alles.

Das Tragische daran ist, dass mit der großen Verbreitung, die der IE7 im nächsten Jahr erfahren wird, das Konzept der flexiblen Layouts ad absurdum geführt wird. Flexible Layouts sind darauf ausgerichtet, dass – im Normalfall – lediglich die Schriften vergrößert werden. Wenn der IE nun durch die Bank weg alles vergrößert, also sowohl Schriftgrößen als auch Abstände, Bildern und Grafiken, sind flexible Layouts überflüssig.

Nicolai Schwarz betreibt die kleine Agentur textformer mediendesign in Dortmund

CSS allein kann nicht soo viel…

Diese “CSS only”-Lösungen sind ganz tolle technische Beispiele, aber im echten Anwendungsbereich auch großer Unfug. Ich habe mich lang und breit darüber in einem englischen Artikel ausgelassen, doch hier sind die Hauptgründe:

• CSS hat nur eine Möglichkeit um dynamische Effekte zu erstellen: Pseudoselektoren wie :focus und :hover. Microsoft Internet Explorer versteht diese nur für Links und Textfelder.
• CSS hat nur eine begrenzte Möglichkeit zusätzliches HTML und Inhalte zu erstellen, wenn sie nötig sind, und ein dynamisches Menü sollte weder JavaScript noch CSS zwangsweise erfordern.
• CSS kann nur binär ein- oder ausschalten, in JavaScript kann man Effekte zeitlich verzögern, um es dem Besucher zu erlauben, auch mal mit der Maus auszurutschen.
• Es gibt keine Möglichkeit zu testen ob CSS eingeschaltet ist, was bedeuten kann, daß man den Besucher mit viel zu vielen Links verwirrt.

JavaScript kann viel mehr…

JavaScript dahingegen kann einiges mehr was CSS nicht kann:

• Mittels des DOM und BOM kann man das Dokument nach Belieben verändern und erweitern.
• Mittels timeout() kann man Besuchern erlauben Fehler zu machen.
• Mittels Event Handling kann man auf alles, was im Dokument passiert, reagieren – egal ob das per Maus oder Tastatur geschieht.
• Ich kann in JavaScript jederzeit überprüfen ob das, was ich erreichen will, auch von dem Anzeigeprogramm unterstützt wird. Wenn das der Fall ist, kann es losgehen, ansonsten nicht (der klassische Fall von “Tiefe des Wassers prüfen bevor man reinspringt”)
• Ich kann Daten, die nur mit CSS und JavaScript Sinn machen, per Ajax laden, nachdem die eigentliche Seite geladen ist.

Gemeinsam sind sie stark!

Diese Pro-JavaScript-Punkte bedeuten allerdings nicht, daß man nur JavaScript verwenden sollte, sondern wann immer möglich den CSS-Parser seine Arbeit erledigen lassen.

Hier ein paar Beispiele wie JavaScript und CSS zusammen arbeiten können:

Ist CSS eingeschaltet?

Einer der Hauptpunkte, den selbsternannte Barrierefreiheit-Sheriffs immer gerne anbringen, ist, daß Produkte nicht funktionieren, wenn JavaScript eingeschaltet, aber das passende CSS nicht erreichbar oder durch ein User Style Sheet überschrieben wurde.

In JavaScript ist es allerdings mit einem kleinen Trick ganz einfach möglich zu überprüfen, ob ein Style Sheet geladen wurde. Der Trick ist, die Höhe oder Breite eines Elementes (was extra dafür angefügt werden kann oder eines, das sowieso auf der Seite ist) zu definieren:

#ichkannCSS{height:20px;}

Dann überprüft man in JavaScript, ob die offsetHeight beziehungsweise offsetWidth des Elementes den gleichen Wert hat:

var CSStestDingen = document.getElementById(‘ichkannCSS’);
if(CSStestDingen !== undefined){
  if(CSStestDingen.offsetHeight === 20){
     // hier wird CSS gekonnt!
  } else {
    // der kann fei kei CSS ned.
  }
}

Unterschiedliches Styling für JavaScript- und nicht-JavaScript-Versionen

Oft ist es nötig, daß die Seite mit und ohne JavaScript unterschiedlich daherkommt – gerade wenn man beispielsweise eine Liste in ein Menü verwandelt. Die einfachste Möglichkeit ist es, in JavaScript, nachdem die Seite geladen wurde, eine CSS Klasse an das BODY-Element anzufügen und es damit dem CSS-Designer zu erlauben, zwei verschiedene Styles zu erstellen.

window.onload = function(){
  var klasse = document.body.className ? ‘ dynamisch’:’dynamisch’;
  document.body.className = klasse;
}

Natürlich gibt das die normalen Ladeprobleme und man sollte statt eines onloads eben addEvent verwenden. Mehr dazu gibt es bei “Barrierefreies JavaScript” nachzulesen.

Schnelleres JavaScript als Gratiszugabe

Diese Technik hat auch noch einen anderen Vorteil: Man kann die schwere Arbeit, Teile der Seite zu verstecken, dem CSS-Parser überlassen, der dafür erstellt wurde. Wenn man ältere JavaScripte analysiert, findet man des öfteren solche Schoten:

var n = document.getElementById(‘nav’);
if(n!==undefined){
  var uls = n.getElementsByTagName(‘ul’);
  for(var i=0; i<uls.length;i++){
    uls[i].style.display = ‘none’;
  }
}

Schleifen sind hübsch im Haar, doch machen Sie JavaScript langsam, und wenn man Sie vermeiden kann, sollte man das tun.

Mit einer BODY-ID kann man diese Schleife durch eine Zeile im CSS ersetzen:

body.dynamisch #nav ul {display:none;}

Hausaufgabe

Als Hausaufgabe bitte ich darum, einige “CSS only”-Lösungen mal mit der Tastatur oder einer wackligen Maus zu testen und generell darüber nachzudenken, wie praktisch doch gute JavaScript Lösungen sind, die es dem Designer erlauben, sie einfach im Style Sheet anzupassen und neu zu gestalten.

Zum Autor

Christian Heilmann lebt seit 1999 im Ausland (USA, England, Indien) und arbeitet derzeit als lei(d|t)ender Entwickler bei Yahoo! in London, England. In seiner Freizeit bloggt er bei wait-till-i.com und schreibt Bücher für Apress und Friends Of Ed.

Fast jeder kennt das, man ist bei Bekannten, hat ein oder zwei Gläschen Wein (wahlweise auch Bier) getrunken, und möchte nun bald heimfahren. Doch natürlich hat man keine Ahnung wann der ÖPNV Richtung Heimat geht. Der Bekannte hat aber leider gerade nicht die Möglichkeit ins Internet zu schauen. Es wäre also jetzt ein leichtes, mit dem Handy samt eingebauten Browser die elektronische Fahrplanauskunft anzusurfen, und sich bequem den nächsten Bus zu suchen.

Leider spielen auch in Zeiten des WAP 2.0 die wenigsten Internetseiten da mit. Zwar erlauben es moderne Mobilgerätebrowser wie der Opera Mini oder der Minimo mittlerweile auch rein für das Web optimierte Seiten auf Handys etc. anzuzeigen, dennoch sind diese oft aufgrund großer Datenmengen oder vorausgesetztem JavaScript nur mit Einschränkungen benutzbar.

Dabei muss in einen Webauftritt, der für mobile Geräte angepasst werden soll, nicht einmal viel Aufwand gesteckt werden. Der angesehene amerikanische Entwickler Cameron Moll spricht dabei von 4 Methoden:

1. Nichts tun
2. Styling von Elementen entfernen und ungestaltetes HTML ausgeben
3. Angepasste media="handheld"-Stylesheets verwenden
4. Inhalte, Code und Bilder speziell für Benutzer mobiler Geräte anpassen

All diese Methoden haben Vor- und Nachteile, auf die hier kurz eingegangen werden soll.

Nichts tun und hoffen

Natürlich macht es am wenigsten Aufwand, nämlich ziemlich genau gar keinen, wenn man eine Seite nicht für mobile Browser optimiert, und darauf hofft, dass ein Benutzer von Handys oder PDAs alle relevanten Informationen auch ohne eine spezielle Anpassung findet. Wenn alles gut verläuft, so findet der User sogar genau die Informationen, welche er beim surfen mit dem Webbrowser vorfindet. Die Seite wird somit sozusagen „unverfälscht“ auf dem Handy wiedergegeben. Allerdings wird bei dieser Methode auch am wenigsten auf die Bedürfnisse von eben solchen Benutzern eingegangen. Es werden unter Umständen eine Menge an unnötiger Daten, große Bilder, Stylesheets, aufgeblähter Code und so weiter übertragen. Das verursacht dem Benutzer auch in der heutigen Zeit noch recht hohe Übertragungskosten. Ein wenig freundlicher ist da schon die nächste Methode.

„Rohes“ HTML ausgeben

Bei dieser Methode, bei der die Website im Optimalfall zwischen Inhalt (HTML) und Styling (CSS) trennt, wird auf sämtliche Stylesheets verzichtet, der Handheld-Browser somit dazu gebracht browsereigene Stildefinitionen beim Rendern der Seite zu benutzen. Dies spart zumindest ein wenig Code ein, da keine extra Stylesheets, und somit auch keine möglicherweise definierten, speicherintensiven Hintergrundbilder geladen werden müssen. Doch auch hier besteht die Seite eigentlich aus gewöhnlichem HTML Output, welcher in der Regel für die Ausgabe am Bildschirm erstellt wird.

Handheld-Stylesheets einbinden

Eine bessere Variante ist, ein Stylesheet für Mobilgeräte zu optimieren, und dieses für nur eben solche Geräte, mittels media="handheld"-Attribut mit in die Seite einzubinden. Das bietet uns den Vorteil unnötige Elemente ausblenden zu können oder speicherintensive Bilder gar nicht erst laden zu lassen. Der User muss sich somit auch keine zusätzliche Adresse merken (beispielsweise eine Subdomain wie mobile.google.com oder google.com/mobile) und das Prinzip der Geräteunabhängigkeit von Dokumenten bleibt somit außerdem gewahrt. Dennoch muss man bei dieser Methode beachten, dass das media="handheld"-Attribut teilweise immer noch unzureichend unterstützt wird, und selbst dann auch nur einige wenige CSS-Eigenschaften letztendlich vom Browser korrekt interpretiert werden. Der Entwicklungs- und Wartungsaufwand hält sich aber auch bei dieser Methode noch in Grenzen.

Eigenen Content, Code und Bilder für mobile Geräte

Die vierte und somit auch letzte Methode ist wohl die, mit meisten Vor- aber auch Nachteilen. Nämlich die Bereitstellung von eigenen Inhalten speziell für Handhelds. Hierbei wird der Code von allen, für die mobile Darstellung irrelevanten Seitenelementen bereinigt. Beispielsweise werden wohl kaum „Seite drucken“ Links, Bilder in hoher Auflösung und dergleichen auf kleinen Handydisplays benötigt. Der Aufwand ist bei dieser Methode wohl am höchsten, da der Entwickler hierbei für gewöhnlich 2 verschiedene Seiten entwickeln muss. Dies widerspricht außerdem dem Prinzip der geräteunabhängigen Erstellung von Dokumenten für das Web. Weiter muss eine solche Seitenversion meist unter einer separaten Adresse aufgerufen werden, was nicht immer für Jedermann logisch und ersichtlich ist. Ein Aufwand der eines Tages umsonst gewesen sein könnte, wenn Mobile Endgeräte später einmal so leistungsfähig wie Desktop PCs sind. Doch bis dahin sollte wohl noch einiges an Zeit vergehen.

Eine kurze Anleitung wie man einen ersten Schritt in die letzte genannte Methode gehen kann, beschreibt Mike Davidson in seinem Artikel „Make your Site Mobile-Friendly in Two Minutes“ (englisch). Dort wird darauf eingegangen wie man mittels eigener Subdomain, binnen 2 Minuten, eine Seite von unnötigen Elementen bereinigen, und den Code durch entfernen von Leerzeilen verkleinern kann.

Das Ergebnis rechtfertigt den Aufwand

Lohnt sich ein solcher Aufwand für eine verschwindend kleine Minderheit an Benutzern, die unterwegs ins Internet gehen möchten? Das bisher nur wenige Benutzer vom Handy gebrauch machen um ins Internet zu gehen, dürfte momentan jedoch primär daran liegen, dass sich viele Entwickler die gleiche Frage stellen.

• Der Benutzer hat stets die volle Kontrolle darüber wo er die Inhalte einer Website lesen möchte. Im Bus auf dem Weg zur Arbeit, zuhause auf dem Sofa oder heimlich im stinklangweiligen Seminar.
• Anbieter von Klingeltönen haben es erfolgreich vorgemacht, schon 12-jährige geben jeden Monat viel Geld für Klingeltöne und Handyvideos aus. Das Handy ist längst als neues Medium neben Internet, TV, Radio und Print anerkannt. Wieso sollte man einem Markt, für vergleichsweise so geringen Aufwand so wenig Beachtung schenken? Nach der Kamera wird auch das Internet in Handys von immer mehr Leuten benutzt. Wieso nicht einfach einmal einer der ersten sein, der diesen Markt für sich erschließt?
• GPS macht es heute bereits möglich durch fremde Orte und Städte zu navigieren. In Zukunft wird noch viel mehr mit dem Handy in Verbindung mit dem Internet möglich sein. Beispielsweise eine GPS-gesteuerte Suche nach dem nächsten Restaurant in der Umgebung. Ein Handy ist standortunabhängig und kann auch heute schon als Navigationsgerät benutzt werden, entsprechende Software vorausgesetzt.
• Durch so genannten Semacode ist es möglich, beispielsweise Informationen mit Wikipedia Artikeln zu verknüpfen. Semapedia ist nur ein praktisches Beispiel wie man die Außenwelt über das Handy mit dem Internet in Verbindung bringen kann. Durch Semapedia ist es z. B. möglich, Sehenswürdigkeiten oder interessante Bauwerke mit einem Aufkleber zu bekleben welcher so genannten Semacode enthält (zu finden übrigens auch auf jeder Handyrechnung zur leichteren Auffindung von Kundendaten). Fotografiert man nun mit seiner Handykamera diesen Sticker ist es (ähnlich wie beim EAN-Barcode) möglich, durch diesen auf den entsprechenden Wikipedia-Artikel oder andere Zusatzinformationen geleitet zu werden.
• Neben dem Internet hat in letzter Zeit vor allem das Handy unsere Welt verändert wie kaum etwas anderes. Mittlerweile ist es möglich nicht mehr nur beides separat zu benutzen, die Übergänge sind mittlerweile fließend. Über Dienste wie Skype oder Jajah ist es möglich über das Internet mit dem Handy zu telefonieren. Mit jedem modernen Handy kommt man problemlos ins Internet. Eine Technologie die sich in den nächsten Jahren mit hoher Wahrscheinlichkeit noch viel weiter entwickeln wird.

Fazit

Auch wenn viele Stimmen, aus teilweise berechtigten Gründen, gegen die .mobi Top-Level-Domain sind: Die bereits abgeschlossene Einführung einer Domain speziell für Mobile Geräte ist ein weiterer Punkt in einer Liste, welche verdeutlichen soll, welchen Stellenwert die Anpassung von Internetseiten für portable Geräte in Zukunft haben wird. Das Internet wird viele neue Möglichkeiten bieten welche mit dem Handy genutzt werden können. Jemand der im Internet Erfolg haben möchte, sollte nicht davor zurückschrecken zumindest einmal einen Blick auf das „mobile Web“ zu wagen.

Weiterführende Links

• Buchtipp: Cameron Moll – Mobile Web Design (Englisch) .
• 10 Reasons to Publish to Mobile (Englisch) .
• Make your Site Mobile Friendly in 2 Minutes (Englisch) .
• Semapedia Projekt .
• Positivbeispiel: Mobile Wikipedia .
• Positivbeispiel: Kicker.mobi .

Zum Autor

Manuel Bieh aus Dortmund arbeitet als Web-Entwickler und beschäftigt sich seit etwa 4 Jahren intensiv mit der Entwicklung standardkonformer Websites. Als Betreiber eines Fachweblogs und freier Autor für das Dr. Web Magazin veröffentlicht er regelmäßig Artikel zum Thema Usability, XHTML, CSS und Webstandards. Zu seiner großen Liebe, dem Internet, ist er stets verbunden. Auch unterwegs.

Grundlegendes

Bei CMS made simple handelt es sich um ein Open Source-CMS, das unter der GPL veröffentlicht wurde und auf allen gängigen Betriebssystemen lauffähig ist, sofern PHP und ein Webserver vorhanden sind. Hinsichtlich der zugrunde liegenden Datenbank ist man sehr tolerant und akzeptiert neben MySQL auch PostgreSQL. Viel wichtiger aber ist: Die Installation ist kinderleicht und wird Schritt für Schritt von einem interaktiven Assistenten begleitet, so dass eine Komplettinstallation mit Demo-Inhalten auch für CMS-Neulinge schon nach wenigen Minuten lauffähig ist.

Back-End: Für Redakteure, Webdesigner und Administratoren

Internetseiten erfordern zumeist ein arbeitsteiliges Vorgehen. In der Praxis sieht es meist so aus, dass ein Webdesigner für einen Kunden eine Website layoutet, programmiert und lauffähig auf einem Server mit CMS installiert. Dem Kunden obliegt dann die Pflege der Inhalte und die Erweiterung der Navigation, sofern letzteres gewünscht ist. Genau an dieser Rollenverteilung orientiert sich CMS made simple und bietet drei vordefinierte Benutzergruppen, denen man eine Vielzahl von Rechten zuordnen oder entziehen kann. Auf diese Weise bleiben Funktionen zur Template-Erstellung, Benutzerverwaltung und Modul-Verwaltung vor den Augen eines Nur-Redakteurs verborgen und tragen so zur Fokussierung auf das Wesentliche bei: Der Inhaltserstellung und -pflege.

Einfach für Webdesigner

Hand aufs Herz: Spezialist kann man nur in einer Sache sein. Wenn man Webkraut ist, gehen Standards über alles und man ist mit Leib und Seele den Quelltexten in HTML und CSS verschrieben, mag RSS beziehungsweise XML und freut sich über saubere URLs. Wenn man dafür allerdings erst den kompletten ASP-, JSP- oder PHP-Code eines Systems auseinandernehmen und wieder zusammensetzen muss, hört der Spaß für Webdesigner auf und die Arbeit eines Programmierers beginnt. Die gute Nachricht: CMS made simple kommt ohne Tweaks, Hacks und Frickeleien am PHP-Code aus und bietet sehr viel mehr Flexibilität als man auf den ersten Blick vermuten könnte.

Der Grund dafür liegt im Aufbau des Systems, denn dieses CMS setzt auf der Template Engine Smarty auf. Die mächtige Syntax und die ausgezeichnete Performance von Smarty machen einen Großteil der Flexibilität aus und sorgen in der Praxis dafür, dass Webdesigner die volle Kontrolle über den augegebenen Code behalten, ohne in den kreativen Möglichkeiten eingeschränkt zu werden. Was sehr theoretisch klingt ist Webdesigner-Alltag: Gestreifte Tabellen, bei denen der Tabellenkopf anders aussehen soll als die übrigen Zeilen und wo man am Ende oder nach jedem zehnten Datensatz noch eine Schmuckgestaltung mit einbeziehen möchte. Dank Smarty kein Problem, denn man kann mit {foreach}{/foreach} oder {cycle} durch ganze Arrays arbeiten und entsprechende Formatierungen vornehmen. Jede zehnte Zeile kann man dann wie folgt formatieren, ohne Programmierer zu sein:

{if $smarty.foreach.ListenName.iteration % 10 == 1}
  <tr class="zeileZehn">
    <td colspan="3"><img src="zeilezehn.gif" alt="" />Eine Schmuckzeile</td>
  </tr>
{/if}

Derartige Smarty-Schnippsel kann man beispielsweise für die Ausgabe von kategorisierten News-Meldungen sehr vorteilhaft einsetzen, um Anleser zu erzeugen, Link-Listen darzustellen oder eine tabellarische Übersicht zu generieren. Oder alles zusammen, je nach Geschmack. Letzteres wird durch einen weiteren Flexibilitäts-Vorteil des Systems möglich: Beliebig viele Templates und Sub-Templates.

Modular: Inhalte, Erweiterungen, Menüs und Vorlagen

Für viele Content Management Systeme ist die Verwaltung von Inhalten, die in mehreren Spalten angeordnet sein sollen, problematisch. Das beginnt schon bei der Zurodnung der Seitenvorlagen zu den Inhalten und zieht sich wie ein roter Faden bis hin zur Befüllung zusätzlicher Spalten oder dem Verhalten des Content Management Systems, wenn man von einem zweispaltigen Layout auf ein einspaltiges Layout umstellt. Benutzerfreundlich und flexibel präsentiert sich CMS made simple in dieser Hinsicht und offeriert dem Vorlagen-Ersteller ohne Programmierkenntnisse zahlreiche Möglichkeiten, die sich alleine mit Worten nicht erklären lassen.

Seiteninhalte beispielsweise werden wie folgt im Template aufgerufen:

{content}

Zusätzliche Inhaltsblöcke oder Spalten definiert man dann einfach so:

{content block="spalte_rechts"}

{content block="teaser"}

Nun erhält man beim Editieren der Seite nicht nur ein einzelnes Eingabefeld – das man wahlweise mit oder ohne WYSIWYG bearbeiten kann beziehungsweise sogar mit dem Editor seiner Wahl – sondern derer gleich drei. Jedes Eingabefeld ist dann mit dem Namen des Blocks verbunden, der bearbeitet wird. Bei guter Planung durch den Webdesigner kann man auf diese Weise sogar das grundlegende Template von einem dreispaltigen auf ein einspaltiges Layout ändern, vorausgesetzt der Haupt-Inhalt wurde mit {content} erfasst. Alle anderen Inhalte bleiben in der Datenbank bestehen.

Ähnlich flexibel wie bei den Templates oder den Inhalten präsentiert sich das System bei Modulaufrufen. Das wichtigste Modul, das gleichzeitig zum Kern des Systems gehört, ist der Menü-Manager. Was simpel klingt, entpuppt sich in der Anwendung als Killer-Applikation für die Aufbereitung und Ausgabe von Menüs. Standardmäßig wird bereits ein Accessibility-Menü mitgeliefert, das man hierzulande aus EfA-Tutorials kennt und das wohl zu den barriereärmsten Varianten gehört, die man im Web antreffen kann. Aktive Menüpunkte sind nicht mehr als Links ausgezeichnet, zudem hat man über Sub-Templates die Möglichkeit, alle Menüs den eigenen Anforderungen anzupassen. Dank Smarty keine allzu komplexe Angelegenheit. Gleiches gilt für mehrere Menüs, die aus der gleichen Menüstruktur generiert werden. Diese können unterschiedlichster Art gestaltet, formatiert und in HTML und CSS ausgezeichnet werden, man kann den Seitenbaum und den Menü-Manager sogar zur Generierung einer Sitemap benutzen. Ein Modulaufruf in CMS made simple erfolgt über

{cms_module module="news" detailpage="presse" category="Presse" number="5" template="presse_teaser.tpl" lang="de_DE"}

Damit wird das Modul "News" aufgerufen, das ebenfalls zum Kern des Systems gehört. Dargestellt werden fünf Meldungen aus der Kategorie Presse und zwar wird dafür die Vorlage "presse_teaser.tpl" genutzt, die man via FTP in den Template-Ordner des entsprechenden Moduls spielen kann – sonst wird die Standard-Vorlage für News verwendet. Wenn man eine Pressemitteilung anklickt werden die Details in der Seite mit dem Alias "presse" dargestellt und alle Seiteneinstellungen, inklusive Menü und Ariadne-Pfad (Breadcrums), entsprechend angepasst.

Qualitätssicherung: Aktion sauberer Quelltext

Gegenwärtig hat man die Qual der Wahl zwischen acht verschiedenen WYSIWYG-Editoren zur Inhalts-Eingabe. Der standardmäßig gelieferte FCKeditor wird wohl in Kürze TinyMCE weichen. Hinsichtlich eines validen Quelltextes offeriert FCKeditor zwar eine solide Basis, allerdings muss man die Möglichkeiten der Werkezeugleisten und somit des Redakteurs auf ein Minimum beschneiden und selbst dann ist Gefahr im Verzug: Durch Copy & Paste aus anderen (Windows-)Anwendungen kopierte Inhalte müssen dringend über die "aus MS Word einfügen"-Funktion in den WYSIWYG-Editor eingebracht werden, da sonst schlimmstmögliche HTML-Fehler mit eingeschleust werden können. Doch auch die bereinigte Version von Word-HTML bleibt leider hinter den Erwartungen zurück, allerdings ist dies kein spezieller Fehler dieser Systemkombination, sondern ein Problem von vielen Richtext-Editoren im Zusammenspiel mit Content Management Systemen.

Das Ausweichen auf einen alternativen HTML-Editor ist dann unausweichlich. Im praktischen Einsatz hat sich unter anderem widgEditor bewährt, aber auch Xinha/HTMLArea bieten hier deutlich besseren Quellcode in der Ausgabe. Interessant ist in diesem Zusammenhang sicherlich auch die Arbeit an einem Tidy-Modul, das man sowohl im Pre- als auch im Post-Rendering der Inhalte einsetzen kann. Allerdings befindet sich dieses Modul noch im Aufbau, dürfte aber im Hinblick auf zukünftige Versionen und das Commitment der Entwickler zu WCAG und ATAG an Bedeutung gewinnen. Momentan muss man sich mit alternativen Modulen oder Regie-Anweisungen an die Redakteure behelfen.

An anderer Stelle funktioniert die Qualitätssicherung jedoch schon hervorragend, beispielsweise beim Anlegen von Seiten: Dort werden bereits Möglichkeiten zum Vorbelegen von Accesskeys oder Tab-Index angeboten, für jene, die es mögen oder brauchen. Zudem verfügt jeder Eintrag über ein Hilfe-Menü, das gerade über das Wiki sukzessive ausgebaut wird, momentan aber nur in englischer Sprache wirklich ausführlich ist.

Stärken und Schwächen

Ein Content Management System, das nicht einmal drei Jahre alt ist, darf sich Schwächen leisten. Zumal, wenn es so viele Stärken vereint und eine derart aktive Community in der Hinterhand hat. Davon zeugt nicht zuletzt das ausführliche deutschsprachige Forum mit eigenen Unterbereichen. Wer Fragen hat, findet in der Regel bereits bestehende Antworten oder offene Ohren für neue Lösungen.

Schon heute gibt es eine Vielzahl an vorgefertigten Modulen, Tags und Templates. Daraus kann sich jeder Nutzer bedienen und so entweder bestehende Seiten mit Hilfe von CMS made simple umbauen oder neue Websites entwickeln. Einarbeitungszeit, Arbeitsgeschwindigkeit, Flexibilität und Standardkonformität sind dabei eindeutige Stärken. Saubere URLs sind über verschiedene Wege möglich und in der Konfiguration einstellbar, gleiches gilt für das serverseitige Caching von Seiten mit Hilfe von Smarty. Hervorzuheben ist der Menü-Manager, der in der Open-Source-CMS-Welt nahezu einzigartig in dieser Form ist. Mit der integrierten Suchfunktion, die auch alle Modulinhalte wahlweise mit einbezieht, hat man seit Version 1.0 endlich auch den Schritt zu mehr Benutzerfreundlichkeit getan. Prinzipiell werden Inhalt & Gestaltung voneinander getrennt und dank Smarty bleibt auch die Logik außerhalb der Templates – ein deutliches Plus gegenüber anderen Content-Management-Systemen.

Schwächen offenbart das System vor allem beim Einsatz diverser WYSIWYG-Editoren und den damit einhergehenden Problemen: Formatierung, Bilder und Tabellen. Die Probleme sind bekannt und werden mit Version 1.5 weitestgehend behoben sein. Gleiches gilt für andere Problemstellungen, wie Workflow-Management oder Mehrsprachigkeit. Hier besteht noch Nachholbedarf gegenüber manch anderem Content-Management-System. Gegenwärtig gibt es nicht für jeden Spezialfall ein eigenes Modul, so dass es zum Teil notwendig ist, eigene Module zu entwickeln. In der Frage XHTML oder HTML hat man ein klares Statement zugunsten von X gesetzt. Allerdings kann man mit ein paar kleinen Änderungen auch HTML-Seiten ohne X ausliefern, allerdings muss man in diesem Fall bei den meisten Modulen die Standard-Ausgabe-Templates anpassen und ist in der Wahl des WYSIWYG-Editors etwas eingeschränkter.

Fazit

Dass man mit CMS made simple hochwertige Websites unter Beachtung aktueller Webstandards erstellen kann und dabei auch den Geldbeutel der Kunden schont, zeigen Positivbeispiele wie Wohnungsbau GmbH Familienhilfe Düsseldorf oder die Website der NatKo. Letztere schaffte im vergangenen Jahr die Nominierung für die BIENE und das mit einer minimal angepassten Pre-Alpha-Version des Systems. Seit Version 1.0 ist man in eine stabile Phase eingetreten und hat deutliche Performance-Verbesserungen und Arbeitserleichterungen für den Redakteur eingeführt. Dazu zählt die Content-Reorganisation mit AJAX ebenso wie Front-Side-Editing oder die neue Vorschau, die dank AJAX nun ebenfalls deutlich schneller ist.

Eine Empfehlung ist CMS made simple für kleine bis mittelgroße Projekte, bei denen wenig erfahrene Internetnutzer als Redakteure in Frage kommen und Webstandards beziehungsweise Barrierefreiheit dennoch eine Rolle spielt.

Weiterführende Links:

• opensourcecms.com: Aktuelle Demo-Version
• Themes & Templates: Vorlagen für Front- und Backend
• Wiki: Deutsche Hilfe-Seiten

Über den Autor:

Ansgar Hein beschäftigt sich schon seit 1994 mit den Anforderungen komplexer Internet-Lösungen und Content Management Systeme. Als Geschäftsführer der Agentur anatom5 in Düsseldorf und Mitbegründer des Barrierekompass engagiert er sich für barrierefreie Websites. Dieses Engagement spiegelt sich in zahlreichen Publikationen und Vorträgen wider, unter anderem zum Thema TYPO3 und Barrierefreiheit. Anfang des Jahres erschien unter dem Titel "Einkaufsführer Barrierefreies Internet 2006" eine Marktübersicht mit Agenturen für Barrierefreies Webdesign, für das Ansgar Hein als Herausgeber und Redakteur mitverantwortlich zeichnet.

Webentwicklung am Mac hat lange Zeit nicht wirklich Spaß gemacht – zu Zeiten von Netscape 4 selig musste man sogar den Rechner neustarten, wenn der Browser sich mal wieder mit einer Bombe verabschiedet hatte. Das änderte sich erst, als Microsoft den IE5/Mac herausbrachte: der erste Browser, bei dem man HTML & CSS entsprechend der W3C-Spezifikation einsetzen konnte, ohne dass der Browser daraus Layout-Brei machte.

Microsoft hatte dann aber nach einiger Zeit das Interesse am Nischenmarkt Mac-Browser verloren, und die Gecko-basierten Browser waren, vorsichtig ausgedrückt, noch nicht so weit – Apple musste sich also nach Alternativen umsehen. Fündig wurde man beim KDE-Projekt und dessen Framework KHTML, so dass MacOS X 10.3 im Juni 2003 mit einem neuen Browser ausgeliefert wurde: Safari 1.0.

Apple hat mittlerweile die Quellen offengelegt, im WebKit Open Source Project kann sich auch die KDE-Community bedienen, um die Linux-Pendants von Apples Browser zu verbessern. WebKit ist dabei nur ein Framework, daß unter anderem aus den Komponenten WebCore und JavaScriptCore besteht. WebCore ist der Kern des Browsers Safari und dort zuständig für die Verarbeitung und Darstellung von HTML & CSS. Er entspricht in den neueren Versionen der KHTML-Engine, was das Testen ungemein vereinfacht. Diesen Kern machen sich auch eine Reihe weitere Programme wie mail.app, die Dashboard-Widgets, mobile Webbrowser und viele mehr zunutze, um Inhalte darzustellen.

Standards? Standards!

Spulen wir vor ins Jahr 2005. Der Safari 2.0.2 ist der erste Browser, der den harten Acid2-Test des Web Standards Project besteht. Kurz darauf folgen iCab (ein Mac-Browser des deutschen Entwicklers Alexander Clauss), Konqueror (ein ebenfalls auf KHTML basierender Linux-Browser) und später auch Opera in der Version 9. Damit war der dringend nötige Beweis erbracht: Webstandards funktionieren.

Für Webentwickler eine frohe Botschaft, aber auch ein zweischneidiges Schwert: bisher konnte man sich immer mit unzureichenden Browsern herausreden, wenn etwas nicht lief. Mit der zunehmenden Verbreitung standardkonformer Browser wird diese Ausrede immer unwahrscheinlicher – wenn in einem modernen Webbrowser etwas nicht funktioniert, dann liegt es in den weitaus meisten Fällen an Fehlern im eigenen Quelltext, also am HTML, CSS oder JavaScript der Seite oder Anwendung und nicht am Browser.

Spätestens seit dem Bestehen des Acid2-Tests meistert Safari den CSS1-Standard vollständig, das meiste aus CSS2.1 (Testreihe des W3C) und auch schon vieles aus dem noch in der Entwicklung befindlichen CSS Level 3. Die Nightly Builds genannten Entwicklerversionen von WebKit gibt es auch mit eingebauter SVG-Unterstützung (wenn auch, wie bei allen anderen Browsern, nur teilweise), wobei sich Apple gemeinsam mit anderen Herstellern im Augenblick eher auf die Implementierungen der WhatWG-Spezifikationen wie <canvas></canvas> und damit auf HTML 5 zu konzentrienen scheint.

Bauen und Testen

Reine Standard-Konformität ist zwar schön, aber Webentwickler brauchen zum Bau von Websites und Applikationen weitergehende Infos, die über die rein visuelle Kontrolle hinausgehen. Dazu gibt es für die meisten Browser Erweiterungen, mit denen sich Informationen auslesen oder darstellen lassen, die man zum Beispiel bei der Erstellung von CSS-Layouts benötigt. Safari versteht zwar die Netscape-typischen Plugins, hat aber keine eigene Architektur für Erweiterungen nach Art von Mozilla XUL. Die meisten Erweiterungen lassen sich aber Mac-typisch einfach installieren und rüsten Funktionen nach, die der Safari in der Werkseinstellung nicht bietet.

Die zentrale Anlaufstelle für alle, die ihren Safari erweitern wollen ist die Website »PimpMySafari.com« von Jon Hicks, der neben vielen anderen Erweiterungen auch eine Sparte für Web development Plugins eingerichtet hat. Die wichtigsten haben wir für Sie rausgesucht:

Saft

Keine Erweiterung für Webentwickler im strengen Sinne, aber wenn Sie nur eine Erweiterung mit auf eine einsame Insel nehmen dürften, dann sollten Sie sich für Saft entscheiden.

Ein wichtiges Feature ist, dass man mit dieser Erweiterung das Debug-Menü in Safari anschalten kann. Ohne die Erweiterung geht dies nur, indem man defaults write com.apple.Safari IncludeDebugMenu 1 in ein Terminalfenster eintippt – also an einer Stelle, an die sich der durchschnittliche Mac-User selten hintraut. Nachdem das Debug-Menü aktiviert ist finden Sie dort einen rudimentären DOM-Inspektor, eine JavaScript-Konsole und noch einiges mehr.

SafariStand

Ebenfalls eine unerlässliche Erweiterung für Informationen über und Manipulationen von Webseiten. Nach der Installation kann man unendlich viele Dinge wie benutzerdefinierte Regeln zum Verhalten von Seiten einstellen, aber unser Favorit ist die Möglichkeit, in der Quelltext-Ansicht den Code einer Seite zu ändern und die Änderungen direkt auf die Seite anzuwenden.

SubEthaFari

Manchmal muss man dann aber doch in einen richtigen Editor wechseln, und dafür gibt es Skripte, die den Quelltext zur weiteren Verarbeitung an SubEthaEdit oder BBEdit schicken.

Safari Tidy plugin

Das Plugin installiert das bekannte Prüfprogramm Tidy in die Statuszeile des Browsers. Ein Klick auf die Icons öffnet die Quelltext-Ansicht; dort werden in einer Tabelle die eventuell vorgefundenen Fehler aufgelistet sowie Hinweise zu deren Behebung gegeben. Ein Klick auf den Fehler oder die Warnung setzt den Cursor an die entsprechende Stelle im Quelltext der Seite.

Wenn Sie lieber einen echten Validator nutzen: auch der W3C HTML Validator lässt sich in MacOS X nachrüsten.

WebDevAdditions

Eine Rezension dieser in älteren Safari-Versionen wunderbar funktionierenden Erweiterung nach Art der Web Developer Toolbar für Firefox fällt leider flach, da diese mit dem neuesten Safari-Release nicht mehr funktioniert und auch kein Update in Sicht ist. Die wichtigsten Funktionen der abhanden gekommenen Toolbar lassen sich aber als Favelets im Browser ablegen. Ziehen sie dazu einfach die folgenden Links auf die Lesezeichenleiste: Tabellen zeigen, DIV Borders zeigen, DIV Borders mit IDs zeigen, HTML validieren und CSS validieren

Web Inspector

Wenn der DOM Inspector von Firefox groß ist, dann möchte er so werden wie der Web Inspector. Leider gibt es dieses geniale Werkzeug (noch?) nicht in den regulären Versionen von Safari, sehr wohl aber in den Nightly Builds von webkit.org. Nach der Installation findet man im Kontextmenü ganz unten einen neuen Eintrag »Inspect Element«. Wenn man nun ein Element einer Webseite anklickt und diesen Befehl auswählt öffnet sich ein neues Fenster. Dort erhält man weitergehende Informationen zu allem, was das CSS-Designer-Herz begehrt: die DOM- und Style-Informationen des betreffenden Elementes, die genauen Bemaßungen, welche Styles auf dieses Element vererbt werden und vieles mehr.

Drosera

Drosera ist zum einen der lateinische Name für eine Gattung von Pflanzen, die Insekten (engl.: Bugs) fressen, und zum anderen der Name des neuen JavaScript-Debuggers (der übrigens selbst in HTML und JavaScript geschrieben ist). Leider bisher ebenfalls nur in den Nightly Builds erhältlich.

Testen mit Safari

Wenn ein Webbrowser so eng mit dem Betriebssystem verknüpft ist wie der Safari oder die Konkurrenz aus Redmond, dann stößt man schnell an den Punkt, wo man nach einem Update des Betriebssystems nicht mehr in einer älteren Version des Browsers testen kann.

Bei relativ jungen Versionen von Safari kann man sich entspannt zurücklehnen, denn die letzte Version für MacOS X 10.3 entspricht in allen wesentlichen Teilen dem Nachfolger für 10.4. Aber auch für ältere Versionen gibt es Lösungen. Michel Fortin hat bei Multi-Safari eine ganze Reihe von Safaris veröffentlicht, die bis zur Version 1.0 zurückgehen und einen parallelen Betrieb ermöglichen.

Da die Versionen 1.2.x und 1.3.x jedoch nicht unter 10.4 (Tiger) laufen hilft hier nur der Rückgriff auf OmniWeb. Dieser Browser basiert ebenfalls auf WebKit, installiert aber seine eigene Engine und ist somit unabhängig von der Version des jeweiligen Betriebssystems. Die älteren Versionen erhalten Sie im Browser-Archiv von evolt.org.

Safari ohne Safari testen

Was tun, wenn man seine Webseiten unter Safari testen will, aber gerade keinen Mac zur Hand hat?

• Die webbasierte Anwendung iCapture von Daniel Vine macht kostenlose Screenshots, wie Ihre Seiten in Safari aussehen. Zum Zeitpunkt der Veröffentlichung war dies Safari 2.0.3 unter OS X 10.4.4.
• BrowsrCamp.com macht ebenfalls kostenlose Screenshots von Safari 2.0.4, gegen Bezahlung werden auch sämtliche anderen Mac-Browser getestet.

Die gängigsten Bugs und Lücken

Wie findet man den Schuldigen? Hat man trotz aller Anstrengungen immer noch Darstellungsfehler in seinen Seiten, dann hilft diese Anleitung aus dem WebKit Open Source Project: Test Case Reduction. Hier werden eine ganze Reihe wertvoller Tipps gegeben, wie man den oder die Verursacher möglichst schnell und zuverlässig isolieren kann. Bei der Suche nach Fehlern hat sich auch das Programm Xyle scope von Cultured Code als enorm hilfreich erwiesen. Auch dieses Programm basiert auf dem Kern von Safari und ist die Luxusvariante des oben erwähnten Web Inspectors.

Falls das alles nicht hilft könnte es sein, dass Sie auf einen der verbliebenen Bugs in Safari bzw. WebKit gestoßen sind:

• Quotes (<q></q>) kann Safari bis heute nicht korrekt umsetzen. Bemerkbar macht sich der Fehler insbesondere in Verbindung mit lang-Selektoren, mit denen man die für die jeweilige Sprache korrekten typografischen Anführungszeichen setzen kann – sie werden schlichtweg ignoriert. Für einen Browser, der sich typografische Präzision auf die Fahnen geschrieben hat ist so etwas eher peinlich.
• Label (<label></label>) – bis heute beherrschen die offiziellen Versionen nicht das label-Element aus HTML. D.h. ein Klick auf das Label einer Textbox setzt den Cursor nicht in die Box, bei Checkboxen werden keine Häkchen gesetzt wenn man auf das Label klickt u.s.w. Dem Vernehmen nach soll dieser Fehler aber in einer der kommenden Versionen behoben sein. Bis dahin muss man sich mit Skripten wie »Adding Click Support to Labels in Safari« von Chris Cassell behelfen.
• Ebenfalls kein Kraut gewachsen ist gegen das Fehlen einiger CSS2.1-Properties wie counter-increment und counter-reset, pre-wrap und pre-line sowie die für den sauberen Ausdruck wichtigen Paged Media Properties wie Seitenumbrüche, Hurenkinder und Schusterjungen – sie werden bisher noch nicht von Safari unterstützt.

Bugs die keine sind

Keine Bugs, aber natürlich trotzdem nervend sind Elemente, die in den verschiedenen Browsern unterschiedlich gerendert werden und unter Umständen jedes wohldurchdachte Layout zerlegen. Dazu gehören insbesondere Abstände von caption in table, legends in fieldset und Ränder (border) um Textfelder (<input type="text"/>, <textarea></textarea>). Im Gegensatz zu Safari und auch Opera addiert der Firefox bei letzteren aus unerfindlichen Gründen immer noch 2 Pixel hinzu. Der Schuldige ist hier aber wohl weniger bei den Browserherstellern zu suchen, sondern eher bei den schwammigen bis fehlenden Vorgaben der W3C-Spezifikationen.

Weiterführende Links zu Safari, WebKit und MacOS X:

• apfelwiki.de: Safari
• Apple Developer Connection: CSS Support in Safari
• Apple Developer Connection: Safari Developer FAQ
• Andy Budd: Common CSS Bugs in Safari, Firefox and Opera
• W3C: CSS2.1 Test Suite

Über den Autor

Tomas Caspers hat eine Hassliebe zu Webbrowsern, die sich bis zu Netscape 0.9b zurückverfolgen lässt. Schon früh erkannte er den Wert standardkonformer Webentwicklung und beschäftigt sich seitdem mit CSS und den Techniken zur Barrierefreiheit. Caspers gehörte 1998 zu den Gründern des Web Standards Project, wo er sich in der Accessibility Task Force darum kümmert, dass moderne Webangebote auch für Menschen mit Behinderung zugänglich werden. Neben der Beratung für Unternehmen und Behörden verbringt Tomas Caspers die verbleibende Zeit mit der Pflege der Website zur Initiative »Einfach für Alle« der Aktion Mensch.

Die hier vorgestellte Javascript-Klasse wurde für diesen Artikel entwickelt um zu zeigen, daß PopUps nicht generell böse sein müssen.

Die Basismöglichkeiten mit Javascript

mit dem “javascript:”-Pseudoprotokoll:

<a href="javascript:void(window.open('http://www.webkrauts.de'));"> Fenster öffnen</a>

mit einem “blinden” Link und dem onclick-Event :

<a href="#" onclick="window.open('http://www.webkrauts.de');return false">Fenster öffnen</a>

…und funktionieren würden beide Ansätze auch – aber:

… bei einem User mit einem Browser ohne Javascript-Unterstützung würde sich das PopUp nicht öffnen. Noch schlimmer ist aber, dass die gewünschte Seite, ohne jedes Feedback an den User, überhaupt nicht geladen werden würde. Wenn der Link auch ohne Javascript funktioniert und keine Fehlermeldung erzeugt ist die Verwendung in Ordnung.

Dieser Link würde auch ohne Javascript funktionieren:

<a href="http://www.webkrauts.de" onclick="window.open(this.href);return false">Fenster öffnen</a> Fenster öffnen

Aber auch diese Version hat noch diverse Nachteile:

Bei der Verwendung in einem CMS z.B. wären hierbei auch für Redakteure Javascript-Kenntnisse notwendig. Sollte das Fenster zusätzliche Eigenschaften, wie z.B. eine festgelegte Grösse, benötigen, wird der Code sehr schnell noch unübersichtlicher.

Die Vermischung von HTML und Javascript stellt ebenfalls ein grosses Problem dar. Inhalt (HTML), Gestaltung (CSS) und Verhalten (Javascript) sollten generell voneinander getrennt werden [1][2].

Ein weiteres Problem ist auch, dass der Benutzer nicht darüber informiert wird, dass sich der Link in einem neuen Fenster öffnen wird.

Wie Screenreader mit PopUps umgehen

Die aktuellen Screenreader können, im Gegensatz zur herrschenden Meinung, sehr wohl Javascript interpretieren. Dies hat hier aber eher Nachteile als Vorteile. Im letzten Beispiel, würde ein aktueller Screenreader tatsächlich ein neues Fenster öffnen aber den User nicht darauf hinweisen können. Für diesen hat es weiterhin den Anschein als wäre nichts passiert.

Was wäre also ideal?

Eine ideale Lösung muss unbedingt einfach anwendbar sein. Das Hinzufügen eines “class”-Attributs wäre ein guter Ansatz, den auch die meisten CM-Systeme ermöglichen. Zusätzlich kann dem Link mit der Klasse über CSS eine besondere Formatierung zugerwiesen werden (z.B. ein Icon das den User über das neue Fenster Informiert).

Sinnvoll wäre es auch, wenn verschiedene Fenstertypen (z.B. feste Fenstergrössen oder Fenster ohne Adresszeile) erzeugt werden können. Wenn diese Fenstertypen zentral definiert werden könnten, könnten diese leicht in einer ganzen Website genutzt werden.

Der Nutzer sollte darüber informiert werden, dass der Link sich in einem neuen Fenster öffnen wird. Ein Hinweistext im “title”-Attribut wäre eine gute Lösung. Allerdings nur, wenn Javascript auch wirklich aktiviert ist und das PopUp geöffnet werden kann, wenn nicht, wäre der Hinweis wiederum sehr verwirrend.

Abschliessend wäre es natürlich noch toll, wenn gar kein Javascript im HTML-Dokument stehen müsste.

JsPopUp – (m)ein Lösungsansatz

JsPopUp ist der Name der Javascript-Klasse, die ich für diesen Artikel entwickelt habe. Sie bietet Lösungen für die genannten Probleme und ist sehr leicht anzuwenden. Die benötigen Zeilen Javascript werden einfach innerhalb des Head-Bereichs eingebunden und werden dann automatisch ausgeführt.

Die Anpassungen für die eigene Seite können dann entweder direkt in dem aktuellen Dokument oder (besser noch) in einer weiteren externen Javascript-Datei erfolgen. Dadurch kann man das Script einfach für ein gesamtes Web einsetzen.

Für die Auszeichnung der PopUp-Links habe ich mich für das “class”-Attribut entschieden, da dieses im Vergleich zu dem ebenfalls geeigneten “rel”-Attribut zusätzlich auch über CSS gestylt werden kann.

Beispiel 1 (Minimal):

Dieses Beispiel wird alle Links auf der Seite die mit der Klasse “popup” versehen wurden, so verändern, dass diese in einem neuen Fenster geöffnet werden. Zusätzlich wird der Text “Dieser Link wir in einem neuen Fenster geöffnet” in das Title-Attribut geschrieben, sodass der Nutzer weiss, was passiert wenn er klickt. Hinweis: der Einfachkeit-Halber wurde hier der window.onload-Event verwendet. Empfehlenswert statt dessen wäre ein moderner DomLoaded-Event [3].

1. Einbindung der Klasse im Head:
   

   <script language="javascript" type="text/javascript" src="popup.js"></script>

2. Aufruf der Klasse:
   

   <script type="text/javascript">
window.onload = function(){
popup = new PopUp();
popup.apply();
}
</script>

3. Ein Beispiel-Link
   

   <a class="popup" href="http://www.webkrauts.de">Link</a>

Beispiel 2 (Erweiterte Funktionen)

Dieses erweiterte Beispiel zeigt, wie man zusätzliche Fenstertypen definieren kann. Man übergibt der Methode “addType()” ein Objekt mit den gewünschten Eigenschaften. Dabei ist jede Eigenschaft bis auf “name” optional (“name” wird immer benötigt, da dieser dem class-Attribut des PopUp-Links entspricht). Verfügbar sind derzeit folgende Eigenschaften mit den vordefinierten Standardwerten (weitere sind geplant):

• name:"MeinNeuerFensterTyp" (der Name des neuen Fenstertypes ohne Leerzeichen und Sonderzeichen)
• width:800 (die Breite des PopUps in Pixeln)
• height:600 (die Höhe des PopUps in Pixeln)
• top:0 (der Abstand des PopUps vom oberen Bildschirmrand in Pixeln)
• left:0 (der Abstand des PopUps vom linken Bildschirmrand in Pixeln)
• location:false (true oder false. Blendet die Adresszeile des neuen Fensters ein oder aus)
• resizable:false (true oder false. Erlaubt oder verbietet des Verändern der Fenstergröße durch den Nutzer)
• scrollbars:false (true oder false. Blendet den Rollbalken des neuen Fensters ein oder aus)
• status:false (true oder false. Blendet die Statuszeile des neuen Fensters ein oder aus)
• toolbar:false (true oder false. Blendet die Werkzeugzeile des neuen Fensters ein oder aus)
• menubar:false (true oder false. Blendet die Menüzeile des neuen Fensters ein oder aus)
• center:true (true oder false. Zentriert das neue Fenster automatisch in der mitte des Bildschirms (Achtung: Überschreibt die Werte “top” und “left” wenn true!))
• title:"Dieser Link wir in einem neuen Fenster geöffnet" (Dieser Text wird bei Überfahren des Links mit der Maus angezeigt)

In dem folgenden Beispiel wird der zusätzliche Fenstertyp “pdf” definiert. Fügt man Links nun zusätzlich zu der Klasse “popup” auch die Klasse “pdf” hinzu so werden diese mit dem geänderten Title-Text angezeigt und in einem neuen Fenster mit den angegebenen Eigenschaften geöffnet. Natürlich kann man auch diese Links über CSS wieder angepasst stylen (hier z.B. mit einem PDF-Icon)

1. Einbindung der Klasse im Head:
   

   <script language="javascript" type="text/javascript" src="popup.js"></script>

2. Aufruf der Klasse:
   

   <script type="text/javascript">
window.onload = function(){
popup = new PopUp();
popup.addType({
name: "pdf",
width: 800,
height: 500,
resizable: true,
title: "Dieses PDF wird in einem neuen Fenster angezeigt"
});
popup.apply();
}
</script>

3. Ein Beispiel-Link
   

   <a class="popup" href="http://www.webkrauts.de">Link</a>
<a class="popup pdf" href="http://www.webkrauts.de">Link</a>

Download und aktuelle Infos der Klasse

• Projektseite: blog.ginader.de/dev/popup.html

Weiterführende Links

1. Barrierefreies Javascript .
2. The Behavior Layer (Englisch) .
3. Blogpost über Events die das Vorhandensein des DOMs prüfen

Zum Autor

Dirk Ginader ist Technischer Leiter der Unit Interactive von Bartenbach & Co. in Mainz. Er ist leidenschaftlicher Webworker is Sachen (X)HTML, CSS, Javascript, Dom, Ajax, PHP, Flash usw. Sein täglicher (stark Internet-lastiger) Output ist in seinem Blog: “web output” zu lesen.

Dieser Artikel propagiert pragmatische SEO und benennt in „kompakter“ Form die wichtigsten und am wenigsten umstrittenen Techniken zur Suchmaschinenoptimierung, wie sie als gutes Vorgehen angesehen werden. – Interessierte finden mehr Informationen zum SEO-Komplement SEM (Suchmaschinenmarketing) bei Wikipedia, natürlich auch auf Englisch.

Positive Faktoren

Nützliche Inhalte

Die offensichtlichste, wichtigste und doch gerne vergessene Optimierungsmaßnahme: Hochwertige, nützliche, wertvolle Inhalte und Dienste, sofern nicht etwas außergewöhnlich „Künstlerisches“ veröffentlicht wird. Keiner sucht etwas, das nicht benötigt wird, und Suchmaschinen lassen ungerne etwas finden, das nicht benötigt wird. Sergey Brin and Lawrence Page wiesen bei ihrer Vorstellung von Google (1998) besonders auf Qualität und Relevanz hin:

[…] we want our notion of „relevant“ to only include the very best documents since there may be tens of thousands of slightly relevant documents.

Hinterfragen, optimieren, warten Sie Ihr Angebot. Machen Sie es hochwertig.

Schlüsselwörter in Inhalten

Ähnlich naheliegend, aber auf den zweiten Blick nicht ganz so trivial, ist, dass Dokumente auch die Begriffe beinhalten sollten, zu denen sie gefunden werden wollen. Achten Sie auf Schlüsselwörter, nicht nur in Domain-Namen, URLs, Seitentiteln, Überschriften, sondern grundsätzlich: Variieren Sie Schreibweisen, verwenden Sie alternative Begriffe, prüfen Sie, wonach Leute suchen, und analysieren Sie die „Keyword“-Dichte Ihrer Dokumente.

Dedizierter inhaltlicher Schwerpunkt

Analog zum Fokus auf Schlüsselwörter entspricht auch der inhaltliche Schwerpunkt einer Webseite in gewisser Weise einem Optimierungsfaktor. Webseiten mit vielen Themen sorgen für „interne Konkurrenz“ und weniger Exklusivität des Angebots – mal abgesehen davon, dass es mit zunehmender Themenmenge schwieriger wird, hohe Qualität zu erzielen, sofern nicht entsprechend mehr Mittel zur Verfügung stehen. Konzentration auf abgrenzbare Themengebiete, in die man Kompetenz einbringt, zahlt sich eher aus.

Übrigens: Ein gutes Beispiel dafür sind die vielen Spezialseiten, die relevanter als Wikipedia eingestuft werden – wie aktuell bei der (englischen) Google-Suche nach „SEO“.

Angemessene Seitentitel

Wie unter Schlüsselwörter in Inhalten bereits angesprochen: Legen Sie Wert auf aussagekräftige Seitentitel.

Seitentitel:

• sind das erste, das ein Benutzer beim Laden einer Seite sieht;
• erscheinen prominent in Suchmaschinenergebnissen (SERP);
• werden von Suchmaschinen besonderes Gewicht beigemessen.

Durchgängige interne Verlinkung

Auch die interne Verlinkung stellt einen Aspekt von SEO dar. Die Wichtigkeit eines Dokuments lässt sich mitunter durch die angebotsinterne Linkanzahl und -architektur ableiten: Eine durchgängig verlinkte Seite gilt als relevanter als wenig oder sogar gar nicht referenzierte, „vergrabene“ Seiten. Bei gleichzeitigem Fokus auf die entsprechenden Linktexte sollten Sie sicherstellen, dass die interne Verlinkung stimmig ist.

Relevante externe Links

Externe Links sind einer der wichtigsten, wenn nicht gar der wichtigste SEO-Faktor: Ohne Links von anderen Webseiten ist Ihr Angebot quasi nicht existent, und wenn andere Seiten auf Ihr Angebot verlinken, ist weniger ihre schiere Zahl (messbare Linkpopularität) als vielmehr deren Relevanz entscheidend. Auch wenn die Algorithmen, nach denen Suchmaschinen externe Links in die Bewertung eines Dokuments einfließen lassen, nicht genau bekannt sind, ist unstrittig, dass diese deutlichen Einfluss auf die Popularität haben.

(Warum steht dieser Punkt erst hier und nicht am Anfang des Artikels? Weil die beste SEO-Maßnahme aus einem qualitativ hochwertigen Angebot besteht, nicht aus unzähligen externen Links, die auf zusammengeschustertes Irgendwas verweisen.)

Um mehr und/oder relevante externe Links zu erhalten, sollte man gemeinhin nicht Links einkaufen, in großem Stil tauschen (vor allem in „schlechter Nachbarschaft“) oder gar Linkfarmen errichten. Diese Punkte mögen mitunter gar legitim sein oder vorkommen (mit der eigenen Seite will man ja tun und lassen können, was man will), bergen aber die Gefahr, von Suchmaschinen durch niedrigere Einstufung oder gar Entfernen aus dem Index bestraft zu werden.

Vielmehr sollten Sie für Ihre durch ihren Nutzen nahezu und idealerweise „selbst vermarktende“ Webseite eine durchdachte Linkstrategie verfolgen. Da das den Rahmen dieses Artikels sprengen würde, finden Sie weitere wertvolle Informationen unter anderem im Bericht „Linking Matters“.

Aussagekräftige Texte von externen Links

Um den Inhalt einer Webseite zu ermitteln, werden nicht nur die Texte eines Angebots, sondern auch die Texte interner sowie der auf das Angebot verweisenden Links (zu wenn auch unklarem und variierendem Grad) einbezogen. Wenn viele Links mit themenbezogenem Text auf ein Dokument verweisen, wird dieses mit hoher Wahrscheinlichkeit als relevanter bewertet und entsprechend höher in Suchergebnissen plaziert werden (ein Grund mehr, warum „hier klicken“-Links auf jeden Fall zu vermeiden sind). Texte externer Links sind wichtig, und "ethische" Gelegenheiten, diese zu beeinflussen, sollten genutzt werden.

Höheres Alter des Angebots

Zuguterletzt gilt (wenn auch nicht unumstritten) auch das Alter eines Informationsangebots und ebenso das darauf verweisender Links als positiver, wenngleich nur „natürlich“ zu beeinflussender Faktor: „Je älter, desto besser.“

Negative Faktoren

Ausschluss von Suchmaschinen

Ganz logisch: Suchmaschinen aussperren heißt, nicht gefunden zu werden. Das „Aussperren“ kann auf viele Arten erfolgen, unerheblich, ob nun beabsichtigt, da der Ausschluss von Suchmaschinen durchaus gewünscht und sinnvoll sein kann, oder versehentlich, wie unter anderem durch:

• Nicht (mehr) vorhandene oder zugängliche Dokumente (404 und Co.);
• Einsatz nicht oder schwer indizierbarer Multimedia-Inhalte ohne Fallback, von Audio bis Video (Barrierefreiheit?);
• Einschränkungen durch robots.txt;
• Einsatz von bestimmten URL-Weiterleitungen;
• Einschränkungen durch noindex und nofollow.

Seitenbetreiber sollten sicherstellen, dass Inhalte nicht versehentlich von der Erfassung durch Suchmaschinen ausgeschlossen werden. (Ja, soll vorkommen.) Wenn ganze Webseiten oder -bereiche nicht berücksichtigt werden sollen, empfiehlt sich der Einsatz der robots.txt, deren Syntax und Auswirkungen man leicht überprüfen kann.

Links in „schlechte Nachbarschaft“

Zwar ist der exakte Einfluss dieses Punkts nicht ganz klar und auch nicht unumstritten: Links zu Dokumenten „niedriger Qualität“ und vor allem solchen, die gegen Richtlinien der Suchmaschinenbetreiber verstoßen – was üblicherweise auch Verstöße gegen geltendes Recht einbezieht – können negativen Einfluss auf Bewertung und Plazierung haben, im schlimmsten Fall in Form von Sperre und Ausschluss aus dem jeweiligen Index. Wer macht das schon (absichtlich), aber: Vermeiden Sie Links zu illegalen und unseriösen Angeboten.

Keyword Spamming

Das Ausstaffieren und Überborden von Dokumenten mit Schlüsselwörtern kann das Ranking negativ beeinflussen. Dazu gehört vor allem der Missbrauch des keyword-meta-Elements: Wenn Sie es benutzen, benutzen Sie es richtig und benennen Sie nur die tatsächlichen Schlüsselwörter, nicht 19 alternative Schreibweisen, 13 themenferne Begriffe und 21 andere tolle „Buzzwords“.

Link Spamming

Vermeiden Sie Link Spamming:

• Automatisierte Einträge und Kommentare in Verzeichnissen, Blogs oder Gästebüchern;
• Übertriebene reziproke (gegenseitige) Verlinkung;
• themenferne Links;
• anormale Link-Text-Verhältnisse.

Schlussbemerkung

Wie eingangs und auch zwischenzeitlich bemerkt besteht der Schlüssel zu hoher Relevanz für Suchmaschinen in hoher Relevanz und hoher Qualität der Inhalte und Leistungen. Alle anderen Maßnahmen zur Optimierung sind gut und nützlich, aber in diesem Sinne nachrangig. Setzen Sie auf „weiße SEO“ und planen Sie Ihre Suchmaschinenstrategie langfristig. Behalten Sie im Hinterkopf, dass alle genannten Punkte, ob negativ oder positiv, sich nicht unbedingt (sofort) entsprechend manifestieren müssen; ebenso, wie sie nicht sofort 57 Millionen tägliche Zugriffe auf Ihren neuen fantastischen „Social Bookmarking“-Service erhalten werden (zusammen mit einem 10er PageRank), fliegen Sie bei der ersten umfangreichen Linkliste nicht gleich aus dem Yahoo-Index.

Weiterführende Links

• Ranking-Faktoren im Detail;
• Google: Anatomie einer Suchmaschine;
• Google: PageRank-Aktualisierungen;
• Visualisierung eines Indizierungsexperiments;
• SEO-Analyse-Werkzeuge.

Zum Autor

Jens Meiert (Webdesign mit CSS) jongliert primär für die Berliner Agentur Aperto, wird aber auch mit dem W3C und anderen Organisationen in Verbindung gebracht. Wenn er nicht gerade praxisnahe CSS-Experimente verbreitet, verschifft er Poster von leichtbekleideten Damen nach Lesotho.

Allgemeine Features

Alle Artikel in Redaxo werden in Kategorie-Ordner untergebracht, die sortiert werden und wiederum aus Kategorien bestehen können. Einem komplexeren Menü mit mehreren Ebenen steht somit technisch nichts im Wege, jedoch sollte man die Verschachtelung aus Usabilitygründen nicht übertreiben. Jedem Artikel kann nicht nur ein eigenes Template zugeordnet werden, sondern es können auch dessen Metadaten editiert werden. Der Artikel wird dann aus einzelnen Modulen wie Texteingaben oder Bildern aufgebaut, ähnlich wie in Typo3. Diese Module können beim Aufbau einer Site aus der Demo übernommen werden. Man kann aber auch in "ordinärem" PHP eigene Module schreiben, ohne sich in eine obskure proprietäre Skript-Sprache einarbeiten zu müssen. Dadurch ist das ganze System ungeheuer flexibel, komplexe Projekte wie Online-Shop-Systeme oder eine Community-Website mit den üblichen Kommunikations-Features sind bereits erfolgreich mit Redaxo realisiert worden.

Zudem lassen sich auch mehrsprachige Seiten einfach mit Redaxo realisieren. Dazu kann man das System in den Einstellungen auf UTF8 umstellen, angeben, welche Sprachen verwaltet werden sollen, und schon hat man, zusammen mit dem ausgefeilten Benutzer/Rollen-System, die Möglichkeit, seine Inhalte mehrsprachig einzugeben und zu verwalten. Auch das Backend kann auf eine andere Sprache umgeschaltet werden, jedoch nicht benutzerabhängig.

Ajax-Funktionalitäten im Backend sucht man bisher leider vergebens, obwohl es sicher beim einen oder anderen Punkt (z.B. Kategorien umbenennen) durchaus angebracht wäre.

Bewertung der Qualität bezüglich Webstandards

Anhand einiger Stichpunkte könen Sie sich selbst ein Bild machen, ob Redaxo ihre Kriterien in Sachen Webstandards erfüllt.

1. Valider QuellcodeMit Redaxo hat man die komplette Kontrolle über den ausgebenen Quelltext: Was man in Template reinsteckt, kommt auch genau so im Browser des Benutzers an. Saubere CSS-Templates sind somit einfach realisierbar. Falls man doch mit der Ausgabe des ein oder anderen AddOns nicht zufrieden ist, kann diese leicht angepasst werden, da das Redaxo-System sauber strukturiert und übersichtlich gehalten ist.
2. Saubere URLsÜber eine Einstellung im System lässt sich Mod_Rewrite aktivieren, welches aus parametrisierten URLs wie "http://www.example.de/index.php?article_id=3&clang=0" nun "sprechende" Adressen wie "http://www.example.de/3-0-impressum.html" ausgibt. Noch schöner wäre es allerdings, wenn die Sprache nicht mit einer Zahl, sondern durch die interne Abkürzung dargstellt würde (z.B. "de"), aber es muss ja auch noch Raum für zukünftige Verbesserungen geben.
3. NavigationMehrstufige Menüs lassen sich schön als Liste ausgeben, auch die Vergabe von IDs für Listenpunkte, um diese z.B. mittels CSS ansprechen zu können, ist kein Problem. Auch mehrere unabhängige Menüs sind so machbar. Mit etwas PHP ist sogar eine dynamische Navigationsgrafikgenerierung möglich, die mit ein paar Tricks auch in barrierearmen Seiten eingesetzt werden kann.
4. BilderDurch den eingebauten Medienpool ist das Verwalten von Bildern und anderen Dateien schmerzlos. Jedem Bild kann u.a. ein Titel und eine Beschreibung mitgegeben werden, die über die Module dann z.B. in den Alternativtext übernommen werden können.
5. SuchfunktionEine eingebaute Suchfunktion gibt es in der Demo nicht, aber sie kann über ein AddOn (search_index) hinzugefügt werden. Auch dieses AddOn kann natürlich an die eigenen Wünsche angepasst werden.
6. BackendDas Backend ist derzeit noch nicht wirklich barrierefrei, jedoch wird sich dies in der nächsten Version 3.3 ändern: ein barrierearmes, CSS-basiertes Backend stand oben auf der Wunschliste der Entwickler und wird kommen, da es bereits jetzt sehbehinderte User gibt, die mittels Redaxo ihre Seiten pflegen.

Fazit

Redaxo überzeugt dadurch, daß es sich bei der Gestaltung des ausgeworfenen Quellcode angenehm im Hintergrund hält. Im Gegensatz zu anderen bekannten Open-Source-CMSen versucht es nicht mit Gewalt, eigene (seltsame) Vorstellungen von Quellcodestrukturen gegen den Willen des Entwicklers durchzusetzen. Bei der Erstellung mehrsprachiger Seiten oder bei komplexeren Menüs, die von Redakteuren angepasst werden sollen, ist es derzeit mein Mittel der Wahl.

Weiterführende Links

• Redaxo .
• PERGOPA Kristinus GbR .
• Wikipedia über Ajax .
• Wikipedia über mod_rewrite .

Zur Autorin

Beate Paland ist Webentwicklerin und setzt seit 2002 auf Webstandards, in sämtlichen HTML-Projekten, sei es mit PHP oder Ruby on Rails.

<address>
Michael Jendryschik
Dorstfelder Hellweg 36
44149 Dortmund
Telefon: +49 (0)231 2217811
E-Mail: michael@jendryschik.de
Web: http://jendryschik.de
</address>

Maschinenlesbar, das heißt für Browser und andere Benutzerprogramme erkennbar, ist die Information, dass das Dokument Kontaktinformationen über den Autor enthält, strukturiert durch einige Zeilenumbrüche, darunter eine E-Mail-Adresse und den Link zu einer Website. Wir Menschen, so wir der verwendeten, natürlichen Sprache mächtig sind, können weit mehr Informationen ausmachen: Wir erkennen darüber hinaus

• einen Namen,
• eine Adresse, bestehend aus Straße, Hausnummer, Postleitzahl und Ort sowie
• eine Festnetz- und eine Mobiltelefonnummer.

Diese Informationen sind jedoch nicht maschinenlesbar und damit nicht oder nur beschränkt programmatisch wiederverwendbar. Genau dieses Problem versuchen Mikroformate zu lösen. Dabei handelt es sich um Formate zur »Feinstrukturierung« von Webseiten. Dokumente, vor allem (X)HTML-Dokumente, werden menschen- und maschinenlesbar durch zusätzliche Semantik ergänzt, ohne die Inhalte zu verändern. Zum Einsatz kommen dabei drei Attribute: class, rel und rev.

Die Attribute class, rel und rev

Das Attribut class weist einem Element einen Klassennamen oder einen Satz von Klassennamen zu. Derselbe Klassenname kann einer beliebige Anzahl von Elementen zugeordnet werden. Wie alle Attribute werden Klassen im Start-Tag des Elements notiert:

<em class="wichtig">

Wenn Elemente zu mehreren Klassen gehören, zum Beispiel zu der Klasse »wichtig« und zu der Klasse »extern«, dann werden die Klassennamen mit einem Leerzeichen getrennt aufgeführt:

<em class="wichtig extern">

Die Attribute rel und rev werden hauptsächlich an a-Elementen notiert und nehmen entgegengesetzte Rollen ein – das rel-Attribut spezifiziert eine Vorwärts-, das rev-Attribut eine Rückwärtsbeziehung. Das Attribut rel beschreibt die Beziehung des aktuellen Dokuments zu der durch das href-Attribut angegebenen Zielressource. Das Attribut rev dient dazu, einen Rückwärtslink von der durch das href-Attribut angegebenen Zielressource zum aktuellen Dokument zu beschreiben. Der Wert beider Attribute ist eine durch Leerzeichen getrennte Liste von Beschreibungen.

So sagt beispielsweise
<a href="glossar" rel="glossary">Glossar</a>
aus, dass die verlinkte Ressource ein Glossar für das aktuelle Dokument bereitstellt. Mit

<a href="foo" rev="contents">Foo</a>
wird angezeigt, dass das aktuelle Dokument ein Inhaltsverzeichnis (table of contents) für die verlinkte Ressource darstellt.

Mikroformate werden eingesetzt, indem Elementen eines oder mehrere der drei Attribute mit festgelegten Werten zugewiesen wird.

Verfügbare Formate

Mittlerweile gibt es zahlreiche Formate für ganz spezifische Formen von Auszeichnungen. Dabei unterscheidet man zwischen zwei Gruppen von Formaten: elementare und zusammengesetzte. Zusammengesetzte Formate wie hCard oder hReview basieren auf elementaren Formaten wie XFN oder rel-tag und alle letztendlich auf XHTML. Zu den bekanntesten Mikroformaten zählen die folgenden:

• hCard ist ein Mikroformat zur Auszeichnung von Kontaktinformationen. Es überträgt den vCard-Standard (RFC 2426) in (X)HTML.
  Eine vCard ist eine elektronische Visitenkarte, die ein Benutzer direkt in ein Adressbuch importieren kann.
• hCalendar ist ein mittlerweile sehr verbreitetes Mikroformat, das sich an vCalendar (RFC 2445) orientiert. Dabei handelt es sich um ein Format zur Auszeichnung von Kalender- und Veranstaltungsdaten.
• Das Format XFN dient der Auszeichnung sozialer Beziehungen. So können sie angeben, ob Sie eine Person bereits persönlich getroffen haben oder ob sie ein Arbeitskollege, ein Freund oder ein Familienmitglied ist.
• xFolk dient der Auszeichnung von Bookmarks.
• Zur Auszeichnung von Weblog-Einträgen und News eignet sich hAtom.
• Zu den in Zukunft sicherlich wichtigsten Mikroformaten gehört hReview, mit dem Bewertungen und Besprechungen von Serviceleistungen, Veranstaltungen, Filmen und – vor allem – Produkten angereichert werden können.

Mittlerweile gibt es eine große Anzahl weiterer Formatspezifikationen und -entwürfen, die im Microformats Wiki aufgeführt sind.

Beispiele: hCard und hCalendar

Es bietet sich an, die Anwendung von Mikroformaten anhand hCard zu demonstrieren, indem das oben aufgeführte Beispiel durch die entsprechenden Klassen und einige wenige, umschließende Elemente erweitert wird:

<address class="vcard">
<span class="adr">
<span class="fn">Michael Jendryschik</span>
<span class="street-address">Dorstfelder Hellweg 36</span>
<span class="postal-code">44149</span>
<span class="locality">Dortmund</span>
</span>
Telefon: <span class="tel">+49 (0)231 2217811</span>
E-Mail: <a href="mailto:michael@jendryschik.de" class="email">michael@jendryschik.de</a>
Web: <a href="http://jendryschik.de/" class="url">http://jendryschik.de</a>
</address>

Alle Informationen, die vorher nur für Menschen lesbar waren, können nun auch Maschinen verstehen.

Ein weiteres Beispiel ist die Anwendung des Mikroformats hCalendar. Es kommt unter anderem auf der Veranstaltungsübersicht von Einfach für alle, der Aktion-Mensch-Initiative für ein barrierefreies Web, zum Einsatz. Eine Veranstaltung, hier die Preisverleihung der BIENE 2006, wird beispielsweise wie folgt ausgezeichnet:

<div class="vevent">
<h3 class="summary"Preisverleihung:
<a href="/biene-2006/" class="url">BIENE 2006</a></h3>
<p class="description">Seit 2003 prämieren die Aktion Mensch und die Stiftung
Digitale Chancen die besten barrierefreien Angebote im Internet mit einer
BIENE. BIENE steht für »Barrierefreies Internet eröffnet neue Einsichten«,
aber auch für Kommunikation, gemeinsames Handeln und produktives
Miteinander.</p>
<p class="datum"><abbr class="dtstart" title="2006-12-08">08. Dezember</abbr>,
<span class="location">Berlin</span>, weitere Infos unter:
<a href="http://www.biene-award.de/" rel="external" class="url">
biene-award.de</a>.</p></div>

Mikroformate erstellen und verarbeiten

Die Annotation von Mikroformaten zu (X)HTML-Dokumenten ist zwar keineswegs schwierig und lässt sich leicht per Hand erledigen. Dennoch sind Sie nicht vollkommen auf sich allein gestellt: Es gibt mittlerweile einige Werkzeuge, die Autoren bei dieser Arbeit unterstützen. Bei der Erstellung einer hCard-Auszeichnung hilft der hCard Creator. Für hCalendar gibt es mit dem hCalendar Creator einen vergleichbaren Service, für hReview den hReview Creator. Abbildung 1 zeigt, wie einfach sich der hCard Creator bedienen lässt. Der erzeuge Code kann bearbeitet und direkt in das Zieldokument kopiert werden.

Die Erstellung von Mikroformaten ist jedoch nur die eine Seite der Medaille, deren Auswertung und Verarbeitung die andere. Aber auch da gibt es mittlerweile einige nützliche Werkzeuge und Browsererweiterungen.

Technorati, eine Echtzeit-Suchmaschine speziell für Weblogs, bietet einen so genannten Contacts Feed Service an, der es ermöglicht, mittels hCard ausgezeichnete Kontaktinformationen im vCard-Format zu exportieren. Gibt man den URL einer Webseite, die das oben erweiterte address-Element enthält, liefert der Service eine VCF-Datei, die nun problemlos in gängige Adressbücher importiert werden – eine feine Sache.

Der Events Feed Service leistet dasselbe für Kalenderdaten. Es wird eine ICS-Datei exportiert, die direkt in Programme wie Mozilla Sunbird importiert werden kann.

Es gibt auch Browsererweiterungen, die Mikroformate auslesen und darstellen und weiterverarbeiten, etwa in ein entsprechenden Zielformat konvertieren und zum Export anbieten, für Firefox unter anderem die Tails Firefox Extension und Tails Export – letztere leider nur bis Version 1.5. Abbildung 2 zeigt Tails im Einsatz.

Fazit

Mikroformate reichern Dokumente menschen- und maschinenlesbar mit semantischen Informationen an ohne ihren Content zu verändern. Dabei gilt festzuhalten: Maschinenlesbare Semantik ist wiederverwendbarer Content, das heißt, es ist möglich, mit Mikroformaten versehen Daten weiterzuverarbeiten. Informationen lassen sich aus einer Website auszulesen und anderen Programmen zugänglich machen. Dadurch ergibt sich ein großer Mehrwert für den Nutzer. Stellen Sie sich vor, die Veranstaltungsübersicht Ihres bevorzugten Konzerthauses oder ihrer Lieblingsdiskothek wäre mit Mikroformaten ausgezeichnet – welch praktischen Nutzen Sie doch davon hätten! Sie könnten die Daten aller oder ausgewählter Veranstaltungen mit wenigen Klicks aus den Webseiten extrahieren und ihrer Kalendersoftware verfügbar machen. Mikroformate sind ein Teil des Web 2.0: Sie kennzeichnen soziale Beziehungen, unterstützen Bookmarking und Tagging. Und stellen Sie sich vor, wie nützlich Mikroformate werden können, wenn Suchmaschinen sie für sich entdecken. Webseiten mit Buch- oder DVD-Rezensionen könnten so viel effizienter bewertet werden.

Der Veranstaltungskalender Upcoming.org, die Profilseiten von Xing, die Kontaktseite von ZKNet.co.uk, die Produktbewertungen von Yahoo! Tech und viele andere Beispiele zeigen, dass Mikroformate bereits heute sinnvoll eingesetzt werden können. Fangen auch Sie am besten schon heute damit an, die Inhalte Ihrer Websites mit Mikroformaten zu veredeln!

Weiterführende Links

• microformats.org .
• Microformats Wiki .
• Mikroformate (deutsch) .
• mikroformate.org (deutsch) .
• The Big Picture on Microformats .

Zum Autor

Michael Jendryschik beschäftigt sich seit Jahren mit den Webstandards des W3C und ist gern gesehener Gast in einschlägigen Newsgroups, Webforen und Mailinglisten. Erfahrungen als Autor sammelte er vor allem durch zahlreiche Veröffentlichungen auf seiner Website und als Fachjournalist. Bekannt ist er durch seine Einführung in XHTML, CSS und Webdesign, die auch als Buch erhältlich ist.

Die geltenden Richtlinien für barrierefreie Webinhalte, die WCAG 1.0 des W3C bestehen nun schon seit beinahe sieben Jahren in unveränderter Form. Ein Nachfolger ist zwar in der Entwicklung, der Zeitpunkt der Fertigstellung steht jedoch in den Sternen. Da wundert es nicht, dass die Web Content Accessibility Guidelines in der Version 1.0 für viele Dinge im Web 2.0 nicht anwendbar sind oder modernere Techniken wie sauberes DOM-Scripting sogar effektiv unmöglich machen, auch wenn diese für die Erstellung Web-basierter Anwendungen zwingend nötig sind.

Dieses Manko kann man den Richtlinien nicht zum Vorwurf machen; stammen sie doch aus einer Zeit, als das Web größtenteils aus, wie es im W3C-Sprech so schön heißt, ‘strukturierten Dokumentensammlungen’ bestand. Für Websites, die lediglich aus statischen Inhalten ohne Interaktionsmöglichkeiten für den Nutzer bestehen sind die Richtlinien, wenn auch mit gewissen Abstrichen, nach wie vor anwendbar.

Rückwärtsgang oder Vorwärtsgang?

Das Web und die verwendeten Techniken haben sich jedoch seit Inkrafttreten der Richtlinien massiv weiterentwickelt. Das vom W3C auch schon mal als worst invention ever bezeichnete JavaScript hat in den letzten zwei Jahren eine phänomenale Wandlung vom Pfuiwort zu einer allgemein anerkannten Technik für die Erstellung von Web-basierten Applikationen hingelegt. Wer hätte gedacht, dass man mittlerweile Flash zusammen in einem Satz mit Barrierefreiheit erwähnen darf? Das Programm hat sich von einer verpönten Spielwiese zu einem ernstzunehmenden Werkzeug für die Erstellung zugänglicher Rich-Media-Inhalte gemausert. Der englische Accessibility-Experte Mike Davies meint dazu: Its time to admit, Flash is part of the web accessibility toolbox.

Auch die von Menschen mit Behinderung vielfach eingesetzten Hilfsmittel sind längst dem unzureichenden Stand der Technik entwachsen, denen die »Until User Agents…«-Klauseln der WCAG 1.0 begegnen sollten. Moderne Screenreader kommen mit zeitgemäßen Scripting-Techniken und auch mit barrierefrei aufbereiteten Flash-Inhalten sowie gut strukturierten PDF-Dokumenten sehr gut zurecht.

Wenn man dynamische Webinhalte mit echten Screenreader-Nutzern testet (und das ist dringend zu empfehlen – Barrierefreiheit ist keine Fingerübung im Abhaken von Checklisten), stellt man oft fest, dass die meisten Hürden gar nicht technischer Natur sind. Vielfach liegt es an einer Mischung aus konzeptionellen Mängeln im Angebot selbst und dem ungewohnten Umgang der Nutzer mit dynamischen Web-Applikationen, resultierend aus der Erwartungshaltung, dass das Web ein weitestgehend statisches Medium sei.

Der theoretische Part

Nach wie vor fordern die Richtlinien von den Anbietern dynamischer Inhalte, zusätzlichen Aufwand in parallele statische Versionen zu stecken, da die WCAG von Hilfsmitteln ausgehen, für die diese Techniken in der Tat ausgesprochen problematisch waren. Man beachte die Betonung auf »waren«. Staatliche Anbieter brauchen gar nicht erst versuchen, dieses Paradoxon aufzulösen – sie sind per Verordnung zur Einhaltung der Richtlinien verpflichtet:

BITV 6.2

Es muss sichergestellt sein, dass Äquivalente für dynamischen Inhalt aktualisiert werden, wenn sich der dynamische Inhalt ändert.

BITV 6.3

Es muss sichergestellt sein, dass mittels Markup–Sprachen geschaffene Dokumente verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte deaktiviert sind.

Privatwirtschaftlich organisierte Anbieter können sich jedoch der eigentlich spannenden Frage zuwenden: wie stellt man die direkte Zugänglichkeit von dynamischen Webinhalten sicher?

Aus Sicht der Anbieter wie auch aus Sicht der Nutzer scheint der Einsatz lange verpönter Techniken wie AJAX sinnvoller als die von den Richtlinien eingeforderten statischen Alternativen. Die verlangten statischen Alternativen sind zudem in Zeiten von Google Office, Excel 2007, Basecamp und .Mac Webmail keine wirkliche Alternative mehr, sondern fördern eher noch die digitale Spaltung, wenn sie nicht sogar konzeptionsbedingt unmöglich sind.

Der Praxisteil

Nehmen wir ein erdachtes, aber durchaus realistisches Szenario: bei einem bekannten Internet-Auktionshaus laufen gleichzeitig tausende Auktionen ab; gleichzeitig wollen zehntausende Bieter wissen, wie das aktuelle Höchstgebot ist. Die Seiten, die kurz vor Ablauf der Auktionen immer wieder neu geladen werden, sind, wie für dieses Auktionshaus typisch, eher etwas zu groß geraten. Das Auktionshaus hat also ein permanentes Problem mit der Serverlast, die Nutzer haben ein permanentes Problem mit den Antwortzeiten des Servers. Und das alles nur, um zu erfahren, ob sich eine vielleicht vierstellige Zahlenfolge geändert hat und man nicht mehr der Höchstbietende ist.

Alleine aus einer simplen Abwägung von Kosten und Nutzen heraus ist es sowohl für das Auktionshaus wie auch für dessen Nutzer ist hier der Einsatz von AJAX oder ähnlichen Techniken sinnvoll. Das jeweils aktuelle Höchstgebot wird in Echtzeit per Skript ausgetauscht, ohne das jedes Mal die kompletten Seiten neu geladen werden. Die von den WCAG eingeforderte statische Alternative gibt es weiterhin (weil ja schon vorhanden) und die Richtlinien zu Barrierefreiheit sind damit (zumindest auf dem Papier) erfüllt.

Dumm nur:
mit der statischen Alternative gewinnt man keine Auktion mehr, da diese zwar WCAG-konform ist, aber damit auch langsamer.

Das Fazit

Tests der WaSP Accessibility Task Force haben ergeben, dass Screenreader nahezu die gleichen Probleme mit Änderungen in Seiten oder Anwendungen haben, egal ob sie dynamisch erfolgt sind oder durch einen kompletten Neuaufbau der Seite. Die Ursache der Probleme scheinen also nicht dynamische Änderungen per Skript zu sein, sondern Änderungen generell.

Es kann eigentlich nur im ureigensten Interesse der Nutzer assistiver Hilfsmittel wie Screenreader, Lupenprogrammen etc. sein, dass Ihre Schnittstellen ins Web 2.0 dessen Möglichkeiten auch vollständig ausnutzen, sie korrekt umsetzen und so eine gleichberechtigte Teilnahme von Menschen mit Behinderungen ermöglichen.

Um dies zu erreichen muss sich die Erkenntnis durchsetzen, dass die Web Content Accessibility Guidelines des W3C lediglich ein Drittel der Richtlinien zur Barrierefreiheit ausmachen. Auch die User Agent Accessibility Guidelines (UAAG) und insbesondere die Authoring Tools Accessibility Guidelines (ATAG) sind ebenso wichtig, um das umfassende Ziel eines barrierefreieren Web 2.0 zu erreichen.

Wenn jedoch weiterhin die gesamte Verantwortung auf die Webentwickler abgewälzt wird, die mit Interimslösungen ihren Redaktionssystemen, Autorenwerkzeugen, aber auch den Browsern und Hilfsmitteln auf die Sprünge helfen müssen, die sich ihrerseits nicht im mindesten an die Standards halten, dann werden damit die Altlasten von morgen geschaffen. Und Interimslösungen können, wie wir alle wissen, ziemlich langlebig sein…

Weiterlesen:

• Accessibility nach Vorschrift: Wenn Web-Entwickler zu Bürokraten werden
• WCAG 2 – was ändert sich?
• Constructing a POUR Website – Putting People at the Center of the Process
• Accessibility explained the Star Wars way

Über den Autor

Tomas Caspers hat eine Hassliebe zu Webbrowsern, die sich bis zu Netscape 0.9b zurückverfolgen lässt. Schon früh erkannte er den Wert standardkonformer Webentwicklung und beschäftigt sich seitdem mit CSS und den Techniken zur Barrierefreiheit. Caspers gehörte 1998 zu den Gründern des Web Standards Project, wo er sich in der Accessibility Task Force darum kümmert, dass moderne Webangebote auch für Menschen mit Behinderung zugänglich werden.