18.10.09

Über den Sinn typographischer Kreuzzüge, die zwei Ebenen der Textverarbeitung und das Leben.

Die „typografische Verrohung“ nimmt zu. Schuld sollen Schreibmaschinen und das Mitmachweb sein. Warum es nichts hilft, die unkundigen Nutzer zu besserer Typografie überreden zu wollen.

Bevor ich auf meine eigentlichen Thesen zu sprechen komme, sollte klar sein, dass es sich bei Schrift, egal ob gedruckt oder auf dem Bildschirm um ein Mittel zur Kommunikation handelt. Ein Mittel zur möglichst schnellen Kommunikation sollte man dazu sagen. Die Schnelligkeit wird durch gute Lesbarkeit erreicht. Gute Lesbarkeit ergibt sich, je nach Studie, die man heranzieht, aus der Differenzierbarkeit und der Gewohntheit der einzelnen Zeichen und des gesamten Schriftbildes. So wird Arial von vielen als besser lesbar empfunden als z.B. die Dax.

Aber wie man weiß, werden Informationen nicht ausschließlich über den bloßen Text kommuniziert, sondern auch über die Aufmachung dessen. Die Entscheidung der CDU, im visuellen Wahlkampf hauptsächlich auf die langweilige Helvetica zu setzen, sagt beispielsweise viel mehr aus, als die Wahlkampfslogans der Partei. Ein ausgeglichener Grauwert und eine gleichmäßige Linienführung machen Texte aus, die gut lesbar sein und obendrein noch gut aussehen sollen.

Glyphen sind also nur eine Abstraktion von Sprache, welche wiederum der Kommunikation, dem Informationsaustausch dient. Zu den starken Zeiten des Prints gab es kaum Probleme, denn die beiden Faktoren Lesbarkeit und äußere Erscheinung konnten perfekt justiert werden. Aufgrund der Omnipräsenz gut gesetzter Texte mit korrektem Sonderzeichengebrauch, brannten sich diese ausgeglichenen Schriftbilder in die Köpfe der Leser ein, was wiederum dem Faktor der Lesbarkeit zugute kam, denn Gewohntes liest sich besser.

Jetzt kann man aber unweigerlich beobachten, dass das Web die gedruckten Magazine und Zeitungen ablöst. Dadurch, dass sich im Internet die Rollen des Autors, des Lektors und des Setzers in einer Person treffen, bleibt verständlicherweise viel Fachwissen auf der Strecke. Typographisches Fachwissen, wie der korrekte Einsatz von Ganz-, Halb- und Viertelgeviertrichen oder die Anwendung der richtigen Anführungszeichen, sind dabei besonders schwer erlernbar, denn die Technik macht es dem, meist noch lernunwilligen, Benutzer hier besonders schwer.

Schon die Einführung der Schreibmaschinen auf dem freien Markt trug einen Großteil zu der oft genannten typographischen Verrohung bei. Plötzlich musste jeder Mensch per Tastendruck Texte zu Papier bringen können. Die Zusammenlegung von Zoll-, Sekunden- und Anführungszeichen war eine notwendige Einsparung, denn der Platz auf der Schreibmaschinentastatur war begrenzt und man wurde ohnehin schon erschlagen von den ganzen Tasten.

Es war auch eine rationale Entscheidung, das Tastaturlayout der alten Schreibmaschinen auf die Computerbedienelemente zu übertragen. Schließlich hatten die Nutzer schon einmal etwas Neues erlernen müssen, eine nochmalige Umstellung wäre frustrierend gewesen. Dass man dabei auch seltsame Abarten wie die Feststelltaste oder den freistehenden Akzent übernahm, ist aus typographischer Sicht noch vergleichsweise schmerzfrei zu betrachten. Weitaus schmerzvoller sind die alten Hochkommata und der Schreibmaschinen-Akzent, welche sich ungerechtfertigterweise prominente Plätze sichern konnten.

Mit dem Web ist die nächste Stufe der „Verrohung“ erreicht, denn jetzt kann nicht nur jeder schreiben, sondern auch jeder alles lesen, was man schreibt. Ich denke, ich lehne mich nicht allzu weit aus dem Fenster, wenn ich behaupte, dass wohl die Anzahl der „falschen“ Sonderzeichen im Web die der richtigen weit übertrifft. Die Auswirkungen spürt man schon. Gerade Jugendliche schreiben zunehmend auch handschriftlich in angelsächsischer Anführungsmanier. Sogar in die Gestik haben die Hochkommata schon seit Jahrzehnten ihren Einzug gehalten, oder wie oft sieht man jemanden auf der Straße, der beim gestischen Untermalen eines Zitats die deutschen Anführungszeichen in die Luft malt?

