HTML5 Semantics Badge

Beim „basteln“ an SemPress, meinem ersten WordPress Theme, habe ich das erste Mal praktische Erfahrungen mit Schema.org gesammelt und mir sind vor allem zwei Dinge klar geworden: 1. Warum Schema.org nach einer Art „Vererbungs“-Prinzip aufgebaut ist und 2. Wie Google mit Schema.org umgeht.

The http://schema.org/Thing

Das „einfachste“ Schema ist ein „Thing“ und hat folgende Attribute:

descriptionTEXTA short description of the item.
imageURLURL of an image of the item.
nameTEXTThe name of the item.
urlURLURL of the item.

Da alle anderen Objekte auf dem „Thing“ aufbauen, kann man davon ausgehen dass man mind. auf diese vier Eigenschaften zugreifen kann und genau das ist der ganze Sinn hinter dieser Struktur.

Vor allem Google setzt massiv auf Schema.org, sei es beim Einsatz in der Suche (über die sogenannten Rich-Snippets)…

rich snippets example

…oder beim Anreichern der, über Google+ oder den +1 Button geteilten Links.

Google+ Example

Um das Parsen der Webseiten (zumindest für diese eher einfachen Ausgaben) auf ein Minimum zu reduzieren, ist die Grundstruktur immer gleich und alles darüber hinaus ist reine Kür. Wahrscheinlich werden aber 90% aller Anwendungen mit Titel (name), Beschreibung, Bild und URL auskommen.

Googles Umgang mit Schema.org

Wer seine Seite mit Schema.org auszeichnen möchte, sollte vor allem eines Beachten: Google+ (wahrscheinlich aber auch alle anderen Google Produkte) interpretiert immer das erste im Quellcode verwendete Schema!

Bei meiner ersten Implementierung von Schema.org habe ich mich etwas zu sehr an RSS bzw. Atom orientiert und folgenden Aufbau gewählt: Ein umschließendes Objekt um den Blog zu beschreiben und ein oder mehrere referenzierte Artikel.

<body itemscope itemtype="http://schema.org/Blog"> ... <header id="branding" role="banner"> <hgroup> <h1 id="site-title" itemprop="name"><?php bloginfo( 'name' ); ?></h1> <h2 id="site-description" itemprop="description"><?php bloginfo( 'description' ); ?></h2> </hgroup> </header> ... <article itemprop="blogPost" itemscope itemtype="http://schema.org/BlogPosting"> ... </article> <article itemprop="blogPost" itemscope itemtype="http://schema.org/BlogPosting"> ... </article> ... </body>
Code-Sprache: HTML, XML (xml)

Egal ob es jetzt um mehrere Artikel (Startseite) oder nur einen Artikel (Post oder Page) gehandelt hat.

Das hat bei Google+ dazu geführt, dass die notizBlog-Links immer mit dem Titel, der Beschreibung und dem Bild des Blogs und nicht mit denen des Artikels verknüpft wurden. Es ist also gerade für Blogs wichtig, dass das Blog-Schema nur auf den Übersichtsseiten benutzt wird und die Einzelansichten lediglich mit „http://schema.org/BlogPosting“ bzw. „http://schema.org/WebPage“ ausgezeichnet werden.

W3C Community Logo

(Kleiner Nachtrag zu der „OAuth ist tot“ Kolumne in der SCREENGUIDE Ausgabe 15 um zu zeigen, warum gerade das W3C auch für Community Formate durchaus nützlich sein kann)

Vor ein paar Wochen kam eine E-Mail mit der Bitte, an einer Umfrage zu den W3C Community and Business Groups teilzunehmen und das hat mich daran erinnert, dass ich mich bisher noch gar nicht zu dem Thema geäußert habe… das hole ich hiermit kurz nach!

Ich beschäftige mich ja jetzt schon eine ganze Weile mit dem Web und seinen diversen Formaten, Standards, Techniken, Spezifikationen usw. usf. Leider ist das Web aber ziemlich vergänglich und eine Menge guter Ideen und Formate sind, aus Mangel an Interesse, mangelndem Durchhaltevermögen, nicht genug Ruhm oder einfach nur aus kurzfristigen „Publicity“ Interessen wieder spurlos verschwunden.

