Und wie sieht es aus Sicht der geplagten Webdesigner aus? Müssen die nun die Hände überm Kopf zusammenschlagen, weil noch ein eigenwilliger Browser ihnen das Leben schwer macht? Die Antwort ist ein »Nein« mit Einschränkungen. Denn beim Webdesign muss man genaugenommen nicht so sehr die Macken maßgeblicher Browsern kennen, sondern eher die Macken maßgeblicher Layout-/Rendering-Engines. Das sind diejenigen Software-Module im Browser, die aus HTML-, CSS- und JavaScript-Code diie Darstellung im Browserfenster erzeugen. Da wäre einmal Trident, der Motor des MS Internet Explorers. 1997 für die Produktversion 4.0 entwickelt, hat Trident im Laufe der Jahre zahlreiche Ummodellierungen erfahren und bleibt bis hinauf zum Internet Explorer 8 die treibende Kraft für die Darstellung von Webseiten. Die nächste zu berücksichtigende Layout-Engine ist die Gecko-Engine, die seit Beginn im Firefox-Browser ihren Dienst tut, sowie im Original-Mozilla-Browser, in Netscape-Browsern ab Version 6.x, Flock und anderen. Die dritte bekannte Engine heißt Webkit. Aus der Linux-Engine KHTML hervorgegangen und von Apple für den hauseigenen Safari-Browser weiterentwickelt, verrichtet diese Engine auch in Google Chrome ihren Dienst. Bleibt noch die Engine Presto, die vom Opera-Browser eingesetzt wird. Was Google Chrome in dieser Hinsicht bewirkt, ist also, dass die Webkit-Engine nun endgültig nicht mehr vernachlässigbar ist, wenn es um das Austesten von Webseiten geht. Da Webkit allerdings ähnlich wie Gecko um möglichst genaue Einhaltung der W3C-Vorgaben zu HTML, CSS und DOM bemüht ist, treten zwischen diesen beiden Engines normalerweise keine wirklich dramatischen Unterschiede beim Rendern von Webseiten auf, solange man sich mit einem bewährten Mix aus HTML 4.01, CSS 1.0 und 2.1 und DOM 1.0 und DOM 2.0 begnügt. Wichtig ist allerdings, dass das HTML standardkonform und fehlerfrei ist. In dieser Hinsicht ist Webkit der Erfahrung nach etwas pingeliger als Gecko. Auf webkit.org können sich Entwickler im Zweifelsfall über Details der Webkit-Engine schlau machen, z.B. über die unterstützten Standard-Features und über Extras wie die genuine Unterstützung von SVG-Grafiken (mit Google Chrome kann man sich deshalb auch auf SVG-Beispiele stürzen).

Neuland ist indessen die völlig neu entwickelte V8-JavaScript-Engine des Google-Browsers. Über deren Internas muss ein Webdesigner allerdings zunächst einmal auch nicht so viel wissen. Es handelt sich um eine Implementierung des ECMA-262-Standards (3. Edition). Die Engine übernimmt alles, was mit JavaScript-Core-Objekten und mit der internen Verwaltung von Variablen, Objekten usw. zu tun hat. Was mit DOM zu tun hat, also Element-Manipulation, Event-Handling usw., wird wiederum von Webkit bereitgestellt. Ein separates Austesten javascript-lastiger Webseiten mit Google Chrome ist jedoch dringend zu empfehlen.

Für eine Einschätzung, wie bedeutend der Einfluss von Google Chrome in Zukunft tatsächlich sein wird, ist es meiner Ansicht nach noch zu früh. Zum Redaktionszeitpunkt dieser News werden für den Neuling auf Clicky Webanalytics 2,0% Prozent Marktanteile verzeichnet, eine Zahl, die sich auf die Auswertung von über 45.000 Websites stützt. Auch wenn man davon ausgehen kann, dass viele Nutzer den Browser zunächst einmal nur mal aus Neugierde ausprobieren, so zeichnet sich doch ab, dass er in Zukunft keine Marginalrolle spielen wird. Dafür wird allein schon die Verlinkung auf der Google-Startseite sorgen, um die so gut wie kein Webanwender herum kommt. Und jetzt werde ich mit dieser bösen Software einfach noch ein paar befreundete Sites absurfen, um auch deren Anbietern eine Freude zu machen …

Ab dem heutigen 2. September 2008 soll er unter http://www.google.com/chrome oder http://gears.google.com/chrome/ zum Download angeboten werden. Beide Adressen funktionieren zum Redaktionszeitpunkt noch nicht, was vermutlich daran liegt, dass in den Vereinigten Staaten gerade mal die ersten Hähne zu schreien beginnen.

Eigentlich ist es in Fachkreisen seit langem ein bekanntes Gerücht, dass Google an einem eigenen Browser arbeitet. Doch die plötzlich verratene, unmittelbar bevorstehende Veröffentlichung, durch ein Blog-Posting und ein geschickt platziertes Intro-Comic ohne weiteres Presse-Trarar inszeniert, sorgt für die nötige »Atmosphäre«.

Zu den Fakten:

• Der Chrome-Browser wird unter OpenSource-Lizenz vertrieben.
• Im ersten Beta-Stadium wird er für MS-Windows-Systeme verfügbar sein, später auch für andere Systeme.
• Der Browser verwendet Webkit als Rendering-Engine, die auch im Apple-Browser Safari zum Einsatz kommt.
• Der Browser arbeitet wie alle modernen Browser tab-orientiert. Er unterscheidet sich jedoch von anderen Browsern dadurch, dass jeder Tab einen eigenen Prozess spendiert bekommt, was zur Folge hat, dass eine problematische Webseite nicht den ganzen Browser zum Absturz bringen kann, sondern nur den betroffenen Tab.
• Der Browser bringt eine von Googles "V8-Team" aus Dänemark völlig neu entwickelte JavaScript-Engine mit. Damit sollen moderne Webanwendungen, die intensiv mit Ajax arbeiten, deutlich performanter und speichersparender ausgeführt werden als mit gegenwärtigen Konkurrenz-Browsern.
• Ähnlich wie Opera 9.5x bietet Chrome die Möglichkeit an, auf der persönlichen Startseite bis zu neun als Miniaturscreens dargestellte Favoriten-Sites zu definieren.
• Chrome bietet unter der Bezeichnung »Incognito« eine Sicherheits-Funktion an, die in etwa der neuen »InPrivate«-Funktion des MS Internet Explorers 8 entsprechen soll, die derzeit ebenfalls in der Beta-Phase ist. Dabei wird sichergestellt, dass keinerlei Cache- oder Cookie-Daten nach Beenden einer Website von dort auf dem Rechner bleiben.
• Der Chrome Browser installiert von Haus aus Google Gears, eine Technologie zur Offline-Nutzung von Webanwendungen.

