Knapp zwei Jahre nach dem ersten Teil, komme ich endlich mal zu Nummer 2 🙂 Nach den ganzen Diskussionen um schema.org und Microformats V2 ist es mal wieder an der Zeit, am Image von Microdata zu arbeiten.

Namenskollisionen und Namespaces

class-Attribute werden in erster Linie zum Gestalten (CSS) und für JS benutzt! Laut "The State of Web Development 2010" setzen nur knapp 35% aller Befragten Microformats ein, das heißt mehr als 65% haben keine Ahnung von Mikroformaten oder setzten sie nicht ein. Das kann zu zwei Problemen führen:

1. Microformats werden oft durch Re-Designs zerstört. Facebook ist wohl das prominenteste Beispiel, nach einem Re-Design verschwanden alle Microformats von den Profilseiten.
2. Es werden fälschlicherweise class-Attribute interpretiert die gar nichts mit Microformats zu tun haben nur zufällig den passenden Namen tragen. Anfällige Klassen sind z.B. url (hCard), photo (hCard), summary (hReview), description (hReview) oder author (hAtom).

Um diesem Problem Herr zu werden denkt die Community Tantek Çelik über eine Art Namespace-Erweiterung nach.

Microformats

So könnten Microformtas demnächst folgendermaßen aussehen:

<div class="h-card">
 <span class="p-fn">Max Mustermann</span>
</div>

Dabei steht:

• "h-*" für die root-names, z.B. "h-card", "h-event", "h-entry"
• und "p-*" für "simple" (Text) Properties, z.B. "p-fn", "p-summary"

…und es gibt noch eine reihe weiterer Prefixes. Das ist zwar schön und gut und verhindert sicherlich einen Großteil der Namenskollisionen und man kann seinen Entwicklern sicherlich auch eintrichtern, alle x- Klassen in ruhe zu lassen… aber man mach damit jegliche Semantik kaputt. Nix mehr mit Plain Old Semantic HTML (POSH):

POSH encapsulates the best practices of using semantic HTML to author web pages. Semantic HTML is the subset of HTML 4.01 (or XHTML 1.0) elements and attributes that are semantic rather than presentational. The best way to learn and understand POSH is to do it.

…und semantic class names:

Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Außerdem verkompliziert man das, jetzt noch so einfach zu nutzende, Format unnötig. Wann ist etwas eine id (i-*) oder eine Nummer (n-*) und was ist mit Attributen, die sowohl aus auch sein können?

Microdata

Der Microdata Teil ist relativ schnell abgehandelt… Durch die Trennung von Semantik und Design kommt es bei Mircodata per se zu keinen Kollisionen:

<div itemtype="http://microformats.org/profile/hcard" itemscope>
 <span itemprop="fn">Max Mustermann</span>
</div>

Informationen Referenzieren

Informationen stehen auf Webseiten nicht immer so nahe beieinander, so dass es oftmals schwer ist, alle Daten mit einem HTML Attribut zu umschließen.

Microformats

Je komplizierter das Format oder der Anwendungsfall, desto mehr stößt man mit Microformats an die grenzen des machbaren. HTML 4 bietet keinerlei Mechanismen, den oben angesprochenen Problem zu lösen, deshalb greift die Microformtas-Community zu einer recht Kreativen Lösung: dem include-pattern.

<div class="vcard">
 <a class="include" href="#author-name"></a>
</div>

<span class="fn n" id="author-name">Max Mustermann</span>

oder:

<div class="vcard">
 <object class="include" data="#author-name"></object>
</div>

<span class="fn n" id="author-name">Max Mustermann</span>

Nette Idee mit etlichen Unschönheiten:

• Leere HTML-Elemente
• Zweckentfremdung von Object- bzw. Link-Element
• Die Nutzung von <object /> führt zu einigen Problem bei einigen Versionen von Internet Explorer, Safari und Firefox

Microdata

Microdata löst das Problem mit dem itemref-Attribut:

<div itemscope
     itemtype="http://microformats.org/profile/hcard"
     itemref="author-name">
 ...
</div>

<span itemprop="fn n" id="author-name">Max Mustermann</span>

Viel mehr gibt es dazu eigentlich nicht zu sagen 🙂

Fazit

