Tim Tepaße: Markupt für Präsentations in den diversen (X)HTML Versionen (Achtung: lang)

Beitrag lesen

Hallo Christian,

ich frage mich wieso das <b>-Element in Strict erlaubt ist! Ähnlich Style Elemente wie <u> und <i> sind ja auch nicht erlaubt. Was soll das also? Ich finde das W3C hat hier entweder geschlampt oder ich verstehe was nicht.

seufz

Immer diese Dogmen und die daraus resultierenden Missverständnisse.

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.

D.h. wenn man so will, bestand die Trennung zwischen Auszeichnung und Darstellung schon damals. Wie man nun aber im obigen Zitat lesen kann, wird auch beachtet, daß manchmal ein festes, verbindliches Rendering nötig ist, und sei es nur das etwas phantasievolle Beispiel dort. Deswegen gibt es in HTML auch Elemente zur Präsentation. Man muß sie ja nicht benutzen, wenn es keinen zwingenden Grund gibt.

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 style   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