Nun hat Google schon diverse Services und Produkte gestartet, die ein eher kümmerliches Dasein fristen. Inwieweit es dem Browser gelingen wird, die große Masse der Internet-User zu erreichen, von der doch bekannt ist, wie träge sie sich in Bezug auf Software-Wechsel verhält, bleibt erst einmal abzuwarten. Manch einer redet schon von einem Wendepunkt in der Geschichte. Sicherlich — der Browser ist das Fenster, durch das die Menschen ins Netz sehen. Und mit der Gears-Technologie kann Google kaum verhehlen, dass sein Produkt nicht nur auf dem Browser-Markt punkten will, sondern versucht, eine neue Desktop-Funktionalität zwischen Betriebssystem-Oberfläche und Internet zu etablieren. Neben aller Euphorie darüber, einen neuen Browser zu entdecken, werden sich aber auch wieder allerlei Zeigefinger erheben, wie bei allen Aktivitäten von Google. Über die Datenkrake Google wird wieder heiß diskutiert werden, und dass Google die Weltherrschaft anstrebe. Stoff genug also für einen spannenden Tag am Bildschirm.

»Neue Medien verlangen neue Regeln«, lautet dagegen eine immer häufiger zu vernehmende Ansicht. Aktuell ist sie im Datenschmutz-Blog unter dem Titel Schreib.Stilistik: Der Blogger und sein Journalist nachzulesen, der wiederum auf den Artikel Journalistische Einfallslosigkeit: Mehr Format wagen! von Klaus Jarchow verweist.

Doch worin bestehen diese neuen Regeln? Wie Klaus Jarchow beobachtet, ist die oberste Regel fürs Schreiben im Netz jedenfalls nicht zwangsläufig das so oft proklamierte »Keep it simple«, dem manchmal auch noch Handlungsanweisungen wie »schreibe keinen Satz mit mehr als einem Komma und mehr als 10 Wörtern« hinterhergeschoben werden. Moderne Bildschirme sind schließlich keine kopfwehverursachenden Röhrenmonster mehr, und Screenreader können zumindest leidlich artikulieren. Ob ein Text auch wirklich gelesen wird, hängt viel stärker davon ab, wie viel Spannendes er zu sagen hat. Das können Neuigkeiten sein, doch auch bereits Bekanntes wird bewusst gelesen, wenn es sich nicht wie lauwarme Gemüsebrühe ins Hirn ergießt, sondern die Rezeptoren fesselt wie ein meisterlich zubereitetes Tandoori-Gericht.

Nun gilt das eigentlich für alle Medien, in denen geschriebener Text eine Rolle spielt. Also auch für klassische Printmedien. Doch worin besteht dann der vielbeschworene Unterschied zwischen Print- und Online-Medien? Antwort: es gibt eigentlich keinen Unterschied. Es gibt interessante und langweilige Texte. Der Unterschied besteht darin, dass Texte im Netz viel mehr Konkurrenz haben als in der Print-Welt, wo die Texte mit Herstellungskosten verbundenen sind. Eine produktionsbedingte Knappheit von Inhalten gibt es im Netz nicht mehr. Alles, was von halbwegs stabilen Webservern ausgeliefert wird, erreicht den Leser mit technischer Chancengleichheit. In den nachwachsenden Generationen verklingt außerdem der Hall ehrfurchtsgebietender Namen traditionsreicher Redaktionen und Publikationsorgane. Gelesen wird, was Interesse weckt, und Interesse weckt, was auffällig gut geschrieben ist. Egal, ob es sich um alltägliche Blog-Beiträge, um Essays von bleibendem Wert, um technische Dokumentation, um begleitende Texte zu multimedialen Inhalten oder um Texte mit Werbefunktion handelt. Besonders unter Bloggern wächst in letzter Zeit die Sensibilität für Interesse weckendes Texten, was sich in entsprechenden Anleitungen niederschlägt. Halten wir uns — wenn auch nur für dieses eine Mal — an die Behauptung, wonach »50 ways to leave your lover« nur wegen des Titels ein Hit geworden sei. Die 27 Sätze sind nämlich hiermit erschöpft.

Vermutlich ist das auch der Grund dafür, warum Frameworks in JavaScript mittlerweile eine so wichtige Rolle spielen. Nicht immer möchte sich ein JavaScript-Programmierer jedoch in die Regeln eines Frameworks zwängen. Manchmal besteht der Wunsch einfach nuir darin, ein paar aus PHP bekannte und in PHP häufig verwendete Standardfunktionen zur Verfügung zu haben.

Genau diesen Wunsch erfüllt das PHP to Javascript Project des niederländischen OpenSource-Programmierers Kevin van Zonneveld. In einer einzigen JavaScript-Datei namens php.js sammelt er JavaScript-Implementierungen beliebter PHP-Funktionen wie zum Beispiel array_diff, array_key_exists, array_map, in_array, ksort, rsort, date, mktime, addslashes, binhex, htmlspecialchars, md5, printf, wordwrap, base64_decode, serialize oder utf8_decode, Die entsprechenden Funktionen sind teilweise Implementierungen komplexer Algorithmen. Von der aktuell ca. 160 KByte großen JavaScript-Datei gibt es auch eine quelltext-sparende Variante, die mit derzeit 57 KByte auskommt. Natürlich kann man sich auch nur einzelne benötigte Funktionen aus der Funktionsbibliothek in eigene JavaScript-Quelltexte kopieren. Die Funktionsbibliothek wird unter MIT-Licence vertrieben, welches eine GPL-kompatible OpenSource-Lizenzform ist.

Erwin Forner gehört zu meinen frühen Wegbegleitern im Web. Einer, der schon lange vor der Jahrtausendwende im GERINT-Forum von CompuServe durch unorthodoxe, anregende Gedanken rund ums Internet und seine Technologien auffiel. Einer, der aus der grafischen Ecke kam und nicht so viel Verständnis für Markup-Sprachen hatte, mit denen man nur höchst unzulänglich Pixel kontrollieren konnte. Einer, der den Mut hatte, von Grafik und Webdesign als Selbständiger zu leben und der kein Hehl daraus machte, dass er immer auch vom kommerziellen Blickwinkel her dachte. Einer, der schon viel früher alles viel bunter im Web haben wollte, als es modem-übliche Bandreiten erlaubten und herrschende Lehrmeinungen wünschten.

