<div class="h-event">
    <time class="dt-duration" datetime="P20Y">
        20 Jahre Microformats 🎉
    </time>
</div>

Longread

Vor zwanzig Jahren haben @KevinMarks und @tantek.com Microformats in einer Konferenzpräsentation vorgestellt.

Happy Birthday 🎉

Ich bin ein bisschen spät dran, ich weiß, ich weiß, aber es gibt wenig, was mich schon so lange (online) begleitet wie das Format und die Community (abgesehen vielleicht von WordPress), dass ich das nicht unkommentiert lassen kann!!

Zu meiner Historie: Im Gegensatz zu vielen Anderen in der Branche, mache ich meinen Job nicht, weil ich Spaß am programmieren alleine habe. Ich hatte nie das Bedürfnis, als Kind oder Jugendlicher an einem Computer oder C64 herumzubasteln. Statt dessen bin ich Ende der 90er dem Internet/Web/Bloggen verfallen.

Das Web war:

But if you think of the years 1995-2005, you remember when the web was our social network: blogs, comments on blogs, feed readers, and services such as Flickr, Technorati, and BlogBridge to glue things together. Those were great years […]

Why Micro.blog is Not Another App.net

Eigentlich passt auch die Beschreibung des IndieWebs:

It is a community of independent and personal websites connected by open standards and based on the principles of: owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content.

indieweb.org

Ich habe damals angefangen Webseiten mit Frontpage zu bauen, hab den HTML Code verändert und geschaut wie sich das auf sie Seite auswirkt, hab CSS „drüber gelegt“, ein wenig Dynamik mit JavaScript dazu „gebastelt“… Es hat Spaß gemacht!

Ich bin also nicht durch die Freude am Programmieren im Web gelandet, sondern habe durch die Faszination am Web, programmieren gelernt 🙂

Wer sich damals, im deutschsprachigen Raum, mehr oder weniger seriös mit dem Thema HTML beschäftigt hat, ist früher oder später über die Webkrauts gestolpert und über diesen Dunstkreis, habe ich 2006 auch das erste Mal von Microformats gelesen.

Wenn man in letzter Zeit durchs Internet surft, stolpert man immer häufiger über den Begriff „Microformats“ oder sieht das grüne Symbol auf Kontaktseiten. Aber was genau sind Microformats und für was sind sie gut?

Microformats

Ich glaub es war das Blog von @pixelgraphix auf dem ich dieses „grüne Symbol“ zum ersten Mal entdeckt habe.

Die Idee hat mich tief beeindruckt! Ein Format, „designed for humans first and machines second„! HTML als API „nur“ unter Verwendung von class und rel Attributen, also klassisches Plain Old Semantic HTML (PoSH)!

Und irgendwie beschäftigen mich Microformats bis jetzt:

• Stand heute habe ich 226 Posts mit dem Tag „Microformats“ auf notiz.Blog veröffentlicht, das ist fast ein drittel aller Beiträge!
• Zwei meiner ersten WordPress Plugins haben Microformats verarbeitet:
  • hCard Commenting
  • Save Microformats
• Ich habe zwei WordPress Themes gebaut, weil bis dato keines Microformats in der Version 2 unterstützt hat.
• Mein erster Artikel für eine Print Magazin erklärte Microformats.
• Die erste Folge des Open Web Podcasts beinhaltet viel Microformats und später kamen auch weitere dedizierte Folgen dazu.
• Ich hatte meine ersten Vorträge zu Microformats, auf BarCamps und Webmontagen!
• Zentraler Inhalt meiner Thesis „Integration von Web 2.0-Inhalten in Smart Products“ war, das Verarbeiten von Microformats und deren Zuordnung zu realen Produkten.

Durch die Erfahrung der letzten Jahre habe ich mittlerweile eine etwas differenziertere Meinung zu „HTML als API“, das Ändert aber nichts an meiner generellen Faszination für Websemantiken.

Die Microformats Community hat mir außerdem die Welt des Open Webs und der Open Standards offenbart, immerhin haben Microformats direkt oder indirekt auch Initiativen wie DataPortability.org, DiSo und das IndieWeb beeinflusst.

Danke Microformats und noch einmal Happy Birthday 🥳!

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

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

Introducing #metaformats (https://microformats.org/wiki/metaformats), an extension to #microformats2 for parsing invisible data published in HTML meta tags, for backward compatibility with existing vocabularies consumed by multiple testable interoperable implementations.

https://tantek.com/2022/091/t1/metaformats

Der Vorschlag ist vom 01. April und war wohl ursprünglich als April-Scherz gedacht.

metaformats started as an April Fools joke concept to describe how to both publish using microformats class names and openly parse meta tags as a fallback for what should be in-the-body visible data, including backcompat with OGP, Twitter Cards, and meta author, description, and anything else real sites (like search engines) appear to consume.

https://indieweb.org/metaformats

Eine Art Fallback-Spezifikation für Microformats-Parser finde ich in der Tat etwas sperrig, aber ich mag die Idee eines Fallbacks an sich.

Microformats sind ein Building-Block des IndieWebs und werden unter anderem auch von Webmentions genutzt. Es sind Markup-Formate zur semantischen Auszeichnung von HTML. In der Version 2, werden Microformats aber fast ausschließlich von der IndieWeb Community benutzt und sind darüber hinaus wenig bekannt.

Aber gerade für WordPress ist es extrem schwer, bestehende Themes nachträglich mit Microformats zu „veredeln“. Wir haben es mit diversen Plugins versucht, mit nur mäßigem Erfolg. Andere Formate wie das Open Graph Protocol oder Schema.org (JSON-LD) sind da wesentlich einfacher zu integrieren, da sie nicht bestehendes HTML erweitern und durch den Support der großen Suchmaschinen und sozialen Netzwerke, auch viel attraktiver sind.