und alle so: yeaahh, in Hochkommata

Aber nicht nur der offensichtlichste Grund – die einfache Erreichbarkeit der „falschen“ Zeichen – ist das Problem alleine. So sind auch die umständlichen Formen der Sonderzeichen ihrem Überleben selbst am wenigsten zuträglich. Stets muss man im Kopf haben, ob der Schwung nun nach links, ob die Striche oben, oder ob vor die drei Punkte ein Leerzeichen kommt. Die verbreiteten Webschriften brauchen bei dieser Problematik auch nicht auf Jubel zu hoffen, denn die bekanntlich falsche Form des Verdana-Anführungszeichens ruft nicht nur Gejammer bei Fachkundigen, sondern auch Verwirrung bei den weniger erfahrenen Anwendern hervor.

Meiner Meinung nach darf man den gemeinen Nutzer am wenigsten als Typo-Vandalen beschimpfen und ihn in die Esel-Ecke stellen. Im Gegenteil, ich habe sogar die Hoffnung, dass die Nutzer durch die eben genannten Probleme abgehärtet sind und mit einer Anti-WYSIWYG-Haltung an’s Webtexten herantreten. Dadurch, dass die Zeichen eh überall anders aussehen, wird die Einsicht geschaffen, die ich wichtig halte, für das Konzept, das ich für die Zukunft der Textverarbeitung im Web halte.

Mit einem einfachen Trick, der vielerorts schon, teilweise bewusst, teilweise unbewusst, angewendet wird, macht man dem Schreibenden das Prinzip der zwei Ebenen der Textverarbeitung klar und bringt ihm die Funktionsweise schonend näher. Wovon ich spreche? Ich spreche beispielsweise von jedem Blog-Kommentarfeld, welches sich einer dicktengleichen Schrift bedient. Dadurch wird signalisiert, dass es sich bei dem, woran man schreibt, noch nicht um das Resultat handelt, sondern lediglich um den Inhalt in der Editierebene. Was letztlich auf der Präsentationsebene entsteht, braucht den Schreiberling nicht groß zu kümmern, denn er vertraut der Software; sie wird schon richtig übersetzen und es besser wissen als der Editor. Auf der Editierebene kann dann ungestraft mit Hochkommata und Schreibmaschinen-Akzenten um sich geworfen werden.

Denn im Grunde sind die, gemeinhin als Gänsefüßchen bekannten, Hochkommata richtige Anführungszeichen, nur eben im Schreibmaschinensatz, d.h. nur in Verbindung mit nichtproportionalen Schriften. In Courier sieht 99-66 genauso fremdartig aus, wie die Hochkommata in Times. Die Gewohntheit eines ordentlichen Schriftbildes wird bei der 2-Ebenen-Methode ideal verknüpft mit der Gewohnheit, „Shift+2“ zu drücken, um ein Anführungszeichen darzustellen.

Positiv hervorzuheben sind in diesem Bereich das PHP-Programm Textile, welches die Hochkommata, Akzente, Divis und Ellipsen von alleine, recht intelligent übersetzt. Ein extremes Beispiel, welches sich nicht so leicht mit dem Web verbinden lässt, ist der LaTeX-Editor LyX. Anstatt wie bei Word & Co. den Nutzer direkt am Dokument arbeiten zu lassen, bekommt man nur die Möglichkeit, die Struktur seines Dokuments zu editieren. Wenn man dieses Prinzip in die Webwelt überträgt, ergibt das bessere Semantik und korrektere Typographie.

Das Prinzip mit den zwei Ebenen ist keinesfalls neu, aber im Web meiner Meinung nach nicht konsequent eingesetzt. Dabei bleibt einem mit den derzeitigen Techniken eigentlich gar nichts anderes übrig.

Kommentare

15.07.09

CSS darf kein Skriptsprachen-Elemente-freier Raum sein!

Das CSS-Boxmodel ist erbärmlich unintuitiv und unpraktisch. Bei dem ganzen Geschimpfe muss man zugeben, dass Microsoft mit dem IE-Boxmodel ein gutes Stück voraus war; sei es nun aus Durchblick und Kompetenz oder aus der Unfähigkeit, Standards zu befolgen.