Ein guter Einstieg in Erwin Forners Sicht der Dinge ist sein KriT-Apfel-Intefview aus dem Jahr 2000. Seine Querdenkerei brachte ihm sogar die Bezeichnung der böse alte Mann des Internet ein. Don Alphonso alias blogbar.de gab es eben damals noch nicht im deutschsprachigen Web. Auch war es noch nicht die Zeit der Blogs und Blog-Kommentare. Es war eher noch die Zeit der Mailinglisten. Erwin Forner gehört zu den Gründern der i-worker Mailingliste. Nichtsdestotrotz wurde auch er zu einem Blogger mit Marke. Erwin Forner - Zwischen Genie und Wahnsinn ist dabei nur sein jüngstes Werk. Voraus ging diesem das Lebensbewältigungs-Blog rund um die Geschichte mit der Filipina alias Annalyn Forner. Neben diesen Spuren im Web hinterlässt Erwin Forner übrigens auch Gedrucktes.

Danke, Erwin, für deine Gedanken!

Hash-Funktionen stellen eine Einwegverschlüsselung dar, d.h. es gibt keine Gegenfunktion zum Entschlüsseln. Eine Hash-Funktion erzeugt aus beliebigen Daten einen Prüfsummen-String mit fester Länge (bei MD5 ist es ein String mit 128 Bit). Gibt der User sein Passwort richtig ein, führt die Anwendung des Hash-Verfahrens wieder zum gleichen Prüfsummenergebnis.

Wenn es um Login-Passwörter für eine Quassel-Community geht, ist dieser Schutz im Falle eines nicht autorisierten Auslesens der gespeicherten Passwortdaten sicherlich ausreichend. Wenn es jedoch um sensiblere Daten geht, beispielsweise um Kreditkartennummern oder bei Zugangsdaten zu persönlichen Daten, die wiederum andere wichtige Zugangsdaten enthalten, sollte man sich als Entwickler ein paar Gedanken mehr machen.

Ein amüsant geschriebener und lesenswerter Beitrag zu diesem Thema ist der Blog-Beitrag Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes von Thomas Ptacek. Er macht deutlich, dass die hohe Verarbeitungsgeschwindigkeit von Hash-Algorithmen wie MD5 in Verbindung mit moderner Rechenleistung und mit Attackier-Methoden wie Rainbow Tables das Knacken von MD5-gehashten Daten durchaus lohnenswert macht.

Als eine mögliche Lösung, die Datendieben das Leben schwerer macht, werden sogenannte Salts empfohlen. Ein Salt (das kann irgendeine Zahl oder Zeichenkette sein) schützt vor Angriffsbeschleunigern wie Rainbow Tables. Als weitere Lösung nennt Thomas Ptacek das Secure remote password protocol (SRP). Dieses weniger bekannte Verfahren basiert auf Schlüsseltausch. Im Gegensatz etwa zu X.509 oder OpenPGP erfordert es jedoch keine Zertifikate und Zertifizierungsverfahren. Ein User kann sich damit einem System gegenüber mit Hilfe eines Passworts identifizieren.

Thomas Ptacek äußert gegenüber der SRP-Lösung jedoch diverse Bedenken. Das Verfahren sei patentiert, was den Anwender juristisch vom Wohlwollen des Patentinhabers abhängig macht. Außerdem sei damit zu rechnen, dass Implementierungen in beliebten Programmiersprachen wie PHP zunächst lausig und unzuverlässig seien. Als der Weisheit vorläufig letzter Schluss verkündet Ptacek stattdessen das Verschlüsselungs-Tool bcrypt. PHP-Entwickler, die damit nun gar nichts anfangen können, sollten sich einmal mit dem Portable PHP password hashing framework beschäftigen.

Für die Mehrheit der Anwender werden dabei Neuerungen wie die neue, visuelle Miniatur-Screenshot-Vorschau beim Tab-Wechsel mit [Strg]+[Tab] im Vordergrund stehen. Für Webentwickler, die heute schon gerne mal die Features von morgen testen wollen, dürfte aber auch die Unterstützung einiger HTML-5-Features interessant sein. Wie das Magazin Maclife berichtet, wird Firefox 3.1 die beiden neuen HTML-5-Elemente video und audio unterstützen.

Maclife verrät auch noch mehr Details: so soll Firefox 3.1 die beiden Elemente so interpretieren, wie sie zunächst vorgesehen waren: nämlich mit in die Browser-Software integrierten Dekodern für die OpenSource-Multimediaformate OGG Vorbis (Audio) und OGG Theora (Video). Das Magazin betont, dass Apple und Microsoft durchgesetzt hätten, dass nicht nur diese beiden Formate unterstützt werden, sondern (gegebenenfalls via Plugin) auch andere Formate.

Angesichts des Mega-Erfolgs von YouTube und vergleichbarer Services stellt sich der kritische Sachverstand allerdings die Frage, welche Chance die neuen HTML-5-Elemente audio und video tatsächlich haben werden, wo doch mit Flash alles so einfach geht und längst auf breiter Basis funktioniert. Allerdings könnte auch Flash davon profitieren, wenn es sich mit Hilfe der neuen, spezialisierten Multimedia-Elemente in HTML referenzieren ließe. Denn die derzeit übliche Praxis zur Referenzierung von Flash-Movies, ein Markup-Kauderwelsch aus object und embed mit vielen historisch gewachsenen Attributen, bedarf dringend einer semantischen Überarbeitung.

Firefox ist auch nicht der einzige Browser, dessen Entwicklerteam bereits unruhig nach HTML 5 schielt. In der Schmiede das Opera-Browsers ist man auf Sichthöhe. Derzeit ist eine experimentelle Opera-Version downloadbar, die ebenfalls die HTML-5-Elemente video und audio mit Dekodern für die OGG-Formate unterstützt. Auf der verlinkten Seite finden Sie auch Links zu Beispielseiten, auf denen Sie die multimedialen HTML-5-Fähigkeiten der Browser austesten können.

