spackblog

Aktuell gibt es im Zuge der HTML5-Spezifikations-Diskussion eine in meinen Augen völlig überflüssige Unterdiskussion: Soll man HTML oder XHTML schreiben? Der von mir geschätzte Eric Eggert argumentiert pro HTML und hat gute Argumente im Gepäck, die ich jetzt nicht noch mal wiedergeben mag. Ich selber schreibe seit Jahren strikt nach XHTML-Syntax mit dem DOCTYPE XHTML 1.0 Strict, liefere aber als text/html aus, was schon immer widersprüchlich war und sich mit HTML5, dessen DOCTYPE ich seit einiger Zeit nur noch verwende, ja sowieso erledigt hat. Deswegen und weil in meinen Augen korrekter Code sowohl in HTML als auch in XHTML gültig ist (bzw. funktioniert), halte ich die Diskussion für überflüssig. Echtes XHTML scheidet in der Praxis wegen des IEs und weil ein wohlgeformtes XML-Dokument faktisch nicht dauerhaft und zu jedem Zeitpunkt sicherzustellen ist, sowieso aus. Auch ich selber übersehe gelegentlich solche Fehler und dann würde das rendern der ganzen Seite abbrechen. In Atom-Feeds sieht man ja, wie lästig das ist: Ein Tippfehler oder auch nur eine benannte HTML-Entity im Dokument (hallo an die WYSIWYGs dieser Welt) und der Feedreader verarbeitet den ganzen Feed nicht mehr, na vielen Dank.

Für wichtig halte ich aber die Frage, ob man die SGML-Freiheiten von HTML nutzt oder sich Mühe gibt, sauberen und wohlgeformten XML-Code zu schreiben. Und da sehe ich den großen Schwachpunkt von HTML: Hier sind syntaktische Konstrukte erlaubt, die mir den kalten Schweiß auf die Stirn treiben und die wirklich niemand benutzen sollte. Aber auch schon so Dinge wie ungequotete oder fehlende Attributwerte kann ich nicht ertragen. All das ist in HTML erlaubt und was erlaubt ist, wird von irgendwelchen Leuten und vor allem WYSIWYG-Editoren auch genutzt. Das war der Grund, wieso ich meine Dokumente stets als XHTML 1.0 strict deklariert habe: Solche schlechten Angewohnheiten müssen zumindest vom Validator bemängelt werden. Dass die Browser so fehlertolerant sind ist in der Praxis ja schön, aber es verleitet eben auch zu krudem und unverständlichen und fehleranfälligem Code. XML-Syntax ist letztlich wegen der strikteren Regeln deutlich einfacher zu erlernen und zu nutzen: Klare Regeln sind hier immens von Vorteil für alle, das merkt man spätestens, wenn man Menschen an HTML und allgemein Auszeichnungssprachen heranführt.

Also mein simples Fazit: Aktuell und in Zukunft deklariere ich als HTML5, schreibe aber in strikter XML-Syntax. Das ist in HTML5 gültig, für jeden verständlich und eindeutig und es geht mit gutem Beispiel voran. Wünschenswert wäre ein Modus in HTML5, dessen Syntax XML statt SGML nutzt (was sich im Validator ausdrückt), ohne gleichzeitig die Strenge von XML beim Parsen im User-Agent zu erzwingen. Warum basiert HTML5 überhaupt auf SGML? Wer hat was davon? Wer nutzt überhaupt die Freiheiten von SGML? Was spricht gegen eine HTML5 Spezifikation, die XML-artige Syntax vorschreibt, aber den Browsern Fehlertoleranz erlaubt?

Scheiße. Ich binde in der Sidebar u.a. meine letzten identi.ca Dents ein, was an sich ne schöne Sache ist. Ich tue das nicht beim Nutzer mit einem JavaScript, sondern hole die bei Bedarf alle zehn Minuten aktualisiert mit PHP ab und binde sie direkt in meine Seite ein. Soweit so gut, alle wären zufrieden, wenn nicht… ja wenn ich nicht plötzlich in unpassenden Google-Treffern ertrinken würde. Was ist hier passiert?

