Typografische Elemente in XHTML und warum sie (immernoch) erlaubt sind | 18. May 2005 um 19:01 Uhr /

Tim Tepaße schrieb einen sehr langen, artikelähnlichen Beitrag im SELFHTML Forum darüber warum Typografische Elemente wie <b>, <u> und <i> in XHTML immer noch erlaubt sind. Ich denke der Beitrag ist einfach zu schade, um irgendwo als einer von vielen in einem solch großen Forum unterzugehen. Deshalb habe ich Tim hier als ersten Gastautor eingeladen.

Fangen wir mal am Anfang an, bei HTML 2. Dort werden die Elemente <b>, <i> und <tt> in der Sektion »Phrase Markup« einsortiert, dort in den Unterabschnitt »Typographic Elements«, dies im Gegensatz zu den »Idiomatic Elements«, bei denen sich die logischen Auszeichnungen (<em>, <code>, etc.) finden. Dort steht dazu, wozu man typographische Elemente benutzen soll, diese Text:

»Typographic elements are used to specify the format of marked text. Typical renderings for idiomatic elements may vary between user agents. If a specific rendering is necessary - for example, when referring to a specific text attribute as in "The italic parts are mandatory" - a typographic element can be used to ensure that the intended typography is used where possible.«

Das ist natürlich noch aus Zeiten vor CSS. Allerdings, wenn man den Kontext beachtet: das konkrete Rendering von logischen Elementen ist nirgendwo festgelegt, es bleibt Sache des Browsers. Wenn ich das recht sehe, hatte schon der allererste Browser/WYSIWYG-Editor fürs Web eine Unterstützung für userdefinierte Styles, siehe z.b. diesen Screenshot.

Springen wir eins weiter, mitten in die Browser-Kriege und zu HTML 3.2. Mal abgesehen davon, daß ich den Standard nicht so schön und durchdacht finde, wie HTML 2.0 gibt es auch hier diese Elemente zu Präsentation, dazu kommen <u>, <strike>, <big>, <sub> und <sup> (wobei letztere ein besonderer Fall sind). Hier nennen sie sich »Font Style Elements« und werden von logischen Elementen wieder getrennt. Leider gibt es dazu keinen einprägsamen Satz.

Nächste Version, CSS erscheint und das W3C versucht seine Sache mit HTML 4 richtig zu machen. Und das tut es. Praktisch ist HTML 4 immer noch die authorative Version, die uns betrifft. Dazu gleich mehr.

In HTML 4 wird m.W. erstmals die Vokabel »deprecated« benutzt, zu deutsch am besten mit »missbilligt« benutzt. Die Definition dafür sagt u.a. folgendes:

»A deprecated element or attribute is one that has been outdated by newer constructs.«

(...)

»This specification includes examples that illustrate how to avoid using deprecated elements. In most cases these depend on user agent support for style sheets. In general, authors should use style sheets to achieve stylistic and formatting effects rather than HTML presentational attributes. HTML presentational attributes have been deprecated when tyle sheet alternatives exist (see, for example, [CSS1]).«

Wir lesen das im Kontext: Es gibt inzwischen neuere Elemente bzw. eine bessere Technik für Formatierungszwecke (CSS). Wenn diese Technik vorhanden ist, sollte sie auch benutzt werden. Wenn.

Unsere Elemente befinden sich inzwischen in der Sektion »Graphics«, dort wieder unter dem Titel »Font Style Elements«. Zwei Dinge fallen auf: Zum einen der Satz »Rendering of font style elements depends on the user agent.« - es ist nicht mehr verpflichtend, wie diese Elemente angezeigt werden, es gibt nur noch ein informative, d.h. nicht verpflichtende Beschreibung, die sich natürlich an der klassischen typographischer Darstellung orientiert.

Zum anderen sind hier nur zwei (drei) Elemente als deprecated markiert (jeweils mit einem von mir angenommenen Grund): Für die Durchstreichelemente <strike>/<s> gibt es seit HTML 4 das logische Element <del> mit seinem Zwilling <ins>. Das wäre dann eine »neueres Konstrukt«, wie in der Definition von »deprecated« und hat dazu noch den Vorteil sehr viel genereller zu sein. Und das Element <u> wird in der normalen gedruckten Typographie eigentlich weniger verwendet, im Web dagegen verstößt es aber gegen das Default-Rendering so ziemlich aller Browser von Links.

