IMG Tag wird nicht geschlossen

[xoxyss]

Hi zusammen,
kann es sein das der Editor bei neuen Artikeln wenn man den Button "img" benutzt den <img> Tag nicht schließt? Hat das einen Grund? Zwar ist <img src="" alt=""> HTML valide aber verursacht bei mir zumindest Probleme beim Atom-Feed. Ich muss jetzt also für jedes Bild den Tag um einen Backslash ergänzen:

Code: Select all

<img src="" alt="" />

Kann man da irgend etwas machen

Danke für die Hilfe
Robert

[yellowled]

kann es sein das der Editor bei neuen Artikeln wenn man den Button "img" benutzt den <img> Tag nicht schließt?

<img> ist ein sogenanntes self-closing tag, es muss also nicht geschlossen werden. <img> ist im Unterschied zu <img … /> auch nicht valide oder nicht, es ist schlicht HTML-Syntax im Unterschied zu XHTML-Syntax.

verursacht bei mir zumindest Probleme beim Atom-Feed.

Ich sehe auf Anhieb kein Problem mit Deinem Atom-Feed (er validiert sogar), was meinst Du genau?

YL

[xoxyss]

Hi,

<img> ist ein sogenanntes self-closing tag, es muss also nicht geschlossen werden. <img> ist im Unterschied zu <img … /> auch nicht valide oder nicht, es ist schlicht HTML-Syntax im Unterschied zu XHTML-Syntax.

Ah okay danke für die Aufklärung. Also aktuell funktioniert es weil ich diese Variante benutze:

Code: Select all

<img src="" alt="" />

Wenn ich die Standardvariante beibehalte, also:

Code: Select all

<img src="" alt="">

bekomme ich beim Aufruf des Atom Feeds folgende Fehlermeldung und die Seite wird nicht geladen:

Code: Select all

Das Endtag 'div' stimmt nicht mit dem Starttag 'img' überein.
 Zeile: 52 Zeichen: 15

            </div>

Die Fehlermeldung kommt aber nur im Firefox mobile und im IE 11. Der Firefox für Windows scheint da etwas "kulanter" zu sein.

Grüße
Robert

[yellowled]

Wenn ich die Standardvariante beibehalte, also: […] bekomme ich beim Aufruf des Atom Feeds folgende Fehlermeldung und die Seite wird nicht geladen: […] Die Fehlermeldung kommt aber nur im Firefox mobile und im IE 11. Der Firefox für Windows scheint da etwas "kulanter" zu sein.

Zunächst mal ist es in einem HTML5-Doctype schnurzegal, ob Du <img> oder <img/> verwendest. Beides ist völlig okay, Du kannst auch mischen, also z.B. <br>, aber <img/>.

Zudem sind Feeds ja nur bedingt dazu gedacht, in einem Browsertab geöffnet zu werden. So lange der Feed von einem Feed-Validator durchgewunken wird und keine Klagen von Abonnenten kommen, solltest Du auf der sicheren Seite sein.

YL

[xoxyss]

Also ich habe jetzt meinfach mal ein Bild mit <img> verwendet und den von dir verlinkten Feed Validator angeschmissen. Ergebnis:

Code: Select all

Sorry

This feed does not validate.
    line 96, column 325: XML parsing error: <unknown>:96:325: mismatched tag [help]
        ... 3-Piwik__Administration.png"  alt="" ></a> 
                                                     ^
In addition, interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
    line 12, column 113: Self reference doesn't match document location [help]
        ... eeklabor" type="application/atom+xml" />
                                                     ^
    line 16, column 26: subtitle should not be blank [help]
            <subtitle type="html"></subtitle>
                                  ^

    line 91, column 112: style attribute contains potentially dangerous content: font: normal normal 1em/1.2em monospace; margin:0; padding:0; background:none; vertical-align:top; (15 occurrences) [help]
        ... nt-weight: normal; vertical-align:top;"><div style="font: normal normal  ...

Also der Feed ist mit <img> definitiv nicht valide. Verwende ich <img /> ist er valide. So jetzt nochmal zurück zur eigentlichen Frage Kann man den Editro im Background so modifizieren dass er über den Button eingefügte Bilder automatisch mit <img /> einfügt? Oder wäre es nicht sinnvoll das generell im Editor anzupassen wenn es für den HTML Syntax sowieso egal ist?

Viele Grüße
Robert

[Timbalu]

Oder wäre es nicht sinnvoll das generell im Editor anzupassen wenn es für den HTML Syntax sowieso egal ist?

Ich würde sagen ja, in den Templates! Denn valide bedeutet hier ja nicht valide in HTML5, sondern eben nicht valide in XML, was bekanntlich eher ein XHTML ist.
Ansonsten müsste man so ein altes Plugin wie das XHTML event Plugin aus Urzeittagen dafür anschmeißem, bzw sogar noch tweaken.

[yellowled]

Ich würde sagen ja, in den Templates!