Das größte technische Problem mit dem eigentlichen CSS-Boxmodel tritt auf, wenn man Prozent- und Pixelwerte kombinieren möchte. Eine 60% hohe Box soll einen Text beinhalten, welcher nur 60% minus 20 Pixel hoch ist; mit CSS < Version 3 unmöglich, nicht unmöglich aber für den Internet Explorer.

Abhilfe für das Problem mit den Außenabständen, Rändern und Innenabständen schafft box-sizing (CSS3), was schon heute von allen Browsern unterstützt wird.

Einen viel weitreichenderen Ansatz bietet die Funktion calc(). Bei einer Formulierung wie der obigen (60% minus 20 Pixel) denkt man zuerst an eine Rechenoperation. Genau solche einfachen Rechenschritte erlaubt calc().

#testbox {
height: calc(60% - 20px);
padding: 10px;
}

Natürlich lässt sich diese längst überfällige Funktion nicht nur verwenden, um das kaputte Boxmodel zu behandeln. So lässt sich damit z.B. auch eine Box in drei Teile unterteilen, ohne dass man, wie bisher, ein 33.3333% verbrechen muss.

Vierlerorts wird man mit der Prophezeiung des Weltuntergangs konfrontiert, wenn man etwas wie calc() anspricht. CSS verkäme dadurch zu einer Skriptsprache. CSS solle beschreibend bleiben und überhaupt könne man CSS bald in JavaScript umbenennen. Ja ne, is klar!

HTML ist eine Markup-, CSS eine Formatierungs- und JavaScript eine Skriptsprache. Daran wird sich nichts ändern, auch nicht mit der Einführung von Funktionen wie calc(). Denn eine Skriptsprache arbeitet mit Input und Output, solange man CSS nicht erlaubt auf Formularwerte zuzugreifen oder auf Events zu reagieren, sehe ich keine Gefahr, dass man CSS bald JavaScript nennen könnte.

Sehr kontrovers verlaufen auch die Diskussionen um CSS-Variablen. Während man auf der einen Seite versucht, Variablen mit PHP, Python oder Ruby zu simulieren, wettert man auf der anderen Seite heftig gegen die Einführung echter CSS-Variablen. Denn Variablen, so scheint es, sind der Inbegriff einer Skriptsprache und damit Gift für CSS.

Am krassesten aber teilen sich die Meinungen bei CSS Transitions. Auf den ersten Blick handelt es sich bei einer Zeitangabe von JavaScript-gesteuerten Ereignissen in CSS um eine Vermischung von Aussehen und Verhalten. Ist Zeit etwas, das mit Interaktion zu tun hat, oder ist es ein Style-Element? Meiner Meinung nach ist hier der fließende Übergang vor dem man sich immer fürchtet.

Warum sollte man aber auf so nützliche Funktionen wie Rechenoperationen freiwillig verzichten? Für mich scheinen die Buh-Rufe von der Angst, CSS würde zu einfach werden, getrieben zu sein. Wenn man auf einmal Werte miteinander verrechnen kann, muss man keine komplizierten Div-Verschachtelungen mehr anlegen und das Gefrickel entfällt. Ottonormaldesigner kann jetzt plötzlich Webseiten mit CSS stylen, nein, das wollen wir nicht.

Kommentare [2]

7.07.09

Das eigene Grab noch tiefer schaufeln.

XHTML 2 ist also jetzt offiziell tot. Schön, dass man sich seine Zukunft derartig verhunzen kann und nebenher noch jubelnd die Mistgabeln in die Höhe reckt.

HTML 5 wird als großer Fortschritt gefeiert. Das Entwicklerteam, das einst unabhängig vom W3C agierte und sich aus Browserherstelllern, Usabilityexperten und freien Webentwicklern zusammensetzt, arbeitet an der Spezifikation, die die Vorgänger HTML 4.01 und XHTML 1.0 ersetzen soll. Auch beim aktuellsten Working Draft vom 23. April 2009 wird darauf hingewiesen, dass die Spezifikation teilweise noch unausgereift ist.

Der Schwerpunkt der Arbeiten der HTML 5-Arbeitsgruppe liegt dabei auf der bereits erwähnten vollständigen Ablösung vorhergehender Standards. Während bei XHTML 2 eher der Ansatz einer kompletten Neuentwicklung besteht, versucht HTML 5 schon von vornherein auf Browserkompatibilität zu setzen. Stellenweise wird sogar schon davon geredet, HTML 5 produktiv einzusetzen; gewagt für eine im Entwurfstadium befindliche Spezifikation.