So weit es möglich und vertretbar ist, sollen jedoch nicht nur konventionalisierte Klassennamen herhalten, um Mikroformate zu definieren. Deshalb gibt es noch einige andere, sogenannte Design Patterns zur Definition von Mikroformaten. Man möchte eben so gut es geht sinnvolles, vorhandenes HTML-Markup zur Definition von Mikroformaten nutzen. Eines dieser Design-Patterns, nämlich das abbr-Design-Pattern, ist zuletzt heftig in die Diskussion geraten. Denn bei diesem Pattern wird das Universalattribut title= genutzt, um semantische Informationen zu speichern. Leider hat sich herausgestellt, dass es dabei zu Konflikten mit anderen HTML-Interpretationsabsichten kommt. So blenden viele Browser den Inhalt von title-Attributen beim Überfahren des Elementinhalts mit der Maus in einem Tooltipp-Fenster ein. Auf viele Anwender wirkt es jedoch irritierend, wenn in einem solchen Fenster eine Information wie 2008-07-30T20:45+01:00 auftaucht, die eigentlich für auslesende Software gedacht ist, nicht für Menschen. Dazu kommt, dass einige Screenreader so einstellbar sind, dass sie den Inhalt des title-Attributs in abbr-Elementen laut vorlesen. Diese Tatsachen haben den englischen Sender BBC dazu bewogen, hCalendar-Mikroformate aus seinen Inhalten zu entfernen. Innerhalb der Mikroformate- und eigentlich der ganzen Webstandards-Szene wurde das als herber Rückschlag empfunden, da gerade die BBC zu den wichtigsten großen Vorreiter-Websites für den Einsatz von Mikroformaten gehört.

Matthias Pfefferle, Betreiber des Notizblogs, beschäftigt sich intensiv mit Mikroformaten. Heute hat er einen Blick in die entstehende HTML5-Spezifikation geworfen. Dabei ist ihm das neue time-Element aufgefallen, welches einen semantisch sinnvollen Ausweg aus der abbr-Design-Pattern-Misere weist. Mit seinem datetime-Attribut ist es wie geschaffen für Datums-/Zeitangaben innerhalb des hCalendar-Mikroformats.

HTML5 is made for Microformats, titelt Pfefferle deshalb. Als weiteres Beispiel nennt er das besondere HTML-5-Universalattribut data-. Dieses kann beliebige Ausprägungen haben, es muss lediglich mit data- beginnen. Damit eignet es sich hervorragend, um maschinenlesbare Daten aufzunehmen, während im Elementinhalt menschenlesbare Inhalte stehen können.

Innerhalb des Wikis von microformats.org wurde mittlerweile auch eine Seite mit dem Titel Microformats in HTML 5 eingerichtet, die alle für Mikroformate relevanten Neuerungen in HTML 5 dokumentieren soll.

• http://www.webcreme.com/
• http://www.mostinspired.com/
• http://www.webdesignerwall.com/trends/2008-design-trends/
• http://www.cssbeauty.com/
• http://www.cssclip.com/
• http://bestwebgallery.com/

Die Sites ähneln sich darin, dass sie andere, ausgesuchte Websites in Form von Vorschau-Screenshots verlinken. Die Ziele sind häufig Homepages von Leuten oder Agenturen, die Design und Kreativität anbieten und deshalb natürlich durch avandgardistisches Webdesign auffallen wollen.

Dass es sich vorwiegend um Ziele im angloamerikanischen Raum handelt, ist vielleicht von Vorteil. Denn so führt die Reise in teilweise andere als hierzulande übliche Vorstellungen von schönen oder spannenden Farbkombinationen. Auch mutig platzierte Grafiken oder Schriftzüge sowie collage-artige Anordnungen statt Standard-Zwei- oder Dreispalter sind bei vielen der verlinkten Websites als Stilmittel erkennbar. Ganz unterschiedlich sind allerdings die technischen Prioritäten. Vom reinen Flasher bis zum XHTML-strict-Apostel ist alles dabei.

Ein paar direkte Beispiele noch zum Abschluss:

• http://www.loewydesign.com/
  Blau-in-Blau-Komposition mit interessanter Navigation
• http://e-knjige.net/novosti/
  Derzeit nicht ganz unbeliebte Spielerei, Webseiten als vergilbtes Buch zu gestalten. Über Hintergründe dieses Formwillens darf spekuliert werden.
• http://adaptd.com/
  Gewollt gewagte Verstöße gegen gutbürgerliche Usability-Regeln oder geschmackloser Farbrausch ohne geringstes Gespür für Formen?
• http://www.cakephp.org/
  Ebenfalls gewagt vielfarbig, großschriftig und mit dezent eingestreuten schiefen Ebenen versehen.

Verständlich daher der Ansatz, den Wunsch "sagt mir, wie gut meine Website ist!" einem "…ator" zu überlassen, also einer Software-Maschine, die eine Site nach einem Kriterienkatalog durchforstet und abschließend bewertet. Mittlerweile gibt es einige solcher Maschinen (sprechen wir besser von web-basierten Services, sonst versteht uns keiner mehr).

Beginnen wir mit dem hochoffiziellen Designministerium. Dieses bietet einen Bürger-Service namens Designbewerter an. Wie — das Ergebnis erscheint Ihnen nicht seriös? Na gut, Britta Boland und Michael Zirlewagen, Lehrbeauftragte der FH Düsseldorf in den Fachbereichen Design und Medien, die Macher hinter dem Designministerium, haben es nicht bös gemeint. Sie brauchten nur ein Thema für einen Sommersemester-Kurs.

Den Wert einer Site ernsthaft zu vermessen verspricht dagegen der Service Seitwert. Es gibt sechs Blöcke von Faktoren, darunter die Gewichtungen bei Google und Yahoo, die Verlinkungsdichte bei Social-Bookmark-Services sowie technische Details beim Seitenlayout. Websites können bei ganz unterschiedlichen Faktorenblöcken punkten, was insgesamt eine gewisse Chancengleichheit schafft. Inwieweit die Ergebnisse jedoch tatsächlich eine objektive und nicht nur eine irgendwie errechnete Beurteilung darstellen, sei dahingestellt. Die FAQ verraten, dass der Seitwert-Service mit zahlreichen netztechnischen Problemen zu kämpfen hat, für die er nichts kann, und dass die Bewertungsalgorithmen fortlaufend verbessert werden. Offengelegt werden die Algorithmen jedoch nicht. Auch ist der Service nicht uneingeschränkt nutzbar, da die Anzahl erlaubter Abfragen pro Tag begrenzt sind. Übrigens: der Versuch, seitwert.de selber mit seitwert.de zu testen, wird mit der Meldung »Ach nee…möchte ich nicht testen« quittiert.