Google indiziert gelegentlich mein Blog und nimmt alle vorgefundenen Inhalte (ausgenommen die in der robots.txt ausgeschlossenen Kategorien- und Tagseiten) in seinen Index auf. Leider passiert das auch mit den Inhalten in der Sidebar und besonders lästig, passiert das mit meinen dort nur temporär zu findenden identi.ca Dents. Dumm ist jetzt, dass jemand bei Google etwas sucht, was dort zu finden ist und Google zeigt auf einen zufälligen Artikel in meinem Blog, wo der gesuchte Content aber sehr wahrscheinlich durch die aktuellen Dents ersetzt wurde, also nicht mehr da ist. Das will niemand, wie kann man das also lösen?

Der naheliegendste Ansatz ist simpel: Ich binde die Inhalte nicht mehr via PHP Serverseitig ein, sondern liefere ein Script, auf dass sich der Browser des Besuchers die Dents selber hole und einbaue. Google sieht keine Dents mehr, alles ist geritzt. Allerdings mag ich solche JavaScript-Lösungen gar nicht, erzeugen sie doch einen nicht geringen und überflüssigen Overhead bei identi.ca und bei meinen Besuchern.

Die nächste Idee liegt ebenfalls nahe: Das ist eigentlich nur indirekt mein Problem, viel mehr ist es eine Unzulänglichkeit von Google, relevanten Inhalt auf meinem Blog zu finden. Wie kann man Google (immer stellvertretend für alle Suchmaschinen) also dabei helfen? Zwei Wege fallen mir da ein, die aber beide bisher noch nicht (ist das so?) unterstützt werden:

1. HTML5 bietet die praktische semantische Auszeichnung <aside>, mit der man nicht inhaltsrelevante Dinge wie die Sidebar auszeichnet. Allerdings klingt die Spezifikation eher so, dass dort Inhalte einer Randspalte hinein gehören, wie man sie etwa in Büchern findet, also durchaus relevanter Content. Semantisch hat man also nur vielleicht seine Hausaufgaben gemacht. Schaden tut es auch nicht, also werde ich das demnächst benutzen.
2. Das Mkroformat "Robot Exclusion Profile" könnte die Lösung sein. Hierbei werden Tags analog zu den ROBOTS Meta-Angaben mit entsprechenden Klassen versehen, die Hinweise auf die Verarbeitung durch Suchmaschinen liefern. Das scheint mir der richtige Weg zu sein, allerdings unterstützt meines bisherigen Wissens auf Basis einer zehnminütigen Recherche nach noch keine Suchmaschine dieses Mikroformat (seit 2005 im Entwurfsstatus). Zu allem Unglück hat Yahoo eine abweichende Variante implementiert: class="robots-nocontent". Na vielen Dank, zwei voneinander abweichende Methoden… Und Google? Ich konnte keine Infos dazu finden und dank der zwei möglichen Methoden weiß ich jetzt nicht, welche ich vorgreifend für die Zukunft schon mal einsetzen soll. Yahoo ist bei mir ein eher seltener Referrer und ehrlich gesagt ist mir auch egal, was Yahoo so an Alleingängen macht. So hehr das Ziel von Yahoo auch ist, sind sie (zumindest in Deutschland) nicht in der Marktposition, eine neue Technik zu etablieren. Google muss das unterstützen, dann wird es praktisch relevant. Von Live Search brauche ich gar nicht zu reden, auch wenn ich von dort deutlich mehr (zumeist unpassende) Suchtreffer bekomme als von Yahoo.

Also Fazit: Außer meine Dents/Tweets per JavaScript einzubinden oder sie ganz aus meiner globalen Sidebar wegzulassen, ist mir aktuell keine praktisch relevante Möglichkeit bekannt, hierfür Google Hinweise für sinnvolle Suchtreffer zu geben und ich werde wohl weiterhin Scharen von enttäuschten Besuchern von Google bekommen.

Oder hat jemand eine gute Anregung parat?

