rss feed articles all_comments

indeedgeek.de

Florian Eitel

HTML ist nutzlos!

Wofür brauchen wir überhaupt HTML? Mal ganz nüchtern betrachtet ist HTML doch nur ein gravierender Einschnitt in die Freiheit die XML uns bietet. Man muss ich plötzlich in eine Welt hinein zwängen, in der man zwar Videos abspielen kann aber maximal sechs Ordnungen von Überschriften haben darf. In der man zwar zwischen einem Akronym und einer Abkürzung unterscheiden kann aber nicht mal Überschriften automatisch numeriert werden.

Status Quo

Ok, ich bin nicht ganz fair mit meinen Beispielen. Aber mit welchem Grund machen wir diese Einschränkungen? Wäre es nicht einfach möglich XML frei Schnauze hinzuschreiben?

Betrachten wir doch erst einmal HTML. HTML gibt es im Grunde schon so lange wie es Webserver gibt (1987 – Tim Berners-Lee). Am Anfang eigentlich nur zur Textformatierung gedacht entwickelte sich später eher eine semantische Markup Sprache daraus. Mit der Entwicklung von CSS ging man immer mehr zu einer Trennung zwischen Aussehen (CSS) und Auszeichnung (HTML) über. In HTML sollte seit dem nicht mehr ein <b> (für bold – fett) stehen sondern ein <em> (für emphasized – hervorgehoben). Da so die Bedeutung und nicht das Aussehen definiert wird.

Da CSS lange Zeit (bedauerlicherweise bis heute noch) von vielen Browsern unterschiedlich implementiert (oder gar ignoriert) wurde, ist es schwer ein komplettes Layout in CSS abzubilden. Zudem hat bei Vielen nie ein Umdenken statt gefunden, so dass sich heute immer noch Webseiten mit <b> oder <font>-Tags finden. Auch Tabellen werden heute immer noch gerne für ein Layout missbraucht da man sich mit einer alternativen CSS Implementierung sehr schwer tut.

Eigentlich sollte man erst einmal jede Webseite komplett in HTML schreiben. Im HTML den Inhalt entsprechend auszeichnen (Zitate in <blockquote>, Abkürzungen mit <abbr>, etc) und erst anschließend das Ergebnis mit CSS formatieren. Dabei kann man dann auch entsprechend auf den Medientyp wie Bildschirm, Handy oder Screenreader eingehen. Aber leider sind wir wohl in der Praxis davon noch ein ganzes Stück entfernt.

Wo hilft mir nun also mein XML?

Der erste Punkt ist sicher die bereits erwähnte Freiheit. Ich kann jeden TAG den ich brauche einfach selbst definieren. Somit kann ich mein Text auch viel flexibler auszeichnen. Zusätzlich ist im Browser auch kein Standardverhalten (wie kursiv für <em>) vordefiniert. Ich kann sozusagen auf einer leeren Tafel anfangen zu malen und muss nicht jedes mal erst ein CSS-Reset implementieren. Zusätzlich erhält man eine klarere Struktur zwischen Semantik und Design da man erst gar nicht auf die Idee kommt eine Tabelle zum Positionieren zu missbrauchen – schließlich müsste man das Aussehen für ein table-Tag sowieso selbst in CSS implementieren.

Fassen wir zusammen: Formatieren muss ich mit CSS sowieso und durch XML wird die die semantische Aussagekraft ins Unendliche katapultiert. Wer sich noch nicht so ganz vorstellen kann wie ich mir das denke, für den habe ich mal ein kleines Beispiel erstellt.

Wo ist der Haken?

Also erstmal die beiden simpelsten Hindernisse: Zu erst einmal sind die meisten Webseitenbetreiber weder gewillt noch im Stande diese Änderung nachzuvollziehen. Wenn ihr euch die Verbreitung von Tabellenlayouts anschaut wisst ihr was ich meine. Zum anderen dürfte es an der ein oder anderen Browserunterstütung scheitern (Früher oder später bekommt der IE doch in jedem Webdesignartikel sein Fett weg).

Aber gut lassen wir einmal solche trivialen Hindernisse außer acht. Das Hauptproblem was ich sehe ist das durch zuviel Semantikfreiheit jegliche Semantik verloren geht. Zwar kann der Entwickler jeden Tag nennen wie er will aber der Browser versteht trotzdem nicht das “Kontakt” für einen Kontakt steht so lange bis man es ihm sagt. Wenn ich also völlige Freiheit in der Benennung habe kann der Browser daraus auch keine Schlüsse mehr ziehen. Man müsste dazu der Maschine erst denken beibringen damit sie versteht was ich mit Kontakt meine (und auch checkt das “Contact” und ein falsch geschriebenes “Gondagde” das selbe meint).