Kleiner Advocatus Diaboli Einschub: Warum sind nicht die anderen Elemente deprecated? Zwei mögliche Antworten: Zeitlicher Kontext, 1997 wurden diese Elemente noch sehr gerne benutzt. Und ist <em> wirklich ein Ersatz für <i>, <strong> ein Ersatz für <b> und wieso überhaupt zwei Elemente, um etwas zu hervorzuheben? Ist das wirklich besser?

Ich fasse mal den bisherigen Kenntnisstand zusammen:

  • Elemente zur Präsentation wurden und werden als Bestandteil HTML betrachtet, bis hin zu HTML 4.01.
  • Mit dem Aufkommen von CSS wird davon abgeraten, diese Elemente zu benutzen, wo CSS zur Verfügung steht. Ansonsten sind sie zur Rückwärtskompatibilität noch erlaubt.

Kommen wir nun zu XHTML 1.0. Und verlassen es gleich wieder. XHTML 1.0 ist nichts weiter als HTML 4 in XML neu formuliert. Und da es aus Kompatibilitätsgründen mit dem MIME-Typ text/html versendet werden darf, ist es für den Browser nichts anderes als HTML. Man fragt sich, wofür das ganze. Meine Top-Vermutung: Damit die Leute etwas haben können, mit dem sie vor noch Unwissenderen angeben können. Wie ich sagte: Der für uns relevante Standard ist immer noch HTML 4.

Interessanter ist da schon die Modularisierung von XHTML. Hier wird der von HTML 4 in XHTML 1.0 übernommene Sprachbestand auseinandergenommen, in logische Module gesteckt, die Autoren, die Zeug aus der XHTML-Familie benutzen wollen, in ihre Sprache einbinden können. Und daraus kann man Teilmengen des XHTML Sprachumfangs basteln, für begrenzte Zwecke. Aber: Es wird immer noch nichts am Sprachumfang von XHTML gemacht, weder hinzugefügt, noch weggenommen.

Hier treffen wir wieder auf unsere Elemente: Sie befinden sich in dem Modul mit dem korrekten Namen Presentation Module. Dort heißt es zum Sinn und Zweck dieses Moduls:

»This module defines elements, attributes, and a minimal content model for simple presentation-related markup«

Präsentation ist also immer noch ein Bestandteil von XHTML. Kein Wunder, wenn doch immer noch nicht am Sprachbestand gerüttelt wird. Die in HTML 4 als deprecated markierten Elemente lassen sich deswegen hier auch immer noch finden, in dem Legacy Module, Erbschaften aus früheren Versionen.

Was wir bisher also unter XHTML verstanden, war eigentlich nur die Anstrengung, den HTML Sprachstandard in XML zu kriegen, damit man vollwertige XML-Dokumente in XHTML schreiben kann und Bestandteile von XHTML woanders einbinden kann. Am besten man sieht es nicht als Innovation, sondern als .. äh .. Wartung und Produktpflege für das 21. Jahrhundert. Kein großer Wurf, den man erwartete. Interessanter wird es zu den jetzt entstehenden XHTML-Dialekten, da kann man sich schließlich aussuchen, was man da hineinpackt. Hier ein paar Beispiele von beim W3C entwickelten XHTML-Dialekten:

XHTML 1.1 ist so ziemlich genau das, was die meisten wohl unter dem Schlagwort XHTML verstehen. Denn es ist eine Neuformulierung von XHTML 1.0 Strict mittels der XHTML Module. Als deprecated markierte Elemente finden sich hier nicht mehr. Das heißt, es ist das, was man erwartet hat, ein kleiner Fortschritt, missbilligtes Zeug wird rausgeworfen. Aber: Der nicht als als deprecated bezeichnete Sprachbestand von HTML findet sich hier immer noch. Im wesentlichen ist es also HTML 4 Strict in XML. Es ist also eine lange Geburt gewesen.