Schon eine halbe Ewigkeit habe ich Pläne für ein Redesign meines Blogs im Hinterkopf herumgeistern, jetzt werde ich mich mal da dran setzen. Die Vorlesung ist durch, ich habe sogar schon Klausurfragen gebastelt (brauchen noch einigen Schliff), das Buchprojekt ist fertig (hoffe ich zumindest, mehr dazu in den nächsten Tagen) und ich bin heiß auf Neues. Die beiden Phenom II Rechner, die ich nächste Woche baue sind leider nicht für mich, deswegen muss was andere neues her. HTML 5 kommt mir da ganz gelegen. Entgegen der bisher vorherrschenden Meinung, kann man Einiges daraus bereits jetzt – wenn auch unter Vorbehalt – nutzen und so wird mein erstes eigenes Blogdesign voraussichtlich intensiven Gebrauch der neuen Strukturtags von HTML 5 machen. Voll progressiv, ey! Ich bin gespannt, denn endlich wird es semantische Auszeichnungen für Dinge geben, die bereits zuvor hätten ausgezeichnet werden sollen. Dazu auch demnächst mehr. Wer nicht warten kann, kann ja schon mal in den aktuellen Stand der HTML 5 Entwicklung reinschnuppern und etwa etwa hier mal gucken, was man aktuell schon benutzen könnte.

Vielleicht nehme ich bei der Gelegenheit auch gleich eine neue Blogsoftware her, ich habe da schon eine im Blick. Der S9Y-Importer mag allerdings bisher keine Tags importieren, was ein ziemlicher Showstopper ist. Mal schauen, ob ich das einfach fixen kann. Irgendwelche Tipps, welche vielversprechende Blogsoftware ich meine?

Ich zitiere häufig aus verschiedenen Quellen und nutze dafür das vorgesehene <blockquote>-Tag. Um eine logische Verbindung zur Quelle herzustellen, hat dieses Tag ein optionales cite-Attribut, in dem man die URL direkt oder auch eine Quellenangabe im Klartext angeben kann. Eine feine Sache, leider ignorieren die meisten Browser (oder alle?) dieses Attribut. Eigentlich leuchtet das ja auch ein, denn wie sollte ein Browser diese Metainformation auch visualisieren? Um die Quelle also für den Nutzer sichtbar angeben zu können, muss man nun die Quellenangabe immer noch ein zweites Mal (etwa in einem Absatz) machen. Ich habe kein Problem damit und mache das schon lange so, aber aus der Microformats-Ecke kommt eine recht elegante Lösung für das Problem: cite-rel

<p>Folgendes Zitat stammt von
  <cite id="quellangabeXY" class="relationship">
    <a href="URL">QUELLE</a>
  </cite>
</p>
<blockquote cite="#quellangabeXY">
  <p>ZITAT</p>
</blockquote>

An sich eine recht elegante Lösung, allerdings sehe ich ein großes Problem dabei: Die Eindeutigkeit der ID muss gewahrt bleiben, was dann zum Problem wird, wenn mehrere Artikel im Volltext auf einer Übersichtsseite erscheinen können. In meinem Blog ist das so und daher muss ich schon bei eingebundenen Videos sehr auf Eindeutigkeit achten (ich löse das über ein Datumsstempel in der ID). Das strengt mein Hirn mehr an, als mal eben die Quelle zwei mal zu nennen, was auch nicht mehr Tipparbeit ist. Gut oder je nach Situation auch mal weniger gut daran ist aber, dass eine mehrfache Zitierung so mit nur einer gemeinsamen Quellenangabe versehen werden kann bzw. muss, wenn man nicht komisch kommen will.

Es spricht also im Fazit nichts dagegen, grundsätzlich beide Varianten zu nutzen und nach Einzelfall die angemessenere Lösung zu wählen. Hauptsache man versieht seine Zitate überhaupt mit einer semantischen Quellauszeichnung, aber da sehe ich wegen der Faulheit der weitaus meisten Autoren keine großen Chancen auf weite Verbreitung. Umso besser fühlt man sich immerhin, wenn man es trotzdem macht.

Wieso? Sieht man doch eh nicht! Wenn ich diese Begründung für das Weglassen der Quellauszeichnung höre, schwillt mir schon der Hals. Und jede Metaangabe ist überflüssig und Webdesign ist sowieso nur eine visuelle Problemstellung, ganz genau. Wer als Webprofi so denkt oder handelt, hat seinen Beruf verfehlt. Echt mal. Schlimm, wie oft ich Leuten begegne, die so drauf sind.