Seitwert wird von ActiveValue, einer Düsseldorfer Online-Agentur, bereitgestellt. Ganz ähnlich verhält es sich mit dem Qualidator, einem weiteren Rundum-Checker-Service für Websites, von dem es auch eine Variante gibt, den Qualidator Singlepage Analyzer. Das von dem Unternehmen seven49.net bereitgestellte Tool konzentriert sich stärker auf die Technik von Webseiten und weniger auf die vorhandene Sichtbarkeit in Suchmaschinen. Für Webdesigner, die neu entwickelte Projekte technisch überprüfen möchten, ist der Qualidator deshalb wohl die bessere Wahl. Auch bei diesem Tool sind die Bewertungsalgorithmen nicht offen dokumentiert. Mit der Anwendung auf sich selber hat der Qualidator allerdings keine Probleme und verkündet selbstbewusst: »Gratulation! Die getestete Website schneidet in der Gesamtanalyse exzellent ab und spielt in der "Premium League"!« Na, denn!

Caspers erregt Diskussionsbedarf, indem er die Erwartung, dass ein Experte sich mit dem genauen Definieren von Barrierefreiheit schwer tut, enttäuscht. Stattdessen liefert er eine schlichte Definition: »Websites sind dann barrierefrei, wenn sie von Menschen mit Behinderung genau so effektiv und effizient genutzt werden können wie von Menschen ohne Behinderung.«

Bei den Erläuterungen zu dieser Definition schafft Caspers zwar noch den Bogen zu der vorherrschenden Expertenmeinung, dass Barrierefreiheit doch nichts so Triviales ist. Doch der Samen ist gesät: Barrierefreiheit ist machbar, so die Kernaussage.

In den Kommentaren zu Caspers Eintrag tritt vor allem Lothar Beier als Antipode auf. Der auf seiner Website wirbt: »Ich mache Webseiten und Themes für WordPress - schön, preiswert, benutzbar, barrierearm und nach den aktuellen Standards des W3C"«. Nichtsdestotrotz nimmt er in der Diskussion zu Caspers Artikel die Rolle des zynischen Realisten ein: »Und deshalb sollten die Dogmatiker der Barrierefrei-Szene endlich mal aufhören, unerfüllbare Forderungen zu stellen, dann könnte man nämlich das tun, was machbar und sinnvoll ist«.

Stiller Konsens der Diskussion scheint mir zu sein: Barrierefreiheit ist nicht so einfach definierbar, aber sie ist erforderlich. Kathederartige Lehrmeinungen darüber, worin barrierefreie Websites bestehen, sind mit Vorsicht zu genießen. Die Kunst der Barrierefreiheit liegt eher im Blick fürs Detail: es zählt das Gespür, welche Grafik welchen Alternativtext benötigt, was ein vorlesender Screenreader unverständlich oder missverständlich rüberbringen könnte usw.

Vielleicht sind Sie als unbedarfter Leser aber auch über den Namen Webkrauts gestolpert. »Krauts« ist im angloamerikanischen Wortschatz ein liebevoll abfälliges Attribut zur Kennzeichnung der selbstquälerischen deutschen Seele mit ihrer faszinierenden, unberechenbaren und gefährlichen Produktivität. Die Webkrauts wissen das und haben sich bewusst so genannt. In der hier verlinkten Diskussion tritt die problematische deutsche Seele allerdings ziemlich unreflektiert deutlich zum Vorschein. Abhilfe schafft vielleicht ein schöner und kluger Spruch von Accessibility-Experte Eric Hellbusch: HTML ist das Handwerk, CSS ist die Kunst.

Eine Konvention setzt sich auch nicht zwangsläufig durch, indem sie von einem gewichtigen Gremium geschaffen wird. So gibt es viele W3C-Spezifikationen, die so gut wie niemanden interessieren, während viele damit beschäftigt sind, proprietäre Lösungen für den gleichen Zweck zu entwickeln.

Auch das Einreichen einer RFC muss nicht für alles und jedes herhalten, was nicht im engeren Sinne mit dem Internet-Betrieb zu tun hat. Bleibt die Variante, es auf eigene Faust zu probieren.

Ein Beispiel dieser Art, das vielleicht als Vorbild dienen kann, ist die Restaurant Markup Language (RestaurantML). Diese XML-Sprache wird auf einer eigens dafür eingerichteten Website vorgestellt: http://www.restaurant-ml.org/

Die Sprache dient dazu, Restaurant-Daten wie Größe, Öffnungszeiten, Speisen- und Getränkekarten, besondere Angebote usw. zu beschreiben. Entwickelt wurde sie — wen wunderts? — von einem Restaurantführer namens Foodloos. Die RestaurantML wurde jedoch ausdrücklich unter CreativeCommons-Lizenz gestellt und ist damit frei nutzbar.

Auf der Entwicklerseite zur RestaurantML kann man außerdem sehr gut sehen, wie ein praktisch denkender Spracheinführer denkt: neben einer ausführlichen Dokumentation wird auch um die Entwicklung von Client-Bibliotheken in wichtigen Programmiersprachen geworben. Denn XML-Sprachen — das weiß der Anbieter wohl — sind letztlich davon abhängig, wie gut sie software-technisch unterstützt werden. Ein griffiges Gesamtkonzept: nachvollziehbar strukturierte Markupsprache, im Sinne von OpenSource frei nutzbar und mit frei verfügbaren Software-Klassen, funktionierende Implementierungsbeispiele — vielleicht ist das ja die Zukunft, wie sich Websprachen etablieren lassen.

Wer sich näher mit den Anforderungen des "mobilen Web" befassen möchte, sollte die vorgeschlagene W3C-Empfehlung Mobile Web Best Practices 1.0 kennen. Der Titel "Best Practices" verrät schon viel von der Problematik: es geht hier vorwiegend um Kompromisse und Rücksichten bei der Gestaltung normaler Webseiten.