Ein gewichtiger Punkt auf der Liste der HTML 5-Features ist also die Abwärtskompatibilität. Die Entwürfe werden danach gerichtet, was mit heutigen Browsern teilweise schon möglich ist und was der zukünftigen Browergeneration nicht allzu viel Mühe machen wird.

Aufgrund dieser Zielsetzung ist es unmöglich, eine Spezifikation ohne Altlasten zu entwerfen. Die Toleranz von HTML 5 geht sogar so weit, dass das font-Element aufgenommen wird; mit der Begründung, dass WYSIWYG-Editoren ohne dieses nicht auskämen.

Derletzt sind wieder viele Webentwickler den Schritt zurück von XHTML 1.0 zu HTML 4.01 gegangen. Die Begründungen sind allesamt pragmatischer Natur; im Gegensatz zu den eher ideologischen Argumenten pro XHTML damals, als es in war, XML zu schreiben.

Leider fehlt mir bei all’ den Argumenten gegen XHTML die Rücksicht auf die Zukunft. Abwärtskompatibilität in einer Spezifikation, das mag, auf die Gegenwart und nahe Zukunft projeziert, sinnvoll erscheinen. Überlegt man sich aber, wo man eigentlich einmal hin möchte, erweisen sich diese Gedanken als äußerst kurzsichtig.

Um eines klarzustellen: Ich bin überzeugt, dass es nahezu unmöglich ist, eine gesunde, überlebensfähige Spezifikation für das Web zu entwerfen, die ohne jegliche Altlasten auskommt; zuviele Parteien haben ihre Griffel im Spiel. Deshalb bin ich mir auch bewusst, dass XHTML 2 nicht der heilige Gral gewesen wäre, denn auch diese Arbeitsgruppe nimmt genügend Relikte aus der Steinzeit mit. HTML 5 hingegen schafft neue Relikte, neue Altlasten, die die nächste Generation an Markup-Sprachen wieder auszubügeln haben wird.

Denn neben font, b, i und den ganzen anderen Elementen, die es aus unerklärlichen Gründen in die HTML 5-Entwürfe geschafft haben, gibt es neue Elemente, die neue Probleme schaffen werden.

Ich fange am besten ganz vorne an.

Der Doctype

Bis jetzt habe ich zum HTML 5-Doctype nur positive Stimmen lesen können. Das einzige Argument war dabei immer »Hui, den kann ich mir endlich mal merken!« Ich gebe zu, das ist wirklich ein pragmatisches Argument; blöd wird’s nur, wenn es einige Gegenargumente gibt, die weit mehr ins Gewicht fallen.

Warum gibt es überhaupt einen Doctype? Schaut man sich den von HTML 5 an, könnte man meinen, der Doctype wäre nur ein nötiges Übel; man muss es halt machen.

Der Doctype dient der Unterscheidung von Dokumententyp-Versionen. Aus dem HTML 5-Doctype geht jedoch nur hervor, dass es sich um HTML handelt, und nicht um welche Version. Wie werden die nächsten HTML-Generationen damit umgehen?

Aus den Diskussionen um die Form des Doctypes geht als Argument gegen ein <!doctype HTML5> hervor, dass diese Schreibweise gewisse derzeitig aktuelle Browser in den Quirks-Modus versetzt.

Wenn aber doch ganz offiziell verkündet wird, dass mit einer vollen Verbreitung von HTML 5 nicht bis 2022 zu rechnen sein wird, frage ich mich, warum man auf Browser achten sollte, die zu diesem Zeitpunkt fünfzehn bis zwanzig Jahre alt sein werden! Und das zu Ungunsten einer genauen Klassifizierung aller Dokumente, die auf diese Technologie setzen.

Weiter geht’s mit den neuen funktionalen Elementen. Anstatt eine langanhaltende Technologie zu schaffen, wird hier kurzfristige Erleichterung versprochen.

video und audio

Vor einiger Zeit wurde bekannt, dass Google, z.B. mit Youtube in Zukunft auf HTML 5 setzen wird, Begründung: das Video-Element ist klasse. Von Google hätte ich mir ein klein wenig mehr Weitsicht und Durchblick erwartet. »Endlich ist es möglich, auf Flash zu verzichten und trotzdem Videos in eine Website einzubetten«. Wir wissen hoffentlich alle, dass das lächerlich ist, denn man kann schon seit Ewigkeiten alle Arten von Multimedia-Elementen einbetten, object sei Dank.