Gerade las ich im Blog von Mite einen Beitrag zur Opera-Unterstützung und schreibe schnell mal meine Gedanken dazu auf:

Wer Opera benutzt (was viele in meinem Umfeld tun) gehört nach meiner Erfahrung meist zu einem von zwei Typen: Die einen Opera-Nutzer updaten fast nie und leben mit der ein oder anderen Einschränkung, aber beschweren sich auch nicht darüber. Die anderen Opera-Nutzer machen alle Updates sofort und beschweren sich eigentlich nur, wenn die Fehler an nicht standardkonformer Implementierung seitens der Seitenbetreiber liegt. Und alle ham se immer noch einen Firefox in der Hinterhand, falls mal was wichtiges gar nicht läuft. Man gewöhnt sich mit der Zeit daran. Das ist der Punkt, den Opera-Nichtnutzer nicht verstehen: Warum zur Hölle benutzt man den dann überhaupt? Meine Antwort: Opera fühlt sich an wie ein Maßanzug und bedient sich einfach slick und flüssig. Eine bessere Erklärung hab ich nicht. Meine Blogeinträge schreibe ich übrigens wegen der Rechtschreibkorrektur im Firefox und entwickeln tue ich auch damit: Der Firebug ist nicht zu schlagen und was im Firefox funktioniert, läuft auch fast immer so in Opera und Safari.

In meiner Statistik tauchen übrigens munter alle möglichen Alt- bis Uraltversionen von Opera auf, Opera 9.5 macht nur etwa die Hälfte aller Opera-Nutzer hier aus. Insgesamt bewegt sich Opera hier im 5%-Bereich.

Habt ihr mal Opera Mobile 9.5 (zur Zeit noch beta) und Opera Mini gesehen? Unter Windows Mobile und auf normalen Handys sind die beiden so viele Klassen besser als die üblicher Browser-Frust-Suppe.

Es gibt etliche Auszeichnungen in HTML, die kein Browser auswertet. Dazu gehört das cite-Attribut zum Blockquote-Tag. Gibt man dort eine Quelle an (wie ich das meistens tue), hat das zwar keinen greifbaren Effekt beim Besucher der Website, aber es gibt einen semantischen Zusammenhang wieder und schadet ansonsten auch nicht. Genau das will man doch eigentlich. Also pro cite-Attribut zu Blockquotes!

Leute, löst Euch endlich von dem, was die Browser so anzeigen oder nicht. Ihr zeichnet mit HTML Inhalte aus und verknüpft diese miteinander. Ob und wie das hinterher beim Besucher aussieht ist eine Frage der Präsentation und die wird an anderer Stelle bestimmt. Das Web ist nun mal kein Papier. Also liebe Designer, wenn ihr Webdesigns macht, denkt daran. Immer und immer wieder bekomme ich Printdesigns angeliefert von Designern, die sich Webdesigner schimpfen. Und dann wird auf die Frage, was bei anderen Viewport-Größen passieren soll, mit einer Gegenfrage geantwortet: Was ist ein Viewport? Andere hüllen sich einfach komplett in Schweigen, und viele sagen immerhin ehrlich: Nichts, wieso?

Und dann sind da die Online-Redakteure, die immer wieder nach fettem Schriftsatz fragen und wie man Tabs im jeweiligen CMS eingibt (Komisch, mit Tab springe ich immer aus dem Eingabefeld raus). Hey: Ihr seid Online-Redakteure! Klingelts da? Vielleicht sollte man sich auf die Eigenheiten des Mediums einfach mal einstellen und dessen Vorteile nutzen lernen, statt in dem Medium verhaftet zu bleiben, mit dem man aufgewachsen ist. Einmal das Hirn eingeschaltet und nur einen Abend lang aufmerksam ein gutes Buch gelesen und schwupps, kann man das. Denn: Die Auszeichnung von Inhalten mit (X)HTML ist eigentlich derart simpel, dass man da gar nicht viel lernen muss. Man muss nur wollen. Da sind eine Hand voll Tags mit spezifischen Bedeutungen(!), die muss man kennen oder nachschlagen können. Das wars eigentlich schon für den Online-Redakteur. Die komplizierten Sachen hat doch die IT-Abteilung längst gemacht. Merke: Das sind nicht nur normale Menschen mit normalen Monitoren mit Windows XP da draußen, die Eure Inhalte erfassen möchten. Da sind auch Maschinen (nicht nur Google), Menschen mit mannigfaltigen körperlichen und geistigen Beeinträchtigungen oder auch mal Leute, die mit ihrem Handy kommen oder mit Linux oder ohne Maus oder wie auch immer. All diese Leute profitieren von den hilfreichen Angaben, die sich nicht direkt im normalen Browser sichtbar äußern. Wer das weiterhin vor sich hin ignorieren möchte, sollte vielleicht mal über einen Berufswechsel nachdenken.