Damit es nicht bei gutgemeinten Tipps bleibt, bietet das W3-Konsortium im Zusammenhang mit den Mobile-Empfehlungen einen frei nutzbaren Online-Site-Check an: den W3C mobileOK Basic Checker. Der Service, der im Stil eines Validators arbeitet, untersucht etliche Kriterien einer beliebigen HTTP-URL-Adresse — vom Webserver-Verhalten über Zeichenkodierungen, Bemaßungsangaben in CSS bis hin zu Dokumentgrößen und Layout-Techniken.

Von der Mecker-Orgie des Tools sollte man sich allerdings nicht gleich völlig niederschmettern lassen. Selbst viele Webseiten, die sonst mit allerlei Validitäts-Buttons und Barrierefrei-Flair daherkommen, bekommen von diesem kritischen Spürhund noch einiges auf die Mütze. So werden beispielsweise alle Webseiten ermahnt, deren Gesamtumfang inklusive referenzierter Dateien 10 Kilobyte überschreitet (denn das ist bei diversen Handy-Volumentarifen die Menge an Daten, die sich auf den Abrechnungsbetrag auswirkt). Auch alle input- oder textarea-Felder, die keinen Defaultwert enthalten, werden als benutzerunfreundlich angemeckert. JavaScripts sowieso, und für HTTP-Header, die das Neuladen einer Seite erzwingen, gibt es immerhin eine Warnung (PHP-Scripts senden beispielsweise gerne HTTP-Header, die das Neuladen einer Seite erzwingen, damit bei dynamischen Webseiten aktuelle Daten geliefert werden). Kurzum, der W3C mobileOK Basic Checker ist ganz schön streng. Entscheiden muss letztlich des Webdesigners Gewissen, das sich meistens auch in diversen anderen Sachzwängen befindet. Und es bleibt ja auch noch die Möglichkeit, die eigene Website selber mal mit dem Handy zu besuchen …

Die meisten HTML-Autoren wissen, dass HTML-Parser mehrere aufeinanderfolgende, sogenannte Whitespace-Zeichen zu einem Leerzeichen zusammenfassen. Whitespace-Zeichen können Leerzeichen sein, aber auch Sonderzeichen für Zeilenwechsel sowie Tabulatorzeichen. Es handelt sich dabei um die Sonderzeichen mit den Werten 0x9 (= dezimal 9, Tabulatorzeichen), 0xA (= dezimal 10, Zeilenvorschub-Zeichen, in Programmiersprachen häufig in der Form \n notierbar) und 0xD (= dezimal 13, Wagenrücklauf-Zeichen, in Programmiersprachen häufig als \r notierbar). Diese Whitespace-Zeichen gehören zum sogenannten C0-Bereich. Andere Zeichen dieses Bereichs werden von HTML 4.01, XHTML 1.0 und XML 1.0 nicht unterstützt. Lediglich XML 1.1, so klärt der FAQ-Beitrag auf, erlaubt es, solche Zeichen explizit zu notieren, und zwar in Form üblicher numerischer Entities. So ist es in XML 1.1 beispielsweise möglich, durch Notation von  ein Beep-Zeichen zu referenzieren. Ob sich ein Rechner, der einen solchen XML-Inhalt parst, allerdings dazu überreden lässt, tatsächlich ein Beep von sich zu geben, sei dahingestellt.

Im Wikipedia-Artikel über Steuerzeichen werden übrigens alle Steuerzeichen der Bereiche C0 und C1 aufgelistet und erläutert. Viele davon haben heute nur noch historische Bedeutung. Verständlich, dass es im Rahmen von 1-Byte-Zeichenkodierungen, wo jeder Zeichensatz nur 256 Zeichen haben kann, als ärgerliche Verschwendung empfunden wird, wenn so viele überflüssige Steuerzeichen den Raum einschränken. Interessant ist deshalb bezüglich des C1-Bereichs ein Hinweis, der auch in dem von Jens Meiert übersetzten W3C-Artikel zu finden ist. Microsoft hat wegen notorischen Platzmangels bei der 1-Byte-Zeichenkodierung manche Codepages so definiert, dass diese im C1-Bereich, also im Zeichenwertbereich zwischen 0x7F und 0x9F (128 bis 159) Nutzzeichen enthalten. Ein beliebtes Beispielzeichen dieses Bereichs ist etwa der Gedankenstrich, der unter Windows mit [ALT]+[0][1][5][0] (Ziffern auf dem abgesetzten Ziffernblock) erzeugbar ist. Auch wenn einige Browser so erzeugte Zeichen im HTML-Quelltext entsprechend der Microsoft-Codepage-Definitionen interpretieren, so sind solche Zeichen aus HTML-Sicht doch unzulässig. Wer also beispielsweise einen Gedankenstrich erzeugen möchte, notiert in HTML besser gleich ein —.

Die Software-Schmiede Blumentals aus der lettischen Hauptstadt Riga legt mit WeBuilder einen All-in-one- bzw. Universaleditor vor.

Mit 49,85 Euro für kommerzielle Nutzer (35,85 Euro für Privatnutzer) siedelt sich das Shareware-Produkt, das man selbstverständlich als voll funktionsfähige Testversion downloaden kann, eher im oberen Preisbereich an. Doch für den Preis eines guten Fachbuchs erhält man ein Code-Werkzeug, das wirklich keine Wünsche mehr offen lässt. Deutschsprachige Benutzeroberfläche inklusive.

Zu Selbstverständlichkeiten wie Syntax-Highlighting, Editieren großer Dateien, Zeilennummerierung, Zeilen-Lesezeichen, UTF8-Unterstützung, Auto-Vervollständigung, FTP-Upload, Code-Bibliothek für Code-Schnipsel, integrierte Browser-Vorschau oder Projektverwaltung findet man auch Funktionen im Repertoire, die nicht alltäglich sind: integrierter PHP-Debugger, konfigurierbare Code-Formatierung, HTML-zu-PHP-Konvertierung (in echo- oder print-Konstrukte), Kopieren mit Syntax-Highlighting (z.B. um Code visuell attraktiv in Dokumentationen zu übernehmen), dialog-gestütztes, visualisiertes Bearbeiten von CSS-Boxdefinitionen, integrierter SQL-Exlorer zum Erkunden einer Datenbankstruktur oder zum Austesten von SQL-Statements — um mal einige der besonderen Features zu nennen. Dazu kommen Funktionen, die auch bei einigen anderen Editoren zu finden sind, aber längst nicht zum Standard gehören: so etwa ein voll integriertes HTML-Tidy, integrierte Validatoren für HTML und CSS, Block-Selektion (z.B. für Kopier- und Ausschneide-Aktionen), Suchen/Ersetzen in vielen, auch nicht geöffneten Dateien, selbst mit mehrzeiligen Such- und Ersetze-Ausdrücken und Suche wahlweise mit regulären Ausdrücken, Code-Explorer zum schnellen Anspringen bestimmter Funktionen innerhalb einer PHP-Quelltextdatei, integrierte Referenzen für HTML 4 und CSS 2 usw.