Wenn das so wäre, sollte es aber systemseitig erfolgen. Sprich: beim Erzeugen der Feeds. Es sollte nicht nötig sein, dass Autoren ihre img-Elemente anpassen müssen, zumal denjenigen, die mit einem WYSIWYG-Editor bloggen, das Problem gar nicht bewusst sein dürfte.

Denn valide bedeutet hier ja nicht valide in HTML5, sondern eben nicht valide in XML, was bekanntlich eher ein XHTML ist.

Valide ist halt auch immer so eine Sache – jage ich z.B. meinen Atom-Feed durch den Feed-Validator, bekomme ich eine Warnung “Non-html tag: figcaption”. Möchte jemand ernsthaft diskutieren, ob figcaption valides HTML ist? (Validiert dann allerdings dennoch.)

Nebenbei ist mir beim Testen auch aufgefallen, dass Atom-Feeds (aber scheinbar nur Atom-Feeds) sich irgendwie™ verschlucken, wenn man Artikel aktualisiert:

Code: Select all

<updated>1970-01-01T00:00:00Z</updated>

(“Implausible date” sagt der Validator dazu.)

YL

[Timbalu]

Wenn das so wäre, sollte es aber systemseitig erfolgen.

Ja. Genauso war das gemeint.

[onli]

Das Problem liegt bei uns. In https://github.com/s9y/Serendipity/blob ... .0.tpl#L50 setzen wir den content-type des Artikels auf xhtml. Stattdessen müssten wir content:encoded oder ![CDATA nutzen. Also testen, ob https://github.com/s9y/Serendipity/blob ... .0.tpl#L42 stattdessen auch für Atom funktioniert, oder ob es genügt, ein ![CDATA um den Artikel zu setzen.

[xoxyss]

Hi,
also in der feed_atom1.0.tpl einfach

Code: Select all

<content type="xhtml" xml:base="{$serendipityBaseURL}">
     <div xmlns="http://www.w3.org/1999/xhtml">
          {$entry.feed_body} {$entry.feed_ext}
     </div>
</content>

ersetzen durch:

Code: Select all

<content:encoded>
    {$entry.feed_body|@escape} {$entry.feed_ext|@escape}
</content:encoded>

funktioniert nicht oder ich habe was falsch gemacht. Ich glaube es kam eine Fehlermeldung mit "type mismatch 'content'". Kann das jemand anderes nochmal bestätigen?

[Timbalu]

Ich glaube das ist der falsche Ansatz. Es müsste eher generell als <img/> geliefert werden, da es ja in HTML5 egal ist, aber nicht in XHTML.

[xoxyss]

Der Meinung bin ich ja auch Das hatte ich ja bereits in einer früheren Antwort gefragt:

Also der Feed ist mit <img> definitiv nicht valide. Verwende ich <img /> ist er valide. So jetzt nochmal zurück zur eigentlichen Frage Kann man den Editro im Background so modifizieren dass er über den Button eingefügte Bilder automatisch mit <img /> einfügt? Oder wäre es nicht sinnvoll das generell im Editor anzupassen wenn es für den HTML Syntax sowieso egal ist?

[onli]

Nein, das stimmt nicht. Man kann in einem XML/Atom Feed Zeug hineinkippen, das kein XHTML ist. Das wäre doch Wahnsinn, immer zwischen den verschiedenen HTML-Sorten hin- und herformatieren zu müssen. Effekt wäre, dass wir den Atom-Feed dann abschalten müssen, finde ich, wenn er in Feedreadern wirklich nicht funktioniert.

Aber noch ist nichts verloren. Wenn content:encoded nicht funktioniert, dann müsste <![CDATA[]]> funktionieren. Kannst du das direkt auch mal probieren?

Code: Select all

<content>
    <![CDATA[{$entry.feed_body} {$entry.feed_ext}]]
</content>

[xoxyss]

Direkt leider nicht aber heute abend gern

[garvinhicking]

Ansonsten gibtrs das xhtmlcleanup plugin (wenn wir es mit 2.0 nicht gelöscht haben, aber ich glaube nicht) das solche single-tag fehler glaube ich auch korrigiert?!?

Ansonsten stammt die ATOM-Feedimplementation noch aus einer Zeit als XHTML als "die Zukunft" angesehen wurde und daher auch unser xhtml-Standard dort genutzt wurde. Letztlich hat sich das ja nicht durchgeetzt, und Atom-Feeds mit normalem Doctype zu nutzen und der CDATA-Implementation wie onli empfiehlt könnte möglich sein. Aber soweit ich weiß nur für Atom 1.0, bei atom 0.3 war xhtml als Content-Typ zwingend erforderlich. Die CDATA-Sache müsste theoretisch auch für xhtml-Content-Types gelten, so dass wir den Typen damit belassen könnten aber CDATA tatsächlich mal hineinwrappen könnten. Der Nachteil ist da halt dass Clients sich daran verschlucken können und den CDATA-Kram dann potentiell escapen und HTML nicht interpretieren...