Nachtrag: Das ist übrigens auch einer der Gründe, warum ich das WYSIWYG-Prinzip im Webbereich (zumindest aber in der jetzigen Form) als grundlegend gescheitert ansehe: Wer für Online-Medien Inhalte schreibt, muss einfach Meta-Informationen wie das cite-Attribut am laufenden Band eingeben. Und Meta-Informationen sieht man in der Regel nicht, so dass es einer geeigneten Visualisierung bedarf, was wiederum dem WYSIWYG-Prinzip widerspricht. Scheiße! WYSIWYG funktioniert nur sinnvoll mit rein visuellen Medien, für alles andere kann es nur einen Ansatz zur Arbeitserleichterung darstellen. Oder jemand erfindet einen wirklich guten Spagat-Ansatz. Das WYSIWYM (hier hab ich dazu schon mal was geschrieben) ist da schon mal ein interessanter Ansatz, verwirrt allerdings nach meiner Erfahrung viele Leute mehr als ein nacktes Eingabefeld, das HTML oder BBCode erwartet.

Frank Westphal hat eine neue feine Rivva-Funktion an den Start gebracht: Die Blogkarte. Nichts weltbewegend neues an sich, aber gewohnt schön umgesetzt. Ich stehe auch drin und bevölkere Flingern-Nord. Der Arme Kerl hat sich, um seine 1304 eingetragenen Blogs zu geotaggen, durch fast alle davon durchgewühlt und die Adressen aus dem Impressum gezogen. Lästige Aufgabe. Wirklich schlimm, dass nur so wenige Websites ihre Adresse im hCard-Format anbieten, wobei ich mir hier mal nicht an die eigene Nase fassen muss: Meine Adresse im Impressum hat diese Mikroformate und hat dem armen Frank wenigstens bei mir das manuelle Verarbeiten erspart. Liebe Leute, die ihr Euch Webdesigner (oder so) nennt und nicht wisst, was es damit auf sich hat: Nachsitzen, sofort!

Angeregt durch die ganze Kartensache habe ich jetzt auch Geoinformationen in den Header dieses Blogs eingebaut, auf dass die Verortung in Zukunft noch einfacher vonstatten geht. Wenn man der sich hierbei selbst anzweifelnden Wikipedia vertrauen kann, funktioniert das für meine Adresse folgendermaßen:

<meta name="geo.region" content="DE-NW" />
<meta name="geo.placename" content="Düsseldorf" />
<meta name="geo.position" content="51.2288;6.81500" />
<meta name="ICBM" content="51.2288, 6.81500" />

Die Geokoordinaten kann man sich mit Google-Earth generieren oder die praktische lokale Suche bei der Rivva-Karte benutzen, die einem die beiden letzten Zeilen zu einer Adresse ausgibt. Das werde ich jetzt ein paar mal machen und das ein oder andere Projekt damit versehen.

P.S. Jeder fängt mal klein an, deswegen noch mal der kurze Anfängerhinweis: Diese Angaben gehören in den Head-Bereich einer (X)HTML-Seite. Ich weiß noch, wie ich ganz (gaaaaanz!) am Anfang einfach nicht eingesehen habe, wozu dieser komische unsichtbare Bereich gut sein soll. Von CSS war damals nicht die Rede, Scripte können ja überall hin und eine Charset-Angabe fand ich überflüssig (weil ich nicht wusste, was das bedeutet). Und das Title-Tag hätte ich auch lieber weg gelassen. Zu meiner Entschuldigung: Ich war damals 15. Heute fragt sich ja so mancher Webentwickler, wofür dieser komische alte Body-Bereich noch gut sein soll, kann man doch alles per AJAX ins DOM hängen… Wie sich die Zeiten ändern.