Dass man im Browser Videos ohne Plugins abspielen möchte, ist ein teilweise verständlicher Wunsch. Dass man dazu eine neue Spezifikation benötigt, leuchtet mir allerdings nicht ein. Dadurch, dass HTML 5 explizit erwähnt, dass die Browser das »jetzt so machen«, heißt nicht, dass sie das nicht schon seit Urzeiten hätten tun könnten.

Genau dieses object-Element, das in XHTML 2 verbessert werden soll, indem beispielsweise die Attributnamen sinnvoller gestaltet werden, hat der Unterscheidung von audio, video und image einiges vorraus.

Multimedia beschränkt sich nämlich keinesfalls nur auf diese drei Gruppen. Was, wenn man in eine Website plötzlich Gerüche einbinden kann? Natürlich kann man auch in HTML 5 noch object einsetzen, aber das ist dann doch sehr heuchlerisch und inkonsistent.

Darüberhinaus muss man erwähnen, dass HTML 5 mit dem Video-Element keinesfalls das bietet, was es einst versprach. Seit kurzem ist bekannt dass es keinen einheitlichen Codec geben wird.

Die strukturierenden Elemente

In einer simplen Webseite steckt so viel potenzielle Semantik, da braucht man ein erweiterbares System, um alles abdecken zu können. XHTML 2 führt @role ein, ich denke, hier kann man von einfacher Erweiterbarkeit sprechen. Außerdem ist bekannt, dass das X in XHTML ermöglicht, über Namensräume andere XML-Dokumente einzubinden. Das könnten z.B. Vektorgrafiken (SVG), mathematische Ausdrücke (MathML) oder Multimedia-Informationen (SMIL) sein.

Was tut HTML 5? Aside, nav, header und footer decken einen Bruchteil der notwendigen semantischen Elemente ab.

Ich möchte dazu einfach mal Tobias Otte zitieren:

Durch das Hinzufügen dieser Elemente zeigen wir das HTML mehr semantische Fähigkeiten braucht. Aber nur in einem engen Anwendungsbereich. Egal wie viele Elemente wir aussieben wir werden immer denken das es nicht ausreicht. Also, wir können so viele Elemente hinzufügen wie wir wollen, es wird das Problem nicht lösen. Wir brauchen nicht spezielle Ausdrücke zu den Begriffen von HTML hinzufügen, wir müssen eine Mechanismus einbauen der es uns erlaubt einem Dokument so viel semantische Fülle zu geben wie es braucht. Wir müssen HTML erweiterbar machen. HTML 5 enthält keinen Mechanismus für Erweiterbarkeit.

Das ist der Punkt. XHTML 2 bietet diesen Mechanismus, HTML 5 nicht.

Schlusswort

Mit diesem Artikel habe ich mir wahrscheinlich auf beiden Seiten Feinde gemacht. Die trendhechelnde HTML-Fraktion wird mir aus naheliegenden Gründen Briefbomben en masse zusenden und die X-Parteien lynchen mich, weil ich bei weitem nicht alle Nachteile von HTML 5 und nicht alle Vorteile von XHTML 2 dargestellt habe.

Abschließend möchte ich sagen, dass ich die Entwicklung zwar verstehe, aber nicht gutheiße. Die zugrundeliegenden Konzepte beider Sprachen sind gut. Sauberer Rewrite gegen pragmatischen Realismus. Bei ersterem war das Problem der zu akademische Ansatz und bei zweitem wird das Problem die miese Ausführung sein.

Ich denke, dass eine Spezifikation nicht abwärtskompatibel sein sollte. Die bearbeitenden Programme sollten dies können, aber eine Spezifikation sollte man sauber schreiben, denn noch schlimmer, als dass man die Webdesigner mit Hacks frickeln lässt, ist es, die Hacks in eine Spezifikation einzubauen.

Einerseits kann ich schon verstehen, warum man keine Spezifikation ganz ohne Altlasten entwicklen kann. Andererseits schaufelt man sich mit so etwas wie HTML 5 nur noch tiefer ins Grab.

Kommentare
Neuere Artikel
Ältere Artikel

Meine Position

Ich bin ein junger Webdesigner und werde mich deshalb auch noch eine Weile mit Webstandards herumschlagen müssen. Zukunftssichere Technologien liegen mir deshalb besonders am Herzen. Das kann auch der Grund sein, warum ich mit HTML5 nicht so recht warm werde. Trotzdem versuche ich jede Entwicklung positiv zu sehen oder zumindest zum Positiven hin zu lenken.

Diskussionen sind mir besonders wichtig, ich lade deshalb jeden Leser herzlich ein, zu kommentieren und auch zu widersprechen.

Gastbeiträge

Fachartikel

Themenserien