nicht angemeldet
Bilder in RSS-Feed verlinken
Hallo
Ich habe einen einfachen RSS-Feed für meinen Onlineshop erstellt.
Darin habe ich auch Bilder.
Nun würde ich diese Bilder auch gerne verlinken.
Dann gibts aber vom FeedValidator eine Warnung, dass in den <description> HTML-Code nix zu suchen hat.
Ich habe auch schon versucht, die Tag-Klammern zu maskieren.
Aber dann bemängelt er immer noch das a-Tag.
meine Frage ist nun, ob es überhaupt "erlaubt" ist, in einem RSS-Feed Bilder zu verlinken.
Und wenn ja, wie mache ich das am besten?
Hier mal ein Link zu meinem RSS-Feed:
SPACEart RSS-Feed
Über Eure Hilfe würde ich mich sehr freuen.
Gruß
Ingo
-
Hallo Ingo,
Dann gibts aber vom FeedValidator eine Warnung, dass in den <description> HTML-Code nix zu suchen hat.
Einfach so reingepasteter HTML-Code darf da nicht rein, ja.
Ich habe auch schon versucht, die Tag-Klammern zu maskieren.
Aber dann bemängelt er immer noch das a-Tag.Wenn ich jetzt Deinen Feed mit dem Feedvalidator des W3C validiere, kommt ein (relativ unbedeutender) Fehler und eine Warnung, aber kein Fehler in Bezug auf den Link – Du hast diesen offenbar rausgenommen?
meine Frage ist nun, ob es überhaupt "erlaubt" ist, in einem RSS-Feed Bilder zu verlinken. Und wenn ja, wie mache ich das am besten?
Früher war als Inhalt des description-Elementes nur reiner Text erlaubt. Irgendwann hat der Autor der RSS-„Spezifikation“ sich entschieden, dass HTML-Inhalt toll wäre, das Default-Inhalts-Modell wurde dann von „reiner Text“ auf „HTML“ geändert. Da er aber mit XML-Namensräumen auf Kriegsfuss stand, muss man das HTML maskieren, damit die HTML-Elemente nicht mit den XML-Elementen in Konflikt geraten. Dafür gibt „von offizieller Seite“ folgende Möglichkeiten:
a) Die XML-relevanten Zeichen mit Entities kodieren, bereits bestehende Entities doppelt maskieren:
~~~xml <description>
<p>In XML gibt es nur fünf definierte Entities:
<code>&lt;</code>, <code>&gt;</code>,
<code>&amp;</code>, <code>&apos;</code> und
<code>&quot;</code>.</p>
</description>b) Alles in einen CDATA-Block packen. Dieser sagt dem XML-Prozessor im wesentlichen „Lese diesen Inhalt nicht als XML sondern reiche es einfach so weiter“: `<description><![CDATA[Dies ist <abbr title="...">HTML</abbr>]]></description>`{:.language-xml} Etwas habe ich bisher verschwiegen: Das Inhaltsmodell des description-Elementes ist nicht „HTML“, wie gerade behauptet. Tatsächlich ist es „Text oder HTML und ich sage Dir nicht was“. D.h. es ist vollkommen erlaubt, auch nur Text in das description-Element zu packen. Manchmal soll es ja vorkommen, dass man auch Kleiner- und Größer-Zeichen in seinem Text verwenden will. Dafür schlägt die „offizielle Seite“ folgende Variantionen vor: c) Die XML-relevanten Zeichen zu maskieren, wie es in XML Brauch ist: `<description>Für alle a ∈ [1, 10], b ∈ [11, 20] gilt: a < b</description>`{:.language-xml} d) CDATA-Bereiche zu verwenden und darin die relevanten Zeichen zu maskieren, denn es handelt sich bei den Inhalt des CDATA-Elementes ja um „HTML“: `<description><![CDATA[Wer nutzt eigentlich das <bdo>-Element?]]></description>`{:.language-xml} Ein RSS-Reader hat nun nach dem Akt des XML-Parsens (und dem dadurch entstehenden Ersetzens von "<" und ">" durch "<" und ">") mehrere Möglichkeiten, wie er den Inhalt des description-Elementes verarbeiten soll: • Als reinen Text • Als reinen Text mit zufälligerweise darin enthaltenen Kleiner- bzw. Größerzeichen • Als HTML-Quellcode • Als HTML-Quellcode mit zufälligerweise darin enthaltenen maskierten Kleiner- bzw. Größerzeichen. (Letztere beiden Möglichkeiten sind eigentlich gleich, muss man gerechterweise sagen.) U.a. deswegen greifen moderne Feedreader oftmals gerne zum Feed im konkurrierenden Format [Atom](http://atomenabled.org/developers/syndication/), wenn sie denn die Auswahl zwischen RSS und Atom haben. Der IE 7 macht dieses meines Wissens bei dem Akt des Feed Autodiscovery. In Atom muss man HTML auch noch maskieren, aber man schreibt wenigstens dran, was im jeweiligen Element enthalten ist und wie es verarbeitet werden soll, so dass der Feedreader nicht raten muss. Das sieht dann so aus: a) Für reinen Text: `<title type="text">Die Geheimnisse des <description>-Elementes</summary>`{:.language-xml} b) Für HTML: `<summary type="html">Dies ist <abbr title="How To Make Love">HTML<abbr></summary>`{:.language-xml} c) Bei vorhandenem echten XHTML kann man richtige XML-Namensräume verwenden: ~~~xml <content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> <h1>Benannte Zeichenreferenzen</h1> <p>Die International Organization for Standardization (ISO) hat für folgende Zeichen aus dem Zeichensatz Latin 1 bereits Entities bereit gestellt:</p> <table> <tr><th>Unicode Nummer</th><th>Entity</th><th>Bedeutung</th></tr> <tr><td>A0</td><td>&nbsp;</td><td>Geschütztes Leerzeichen</td></tr> ... </table> </div> </content>Das div-Element wird vom Atom-Standard benötigt. Wenn man den Namensraum geschickt einbindet, wie ich das gerade hier getan habe, kann man sein (wohlgeformtes) XHTML einfach so reinkippen, ohne jedes Element mit einem Präfix auszustatten.
Dieser Ausflug in die atomare Welt hilft Dir ja nicht mit Deinem Problem, 'tschuldige. Was ich an Deiner Stelle machen würde? Den HTML-Quelltext in CDATA-Bereiche packen. Das erspart einem eventuelle Sorgen mit doppelter Entity-Maskierung und dem Problem des Erkennens des Feedreaders, ob der Inhalt nun „reiner Text“ oder „maskiertes HTML“ ist. CDATA ist im RSS-Kontext ein sehr wahrscheinlicher, wenn auch nicht eindeutiger Hinweis auf „HTML“, also sicherer.
Beachte übrigens auch, dass dieses maskierte HTML in RSS nur für das Element description gilt, alle anderen Elemente wie title dürfen nur reinen Text enthalten.
Tim
-
Hallo Gunnar,
zwei Anmerkungen, die Du vergessen hast:
Wenn ich jetzt Deinen Feed mit dem Feedvalidator des W3C validiere
... der Feedvalidator des W3C ist genau dieselbe Software, die auch bei feedvalidator.org eingesetzt wird, nur gibt es gerade bei letzterer Adresse Server-Problemchen. Nicht dass es deswegen zu Verwirrungen kommt, welche Adresse „offizieller“ wäre. Streng genommen gibt es keine offizielle Adresse, nur einen Haufen Erfahrung und geschickter Deutung der RSS-„Spezifikation“.
~~~xml
<description>
<p>In XML gibt es nur fünf definierte Entities:
<code>&lt;</code> ....Hier und im Rest dieses Beispiels steckt ein Fehler, die Entity-Auszeichnung müsste eigentlich so lauten:
[code lang=xml]... <code>&&lt;</code> ...
... denn schliesslich will man ja im dekodierten HTML den Quelltext des Entities lesen und nicht durch das Zeichen ersetzt bekommen. Tim
-
-
Hallo Tim
Puhhh, ganz schön harter Stoff für mich als Anfnger :)
Aber vielen lieben Dank für Deine ausfühlichen Erklärungen.Mir ist es besonders wichtig, dass mein RSS-Feed von möglichst vielen Usern genutzt werden kann.
Was auch immer diese für eine "alte" Software einsetzen.
Bzw. was sie auch immer für einfache Feed-Reader nutzen.Darum ist es doch vielleicht gescheiter, wenn ich auf die Verlinkung der Bilder verzichte.
Oder was meinst Du (Ihr)?
Gruß
Ingo-
Hallo Ingo,
Mir ist es besonders wichtig, dass mein RSS-Feed von möglichst vielen Usern genutzt werden kann. Was auch immer diese für eine "alte" Software einsetzen. Bzw. was sie auch immer für einfache Feed-Reader nutzen. Darum ist es doch vielleicht gescheiter, wenn ich auf die Verlinkung der Bilder verzichte.
Meiner Meinung nach sind nur noch Selbstbau-Feedreader nicht imstande, das HTML zu verarbeiten, insofern halte ich HTML schon für ein einsetzbares Feature. Was Du auch machen könntest wäre dieses hier:
~~~xml <item>
<title>Wichtige Nachrichten</title>
<description>Einmal in Textform</description>
content:encoded<![CDATA[Zum anderen in
<abbr title="HyperText Markup Language">HTML</abbr>]]></content:encoded>
</item>... vorrausgesetzt natürlich, das Präfix "content" sei vorher an den passenden XML Namensraum gebunden: ~~~xml <rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">Um das zu erklären: Früher, als RSS 2.0 nur Text im description-Element transportieren durfte, suchte man nach einer Möglichkeit, trotzdem HTML damit zu transportieren. Es hatte sich (neben anderen inzwischen nur noch unter „exotisch“ laufenden Möglichkeiten) eingebürgert, dazu extra XML-Vokabular aus dem RSS 1.0 Modul Content zu nehmen. RSS 1.0 ist zwar wegen eines anderen Datenmodells (dem von RDF) nicht zu RSS 2.0 kompatibel, allerdings hat es viele „Module“ (XML Namensräume), die gerne ungedachtet der RDF-Herkunft als fremdes XML in RSS 2.0 eingesetzt werden.
Das Element content:encoded ist zusammen mit dem Dublin Core Modul mit Abstand die beliebteste Erweiterung von RSS 2.0 – da darin maskiertes HTML erlaubt ist. Daraus hat sich in den meisten besseren Feedreadern die Praxis herausgebildet, den Inhalt von content:encoded gegenüber description zu bevorzugen, aus zwei unterschiedlichen Gründen:
• description wurde oft als Zusammenfassung/Excerpt eines Eintrages genommen, während content:encoded dann den kompletten Eintrag darstellt.
• description war früher nur reiner Text, während content:encoded den reicheren HTML-Inhalt bereit stellt.Da die besseren Feedparser content:encoded verwenden, würde ich Dir ans Herz legen, das HTML da hinein zu packen; so kann jeder billige, kaputte Feld-, Wald- und Wiesen-RSS-Parser, der keine Ahnung von der über XML hinausgehenden RSS-Welt hat, immer noch Textinhalt im description erwarten und das ihm unbekannte Element content:encoded ignorieren.
Tim
-
Lieber Tim
OK, ich verstehe.
Dann scheint mir Deine Idee ja wirklich die beste Lösung zu sein.Ich habe das auch gleich mal umgesetzt:
SPACEart RSS-Fed
Klappt alles wunderbar und ist auch 100% valide.Vielen Dank für Deine Mühe
Gruß
Ingo
-
-