P.P.S. Nebenbei gibt es bei Rivva jetzt die Planeten, Düsseldorf ist als eine der blogaktiveren Städte in Deutschland schon vertreten. Eine sehr schöne Funktion, vielen Dank.

Ich mag keine Blogparaden und son Zeugs, da ich aber gerne von mir erzähle und mir die Fragen in den Kram passen, beantworte ich mal den Fragensatz des Webstandard Blogs:

Seit wann beschäftigst du dich mit den Themen Webentwicklung bzw. Webdesign?

Wir hatten schon früh einen Atari 1040 STF, da war aber nix mit Web und so. Dieser Atari war aber der Grund dafür, dass mein Bruder erst mit einem Pentium 200MMX die PC-Zeit in unserem Haushalt einläutete und etwas später auch die Internet-Ära. Spannend, und das nicht mal in erster Linie der frei verfügbaren Pornographie wegen. Auf irgendeiner Heft-CD war dann die Frontpage 97 Beta drauf und ich hab damit rumgeschrubbt, schlimme Zeit. Der WYSIWYG-Ansatz gefiel mir aber schon damals nach kurzer Zeit gar nicht (Kontrollverlust und so) und so habe ich nur die Code-Funktion von Frontpage genutzt und die Vorschau gemieden, die mir stets ungefragt meinen Code kaputt gemacht hat. Um die Frage zu beantworten: seit 1996/1997 rum bin ich dabei, hab also mit 14 oder 15 angefangen.

Welches war deine erste Entwicklungsumgebung bzw. der erster Editor in Sachen Webentwicklung?

Entwicklungsumgebung... Naja Frontpage 97 Beta halt. Schnell bin ich auf den Trichter mit Allaire Homesite gekommen, das dann ja im Dreamweaver aufgegangen ist, dessen erste beiden Versionen ich auch zeitweise benutzt hatte. Die Reihenfolge weiß ich nicht mehr, jedenfalls habe ich mit schönen Netscape 4 Layer-Elementen hantiert und die Abonnierfunktion des IE4 fand ich ganz groß (die gleiche Kiste wie heute RSS übrigens, nur proprietär und wenig durchdacht). Auch habe ich mit JavaScript meine ersten "Programmiererfahrungen" gemacht. Für all das kam nur die Arbeit direkt im Code in Frage.

Welches war dein erstes Bildbearbeitungsprogramm und nutzt du es noch immer?

Paint Shop Pro 4.11 war mein erstes Bildbearbeitungsprogramm und hat mich auch bis zur Version X2 begleitet. Nach wie vor kein schlechtes Programm. Mit Photoshop kam ich gar nie klar, vor allem nicht mir Version 3 und 4. Außerdem war das Programm schon immer viel zu teuer für den von mir genutzten Funktionsumfang, auch wenn ich es als Schüler sowieso nicht gekauft hätte… Heute versuche ich mich an The GIMP zu gewöhnen. Fällt schwer, aber wer Open-Source konsequent nutzen möchte, der muss auch Kröten schlucken. Gut, dass ich so viel Grafikarbeiten nicht mache.

Welches war dein erstes und letztes Buch, zu den Themen Webentwicklung bzw. Webdesign?

Die gedruckte Fassung von SelfHTML von Stefan Münz war mein erstes und lange einziges Buch zum Thema. Die Online-Fassung war einfach aktueller und besser durchsuchbar. Meine neuesten und sehr geschätzten Bücher zum Thema sind die großartigen "Little Boxes" und Little Boxes 2" von Peter Müller, die einen wirklich sinnvollen didaktischen Ansatz verfolgen.

Welche Top-3 Blogs zu den Themen Webentwicklung bzw. Webdesign sind von dir abonniert und würdest du auch anderen Lesern empfehlen?

Ganz klar: Der Krautkosmos von den Webkrauts, das Web Resources Depot und die Technikwürze, die aber ein Podcast ist und momentan irgendwie mehr oder weniger eingeschlafen zu sein scheint, hoffentlich kommt da wieder mehr.