Im Arbeitsspeicher macht sich der WeBuilder deutlich breiter als viele andere Editoren. Bei betagteren Rechner mag das ein mögliches Gegenargument sein. Bei modernen RAM-Dimensionen im Gigabyte-Bereich stellen die vom WeBuilder benötigten Ressourcen jedoch keine nennenswerte Größe dar.

Insgesamt macht der WeBuilder-Editor, der auf den Windows-Versionen 98, Me, 2000, 2003, XP und Vista läuft, jedenfalls einen verdammt vollständigen Eindruck und kommt beim nächsten Mal sicher auch mit auf unsere Buch-DVD.

Wer die volle CSS-Kontrolle über alle HTML-Elemente möchte, muss deshalb das interne Default-Stylesheet eines Browsers entweder kennen oder außer Kraft setzen. Da einzelne Browser nicht zwangsläufig exakt das vom W3-Konsortium beschriebene Default-Stylesheet zum Rendern von HTML verwenden, ist es konsequenter, das Default-Stylesheet ganz außer Kraft zu setzen. Benötigt wird dazu ein Set von CSS-Formatdefinitionen am Anfang des oder der eigenen Stylesheets, die noch gar nichts mit dem gewünschten eigenen Layout zu tun haben, sondern lediglich tabula rasa machen.

Das erfordert mehr Überlegungen als man ahnt, und man tut gut daran, bewährte Lösungen zu übernehmen. Der bekannteste CSS-Reset ist der von CSS-Experte Eric Meyer, zu finden beispielsweise in seinem Blogbeitrag Reset Reloaded (Mai 2007) .

Etwas mehr als nur einen Reset leistet Tripoli (Link dorthin gefunden bei den Frischen Zitronen zum gleichen Thema). Ein Blick in die Basis-CSS-Datei von Tripoli offenbart eine ganze Reihe von Formatdefinitionen, die auf den ersten Blick eher unsinnig erscheinen, aber viel zu dem beitragen, was die englische Spache als "bulletproof" ("wasserdicht") bezeichnet: hinter Sequenzen wie html{font-size:125%}; body{font-size:50%} verbergen sich Erfahrungswerte mit ganz verschiedenen Browsern, wie sie ein einzelner Webdesigner kaum je zusammenbringt. Dazu kommt, dass Tripoli die Formatierungseffekte nicht mehr erwünschter HTML-Elemente wie font in wohlgemeinter erzieherischer Absicht außer Kraft setzt. Zum Anspruch des Sets gehört außerdem die strikte Trennung zwischen Layout-Bemaßung und Typografie. Für CSS-schwache Browser gibt es zusätzliche CSS-Dateien mit CSS-Hacks. Tripoli setzt allerdings eine Einarbeitungszeit voraus, die man wenn überhaupt dann eher für ein vollständiges CSS-Framework aufwänden würde. Die meisten Webdesigner werden deshalb vermutlich doch eher eine überschaubare Reset-Lösung wie die von Eric Meyer bevorzugen.

Viel Zeit bleibt jedoch nicht zum Testen, denn in wenigen Tagen, am 17. Juni 2008, wird der Firefox-Browser in Version 3.0 offiziell erscheinen. Die Spread-Firefox-Initiative hat für diesen Tag einen Download Day 2008 ausgerufen. Die Webanwender dieser Welt sollen helfen, einen neuen Guinness-Weltrekord im Downloaden eines einzigen Produkts innerhalb eines einzigen Tages aufzustellen.

Normalanwender können sich bei Ralph Segerts Video-Anleitungen mit den Oberflächen-Features der neuen Firefox-Version vertraut machen. Welche Verbesserungen Firefox 3 in Sachen Webstandards-Unterstützung en detail bringen wird, muss sich erst noch herausstellen. In jedem Fall soll er den Acid-2-Test für Browser bestehen.

Während der Opera-Browser bei den Marktanteilen für Browser kaum die 1%-Marke knackt (Safari hat mit 6% bereits wesentlich mehr Bedeutung), werden für Firefox aktuell und weltweit immerhin schon 18% ermittelt (in Deutschland und einigen anderen Ländern Mitteleuropas liegt der Marktanteil deutlich höher, teilweise über 30%). Die 3er-Version soll dem Internet Explorer weitere Prozente abjagen.

Letzterer gilt nach wie vor als das große Ärgernis für viele Webentwickler, denen vor allem die immer noch erhebliche Verbreitung der 6er-Version in der Praxis unschöne Verrenkungen abverlangt. Noch hat die Version 7 die 6er-Version nicht endgültig verdrängt, da läutet Microsoft schon die Beta-Phase für Version 8 ein. Als Nachfolger der noch aktuellen Beta 1 Version ist für den Sommer einer Beta 2 Version geplant. Die finale Version erscheint möglicherweise noch im Jahr 2008. Microsoft stellt ebenfalls die Webstandards-Unterstützung neben der Verbesserungen an der Benutzeroberfläche in den Vordergrund der Versprechen. So soll beispielsweise CSS 2.1 wirklich vollständig unterstützt werden.

Das Alltagsgeschäft der client-seitigen Webentwicklung wird durch die neuen Browser-Versionen allerdings nicht unbedingt leichter. Die Vorgänger-Versionen verschwinden ja nicht von heute auf morgen aus dem Netz. Und auch die neuen Versionen werden die meisten Webstandards nicht zu 100% unterstützen. Das fängt bei fehlender Unterstützung für HTML-2-Elemente wie <link> an und endet bei Details in der DOM-Fehlerbehandlung. Doch es ist wichtig, dass sich das Browser-Versionen-Karussell weiterdreht. Denn nur so dürfen sich Webentwickler jedes Jahr etwas mehr trauen, aus dem Reservoire längst vorhandener technologischer Standars zu schöpfen.