Ich bin kein großer Fan von embedded JSON-LD, aber wenn es nicht anders funktioniert und seine Reichweite hat, warum sollte man es dann ignorieren?

Das IndieWeb hat eigentlich eine großartige Philosophie um mit solchen „Problemen“ umzugehen.

bridge all the things is a nascent IndieWeb philosophy that prioritizes interoperability over ideology, NIH, historical disagreements, etc. ecosystems are valuable and powerful, and one easy way to extend an ecosystem is to bridge it with other existing ecosystems.

https://indieweb.org/bridge_all_the_things

Für das Webmention Plugin haben David und ich schon vor Monaten einen ganz ähnlichen Ansatz gewählt. Neben Microformats unterstützen wir auch OGP, Twitter-Cards, Schema.org, Meta-Header und die WordPress API, um eventuell fehlende Microformats v2 zu kompensieren.

Selbst wenn „metaformats“ nur als April Scherz gedacht waren, hat die Idee Potential um speziell Webmentions voran zu treiben, da sie eine direkte Abhängikeit zu einer speziellen Websemantik verhindert.

Bridge all the things!

Hey there, RSS reader! You’re one of a special few, choosing this old-school yet awesome way of staying informed. Kudos!

Ich lese Blogs!

Am liebsten persönliche (sind das Blogs nicht per Definition?), die keinen speziellen Themen-Fokus haben oder zumindest immer ihre Meinung mit einfließen lassen, wie z.B. anmutunddemut.de, wirres.net und hackr.de.

Ich habe außerdem ein Faible für /about Seiten (meine ist ironischerweise nicht wirklich aussagekräftig 🙁 ). Wenn es um persönliche Ideen und Meinungen geht, interessiert mich natürlich auch der Autor dahinter.

Vor ungefähr einem Jahr bin ich auf ein Projekt gestoßen, das die Idee der /about Page noch einen ticken weiter treibt: Die /now Page!

Most websites have a link that says “about”. It goes to a page that tells you something about the background of this person or business. For short, people just call it an “about page”. […] So a website with a link that says “now” goes to a page that tells you what this person is focused on at this point in their life. For short, we call it a “now page”. […] Besides answering the common question, “What are you up to these days?”, those who have a now page say it’s a good reminder of their priorities. By publicly showing what you are focused on now, it helps you say no to other requests.

Derek Sivers – https://nownownow.com/about

Bisher hab ich mir aber lediglich eine /now Page angelegt ohne mir weiter Gedanken dazu zu machen, bis ich vor ein paar Tagen über einen Artikel von Christian Tietze gestolpert bin.

And a “/now” page is a bulletin board-like page that indicates what someone is up to. It’s a status page. Unlike status feeds on social media, this page does not show incremental updates. It always show the latest status, period. And it doesn’t do push notifications. You have to go there and look. I’ve got one.

[…]

A problem I see is consumption. I sometimes look at what Matt Gemmel is up to, for example. I have to visit each person’s website manually.

Proposing the h-now Microformat to Mark-Up All Our /now Pages

Da hat er natürlich recht… Eine /now Seite macht wirklich nur dann Sinn, wenn man sie regelmäßig ließt… Ansonsten ist sie nicht viel mehr als eine zeitlich limitierte /about Page.

Um eine /now Seite abonnieren zu können, schlägt Christian ein neues Mircoformat vor: h-now.

(…es funktioniert natürlich auch mit h-entry oder semantischem HTML, aber ich liebe neue Formate!)

Christian hat natürlich auch gleich ein kleines Referenz-Tool geschrieben.

Außerdem hat er mich indirekt herausgefordert…

Everybody and their grandchildren can change a WordPress page template to include the h-now class somewhere around the body text. If you run a static site generator, it’s probably even simpler.

…und auch damit hat er recht!

WordPress bietet dafür zwei einfache Möglichkeiten: „Custom Page Templates“ und „Page Templates within the Template Hierarchy“ und natürlich lassen sich auch beide Varianten in einem Template kombinieren.

Über den Datei-Namen page-now.php wird das Template automatisch für die /now Page angezogen und es ist eigentlich keine weitere Arbeit notwendig, falls die Seite aber (warum auch immer) unter einem anderen Slug erreichbar sein soll, kann man das Template auch üder den /** Template Name: "/now" Template */ Header für jede beliebige Seite verfügbar machen.

Eine weitere Alternative wäre post_class zu erweitern, ein dediziertes Template bietet aber einfach mehr Möglichkeiten. Ein schönes Beispiel ist Dominik Schwinds https://lostfocus.de/now/, die er über die Category „nownownow“ updated.

Schöne Ideen! 🙂

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

Prateek Saxena arbeitet gerade daran, das zu ändern! Sein Theme ist seit diesem Jahr auf WordPress.org und er arbeitet fleißig am MF2 Support.