Danke an Stefan Blanz für seinen schönen Artikel über den gemeinen Delinser (oder deutsch Löscheinfüger). Ich bin ein großer Anhänger dieses rhetorischen Typus und nutze von Zeit zu Zeit seine unbändige Kraft und Coolness, meine politische Inkorrektheit oberflächlich zu kaschieren in geordnete Bahnen zu überführen, aber trotzdem die Message zu behalten. In gesprochener Sprache funktioniert das ganze ja auch, wenn man markt, dass eine nicht ganz saubere Aussage korrigiert werden muss. In solchen Fällen greifen Leute mit Mutterwitz gerne auf eine überdeutliche Verbesserung des eben gesagten zurück und sichern sich nebenbei noch ein paar Lacher.

Nach Stefan Blanz bin ich übrigens Der Ideologe: Der Diffamier-Delinser, weil ich das Mittel meistens nutze, um (gemeine, fiese, sonstwie wenig nette) politische Statements unterzubringen. Schön, das mal systematisiert und mit einem griffigen Namen zu sehen.

In irgendeinem Podcast (ich glaube es war Technikwürze) kam mal nebenbei die Diskussion auf, dass man in HTML5 doch neue logische Textauszeichnungen einführen sollte: Ein Tag für Ironie <irony> fehlt der Beschreibungssprache bisher nämlich ganz dringend; bei der Gelegenheit könnte man auch die Tags <sarcasm> oder <btw> an den Start bringen. Wenn man etwas gehirnstürmt fallen einem sicher noch andere sinnvolle Auszeichnungen ein. Ein Kostrukt für Randbemerkungen ist meines Wissens nach im aktuellen Entwurf bereits enthalten, was ich als regelmäßiger Nutzer solcher Konstrukte sehr begrüße. Ob der Browser das dann als Randmeberkung oder Fußnote rendert könnte CSS regeln, den Bezugsbereich könnte ein Inline-Element herstellen. Oder zwei Elemente, eines für Randbemerkungen zu einem Absatz und ein Fußnotenelement. Ich frage mich nämlich schon lange, warum HTML als Beschreibungssprache für (ursprünglich wissenschaftlichen) Hypertext keine sinnvolle Auszeichnung für Fuß- und Endnoten mitbringt.

Ich fordere also ganz offen mehr Rechte für Metainformationen in HTML! Möglichkeiten zur Auszeichnung von Ironie, Randmeberkungen und anderen Metainformationen fehlen dringend, Zitate und Abkürzungen können ja auch zweckmäßig ausgezeichnet werden. Das Thema wäre sicher eine Diskussion wert, oder?

Anderer Vorschlag: Eine Sache wie Mikroformate auf ein semantisch neutrales Element angewendet könnte ebenfalls die benötigten Metainformationen tragen, aber das halte ich wegen der in der Auszeichnungssprache semantischen Neutralität für keine wirklich zufriedenstellende Lösung.

Eine kurze Googlesuche fördert auf die Schnelle zwei interessante Dinge zu Tage: In einigen Foren gibt es einen BB-Code für Ironie in der Form [irony]ironische Bemerkung[/irony], was mit einem zitatähnlichen Kasten und einer direkten textlichen Warnung ausgezeichnet wird. Auch findet man allenthalben eine pseudo-HTML-Auszeichnung mittels eines <ironie>-Tags: Offensichtlich gibt es reichlich Bedarf für diese Auszeichnung. Dabei fällt mir auf, dass es auch ein Tag für Gefühlsausdrücke wie *grins* oder Emoticons geben könnte: <emotion rel="lachender Smilie">:D<emotion> oder <emotion>grins<emotion> oder so. Klar kann man auch ein Span drumrum setzen und mit einem Title versehen, aber das würde nur einen Tooltip für menschliche Leser erzeugen, eine Maschine würde das ignorieren und das als Text mitlesen. Zitate könnte man schließlich auch mit einem Span und einer CSS-Klasse und ggf. einem rel- und einem title-Attribut markieren. Ein echter semantischer Zusammenhang wird so nicht ausgezeichnet. Und dafür ist HTML doch da, oder?