Der einzige Ausweg wird es wohl sein nicht ein HTML zu haben sondern in sich abgeschlossene Semantikbereiche. Diese müssten dann in irgend einer Metasprache definiert werden so damit der Browser damit etwas anfangen kann. Diese übergeordnete Definition müsste einmal das Aussehen definieren aber im weiteren auch die Bedeutung welche die entsprechenden Tags mit sich bringen. Nehmen wir mal als Beispiel SVG, MathML oder was ganz anderes. Diese beschreiben für ein entsprechendes Themengebiet eine Auszeichnungssprache. Möchte ich nun Formeln darstellen kann ich MathML einfach “includen” und kann dann meine Formeln schreiben. Das Problem daran ist: Es kann wieder kein Browser anständig darstellen und selbst wenn versteht er trotzdem nicht den Sinn dahinter (solange man es ihm nicht explizit erklärt). Deshalb meine ich es müsste eine Art Metasprache geben (konsequenterweise wieder XML) in der man beschreibt wie zum Beispiel SVG oder MathML auszusehen hat. Bisher gibt es das soweit ich weiß nur eine Sprache zur Festlegung von Schemata die allerdings nur zur Validierung von XML verwendet werden.

Mein Fazit, was ich aus der Überlegung mitnehme: Eigentlich verwenden wir die gesamte Zeit schon XML denn eigentlich ist HTML ja auch nur ein Teil von XML welcher sich um die Auszeichnung von Text kümmert. Schön wäre es allerdings wenn man den vollem Umfang, der von XML geboten wird, auch nutzen kann. Bisher muss jede Erweiterung erst in jeden Browser implementiert werden was annähernd unmöglich ist. Schön wäre es wenn man einfach auf verschiedene “Libraries” zugreifen, bzw. selbst erstellen, kann. Diese muss man einfach nur einbinden und schon versteht der Browser meine Erweiterungen und kann Formeln darstellen und Überschriften nummerieren.

Was haltet ihr davon? Wäre XML eine brauchbare Alternative? Kennt ihr schon Ansätze um die Semantik von XML wieder in XML zu beschreiben? Und ganz wichtig: Verwendet ihr noch Tabellenlayouts? ;-)

Comments:

(howto comment?)

XHTML ist ja reines XML im Gegensatz zu HTML 4. Mit XSLT lässt sich denke ich das erreichen, was du gerne hättest. Hier ein kleines Beispiel:

contaxts.xml: http://howflow.com/pastes/1542 (Das Ist die selbe XML-Datei wie aus deinem Beispiel, nur die zweite Zeile kam dazu.)

contact.xsl: http://howflow.com/pastes/1543 (Damit lässt sich das XML nach HTML transformieren).

Ergebnis: http://howflow.com/pastes/1544

Auf diese Weise könnte man nun für alles Mögliche Libs in form von XSLT-Files erstellen, und da XSLT Turing-Complete ist, lässt sich damit auch alles machen :) Beispiel: Ne Menü-Lib, die >menu>>item >… Tags nach >ul>>li>… transformiert und mit CSS dementsprechend formatiert. Für die Druckausgabe wird natürlich das Menü nach "" transformiert, dass es nicht angezeigt wird und für die Darstellung auf Handys wird das Menü in das OS integriert, dass es keinen Platz verschwendet.

Die Technologien sind alle schon seit Jahren da, werden aber nur sehr spärlich eingesetzt. Ich glaube, das Hauptproblem ist die Komplexität, die dahinter steckt. Ein WYSIWYG-Editor kommt mit sowas nicht klar. (X)HTML ist nunmal der kleinste gemeinsamme Nenner, der jeder versteht und der überall funktioniert.

Eigentlich ist das, was du möchtest doch schon lange da. Du kannst deine Dokumente doch in XML schreiben und dann von XSLT parsen lassen. Sogar die Gentoo-HP macht das so, wenn ich mich nicht täusche ;)

Postet on by kb.

Mist, da hab ich zu lange zum lesen gebraucht ;)

Postet on by kb.

Naja also natürlich kann ich in XML schreiben und dann irgend eine Art Compiler drüber laufen lassen der mir HTML erzeugt. Aber dann habe ich nicht viel gewonnen. Das Endprodukt, welches der Browser geliefert bekommt, sieht dann genauso aus als wäre es schon immer HTML. Möchte ich nun aber mehr als den Featureumfang (Formeln, Noten, erweiterte semantische Auszeichnung, …) dann bleibt mir nur die Möglichkeit, dass der Compiler dies entsprechend in ein Bild verpackt. Allerdings kann ich ja dann auch gleich bin Bild malen, da mir die Bedeutung von dem Element verloren geht wenn am Ende sowieso nur ein Bild raus kommt.

Zugegeben bietet XSLT einige interessante Möglichkeiten (hatte mich noch nicht damit beschäfigt) aber allein durch Preprocessing wird mein HTML Problem nicht zufriedenstellend gelöst.


Ergänzungen: - Anscheinend kann man doch Überschriften nummerieren: http://de.selfhtml.org/css/eigenschaften/pseudoformate.htm#nummerierung

- Das Äquivalent zu b ist strong nicht emph (thx kb)