`war ne lange Zeit 🙂

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!

Im Ernst, ich freue mich sehr, dass Marcel Interesse an dem Thema hat (und das schon seit einer ganzen Weile) und nach einem kurzen Vorgespräch haben wir auch gemerkt, dass uns der Stoff so bald nicht ausgehen wird!

Die erste Ausgabe ist eine Bestandsaufnahme der letzten 15 Jahre „Open Web“ und ein kleiner Ausblick auf zukünftige Themen.

In der ersten Ausgabe der neuen Podcastreihe zum Themenkomplex ‚Open Web‘ sprechen Matthias Pfefferle und Marcel Weiß über die Evolution von OpenID, die uns einen Hinweis auf allgemeine Herausforderungen für Protokolle in der heutigen Zeit gibt; Stichwort Extrawürste der großen Teilnehmer, welche zu Balkanisierung führen. Weitere Themen sind die DSGVO und Dataportability, Mastodon, Identi.ca und wie ActivityPub aktuell OStatus als zugrundeliegendes Protokoll für dezentrale Netzwerke ablöst. Wir ordnen die Irrungen von Diaspora ein und reden last not least über die Tragödie der Microformats.

Viel Spaß beim Hören!

‚Hier & Jetzt‘ kann man per RSS-Feed abonnieren und findet man natürlich auch bei Apple Podcasts und in jeder Podcast-App.

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

2018 war ein durchwachsenes Jahr!

Mein privates „Ich“ hat letztes Jahr sehr viel Raum eingenommen und auch beruflich hat sich viel verändert.

Das heißt ich hatte generell wenig Zeit für mein online „Ich“ und wenn ich doch etwas Zeit hatte, war das Ergebnis meistens eher frustrierend.

Pfefferles OpenWeb

Ich habe für das SCREENGUIDE/Webstandards-Magazin in den letzten 10 Jahren 36 mal „Pfefferles OpenWeb“, 3 Artikel, 1 Titelthema und 1 Interview geschrieben! Letztes Jahr musste der Verlag das Magazin aus „wirtschaftlichen Gründen“ leider einstellen und ich hab es nicht einmal geschafft darüber zu schreiben!

notiz.Blog

Und zum Bloggen kam ich, trotz der gewonnenen Zeit auch nicht! Wenn ich dieses Jahr so weiter mache, muss ich mir meinen selbstvergebenen Titel als „Chronist des OpenWebs“ wieder selbst aberkennen!

IndieWeb

Das IndieWeb wächst und das ist prinzipiell auch gut so. Neben den ganzen Nerds und Geeks interessieren sich auch immer mehr Blogger und Journalisten für das Thema. In der Community spricht man von der 2. Generation.

Auch das Interesse an WordPress wächst. Das ist nicht verwunderlich, immerhin geht es um die Berufsgruppe der Schreibenden und deren Seiten werden, mit einer Wahrscheinlichkeit von 30%, mit WordPress betrieben.

Dieses Interesse beißt sich aber leider mit meinen Möglichkeiten. Von Anfang an verfolge ich folgende Grundsätze des IndieWebs:

Scratch Your Own Itches. Make tools, templates, etc. for yourself first, not for all of your friends or ”everyone“.

und:

Use what you make! Whatever you build you should actively use. If you aren’t depending on it, why should anybody else?

Ich baue (mittlerweile) ausschließlich Plugins die ich für sinnvoll erachte und ich baue sie so, dass sie für mich funktionieren. Das mag erstmal egoistisch klingen, es ist für mich aber die einzige Möglichkeit dieses „Hobby“ überhaupt zu betreiben.

Ich verstehe, dass Anwender teilweise überfordert sind, meine Plugins zu benutzen, kann sie aber nicht in dem Umfang optimieren, der nötig wäre. Ideal ist wahrscheinlich ein großes IndieWeb Plugin, welches alle Features bereit stellt und, am besten ohne viel Einstellungen, einfach funktioniert. Aktuell nutze ich 50% aller, vom IndieWeb vorgeschlagenen WordPress Plugins, eine allumfassende Plugin Suite würde dann also nicht mehr meinen Anforderungen entsprechen.

Ich habe aktuell keine Ahnung wie ich aus diesem Dilemma heraus kommen soll. Es gibt Plugins die will ich nicht aus der Hand geben und Plugins die ich an die Community übergeben habe, werden aus Mangel an Entwicklern nicht weiter gepflegt. Aktuell arbeiten maximal 3 Personen (mich inbegriffen) an über 10 unterschiedlichen Plugins.

…und wenn das noch nicht genug wäre, kommt das „Microformats Problem“ noch on top.

Microformats

Microformats2 und WordPress scheinen nicht kompatibel zu sein und das ist schade, immerhin sind Microformats DER Building-Block des IndieWebs. Mehr noch: Microformats sind die API des IndieWebs!

Ich habe in den letzten Jahren viel ausprobiert um das Problem zu lösen, aber es gibt keine generische Möglichkeit, ein WordPress Theme mit Microformats2 auszustatten.

Benutzt man ein Plugin, um über Hooks einige zentrale Elemente (wie z.B. den Titel) Semantisch auszuzeichnen, bekommt man nette Effekte, mit Themes die ihre Ausgabe „escapen“:

After activating the last version (1.1.0) of your plugin on WordPress 4.9.8 with understrap theme my meta entry become : Posted on September 12, 2018 by <span class='p-author h-card'>Author</span> instead of : Posted on September 12, 2018 by Author for fun I look into the code and I think the error is here but since I’m totally not a PHP developer I’ll pass on the potential PR

Versucht man es mit einer Art Microformats Feed, bekommt man Probleme, alle Meta-Daten zu integrieren. Schlimmer noch, man arbeitet gegen einen Grundsatz der Microformats:

Design for humans first, machines second

Zusammengefasst: Microformats gehören ins Theme, es gibt aber keine generische Lösung. Eine generische API ist möglich, widerspricht aber der Microformats-Idee.

Aktuell gibt es drei WordPress Themes die Microformats2 voll unterstützen und um sein Blog wirklich IndieWeb tauglich zu machen, muss man eines dieser drei Themes benutzen oder selber HTML bzw. ein Theme schreiben.

Das ist frustrierend! Außerdem liefen die Diskussionen (meines Erachtens) etwas aus dem Ruder, weshalb ich mich letztes Jahr entschieden habe, mich aus dem Microformats-Thema komplett heraus zu nehmen.

OStatus

OStatus ist das zentrale Protokoll, über das identi.ca, status.net, gnu.social und friendi.ca sprechen. Es ist arsch-alt, funktioniert aber immer noch prächtig!

Ich hab mich wie bolle gefreut als OStatus mit Mastodon wieder frischen Wind bekam, hab mein altes OStatus Plugin ein wenig aufpoliert und wollte gerade freudig darüber berichten, als Eugen Rochko, der Macher hinter Mastodon, einen meiner Bugs, mit folgenden Worten schloss:

Closing on the grounds that OStatus is no longer our primary mechanism and will be deprecated in the future.

Mein vorbereiteter Blogpost hatte den Titel „My Blog is my Social-Network“ und der erste Abschnitt lautete:

Ich habe in den letzte Woche an einem Update für ein WordPress Plugin gearbeitet, das ich seit 6 Jahren nicht angerührt habe… Nicht dass das Plugin an sich nicht mehr funktioniert hätte, aber PHP und WordPress haben sich weiter entwickelt.

Schade!

ActivityPub

Aber dann kam ActivityPub! ActivityPub ist der heiße Shit im Fediverse. So zu sagen OStatus in neu und besser! Was AtomPub für Atom ist, ist ActivityPub für ActivityStreams… und noch ein bisschen mehr.

ActivityPub ist außerdem der erste, vom W3C veröffentlicht, „Standard“ (abhängig davon wie man „Standard“ definiert), der versucht ein dezentrales, soziales Netzwerke zu definieren.

Naiv wie ich bin, dachte ich, ich geb‘ dem Ganzen eine Chance. Die Spezifikation ist relativ simpel und ein „Standard“ ist „wohl definiert“, das heißt es gibt nur einen Weg um ihn zu implementieren!

Das Ergebnis (Trommelwirbel): ein ActivityPub Plugin für WordPress!

War es so einfach wie ich gedacht habe? Natürlich nicht! Es hat natürlich doch wieder jede Plattform seine extra Wurst, aber im Gegensatz zu Microformats2, basiert ActivityPub auf einer „echten“ API und lässt sich somit relativ leicht in WordPress integrieren.

ActivityPub und das Plugin waren definitiv das Highlight des Jahres, immerhin ist WordPress jetzt offiziell ein Teil des Fediverse:

• https://fediverse.network/wordpress
• https://the-federation.info/wordpress
• https://fediverse.party/en/miscellaneous/

und laut dem „2018 Report“ von fediverse.network sogar auf Platz 8 von 13.

Fazit

Die Arbeit an ActivityPub hat eigentlich Spaß gemacht und ich werde mich wahrscheinlich auch 2019 hauptsächlich mit ActivityPub beschäftigen!

2018 war nicht so dolle, 2019 kann nur besser werden!

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!

[…] und Wertvorstellungen entspricht und nicht von der Mehrheit meiner Freunde abhängig sein.» Dezentrale Walled Gardens Hier erscheinen von Montag bis Freitag ausgewählte Links zu lesenswerten Texten und aktuellen […]

Mit Webmentions und Microformats2 hat sich zwar die Darstellung verbessert, aber die Texte… naja… haben sich „verändert“:

#100DoPP d84:
Both #AS2 & #Micropub are @W3C PRs!
Congrats @SocialWebWG @jasnell @evanpro @aaronpk!
https://www.w3.org/TR/micropub
https://www.w3.org/TR/activitystreams-core/
https://www.w3.org/TR/activitystreams-vocabulary

tantek.com/t4np2

Twitter sei Dank!

…da hätte man sich die Arbeit auch sparen können 😉

Hey there, RSS reader! You’re one of a special few, choosing this old-school yet awesome way of staying informed. Kudos!

Ich durfte mal wieder einen etwas längeren Artikel für das aktuelle SCREENGUIDE Magazin (Ausgabe 34) schreiben. Thema des Artikels sind Websemantics:

Websemantics sind fast 17 Jahre alt, und es hat eine ganze Weile gedauert, bis sie sich wirklich etabliert haben. Aktuell gibt es eine Reihe von Formaten, etwa OpenGraph, Twitter Cards, Schema.org, Microformats, RDFa und Microdata. Wir sagen Ihnen, auf welche Formate Sie sich konzentrieren sollten.

Websemantiken, genauer gesagt Microformats, haben vor einer halben Ewigkeit mein Interesse für offene Standards geweckt und deshalb hab ich mich sehr gefreut, mich wieder etwas ausführlicher mit dem Thema zu beschäftigen. Außerdem habe ich vor fast genau 8 Jahren meinen ersten Artikel über ein ganz ähnliches Thema geschrieben 🙂

Microformats erfreuen sich mittlerweile einer großen Verbreitung, alleine die Yahoo! Suche hat mehr als 4 Milliarden der verschiedensten Formate indiziert und die Zahl wächst stetig. Trotz dieser scheinbar großen Verbreitung und der Unterstützung verschiedenster Browser erreicht das Thema „Semantic HTML“ noch immer nicht die breite Masse. Dieser Artikel beschreibt die Probleme bisheriger Browserunterstützungen und vorhandene Alternativen.

Neben dem Websemantics Artikel, gibt es auch wieder eine Kolumne, diesmal über Micro.blog:

Facebook ist jetzt knapp 13 Jahre alt, und so mancher hat mittlerweile sein halbes Leben auf der Plattform dokumentiert. Je länger Facebook besteht, umso mehr binden wir uns an den Dienst. Deshalb gibt es immer wieder Ideen und Plattformen, um sich unabhängiger zu machen – wie etwa das neue Micro.blog, das gerade via Crowdfunding finanziert wurde.

Falls ich noch einmal zwei Artikel für eine Ausgabe schreiben sollte, sollte ich mir die Einleitungen der beiden Texte etwas genauer ansehen 😉

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

• Activitystrea.ms support (Das Format ist zwar nicht 100% AS aber wer würde denn bei der Fülle an „Standards“ jetzt kleinlich werden…)
• RSS support
• Pubsubhubbub (PuSH) support
• Webfinger support
• Microformats v2 support
• Media RSS und GeoRSS support
• rel-me (und damit auch indieauth support)

Mal schauen was sich damit alles basteln lässt, immerhin hab ich im SCREENGUIDE-Magazin (Ausgabe 18) noch groß getönt:

Mit ein paar wenigen Änderungen und dem Support von z. B. Microformats, RSS/Pubsubhubbub, AtomPub oder Pingbacks, wäre App.net kompatibel zu fast allen Blogs oder IndieWeb-Systemen. Das hätte zum Vorteil, dass sich App.net ohne weitere Anpassungen über RSS-Reader konsumieren und über Blogging-Tools befüllen ließe. Außerdem könnten Posts und Kommentare zwischen App.net und z.B. WordPress ausgetauscht werden, ohne auf komplizierte, dezentrale Protokolle im Sinne von Diaspora oder Tent.io zurückgreifen zu müssen.

😉

via Carsten Pötter

Hey there, RSS reader! You’re cool. Keep being awesome! 😎

<script type="application/ld+json">
{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

Embedded JSON? Wirklich? Und warum? Weil’s geht?

Neben Microformats, Microdata, RDFa, eRDF, OpenGraph Protocol und Twitter Cards jetzt also auch noch JSON? Super Idee!

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

Bob’s blog also retrieves other data required from the content of Alice’s new post, such as the page title, an extract of the page content surrounding the link to Bob’s post, any attributes indicating which language the page is in, and so forth.

Das führt bei WordPress zu Einträgen die ungefähr so aussehen:

[…] und Wertvorstellungen entspricht und nicht von der Mehrheit meiner Freunde abhängig sein.» Dezentrale Walled Gardens Hier erscheinen von Montag bis Freitag ausgewählte Links zu lesenswerten Texten und aktuellen […]

Der automatische generierte Ausschnitt lässt nicht wirklich erahnen was Markus Spath wirklich geschrieben hat und deshalb verüble ich es niemandem, wenn er die Pingbacks/Trackbacks auf seiner Seite auf eine simple Liste von Links beschränkt hat. Als die Spezifikation 2002 geschrieben wurde, war das mit dem „Ausschnitt um den Link“ sicherlich eine gute Lösung. Es gab keine andere Möglichkeit automatisch zu erkennen welcher Text genau zu dem Link gehört oder wann ein neuer Artikel, die Navigation oder sogar Werbung beginnt. Mittlerweile lassen sich Inhalte dank Websemantiken wie Microformats, RDFa oder Microdata sehr gut erkennen. Aber auch mit purem HTML5 Markup lässt sich problemlos ein <article /> und dessen Überschrift erkennen.

Pingbacks sind aktuell die einfachste und wahrscheinlich sogar die einzige Möglichkeit, Kommentare dezentral und vor allem Plattform unabhängig zu „verschicken“, deshalb verstehe ich nicht wieso es so lange gedauert hat, bis jemand (im Rahmen eines IndieWebCamps) auf die Idee kam sie den aktuellen Bedürfnissen und Möglichkeiten anzupassen anstatt sich weiter den Kopf über komplizierte dezentrale Protokolle zu zermartern. Wer sich das Salmon Protocol schon einmal angeschaut hat, weiß was ich meine…

Pingbacks haben diverse Vorzüge:

• Sie sind leicht zu implementieren (einfacher XML-RPC Request an jedem, im Text erwähnte URL)
• Sie bieten einen simplen Schutz (wenn auch keinen 100%igen) gegen Spam, da der Pingende zumindest für eine gewisse Zeit auf die ge-pingte Seite verlinken muss
• DRY… Die Webseite dient als API und man muss seine Texte nicht zusätzlich in diversen XML oder JSON Formaten anbieten

Auf der IndieWebCamp Seite gibt es eine Reihe an interessanten Diskussionen wie sich mit Hilfe von Microformats und ein paar rel-Attributen auch „Likes“ oder „RSVPs“ über Pingbacks realisieren ließen.

Ein Like könnte beispielsweise folgendermaßen aussehen:

<div class="h-entry"><span class="p-autor h-card">Matthias Pfefferle</span> likes <a rel="object-of-like" href="http://hackr.de">hackr.de</a></div>

Sandeep Shetty hat das auf sandeep.io sehr schön erklärt und implementiert!

Ben Werdmuller hat außerdem nochmal alles (Comments/Likes/RSVPs) als Video zusammengefasst:

Im nächsten Blogpost geht es dann um Webmentions, einer etwas moderneren Variante von Pingbacks.

Hey there, RSS reader! You’re one of a special few, choosing this old-school yet awesome way of staying informed. Kudos!

IndieWeb? Schon wieder so ein hippes Buzzword-Dingens wie DataPortability, Synaptic oder Federated Social Web? Naja, irgendwie schon aber irgendwie auch nicht… 😉

Seit dem ich das Internet für mich entdeckt habe hatte ich meine eigene Webseite… Von den ersten Frontpage (das hätte ich vielleicht besser verschweigen sollen) Versuchen auf Geocities mit Kostenlos-Domain-Weiterleitung (wer kennt noch kickme.to?), zum eigenen Webspace und Homesite, zu ersten PHP Erfahrungen und phpNuke, zu diversen Webseiten und Blogs und letztendlich auch zu meinem Beruf. Darum tue ich mich besonders schwer, Inhalte auf Facebook und Co. zu teilen/schreiben, wenn ich sie doch auch auf meiner eigenen Seite veröffentlichen könnte. Außerdem scheint sich meine Generation (oder vielleicht auch nur mein Freundeskreis) nicht sonderlich für Social Networks zu interessieren und man trifft sich lieber oder telefoniert.

Damit stecke ich natürlich in einer Zwickmühle… Einerseits interessiert mich Facebook nicht sonderlich, andererseits bringen Social Networks aber eine Menge Reichweite… und so ist mein Faible für DataPortability, DiSo oder dem Federated Social Web entstanden… Ich will weiterhin der Herr meiner Ideen und Texte bleiben aber schätze die Reichweite und die höhere Dialogbereitschaft von Twitter und Co. sehr.

Bisher hatten alle Bewegungen aber ein großes Problem: Sie hätten nur funktioniert wenn Google, Twitter und Facebook sich angeschlossen und ne Menge hippe „Standards“ eingebaut hätten. Das ist wohl auch der Grund weshalb man von vielen Projekten schon lange nichts mehr gehört hat. Das IndieWeb Credo spricht mir dagegen aus der Seele:

We should all own the content we’re creating, rather than just posting to third-party content silos.
Publish on your own domain, and syndicate out to silos.

Das IndieWebCamp findet in unregelmäßigen abständen statt und beschäftigt sich ausschließlich damit, wie man der Herr seiner Artikel/Tweets bleibt. Im Gegensatz zu DiSo baut die IndieWeb Idee aber nicht auf einem zentralen Framework, CMS oder Blogsystem auf, sondern motiviert jeden selbst aktiv zu werden. Im Vordergrund stehen recht allgemein gehaltene Konzepte und der Slogan eat your own dogfood… Programmiere für deine eigene Bedürfnisse und veröffentliche deinen Code, dass auch andere davon profitieren können. Ein paar Konzepte:

• POSSE (Publish (on your) Own Site, Syndicate Elsewhere): Veröffentliche alles auf deiner eigenen Seite und verteile es dann über die verschiedenen Kanäle.
• Comments: Veröffentliche auch Kommentare auf deiner Webseite und setze den Autor über Pingbacks oder Webmentions darüber in Kenntnis.
• Login: Mit einer Kombination aus rel-me und OAuth (IndieAuth oder RelMeAuth) lassen sich ironischerweise fast mehr Dienste ansprechen als mit OpenID.
• Web Actions: Ein ähnlicher (wenn auch pragmatischerer) Ansatz wie Web Intents. Share/Like-Buttons sollen sich dem Verhalten des Nutzers anpassen und ihm die Möglichkeiten anbieten die er benötigt, sei es das Teilen über Facebook oder eben über die eigene Seite.

(weitere „Building Blocks“ findet ihr im Wiki)

Ich mag die Idee schon alleine deshalb, weil sie aktuell Funktioniert und nicht von der Fertigstellung oder Einführung von diversen Protokollen abhängig ist (naja fast). So ne Art „Dezentrales Netzwerk für Arme“ 😉

Ich selbst versuche seit ein paar Wochen das NotizBlog IndieWeb tauglich zu machen und habe dazu auch ein paar Plugins auf Github veröffentlicht. Demnächst kommt aber sicherlich noch eine kleiner Anleitung in Form von einem Blogpost dazu.

Vielleicht hat ja jetzt der ein oder andere Blut geleckt und greift mir bei meinem WordPress Projekt ein wenig unter die Arme 😉

Macht euch unabhängig!

(Im Screenguide Magazin Ausgabe 17 gibt es übrigens noch eine etwas ausführlichere Beschreibung der einzelnen IndieWeb Building Blocks)

Hey there, RSS reader! You’re one of a special few, choosing this old-school yet awesome way of staying informed. Kudos!

Das Theme verschönert übrigens das notizBlog und ist aus folgenden Gründen großartig:

POSH – Plain Old Semantic HTML5

SemPress basiert, wie schon erwähnt, auf Toolbox und die HTML5 Struktur wurde auch weitestgehend beibehalten. Ich habe lediglich einige Tags in (meiner Meinung nach) semantisch passendere getauscht. Im Detail:

• Semantische Tags – Ich habe einfach mal geschaut welche Tags Toolbox noch nicht unterstützt und sie dann, hoffentlich richtig eingebaut :).
• HTML5 Input-Types – SemPress unterstützt einige der neuen Input-Types wie z.B. „search“, „email“ und „url“. Mehr dazu in einem älteren Artikel.

Websemantics

Eigentlich hab ich das ganze Projekt (wie schon erwähnt) ja nur gestartet, damit ich mal wieder was produktives mit Microformats machen und Schema.org lernen kann. Hier also der Semantic Overload:

• Microformats – Toolbox selbst unterstütz Microformats ja schon von Haus aus und ich musste nur kleine hAtom fixes und die richtigen Profile Header setzen.
• Microformats v2 – Ich bin zwar kein großer Fan von Microformats 2, aber ich wollte testen wie leicht sich das Theme um neues HTML-Classes erweitern lässt und wie viel Arbeit es bedeutet. SemPress unterstützt hCard 2 und hAtom 2.
• Microdata/Schema.org – Ähnlich wie bei Microformats v2 wollte ich testen wie schwer es ist, Schema.org einzubauen. Das Theme unterstützt http://schema.org/Blog, http://schema.org/BlogPosting and http://schema.org/Person.

Was ich noch gerne einbauen will ist hMedia für alle möglichen Medieninhalte wie z.B. auch WordPress „Images“ und „Galleries“ und natürlich auch das Schema.org Pendant.

WordPress Features

Neben dem ganzen semantik Gedöns, hab ich natürlich auch ne Menge WordPress-Features eingebaut.

• Post Thumbnails – SemPress unterstützt diverse Post-Thumbnail Größen (maximal 600px) und versucht sie bestmöglich darzustellen. Alle Bilder kleiner als 480px werden z.B. mit float right in den Text integriert.
• Post Types – Im Gegensatz zu Toolbox unterstützt SemPress folgende Post-Types: „aside, status, gallery, video, audio, link, image“ und fast alle haben auch ein individuelles Layout spendiert bekommen.
• …außerdem: Localization, Sidebar-Widgets und die WordPress‘ Navigation Menu.

Mal schauen ob ich noch ein Custom-Header-Image mit rein nehmen werde…

CSS und Design

Zuerst sollte SemPress gar kein Design bekommen, aber man muss ja auch bei CSS und Fonts auf dem Laufenden bleiben! Ich mach das ja schließlich nicht zum Spaß sondern zur Fortbildung :). Da ich aber kein wirklich großer Designer bin, hab ich mir ne Menge Ideen und CSS bei folgenden großartigen Projekten ausgeliehen:

• Das Basis-CSS hab‘ ich von Toolbox übernommen.
• Die Tabellen, Buttons, Input-Felder, Code-Boxen habe ich mir bei Twitters Bootstrap gemopst.
• Die Icons, die vor einigen Artikeln erscheinen (z.B. die vom Typ Video oder Audio) sind von von Font Awesome.
• Danke auch an HTML5 Boilerplate für einige Ideen!

Ein paar weitere Kleinigkeiten (auf die ich auch bissle Stolz bin):

• Man kann den bei dem <code />-Tag die Programmiersprache mir data-programming-language="PHP" setzen und es wird wie folgend angezeigt: <?php echo "Hallo Welt"; ?>
• Das Theme kommt komplett ohne Bilder aus.

Responsive Design

Das Theme sollte eigentlich und hoffentlich auf jedem Gerät gut aussehen und unterstützt drei++ Breiten:

• Volle Breite + Sidebar rechts
• Volle Breite + Zweispaltige Sidebar am Ende der Seite
• Variable Breite (die, für das Gerät beste Breite mit einem) + Einspaltige Sidebar am Ende der Seite.

Außerdem passt sich das Menü automatisch an die Größen an und das ganz ohne JavaScript! …beim Drop-Down Menü gibt es zwar noch keine Möglichkeit das Menü wieder zu schließen, aber wer will das schon 😉

Was jetzt noch?

Da mir das themen ne Menge Spaß gemacht hat werde ich wohl auch weiterhin fleißig an SemPress weiter basteln und es noch semantischer und WordPressiger machen. Falls ihr irgendwelche Fehler findet oder Dinge besser könnt wie ich… bitte helft mir und forkt SemPress!

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

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>

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>

'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="..." />

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>

Nach der Überarbeitung soll folgendes reichen:

<a class="h-card" href="http://tantek.com/">Tantek Çelik</a>

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>

wird…

[{
  "type": ["h-card"],
  "properties": {
    "name": ["Frances Berriman"] 
  }
}]

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!

Hey there, RSS reader! You’re one of a special few, choosing this old-school yet awesome way of staying informed. Kudos!

Immer mehr Partnerseiten können zusätzliche multimediale Inhalte im Kontext von Tweets darstellen. Ganz eindeutig ist bisher nicht, wohin diese Reise für Twitter geht.

Aber ich habe mir nichts weiter dabei gedacht… Immerhin macht das Twitter ja schon seit einer ganzen Weile und ich meine mich zu erinnern, irgendwo gelesen zu haben, dass sie dazu oEmbed einsetzen… Also alles in bester „OpenWeb“-Ordnung 🙂

Aber, Geek der ich bin, hab ich mir gestern zufällig einen Quelltext angeschaut in dem ich auf folgendes entdeckt habe:

<meta name="twitter:card" content="summary">
<meta name="twitter:url" content="...">
<meta name="twitter:title" content="...">

…und nach kurzem googlen bin ich auf die Twitter Cards gestoßen, Twitters eigenes, kleines Open Graph Protocol. Mit den Twitter Cards bekommen Seitenbetreiber ein Set an Meta-Tags an die Hand, und Twitter kann diese Informationen nutzen um die tweets mit den oben erwähnten Mediendaten anzureichern.

…und ich wollte mich gerade darüber aufregen, warum Twitter dazu eine eigene Meta-Sprache erfindet, da bin ich in der Doku ironischerweise auf folgendes gestoßen:

You’ll notice that Twitter card tags look similar to OpenGraph tags, and that’s because they are based on the same conventions as the Open Graph protocol. If you’re already using OpenGraph to describe data on your page, it’s easy to generate a Twitter card without duplicating your tags and data. When the Twitter card processor looks for tags on your page, it first checks for the Twitter property, and if not present, falls back to the supported Open Graph property. This allows for both to be defined on the page independently, and minimizes the amount of duplicate markup required to describe your content and experience.

„Ok“, dachte ich… vielleicht reichen die Open Graph Properties ja nicht aus um alle Informationen, die Twitter braucht, abzubilden. Also hab ich mir mal die Mühe gemacht sie zu vergleichen:

Es lässt sich also prinzipiell alles mit dem Open Graph Protocol abbilden, es fehlen lediglich die Felder twitter:site:id und twitter:creator:id. Aber wegen diesen zwei Feldern muss man doch nicht das ganze Format „kopieren“. Es reicht doch ein kleiner Absatz, wie man den Open Graph mit den proprietären Werten erweitert… So wie das auch Facebook praktiziert:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:og="http://ogp.me/ns#"
      xmlns:fb="https://www.facebook.com/2008/fbml">
      xmlns:twitter="https://dev.twitter.com/docs/cards">
  <head>
    <title>The Rock (1996)</title>
    <meta property="og:title" content="The Rock"/>
    <meta property="fb:admins" content="USER_ID"/>
    <meta property="twitter:site:id" content="@USER_ID"/>
    ...
  </head>
  ...
</html>

Hoffentlich überlegt sich das Twitter noch einmal… Wenn nicht, wird dank dieser (und folgender) Redundanzen der <head /> einer Webseite in ein paar Jahren mehr Informationen beinhalten wie der <body />.

…welch ein Over-<head> 🙂

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!

Marcels Fazit:

Neben dem Chaos, das das Einbinden offener Standards, oder Möchte-gern-Standards für Entwickler unattraktiv macht, gibt es noch ein weiteres Problem, dem sich das Open Web, das dezentrale Web, gegenüber sieht: Die Protagonisten, also die Fürsprecher und die, welche die Grundlagen entwerfen und weiter entwickeln, haben es bis dato versäumt, einen effektiven Hebel zu erschaffen, um Anreize für alle Seiten zu generieren, die dann zu den virtuosen selbstverstärkenden Effekten führen.

Die im Gespräch angemerkte Kurzlebigkeit der Standards ist das Gegenteil eines effektiven Hebels: Sie treibt die notwendige Entwicklerseite frustriert weg.

Ich bin im übrigen mittlerweile fast der Meinung, dass jede signifikante Weiterentwicklung von Webstandards von Unternehmen wie Google und Facebook kommen wird und muss. Denn in deren Produkten steckt der Hebel schon drin. Das bringt uns allerdings wieder zurück zu den Argumenten von Bradbury zur Abhängigkeit bei Web-APIs.

Obwohl ich das immer noch nicht so richtig wahr haben will hat Marcel mit seiner Aussage wohl den Nagel auf den Kopf getroffen. Ein aktuelles Beispiel: Schema.org! Ich beschäftige mich seit mehr als 5 Jahren mit Microformats und RDFa… für mich ist Schema.org einfach nur ignorant!
Für die meisten Webentwickler ist Schema.org aber der erste Berührungspunkt mit Websemantiken, wieso sich also weiter mit Altlasten herumplagen. Google, Microsoft und Yahoo! einigen sich auf Schema.org… ein simples Format und ein valider Usecase. Damit wird Schema.org zum neuen defacto Standard ohne je den Anspruch darauf erhoben zu haben:

schema.org is not a formal standards body. schema.org is simply a site where we document the schemas that three major search engines will support.

Der Punkt ist: Was bringens uns „Standards“ von W3C und IETF wenn sie niemand unterstützt. Wir brauchen Formate die ein Bedürfnis decken und von der breiten Masse akzeptiert werden… ob man sie jetzt „Standard“ nennt oder nicht!

(Um dieses Thema geht es übrigens auch in meiner Kolumne im nächsten Webstandards Magazin.)

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

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.

You are a true RSS aficionado! While others are drowning in social media noise, you enjoy the simplicity and control of RSS. Congrats!

Seit Freitag gibt es wieder eine neue Ausgabe des Webstandard-Magazins, mit dem Fokus auf Communities.

…als hätte ich es gerochen, passt das Thema meiner Kolumne recht gut zu den aktuellen Diskussionen um Microformats, Microdata, RDFa und schema.org. Noch genauer: Es geht um die Zukunft der Microformtats.

Dieses Jahr feierten die Microformats ihren 8. Geburtstag. In diesen 8 Jahren haben sich mehr als zwei Milliarden hCards im Yahoo! Index angesammelt und die Mikroformate dominieren mit 94% Googles rich snippets (im Verhältnis zu RDFa und Microdata). Trotz allem sind Microformats eine Übergangslösung und es wird Zeit für einen richtigen Standard!

Wie sieht die Zukunft der Microformats aus, was ist ist geplant, machen Microformats neben Microdata und RDFa überhaupt noch Sinn usw.

Also los… kaufen! Zack, zack!

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!

Auf schema.org findet man eine Übersicht alle Schemas die die Suchgiganten in Zukunft unterstützen werden:

This site provides a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google and Yahoo! rely on this markup to improve the display of search results, making it easier for people to find the right web pages.

Was mich besonders freut: Die Schemas basieren alle auf Microdata und wer meinen Blog regelmäßig verfolgt wird wissen, dass ich das Format sehr schätze! Hier ein Beispiel wie eine Person mit dem neuen Schema aussieht:

<div itemscope itemtype="http://schema.org/Person">
  <span itemprop="name">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="image" />
</div>

Soweit so gut, aber… es werden WIEDER einmal weder bestehende Microformats, noch RDFa Schemas auf Microdata portiert, was dazu führt dass mir spontan 5 unterschiedliche Formate einfallen um Personen zu beschreiben: hCard (Microformats), Data-Vocabulary (RDFa- und Microdata-Beschreibung genutzt von den rich-snippets), FoaF (RDFa), vCard (RDFa), schema.org (Microdata).

Die Microformats-Community hat von Anfang an eines richtig gemacht: Es gibt nur eine Stelle an der Microformats definiert werden und man muss einen relativ langwierigen Prozess befolgen um ein neues Format zu definieren. Das führt zwar dazu dass es bisher nur eine handvoll Schemas veröffentlicht wurden, diese aber wohl definiert sind und in der Regel auf bisherigen Formaten aufbauen. Die hCard ist beispielsweise ein 1:1 Abbild der vCard.

Schema.org ist zwar eine ganz nette Idee aber man hat leider versäumt sich mit der Microformats-, RDFa-, RDF- Community zusammenzusetzen und einen gemeinsamen Konsens zu finden!

Wäre folgendes Beispiel so viel komplizierter?

<div itemscope itemtype="http://microformats.org/profile/hcard">
  <span itemprop="fn">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="photo" />
</div>

…oder das?

<div itemscope itemtype="http://www.w3.org/2006/vcard/ns">
  <span itemprop="fn">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="photo" />
</div>

Das Format ist letztendlich Geschmackssache… der eine mag lieber die einfachen Microformats, der andere steht mehr auf RDFa und ich bevorzuge Microdata, man sollte sich aber endlich auf ein einheitliches Schema einigen!

Yahoo! zählt knapp zwei Milliarden hCards in ihrem Index und trotzdem diktiert man Webseitenbetreibern etwas komplett anderes auf…

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!