Mittlerweile droht jedoch neues Ungemach. Denn ein Feature des kommenden CSS-3-Standards sorgt für neue Grabenkämpfe: das sogenannte CSS Grid Positioning Module. Während die eine Fraktion der Webdesigner das Modell der Grids als Basis für die Realisierung von Webseitenlayouts begrüßt, läuft eine andere Fraktion dagegen Sturm. Die interessantesten Diskussionen finden dabei in letzter Zeit auf den Spielfeldern der Grid-Kritiker statt. Zwei Beispiele seien zur Lektüre empfohlen:

Grid-Layouts – das neue Tabellenlayout?
Mit diesem Posting in seinem Blog F-LOG-GE hat Autor Jens Grochtdreis am 30.05.2008 eine provokant formulierte Frage gestellt. Das neue CSS-Feature, so die These, verderbe den HTML-Code fast so schlimm wie die früher üblichen Tabellenlayouts. Denn Grids verlangen HTML-seitig Elementstrukturen, die denen einer Tabelle ähneln. Die Kritik zielt in diesem Beitrag also darauf, dass Grids den HTML-Autor wieder dazu verleiten, nur in optischen Rastern statt in semantisch sinnvollen Bereichen zu denken. Die Kommentarschlacht zu diesem Blog-Posting ist durchaus lesenswert, auch wenn sie zahlreiche Sticheleien enthält.

Flexible Layouts - die Herausforderung der Zukunft
Dieser Artikel, am 10.06.2008 bei Dr.Web erschienen, wurde von Dirk Jesse geschrieben, dem Anbieter des CSS-Frameworks YAML. Bei Jesse richtet sich die Kritik gegen Grid-Layouts eher gegen die Tendenz, dass Benutzer von grid-basierten CSS-Frameworks wie Blueprint CSS oder YUI Grids leichter zu fixen Layouts tendieren. Auch an diesen Artikel schließt sich eine lange Liste an teilweise wortreichen und konträren Diskussionsbeiträgen an.

Das ist eigentlich nichts Neues und in umfangreicheren Dialogboxen von Anwendungen und Programmen in grafischen Betriebssystemumgebungen seit fast 15 Jahren Standard. Dass diese Möglichkeit im Web nicht häufiger genutzt wird, liegt einfach zum einen daran, dass sie zu wenig bekannt ist. Zum anderen liegt es aber auch daran, dass tabbed Interfaces im Gegensatz zu modernen Aufklappmenüs noch nicht allein mit HTML und CSS realisierbar sind. Es gibt jedoch fertige Lösungen, die sich mehr oder weniger einfach in eigene Website-Umgebungen integrieren lassen. Hier Links zu drei Lösungen dieser Art:

• Tabtastic: Semantisch sinnvolles HTML-Markup, eine CSS- und vier JavaScript-Dateien einbinden, fertig ist der eigene Inhalte-Tabber. Alles ordentlich dokumentiert und einfach integrierbar.

• DynamicDrive Tab Content Script: Semantisch sinnvolles HTML-Markup, eine CSS- und eine JavaScript-Datei. Tabs können sogar via GET-Parameter in der URL-Adresse direkt angezeigt werden.

• Yahoo! UI Library: TabView: vergleichsweise aufwändiges Script, da es in die Yahoo Script-Library eingebunden ist. Kommt hier im Wiki zum Einsatz, weil die Wikidot-Wiki-Syntax für tabbed Interfaces eine eigene, einfache Syntax hat. Intern kommt dabei aber die Lösung von Yahoo zum Einsatz.

Über Friend Connect haben wir berichtet. Zwei weitere interessante Services sind jedoch seitdem dazugekommen. Und beide basieren auf Wiki-Technologie. Seit Google im Jahr 2006 den Wiki-Anbieter JotSpot geschluckt hat, war in Fachkreisen immer wieder darüber spekuliert worden, wie wohl ein daraus weiterentwickeltes Wiki im Google-Gewand aussehen würde.

Anwender von Google Apps kamen schon vor einiger Zeit in den Genuss des neuen Services Google Sites. Mittlerweile ist dieser Service für alle Intererssierten offen. Voraussetzung ist wie für die übrigen Google-Services ein kostenloses Google-Konto.

Google Sites ermöglicht das Anlegen und Pflegen eigener Homepages im Web-2.0-Zeitalter. Der Service konfligiert zweifellos mit dem älteren Service Google Page Creator, der wohl über kurz oder lang mit Google Sites zusammenwachsen wird. Während der Page Creator ein einfacher, web-basierter Wysiwyg-Editor für Webseiten ist, ist Google Sites als Wiki konzipiert. Ähnlich wie bei Google Docs lassen sich einzelne Inhalte (hier: Wiki-Seiten) wahlweise gezielt für bestimmte Personen freigeben oder offen im Web publizieren. Auffällig ist die einfache, vorkonfigurierte Integrierbarkeit von Google-Docs-Dokumenten, YouTube-Videos, Google Videos, Google Kalender und Picasa Webalben in Form von eingebetteten Dokumenten, Videos oder Slide-Shows. Und natürlich sämtliche Google-Gadgets. Beim Anlegen neuer Seiten für Google Sites hat man die Auswahl zwischen Seitentypen wie Webseite (blanko), Dashboard, Announcement, File Cabinet und Listen/Tabellen. Fürs Seitenlayout gibt es eine Reihe von Basis-Layouts, die sich so weit ändern lassen, dass halbwegs eigene Layouts möglich werden. Auf die Layout-Freiheiten beim Entwurf eigener Websites muss man allerdings verzichten.

Google Sites ist eine Lösung für alle, die rasch etwas Ansprechendes im Web publizieren wollen (allein oder als Team), ohne sich mit viel Technik herumzuschlagen. Besonders profitieren werden Anwender, die auch andere Google-Services nutzen und dort erstellte Daten automatisch in die Wiki-Seiten von Google Sites integrieren können.

Bleibt der zweite neue Service: Google Doctype ist nicht wie Google-Skeptiker befürchten werden ein alternativer HTML-Enwurf, sondern ein Versuch aus dem Hause Google, gemeinsam mit Usern, die über entsprechende Fachkenntnisse verfügen, die gängigen Webtechnologien zu dokumentieren. Die Basis des Projekts bildet ebenfalls ein Wiki. Bislang existieren bereits diverse Artikel zu HTML, CSS und DOM. Als Sprachen stehen bislang Englisch, Spanisch, Französisch und Japanisch zur Auswahl.