<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:source="http://source.scripting.com/"
xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"

	>
<channel>
	<title>
	Kommentare zu: Microformats: The next generation	</title>
	<atom:link href="https://notiz.blog/2012/07/03/microformats-the-next-generation/feed/" rel="self" type="application/rss+xml" />
	<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/</link>
	<description>a weblog mainly about the open, portable, interoperable, small, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social web</description>
	<lastBuildDate>Tue, 30 Mar 2021 14:10:52 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
<atom:link rel="hub" href="https://pubsubhubbub.appspot.com"/>
<atom:link rel="hub" href="https://pubsubhubbub.superfeedr.com"/>
<atom:link rel="hub" href="https://switchboard.p3k.io/"/>
<atom:link rel="self" href="https://notiz.blog/2012/07/03/microformats-the-next-generation/feed/"/>
	<item>
		<title>
		Von: Siegfried		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185166</link>

		<dc:creator><![CDATA[Siegfried]]></dc:creator>
		<pubDate>Fri, 07 Sep 2012 06:10:03 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-185166</guid>

					<description><![CDATA[Als Antwort auf &lt;a href=&quot;https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185156&quot;&gt;Matthias Pfefferle&lt;/a&gt;.

Naja, Du weisst ja: Mit Computer geht Alles viel schneller, es dauert nur etwas länger :)]]></description>
			<content:encoded><![CDATA[<p>Als Antwort auf <a href="https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185156">Matthias Pfefferle</a>.</p>
<p>Naja, Du weisst ja: Mit Computer geht Alles viel schneller, es dauert nur etwas länger 🙂</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: Matthias Pfefferle		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185156</link>

		<dc:creator><![CDATA[Matthias Pfefferle]]></dc:creator>
		<pubDate>Thu, 06 Sep 2012 21:07:26 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-185156</guid>

					<description><![CDATA[Als Antwort auf &lt;a href=&quot;https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185102&quot;&gt;Siegfried&lt;/a&gt;.

Ich habe bei meinem &lt;a href=&quot;https://notiz.blog/2012/09/06/ive-made-a-wordpress-theme-kind-of/&quot;&gt;WordPress Theme&lt;/a&gt; mal versucht Microformats 2 umzusetzen... Das größte Probleme war für mich der Zusammenhang von Namespace und Datentyp... Ist der hAtom-Title jetzt &lt;code&gt;e-entry-title&lt;/code&gt; oder &lt;code&gt;p-entry-title&lt;/code&gt;...

Dass &lt;a href=&quot;https://notiz.blog/2008/11/12/microformats-in-zahlen/&quot;&gt;Microformats erfolgreich sind, war mir schon klar&lt;/a&gt;... ich bin nur der Meinung dass es langsam Zeit für eine Weiterentwicklung ist ;)]]></description>
			<content:encoded><![CDATA[<p>Als Antwort auf <a href="https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185102">Siegfried</a>.</p>
<p>Ich habe bei meinem <a href="https://notiz.blog/2012/09/06/ive-made-a-wordpress-theme-kind-of/">WordPress Theme</a> mal versucht Microformats 2 umzusetzen&#8230; Das größte Probleme war für mich der Zusammenhang von Namespace und Datentyp&#8230; Ist der hAtom-Title jetzt <code>e-entry-title</code> oder <code>p-entry-title</code>&#8230;</p>
<p>Dass <a href="https://notiz.blog/2008/11/12/microformats-in-zahlen/">Microformats erfolgreich sind, war mir schon klar</a>&#8230; ich bin nur der Meinung dass es langsam Zeit für eine Weiterentwicklung ist 😉</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: Matthias Pfefferle		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185155</link>

		<dc:creator><![CDATA[Matthias Pfefferle]]></dc:creator>
		<pubDate>Thu, 06 Sep 2012 20:59:33 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-185155</guid>

					<description><![CDATA[Als Antwort auf &lt;a href=&quot;https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-183987&quot;&gt;nik&lt;/a&gt;.

Ja, je mehr Namespaces es gibt desto fehleranfälliger wird es wieder. Außerdem ist der eine Buchstabe auch nicht wirklich deskriptiv und sorgt sicherlich wieder für eine Menge Namens-Kollisionen.]]></description>
			<content:encoded><![CDATA[<p>Als Antwort auf <a href="https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-183987">nik</a>.</p>
<p>Ja, je mehr Namespaces es gibt desto fehleranfälliger wird es wieder. Außerdem ist der eine Buchstabe auch nicht wirklich deskriptiv und sorgt sicherlich wieder für eine Menge Namens-Kollisionen.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: Siegfried		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-185102</link>

		<dc:creator><![CDATA[Siegfried]]></dc:creator>
		<pubDate>Wed, 05 Sep 2012 12:18:59 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-185102</guid>

					<description><![CDATA[Ich habe jetzt noch mal einige Zeit darüber nachgedacht und neige nun eher dazu, Dir zuzustimmen: Namespaces bei Microformats sind eher hinderlich. Die nötige Flexibilität erreicht man ggf. über RDFa und/oder Microdata.

Ich teste übrigens gerade viele verschiedene HTML Versionen von Blogs auf Microformats. Die sind gar nicht mal so selten. Und bislang ausschließlich ohne Prefix. Also &quot;plain old&quot;. Hat sich vielleicht doch mehr durchgesetzt, als Du derzeit vermutest.]]></description>
			<content:encoded><![CDATA[<p>Ich habe jetzt noch mal einige Zeit darüber nachgedacht und neige nun eher dazu, Dir zuzustimmen: Namespaces bei Microformats sind eher hinderlich. Die nötige Flexibilität erreicht man ggf. über RDFa und/oder Microdata.</p>
<p>Ich teste übrigens gerade viele verschiedene HTML Versionen von Blogs auf Microformats. Die sind gar nicht mal so selten. Und bislang ausschließlich ohne Prefix. Also &#8222;plain old&#8220;. Hat sich vielleicht doch mehr durchgesetzt, als Du derzeit vermutest.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: nik		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-183987</link>

		<dc:creator><![CDATA[nik]]></dc:creator>
		<pubDate>Fri, 10 Aug 2012 18:43:03 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-183987</guid>

					<description><![CDATA[„Die Prefixes ‘h-‘, ‘p-‘, ‘u-‘, ‘dt-‘ und ‘e-‘ sollen das Zukünftig verhindern und ein generisches parsen ermöglichen.“

Mit Verlaub - na ist ja jetzt richtiger Bullshit! Jetzt werden auf 5 Ebenen Namespaces in Anspruch genommen. Was das jetzt verbessert ist ja nun wirklich die Frage!]]></description>
			<content:encoded><![CDATA[<p>„Die Prefixes ‘h-‘, ‘p-‘, ‘u-‘, ‘dt-‘ und ‘e-‘ sollen das Zukünftig verhindern und ein generisches parsen ermöglichen.“</p>
<p>Mit Verlaub &#8211; na ist ja jetzt richtiger Bullshit! Jetzt werden auf 5 Ebenen Namespaces in Anspruch genommen. Was das jetzt verbessert ist ja nun wirklich die Frage!</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: Siegfried		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182626</link>

		<dc:creator><![CDATA[Siegfried]]></dc:creator>
		<pubDate>Wed, 04 Jul 2012 13:35:46 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-182626</guid>

					<description><![CDATA[Zu 1.: Naja, wer sich erst mal durchgerungen hat, semantisches statt präsentationsorientiertes Markup zu schreiben, wer also z.B. dafür zu Microformats greift, der wird vermutlich auch eher bereit sein, die Klassennamen weiterhin auch bei einem Redesign ordentlich zu wählen. Aber das ist natürlich nur eine Vermutung von mir :)

Zu 2.: Ich verstehe Deine Argumentation. Da ist auch was dran. Der Mehraufwand wirkt zunächst tatsächlich abschreckend. Wobei hier m.M.n. vor Allem die Vielzahl der Präfixe abschreckend ist. Weniger wäre hier deutlich mehr. Aber ich denke immer noch, dass die Vorteile die durchaus vorhandenen Nachteile aufwiegen könnten. Aber natürlich ist auch dies eine persönliche Vermutung.

Zu den Alternativen: RDFa finde ich recht ordentlich. Bei Microdata sehe ich noch nicht so recht klar. Was soll z.B. dieses &quot;itemscope&quot;? Ist das ein Attribut? Dann fehlt hier der Wert. Ohne Wert ist es wertlos (im Sinne des Wortes, und im anderen Sinn auch). Auch, für die entsprechende Meta-Information ein neues Attribut (itemprop) zu erfinden finde ich nicht so das Gelbe vom Ei. Der Inhalt des class Attributs soll den Inhalt des html-Containers (näher) klassifizieren. Daher heisst es ja auch &quot;class&quot;. Es ist nur konsequent, dafür auch genau dieses Attribut zu verwenden.

Und nur als Ergänzung: Natürlich sollte die erste Wahl zur Klassifizierung eines Inhalts immer das passende html-Element sein. Daher bringt hier html5 wirklich Nützliches. Auch, dass man jetzt endlich meta-Informationen nicht nur im Header, also gültig für die gesamte Seite, sondern auch für einen Teilbereich der Seite einfügen kann, ist sehr sehr nützlich. Das war überfällig. Und Vieles von dem, was jetzt endlich realisiert wurde, macht Einiges von dem, was bisher Microformats und Ähnliche leisteten, obsolet. Kann man getrost begraben. Deswegen werden Microformats, RDFa und Dergleichen nicht gleich überflüssig. Aber ich denke, das hast Du ja so oder so ähnlich hier auch schon geschrieben. 

Und was den Blick in die Glaskugel (Zukunft) angeht: Das kann man getrost unterschiedlich interpretieren. Wir werden sehen.]]></description>
			<content:encoded><![CDATA[<p>Zu 1.: Naja, wer sich erst mal durchgerungen hat, semantisches statt präsentationsorientiertes Markup zu schreiben, wer also z.B. dafür zu Microformats greift, der wird vermutlich auch eher bereit sein, die Klassennamen weiterhin auch bei einem Redesign ordentlich zu wählen. Aber das ist natürlich nur eine Vermutung von mir 🙂</p>
<p>Zu 2.: Ich verstehe Deine Argumentation. Da ist auch was dran. Der Mehraufwand wirkt zunächst tatsächlich abschreckend. Wobei hier m.M.n. vor Allem die Vielzahl der Präfixe abschreckend ist. Weniger wäre hier deutlich mehr. Aber ich denke immer noch, dass die Vorteile die durchaus vorhandenen Nachteile aufwiegen könnten. Aber natürlich ist auch dies eine persönliche Vermutung.</p>
<p>Zu den Alternativen: RDFa finde ich recht ordentlich. Bei Microdata sehe ich noch nicht so recht klar. Was soll z.B. dieses &#8222;itemscope&#8220;? Ist das ein Attribut? Dann fehlt hier der Wert. Ohne Wert ist es wertlos (im Sinne des Wortes, und im anderen Sinn auch). Auch, für die entsprechende Meta-Information ein neues Attribut (itemprop) zu erfinden finde ich nicht so das Gelbe vom Ei. Der Inhalt des class Attributs soll den Inhalt des html-Containers (näher) klassifizieren. Daher heisst es ja auch &#8222;class&#8220;. Es ist nur konsequent, dafür auch genau dieses Attribut zu verwenden.</p>
<p>Und nur als Ergänzung: Natürlich sollte die erste Wahl zur Klassifizierung eines Inhalts immer das passende html-Element sein. Daher bringt hier html5 wirklich Nützliches. Auch, dass man jetzt endlich meta-Informationen nicht nur im Header, also gültig für die gesamte Seite, sondern auch für einen Teilbereich der Seite einfügen kann, ist sehr sehr nützlich. Das war überfällig. Und Vieles von dem, was jetzt endlich realisiert wurde, macht Einiges von dem, was bisher Microformats und Ähnliche leisteten, obsolet. Kann man getrost begraben. Deswegen werden Microformats, RDFa und Dergleichen nicht gleich überflüssig. Aber ich denke, das hast Du ja so oder so ähnlich hier auch schon geschrieben. </p>
<p>Und was den Blick in die Glaskugel (Zukunft) angeht: Das kann man getrost unterschiedlich interpretieren. Wir werden sehen.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: Matthias Pfefferle		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182625</link>

		<dc:creator><![CDATA[Matthias Pfefferle]]></dc:creator>
		<pubDate>Wed, 04 Jul 2012 10:38:52 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-182625</guid>

					<description><![CDATA[Als Antwort auf &lt;a href=&quot;https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182620&quot;&gt;Siegfried&lt;/a&gt;.

Im Punkt &quot;1.&quot; sind wir einer Meinung! Ich schätze Microformats sehr, da sie für schönes und beschreibendes HTML sorgen. Worauf ich hinaus wollte ist, dass Microformats immer noch ein Nischenprodukt sind und eine relativ kleine Entwicklergemeinde von deren Existenz weiß, was dazu führt dass Microformats immer wieder durch Re-Designs zerstört werden, weil &lt;code&gt;classes&lt;/code&gt; im Zuge von CSS Änderungen umbenannt werden oder neu JS-Funktionalität hinzu kommt. Es ist meiner Meinung nach einfacher jemandem zu erklären die &lt;code&gt;itemprop&lt;/code&gt; oder &lt;code&gt;property&lt;/code&gt; Attribute stehen zu lassen, als ihm zu erklären dass die Klassen die er für sein CSS nutzt auch für Google interessant sind.

Bei Punkt &quot;2.&quot; muss ich dir widersprechen, weil die Namespaces genau das kaputt machen was Microformats gerade ausmachen. Bisher kann jeder mit Begriffen wie &lt;code&gt;description&lt;/code&gt;, &lt;code&gt;note&lt;/code&gt;, &lt;code&gt;entry-title&lt;/code&gt; oder &lt;code&gt;name&lt;/code&gt; etwas Anfangen, ob er Micorformats kennt oder nicht. Mit der Einführung der Namespaces sieht das anders aus, vor allem weil der Prfix für den Daten-Typ steht.

Ich bin der Meinung, dass man Microformats mit den Prefixes krampfhaft zu etwas machen will, was Microdata und RDFa viel besser leisten können und damit das kaputt macht was Microformas sind... schönes &lt;em&gt;Plain Old Semantic HTML&lt;/em&gt;.]]></description>
			<content:encoded><![CDATA[<p>Als Antwort auf <a href="https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182620">Siegfried</a>.</p>
<p>Im Punkt &#8222;1.&#8220; sind wir einer Meinung! Ich schätze Microformats sehr, da sie für schönes und beschreibendes HTML sorgen. Worauf ich hinaus wollte ist, dass Microformats immer noch ein Nischenprodukt sind und eine relativ kleine Entwicklergemeinde von deren Existenz weiß, was dazu führt dass Microformats immer wieder durch Re-Designs zerstört werden, weil <code>classes</code> im Zuge von CSS Änderungen umbenannt werden oder neu JS-Funktionalität hinzu kommt. Es ist meiner Meinung nach einfacher jemandem zu erklären die <code>itemprop</code> oder <code>property</code> Attribute stehen zu lassen, als ihm zu erklären dass die Klassen die er für sein CSS nutzt auch für Google interessant sind.</p>
<p>Bei Punkt &#8222;2.&#8220; muss ich dir widersprechen, weil die Namespaces genau das kaputt machen was Microformats gerade ausmachen. Bisher kann jeder mit Begriffen wie <code>description</code>, <code>note</code>, <code>entry-title</code> oder <code>name</code> etwas Anfangen, ob er Micorformats kennt oder nicht. Mit der Einführung der Namespaces sieht das anders aus, vor allem weil der Prfix für den Daten-Typ steht.</p>
<p>Ich bin der Meinung, dass man Microformats mit den Prefixes krampfhaft zu etwas machen will, was Microdata und RDFa viel besser leisten können und damit das kaputt macht was Microformas sind&#8230; schönes <em>Plain Old Semantic HTML</em>.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: Siegfried		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182620</link>

		<dc:creator><![CDATA[Siegfried]]></dc:creator>
		<pubDate>Wed, 04 Jul 2012 07:53:01 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-182620</guid>

					<description><![CDATA[Zweierlei:

1. html und css teilen sich die class Namen? Na und? Wenn man konsequent vorgeht und im html nur semantische Bezeichner verwendet (keinerlei Präsentations-Auszeichnungen im html, also auch keine Präsentations-orientierten class Namen), dann bedeutet das weder für die Semantik noch für die Klassen einen Verlust oder eine Einschränkung. Und verwenden kann man diese Klassen im css immer noch, ebenfalls ohne Einschränkung. Es ist einfach eine Frage der Konsequenz.

2. Das mit den Namespaces ist interessant. Aber dafür *- zu verwenden finde ich nicht gut. Wie Namespace Prefixes auszusehen haben, dafür gibt es Spezifikationen beim w3c. Ansonsten fügen Namespaces zwar Aufwand hinzu, aber es lohnt sich. Der Gewinn an Flexibilität und Eindeutigkeit gleicht den Mehraufwand mehr als aus.]]></description>
			<content:encoded><![CDATA[<p>Zweierlei:</p>
<p>1. html und css teilen sich die class Namen? Na und? Wenn man konsequent vorgeht und im html nur semantische Bezeichner verwendet (keinerlei Präsentations-Auszeichnungen im html, also auch keine Präsentations-orientierten class Namen), dann bedeutet das weder für die Semantik noch für die Klassen einen Verlust oder eine Einschränkung. Und verwenden kann man diese Klassen im css immer noch, ebenfalls ohne Einschränkung. Es ist einfach eine Frage der Konsequenz.</p>
<p>2. Das mit den Namespaces ist interessant. Aber dafür *- zu verwenden finde ich nicht gut. Wie Namespace Prefixes auszusehen haben, dafür gibt es Spezifikationen beim w3c. Ansonsten fügen Namespaces zwar Aufwand hinzu, aber es lohnt sich. Der Gewinn an Flexibilität und Eindeutigkeit gleicht den Mehraufwand mehr als aus.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: Matthias Pfefferle		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182596</link>

		<dc:creator><![CDATA[Matthias Pfefferle]]></dc:creator>
		<pubDate>Tue, 03 Jul 2012 11:20:29 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-182596</guid>

					<description><![CDATA[Als Antwort auf &lt;a href=&quot;https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182592&quot;&gt;eric.eggert&lt;/a&gt;.

&lt;blockquote&gt;Wie aus „Ben Ward“ im HTML „Frances Berriman“ im JSON wird kann ich zwar nicht nachvollziehen ;-)&lt;/blockquote&gt;

Das ist die Magie der Microformats :)

Zu den Prefixes: Für Parser sind die Prefixes sicher ein Segen (interpretier alles was mit &#039;&lt;code&gt;*-&lt;/code&gt;&#039; beginnt) aber wie du schon sagst sollten sie wirklich nicht vom Typ abhängig sein. Manche Prefixes wie &#039;&lt;code&gt;dt-&lt;/code&gt;&#039; oder &#039;&lt;code&gt;u-&lt;/code&gt;&#039; sind überflüssig, da sie schon über die HTML-Tags (&#039;&lt;code&gt;&#060;time /&#062;&lt;/code&gt;&#039; oder &#039;&lt;code&gt;&#060;a /&#062;&lt;/code&gt;&#039;) definiert sind und bei &#039;&lt;code&gt;p-&lt;/code&gt;&#039; oder &#039;&lt;code&gt;e-&lt;/code&gt;&#039; ist es schwer einen Unterschied zu definieren.

Eigentlich hätten zwei Prefixes ausgereicht: &#039;&lt;code&gt;h-&lt;/code&gt;&#039; für den Container und &#039;&lt;code&gt;p-&lt;/code&gt;&#039; für die Properties (bei Microdata &lt;code&gt;itemscope&lt;/code&gt; und &lt;code&gt;itemprop&lt;/code&gt;).

Aber auch mit der Variante gibt man, meiner Meinung nach, den semantischen Code zu Gunsten einer besseren Maschinenlesbarkeit auf, die immer noch höchst fehleranfällig ist.]]></description>
			<content:encoded><![CDATA[<p>Als Antwort auf <a href="https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182592">eric.eggert</a>.</p>
<blockquote><p>Wie aus „Ben Ward“ im HTML „Frances Berriman“ im JSON wird kann ich zwar nicht nachvollziehen 😉</p></blockquote>
<p>Das ist die Magie der Microformats 🙂</p>
<p>Zu den Prefixes: Für Parser sind die Prefixes sicher ein Segen (interpretier alles was mit &#8218;<code>*-</code>&#8218; beginnt) aber wie du schon sagst sollten sie wirklich nicht vom Typ abhängig sein. Manche Prefixes wie &#8218;<code>dt-</code>&#8218; oder &#8218;<code>u-</code>&#8218; sind überflüssig, da sie schon über die HTML-Tags (&#8218;<code>&lt;time /&gt;</code>&#8218; oder &#8218;<code>&lt;a /&gt;</code>&#8218;) definiert sind und bei &#8218;<code>p-</code>&#8218; oder &#8218;<code>e-</code>&#8218; ist es schwer einen Unterschied zu definieren.</p>
<p>Eigentlich hätten zwei Prefixes ausgereicht: &#8218;<code>h-</code>&#8218; für den Container und &#8218;<code>p-</code>&#8218; für die Properties (bei Microdata <code>itemscope</code> und <code>itemprop</code>).</p>
<p>Aber auch mit der Variante gibt man, meiner Meinung nach, den semantischen Code zu Gunsten einer besseren Maschinenlesbarkeit auf, die immer noch höchst fehleranfällig ist.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: eric.eggert		</title>
		<link>https://notiz.blog/2012/07/03/microformats-the-next-generation/#comment-182592</link>

		<dc:creator><![CDATA[eric.eggert]]></dc:creator>
		<pubDate>Tue, 03 Jul 2012 10:38:24 +0000</pubDate>
		<guid isPermaLink="false">http://notizblog.org/?p=4343#comment-182592</guid>

					<description><![CDATA[Wie aus „Ben Ward“ im HTML „Frances Berriman“ im JSON wird kann ich zwar nicht nachvollziehen ;-) aber ansonsten finde ich die Neuerungen ganz praktisch. Die Namespaces finde ich zwar auch unschön aber wichtig um interoperablen Code zu haben. Problematisch ist, dass der Prefix den Inhaltstyp beschreibt, ich hätte mir da etwas nachvollziehbareres gewünscht, da das nicht immer aus dem Inhalt zu erschließen ist. (Wo darf man nur plain text, wo rich text, benutzen?)]]></description>
			<content:encoded><![CDATA[<p>Wie aus „Ben Ward“ im HTML „Frances Berriman“ im JSON wird kann ich zwar nicht nachvollziehen 😉 aber ansonsten finde ich die Neuerungen ganz praktisch. Die Namespaces finde ich zwar auch unschön aber wichtig um interoperablen Code zu haben. Problematisch ist, dass der Prefix den Inhaltstyp beschreibt, ich hätte mir da etwas nachvollziehbareres gewünscht, da das nicht immer aus dem Inhalt zu erschließen ist. (Wo darf man nur plain text, wo rich text, benutzen?)</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