Hier ein paar Beispiele:

  • MicroID – Ein simples Format um das leidige Thema „Webseite verifizieren“ zu vereinheitlichen. Domain nicht mehr erreichbar!
  • POSHFormats – POSHFormats wollte alle Websemantiken sammeln die es leider nicht zu einem Microformat geschafft haben. Domain nicht mehr erreichbar!
  • MicroJSON – Ein Projekt welches sich mit der JSON-Serialisierung von Microformats beschäftigt hat. Zum Glück hat die Diskussion einen Weg ins Microformats-Wiki gefunden. Domain nicht mehr erreichbar!
  • Portability Policy – Das DataPortability Vorzeige-Projekt wollte eine vereinheitlichte Policy für die Portability von Daten schaffen. Domain nicht mehr erreichbar!
  • Microsyntax – Eine Sammlung von Microblogging Syntaxen wie z.B. das „@username“ oder „RT“. Domain nicht mehr erreichbar!
  • AXSchema.org – Die Seite wollte die Attribute für OpenIDs Attribute Exchange sammeln. Domain nicht mehr erreichbar!
  • Monkeyformats.org – Eine etwas schräge Idee, Webseiten per Greasemonkey-Scripts mit Microformats zu versehen um sie dann mit Microformats-Plugins interpretieren zu können. Alleine wegen dem Namen aber schon großartig :(|)! Domain nicht mehr erreichbar!
  • Bioformats – Mikroformate um biologische Daten abzubilden. Domain wurde verkauft!

…um nur einige zu nennen. Ob jetzt alle Projekte gut waren, darüber lässt sich streiten, aber es ist auf alle Fälle schade dass sie mittlerweile gar nicht mehr erreichbar sind. Viele Ideen waren vielleicht zu früh gedacht oder das Problem, das sie versuchten zu beheben, war einfach noch nicht groß genug. Oftmals braucht es vielleicht einfach nur ein wenig mehr Zeit! Lange Rede, kurzer Sinn: Die W3C Communities bieten genau für diese Community Formate die ideale Plattform:

A W3C Community Group is an open forum, without fees, where Web developers and other stakeholders develop specifications, hold discussions, develop test suites, and connect with W3C’s international community of Web experts. Community Groups may produce Specifications; these are not standards-track documents but may become input to the standards process. For instance, a Community Group might gather to work on a new technical specification, or convene to have discussions about a tutorial for an existing specification.
W3C FAQ

Auch wenn aus den Formaten kein „Standard“ werden sollte, so sind sie beim W3C doch besser aufgehoben und HOFFENTLICH auch für längere Zeit erreichbar! Gerade Junge Projekte wie „Unhosted Web“ oder „Federated Social Web“ scheinen die W3C Communities gut anzunehmen und auch Facebook forciert eine „Mobile Web“ Gruppe (die jetzt vielleicht nicht mehr so aktiv betrieben wird ;)).

Vielleicht macht sich jemand ja mal die Mühe und zieht zumindest die MicroID und die Portability Policy um!

oauthdead


(das Bild hab ich mir von hueniverse.com ausgeliehen)

Am Freitag (also morgen) gibt’s mal wieder ’ne neue SCREENGUIDE mit dem Fokus auf „Social Commerce“… In meiner Kolumne geht es diesmal um OAuth und das Dilemma dass offene Standards, wenn sie einmal vom W3C oder der IETF betreut werden, zu wahren Monstern mutieren.

Open Web Technologien können sich bald nur noch die Googles, Microsofts, Yahoos und Facebooks des Internets leisten! OpenID Connect mutiert von einem simplen Konzept zu einer 8 Dokumente schweren Spezifikation, RDFa ist so kompliziert, dass es einer “light” Version bedarf und Eran Hammer legt sein Amt als Editor von OAuth 2.0 nieder, da ihm der Standard zu „Enterprise“-lastig wird.

KAUFEN! LESEN! FEEDBACK GEBEN!

Eigentlich wollte ich ja nur einen Toolbox Fork erstellen und das Theme um Microdata/Schema.org erweitern und dann hat es doch so viel Spaß gemacht, dass ein eigenes Theme daraus wurde… Ich präsentiere euch SemPress, das hoch semantische HTML5 Theme mit ner Prise Responsiveness und SEO 🙂

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

POSH – Plain Old Semantic HTML5

HTML5 Logo

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!

OAuth 2 Logo

So, jetzt muss ich mich auch mal zu der OAuth Geschichte äußern! Wer nicht weiß warauf ich anspiele, der sollte sich zuerst mal Eran Hammers Blogpost durchlesen: OAuth 2.0 and the Road to Hell.