XHTML Basic ist dagegen eine Spezifikation, in dem der Sprachstandard wesentlich reduziert wurde. Kein Wunder, Zielgruppe dieser Spezifikation für „small devices“, soll heißen: Mobiltelefone, PDAs, Autos, Armbanduhren. Tatsächlich ist XHTML Basic auch gleich WAP 2, soweit ich informiert bin, aber die Mobilfunkszene ist mir immer fern geblieben. Witzig finde ich nur, daß sich der reduzierte Sprachbestand von XHTML Basic auf das abbilden läßt, was die meisten Semantikprediger für sich selbst einsetzen - man sollte doch meinen, sie hätten ein Bedürfnis nach mehr, nach aussagekräftigeren Elementen als nur etwas Textauszeichnung und divs.

Du wirst es erraten: Präsentationsmarkup oder noch schlimmer deprecated markup findet sich hier nicht. Es ist genau die Reduktion auf logische Strukturen, die gepredigt wird. Im Kontext von XHTML Basic finde ich das etwas unlogisch, aber es wird wohl angenommen, daß CSS-fähige Browser inzwischen zur Grundausstattung intelligenter Armbanduhren gehören.

XHTML Print ist eine Spezifikation, die sich an gedruckte Texte richtet. Zielgruppe sind nicht unbedingt Drucker mit allen Schnickschnack, sondern eher Low-Tech-Drucker. Erinnert sich noch jemand an Nadeldrucker? Genau.

ACHTUNG (Nur damit die bis hierhin eingeschlafenen wieder aufgewachen ;-) Hier findet sich nämlich einer der praktischen Anwendungsfälle für Präsentations-Markup. Hier muß man keine abstrakten Modelle zur Trennung von Content und Präsentation fahren (Auch wenn CSS natürlich erlaubt ist), hier hat man den typographischen Fall, in dem z. B. Hervorhebungen noch durch Fettdruck bzw. manchmal durch Kursivdruck gemacht werden. Demzufolge ist das Presentation Module in diesem XHTML Dialekt enthalten.

Man sieht hier einen Trend: XHTML 1.x ist nicht mehr nur ein Sprachstandard für alles, sondern eine Familie von Sprachelementen, die man unterschiedlichster Verwendung zuführen kann. Präsentationsmarkup war immer in HTML, wieso soll man es nicht beibehalten, wo es sinnvoll sein kann? Es zwingt einen ja keinen dazu, es zu benutzen. Oder um es für Semantiker zu sagen: Fettdruck kann auch eine semantische Information sein, die nicht unbedingt gleich der Information Hervorhebung sein muß.

Und was ist mit der Vision von XHTML als rein logische Dokumentstrukturierungssprache? Obacht, Rettung ist nahe.

Die ganzen Visionen finden sich in der Entwicklung von XHTML 2. Diese Spezifikation versucht sozusagen ein »HTML made right« zu sein. Und da kommen ziemliche Änderungen auf Nutzer zu. Mit dem Nebeneffekt, daß XHTML 2 nicht rückwärtskompatibel zu XHTML 1.x sein wird. Das wird auch noch spannend. Da das noch im Status einen Working Draft ist, ist das ganze natürlich noch ein bewegliches Ziel, aber ein Trend ist sichtbar: Es wird nur noch logisch strukturiert, es gibt keine Workarounds für Weicheier zum Zwecke der Präsentation mehr (OK, das wurde inzwischen auch verwässert, siehe style-Attribut). Aber es wird zumindest interessant.

Tja.

Q: Soll das heißen, Präsentationsmarkup ist noch in HTML 4, weil das in vorherigen HTML-Versionen als Bestandteil von HTML angesehen wurde?
A: Ja.

Q: Und es kam mit in XHTML 1, weil das ganze Projekt XHTML 1 nur darauf abzielte, HTML 4 in XML zu kriegen und nix zu verändern?
A: Riiichtig.

Q: Aber das ist unsemantisch!!
A: Verwende es doch einfach nicht. Oder nutze einen XHTML Dialekt, der Deinen semantischen Vorstellungen mehr entspricht.

Q: Wann kann ich denn mit dem meinen Bürzel vor Freude erregenden XHTML 2.0 rechnen?
A: Ich las neulich was von 2006. Rechne mal plus ein Extra-Jahr, dann wird das 2007 mit dem Status der Candidate Recommendation, ab der das dann in den Browsern implementiert werden soll. Beim Marktführer dauert das natürlich etwas länger.

Q: Kann das sein, daß die Mühlen des W3C eeeetwas langsam mahlen?
A: Ach? </loriot>

Tim Tepaße


Kommentare

Die Kommentare sind für diesen Eintrag geschlossen.