Als Fazit, passt hier sehr gut ein Satz den ich auch als Fazit im aktuellen Webstandards-Magazin verwende:

Microformats sind und bleiben Plain Old Semantic HTML und man sollte auch in Zukunft keinesfalls darauf verzichten sie einzusetzen, selbst mit dem Risiko einer fehlerhaften Implementierungen oder Namenskollisionen, „erzieht“ die Nutzung von Microformats einen jeden Webentwickler dazu „schönen“ und „sprechenden“ HTML-Code zu schreiben.

…um HTML-Code aber wirklich maschinenlesbar zu machen, wird es Zeit auf Microdata und RDFa zu setzen. Microformats haben den Weg für bessere und native Lösungen geebnet und haben weiterhin ihre Daseinsberechtigung aber man sollte nicht mehr als dem Format machen, als es leisten kann.

RSS readers like you are the unsung heroes of the internet. Keep up the good work!

Wie schon erwähnt, vereint Microdata die Vorzüge von RDFa und Microformats in einem Standard… aber nicht nur das, Microdata (in Verbindung mit HTML5) bietet auch einige schicke Lösungen für diverse Microformats-Problemchen.

Das abbr-design-pattern oder das value-class-pattern

Microformats:

Das abbr-design-pattern ist bisher wohl das umstrittenste Pattern im Microformats-Wiki. Grund für die Kritik an dem Pattern ist die etwas unorthodoxe Verwendung des <abbr> Tags um maschinenlesbare Meta-Informationen bereit zu stellen.

<div class="vevent">
  <abbr class="dtstart" title="2007-10-05">October 5</abbr>
  ...
</div>

Eine erste Alternative aus der Microformats-Community ist das value-class-pattern, das zwar das Accessibility-Problem „behebt“ aber noch lange keine Perfekte Lösung bietet.

<div class="vevent">
  <span class='dtstart'>
    <span class='value-title' title='2007-10-05'> </span>
    October 5
  </span>
  ...
</div>

Der HTML-Code wird durch weitere Elemente unnötig aufgeblasen und das Pattern basiert auf teilweise leeren Elementen.

Microdata/HTML5:

In HTML5 gibt es dagegen ein spezielles Tag um Zeit und Datum sowohl user als auch maschinenlesbar zu machen.

<div itemscope
  itemtype="http://microformats.org/profile/hcalendar">
  <time itemprop="dtstart" datetime="2007-10-05">October 5</time>
  ...
</div>

Reine Meta-Informationen

Microformats:

Eigentlich spricht es gegen die Prinzipien der Microformats-Idee, reine Metadaten zu verwenden:

Visible data = more accurate data. By designing for humans first and making the data presentable (thus viewed and verified by humans), the data is inevitably more accurate, not only to begin with (as errors are easily/quickly noticed by those viewing the pages/sites), but over time as well; in that changes are noticed, and if data becomes out-of-date or obsolete, that’s more likely to be noticed as well. This is in direct contrast to „side files“ and invisible data like that contained in <meta> tags.
— Tantek Çelik

…aber GEO-Daten sind z.B. Informationen die der Benutzer nicht unbedingt sehen muss.

<div class="geo">
 <span class="latitude">37.386013</span>
 <span class="longitude">-122.082932</span>
</div>

Microdata/HTML5:

In HTML5 gibt es für dieses Problem eine recht schicke Lösung: Laut der Spezifikation sind <meta />-Tags im kompletten Quellcode (auch im body) erlaubt.

<div itemscope 
 itemtype="http://microformats.org/profile/hcard#geo">
 <meta itemprop="latitude" content="37.386013" />
 <meta itemprop="longitude" content="-122.082932" />
</div>

Fazit

Selbst wenn sich Microdata (item und itemprop) nicht durchsetzen sollte, sind <meta> und <time> schon ein echter „Segen“ für die Microformats-Community 🙂

Im zweiten Teil nehm‘ ich mir das include-pattern und das Problem der möglichen Namens–Kollisionen vor. Microdata – wie Microformats bloß besser… (Teil 2): über „Namenskollisionen und Namespaces“ und „Informationen Referenzieren“

Congratulations on being an RSS reader! You are part of an elite group of people who know how to stay updated in style.