microformats.org wird 7… Alles Gute!

Zur Feier des Tages hat sich Frances Berriman die Mühe gemacht, die letzten 7 Jahre zusammen zu fassen und einen Ausblick auf die kommenden Änderungen zu geben.

Da ich, seit ich bloggen kann, schon über Microformats berichte, will ich den Rückblick nicht weiter kommentieren und nur auf die kommende Weiterentwicklung ein wenig eingehen.

Microformats und HTML5

Seit dem ich das letzte mal über diese Kombination geschrieben habe, hat sich leider nicht viel geändert… Die Microformats Community weigert sich weiterhin auf Microdata oder RDFa „upzugraden“ und hält krampfhaft an den semantischen classes fest. Nichtsdestotrotz macht HTML5 mit <time /> und <data /> dem leidigen Thema abbr-design-pattern bzw. value-class-pattern ein Ende. Statt Meta-Informationen umständlich in HTML-Attributen zu verwurschteln, können Termine und GEO Daten bald sauber dargestellt werden:

<time class="dtstart" datetime="2006-09-23">a Saturday</time>
...
<data class="geo" value="37.386013;-122.082932" >Mountain View</data>Code-Sprache: HTML, XML (xml)

Immerhin! Mehr dazu im microformats-wiki.

Namespaces

Die wohl größten Veränderungen sind aber die geplanten Pseudo-Namespaces welche hauptsächlich das Parsen von Microformats vereinfachen sollen. Microformats waren bisher sehr fehleranfällig, da sie sich die class-Attribute mit CSS und JavaScript zu teilen hatten. Es besteht immer die Gefahr dass rein für CSS genutzte Attribute fälschlicherweise für Microformats genutzt wurden oder dass die semantischen Class-Names einem Re-Design zum Opfer fielen. Die Prefixes ‚h-‚, ‚p-‚, ‚u-‚, ‚dt-‚ und ‚e-‚ sollen das Zukünftig verhindern und ein generisches parsen ermöglichen.

'h-' kennzeichnet einen Microformats-Container

Bisher ist die Microformats Community etwas inkonsequent mit der Benennung ihrer Formate… Mal mit beginnendem „v“, mal mit „h“ und in seltenen Fällen auch ohne oder mit anderem Buchstaben:

• hCard: class="vcard"
• hAtom: class="hfeed"
• adr: class="adr"
• xFolk: class="xfolkentry"
• XOXO: class="xoxo"

Mit den Prefixes soll das jetzt alles vereinheitlicht werden:

• hCard: class="h-card"
• hAtom: class="h-feed"
• adr: class="h-adr"

'p-' zeichnet Properties aus

Die mit ‚p-‚ gekennzeichnet Properties sollten, wenn nicht expliziert definiert, als Plain-Text interpretiert werden (kein HTML). Ein klassisches Property ist beispielsweise der Name einer Person:

<div class="h-card">
 <span class="p-fn">Tantek Çelik</span>
</div>Code-Sprache: HTML, XML (xml)

'e-' zeichnet Rich Text aus

Das ‚e-‚ Prefix könnte als Abkürzung für „element tree“, „embedded markup“, oder „encapsulated markup“ stehen und kann im Gegansatz zu den Properties auch HTML-Code beinhalten. In hAtom könnte der entry-content zu e-entry-content und bei der hReview die description zur e-description werden.

'dt-' für DateTime und 'u-' für URL

Aus dtstart wird dt-start und alle URL-Felder bekommen ein vorgestelltes ‚u-‚:

<a class="u-url" href="...">...</a>

<img class="u-photo" src="..." />Code-Sprache: HTML, XML (xml)

Die URL kann in bestimmten Situtionen auch weg fallen, dazu aber im nächsten Beispiel mehr…

Simpel und unabhängig vom Format

Zukünftig soll es auch nicht mehr so umständlich sein Informationen semantisch auszuzeichnen. Will man derzeit einen simplen Link mit einer hCard versehen, muss man ihn wie folgt aufblähen:

<div class="vcard">
 <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>Code-Sprache: HTML, XML (xml)

Nach der Überarbeitung soll folgendes reichen:

<a class="h-card" href="http://tantek.com/">Tantek Çelik</a>Code-Sprache: HTML, XML (xml)

Dabei gilt die Regel: Wenn es sich bei (z.B.) einer vCard um einen Link oder ein Bild handelt, kann man auf ‚u-*‚ und ‚p-name‚ verzichten… so ungefär zumindest 😉

Mehr dazu im Microformats-Wiki: implied properties

Außerdem kommt mit v2 eine Anleitung wie Microformats auf andere Formate wie JSON gemappt werden sollen. Aus…

<a class="h-card" href="http://benward.me">Ben Ward</a>Code-Sprache: HTML, XML (xml)

wird…

[{
  "type": ["h-card"],
  "properties": {
    "name": ["Frances Berriman"] 
  }
}]Code-Sprache: JSON / JSON mit Kommentaren (json)

Fazit

Ich bin mir noch nicht ganz sicher was ich von den geplanten Änderungen halten soll… die Nutzung der neuen HTML5 Tags und die Vereinfachung und Vereinheitlichung der Formate finde ich gut und notwendig… Auch eine einheitliche Regel, wie Microformats in anderen Formaten abgebildet werden sollen (z.B. JSON) macht durchaus Sinn (warum das Sinn macht, hier)… aber den Pseudo-Namespaces kann ich bisher nichts abgewinnen! Der „Namespace“ sorgt zwar für mehr Qualität beim Parsen der Microformats, aber auf Kosten des semantischen HTMLs.

Microformats sollten weiterhin für schönes, semantisches HTML sorgen und mehr nicht. Geht es um maschinenlesbaren Code, sollte man mit der Zeit gehen und auf Microdata oder RDFa setzen. Ob man seinen Quelltext an Microformats v2 anpasst oder mit Schema.org auszeichnet sollte kaum mehr Aufwand sein.

…Übrigens: Wer noch mehr über die Vorteile von Microdata gegenüber Microformats lesen will, sollte sich die Ausgabe 10 des Webstandards-Magazin durchlesen oder die Reihe „Microdata – wie Microformats bloß besser…“ hier im Blog!