Auf alle Kritikpunkte von Eran Hammer möchte ich gar nicht eingehen… Ich kann seine Kritik durchaus verstehen und teile sie auch weitestgehend. Auch ich bin generell der Freund von schlanken Spezifikationen und hasse Standards die versuchen alles abzudecken und jedes Format zu unterstützen.

Abgesehen von den ganzen Sicherheitsaspekten und dem Fokus auf „Enterprise“-Anwendungen welche Eran Hammer in seinem Artikel erwähnt, hat mich die Fehlende Interoperability von OAuth 2 zuerst am Meisten genervt:

OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.

Mein erster Gedanke: Na toll! Man macht sich hier Gedanken über dezentrale Netzwerke, für die man einfache und simple Spezifikationen braucht und Familie OAuth released ein „Framework“…

Aber eigentlich ist ja gerade das auch eine riesen Chance für das Web! Während OpenID Connect bestimmt, dass jeder Provider die komplette Spezifikation implementieren muss:

The OpenID Connect Basic Client profile only documents Clients using the Code Flow. OpenID Providers MUST support both flows. OpenID Providers should consult the OpenID Connect Standard 1.0 Specification.

bleibt es jedem frei gestellt welchen Teil von OAuth 2 er umsetzt… Also warten wir doch einfach ab, bis das „Framework“ fertig ist, suchen uns die für das Web eleganteste Variante raus, dokumentieren sie schön und fertig ist „OAuth 2 – The Web Edition„.

…nicht perfekt, aber es könnte auch schlimmer sein!

mf-white

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!

Anfang der Woche hat Martin Weigert schon über Twitters Pläne, die eigenen Tweets mit noch mehr Medieninhalten zu erweitern, geschrieben:

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="...">
Code-Sprache: HTML, XML (xml)

…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.

Example Twitter Card

…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:

Twitter CardsOpen Graph Protocol
twitter:cardog:type
twitter:siteog:site_name
twitter:urlog:url
twitter:descriptionog:description
twitter:titleog:title
twitter:imageog:image
twitter:image:widthog:image:width
twitter:image:heightog:image:height
twitter:player oder twitter:player:streamog:video oder og:audio
twitter:player:widthog:video:width
twitter:player:heightog:video:height

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>
Code-Sprache: HTML, XML (xml)

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> 🙂

Pfefferles OpenWeb: Web Intents

Seit Freitag ist die zweite Ausgabe des SCREENGUI-Magazins (mit dem Fokus auf E-Payment, CSS4 und Boilerplates) in allen Bahnhofs- oder Flughafen-Buchhandlungen erhältlich.

In „Pfefferles OpenWeb“ geht es diesmal um Web Intents:

Seit Webseitenbetreiber das Potenzial von sozialen Netzwerken erkannt haben, nimmt die Anzahl der share, like, bookmark und +1 Buttons stetig zu und entwickelt sich zu einer regelrechten Plage. Jeder Besucher soll die Möglichkeit bekommen, seine Entdeckung schnellstmöglich mit seinen Freunden zu teilen – egal auf welcher Plattform. Um diesem Problem Herr zu werden, arbeitet Google seit ein paar Wochen an einem Framework namens Web Intents.

Viel Spaß beim lesen!

Wie kommt jemand mit relativ beschränktem Talent in gestalterischen Dingen dazu, einen Font zu basteln? Naja… "Font" wäre etwas übertrieben… Eigentlich hat mich ja nur genervt, dass Font Awesome kein RSS-Icon hat… und nach einer kleinen Internet Recherche hat sich herausgestellt, dass das Icon-Font erstellen gar nicht so schwer ist:

Also hab ich noch weitere Icons gesammelt (nur das RSS-Icon wäre etwas langweilig gewesen ;)), sie mit Inkscape entsprechend bearbeitet und irgendwie ist daraus überaschenderweise wirklich so ne Art Font entstanden 🙂

Ich präsentiere die OpenWeb Icons:

OpenWeb Icons (a font)

(weil ich nur OpenWeb kann ;))

Eine Liste mit allen Icons, wie man sie benutzt und was sie bedeuten, findet man bei Github: http://pfefferle.github.com/openwebicons/

Falls ihr Kritik oder Anregungen habt, dann immer raus damit! …vielleicht fällt dem Ein oder Anderen ja auch noch ein Icon ein, welches ich bisher vergessen habe.