XHTML im Internet Explorer will nicht dargestellt werden

[johny7]

Moin allerseits,

ich habe eine Site in XHTML geschrieben.
http://johny7.bplaced.net

Der IE will sie partout nicht darstellen. Ich habs mit IE6 und IE 8 versucht.

Grüße, JN

[fastix®]

Moin!

Moin allerseits,

ich habe eine Site in XHTML geschrieben.
http://johny7.bplaced.net

und Validiert?

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[johny7]

Moin allerseits,

Moin!

Moin allerseits,

ich habe eine Site in XHTML geschrieben.
http://johny7.bplaced.net

und Validiert?

Ja klar! (Ein Tippfehler war drin.)

Grüße, JN

[Cheatah]

Hi,

Der IE will sie partout nicht darstellen.

wie jetzt, gar nicht?

Ich habs mit IE6 und IE 8 versucht.

Warum zwingst Du die IEs eigentlich in den Quirks-Mode?

Cheatah

[johny7]

Moin allerseits,

Hi,

Der IE will sie partout nicht darstellen.

wie jetzt, gar nicht?

Ja, da kommt gar nichts zurück.

Ich habs mit IE6 und IE 8 versucht.

Warum zwingst Du die IEs eigentlich in den Quirks-Mode?

Wie denn das? Ich habe doch die Variante Strikt...

Cheatah

Grüße, JN

[gast42]

Warum zwingst Du die IEs eigentlich in den Quirks-Mode?
Wie denn das? Ich habe doch die Variante Strikt...

durch die xml-Declaration und den Kommentar vor der Doctype

[johny7]

Moin allerseits,

Warum zwingst Du die IEs eigentlich in den Quirks-Mode?
Wie denn das? Ich habe doch die Variante Strikt...

durch die xml-Declaration und den Kommentar vor der Doctype

Heißt das, der Kommentar muss in den html->head Bereich? Oder ist an dern XML-Deklaration etwas verkehrt?

Grüße, JN

[johny7]

Moin allerseits,

jetzt läuft es auf einmal. Ich habe den Kommentar in den head-Bereich verschoben und die Tippfehler behoben. Woran lag es denn jetzt eigentlich? Die fehlenden alt-Tags in Bildern könnens wohl kaum sein.

Grüße, JN

[fastix®]

Moin!

Ich habe den Kommentar in den head-Bereich verschoben und die Tippfehler behoben. Woran lag es denn jetzt eigentlich?

Nun, wenn der HTML-Kommentar außerhalb des (X)HTML-Dokumentes lag, dann stieß der IE auf etwas, was ihm wohl den Download vergrätzte.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[suit]

Woran lag es denn jetzt eigentlich?

Eine XML-Deklaration (bzw. irgen etwas, auch wenns nur ein Leerzeichen ist) vor der DTD triggert den Quirksmode im IE (zumindest in älteren).

[TomD]

Eine XML-Deklaration (bzw. irgen etwas, auch wenns nur ein Leerzeichen ist) vor der DTD triggert den Quirksmode im IE (zumindest in älteren).

Nur im IE6, aber Kommentare vor dem Doctype lassen den IE bis heute verquirkeln.

[Gunnar Bittersmann]

@@suit:

nuqneH

Eine XML-Deklaration (bzw. irgen etwas, auch wenns nur ein Leerzeichen ist

außer, wenns ein BOM ist

) vor der DTD triggert den Quirksmode im IE (zumindest in älteren).

Qapla'

[suit]

Eine XML-Deklaration (bzw. irgen etwas, auch wenns nur ein Leerzeichen ist

außer, wenns ein BOM ist

Das BOM ist ja offiziell nicht "da", zumindest sollte es das darstellende Programm auswerten, aber auf keinen Fall anzeigen.

btw: wie siehts eigentlich mit U+0000 aus, triggert das den Quirksmode?

[Gunnar Bittersmann]

@@suit:

nuqneH

btw: wie siehts eigentlich mit U+0000 aus, triggert das den Quirksmode?

Das ist kein in XML erlaubtes Zeichen.

Qapla'

[Cheatah]

Hi,

Die fehlenden alt-Tags in Bildern könnens wohl kaum sein.

nein, <alt>- oder </alt>-Tags sind in HTML und XHTML bisher ohnehin unzulässig. Ferner lautet das Content-Modell von <img> auf EMPTY, d.h. Du hättest darin gar kein <alt>-Element unterbringen dürfen. Was allerdings bei <img>-Elementen notwendig ist, ist ein alt-Attribut.

Cheatah

[Jean-Max]

Bounjoun Cheatah,

Was allerdings bei <img>-Elementen notwendig ist, ist ein alt-Attribut.

Auch, wenn man sein Alter nicht angeben will: alt=""

Adiou.

[Gunnar Bittersmann]

@@Cheatah:

nuqneH

nein, <alt>- oder </alt>-Tags sind in HTML und XHTML bisher ohnehin unzulässig. Ferner lautet das Content-Modell von <img> auf EMPTY, d.h. Du hättest darin gar kein <alt>-Element unterbringen dürfen. Was allerdings bei <img>-Elementen notwendig ist, ist ein alt-Attribut.

Schlag nach bei [Meiert].

Qapla'

[suit]

Ferner lautet das Content-Modell von <img> auf EMPTY

Zumindest, wenn man von HTML5 absieht ;)

[Gunnar Bittersmann]

@@suit:

nuqneH

Ferner lautet das Content-Modell von <img> auf EMPTY
Zumindest, wenn man von HTML5 absieht ;)

?? Was hat sich dran in HTML5 geändert? Nichts. [HTML5 §4.8.1] Leider. Denn Alternativtext wäre im Elementinhalt wohl sinnvoller aufgehoben als in einem Attributwert; so wie es bei 'object' und 'iframe' der Fall ist.

Aber HTML5 ist ja nicht dazu da, Unzulänglichkeiten von HTML 4 zu verbessern. Eher dazu, neue hinzuzufügen.

Qapla'

[suit]

?? Was hat sich dran in HTML5 geändert? Nichts. [HTML5 §4.8.1] Leider. Denn Alternativtext wäre im Elementinhalt wohl sinnvoller aufgehoben als in einem Attributwert; so wie es bei 'object' und 'iframe' der Fall ist.

Recht hast du - mein Fehler.

Ich hatte jetzt im Kopf, <figure /> sei ein erlaubtes Kind-Element von <img /> - ist aber falsch.

Aber HTML5 ist ja nicht dazu da, Unzulänglichkeiten von HTML 4 zu verbessern. Eher dazu, neue hinzuzufügen.

Gut gebrüllt.

[Gunnar Bittersmann]

@@suit:

nuqneH

Gut gebrüllt.

Ja, ich weiß, dass das Musik in deinen Ohren ist. ;-)

Qapla'

[TomD]

?? Was hat sich dran in HTML5 geändert? Nichts. [HTML5 §4.8.1] Leider. Denn Alternativtext wäre im Elementinhalt wohl sinnvoller aufgehoben als in einem Attributwert; so wie es bei 'object' und 'iframe' der Fall ist.

Was spricht dagegen, Bilder als object einzufügen?

Aber HTML5 ist ja nicht dazu da, Unzulänglichkeiten von HTML 4 zu verbessern. Eher dazu, neue hinzuzufügen.

Ach Kinder, immer das selbe unsinnige Gedöns. HTML5 hat im Gesamtbild vielleicht ein paar unschöne Ecken und Kanten, aber es löst viele der Probleme die wir nicht hätten, wenn HTML und XHTML mit mehr Sorgfalt spezifiziert worden wären.

[suit]

Was spricht dagegen, Bilder als object einzufügen?

Die mangelnde Browserunterstützung. Es spräche logisch auch nichts dagegen musik und film als object einzubinden, aber dafür hat man halt einfach mal <audio /> und <video /> gebastelt, weil man zu faul war object ordentlich zu erweitern.

HTML5 hat im Gesamtbild vielleicht ein paar unschöne Ecken und Kanten, aber es löst viele der Probleme die wir nicht hätten, wenn HTML und XHTML mit mehr Sorgfalt spezifiziert worden wären.

Welche Probleme genau?

[TomD]

Die mangelnde Browserunterstützung. Es spräche logisch auch nichts dagegen musik und film als object einzubinden, aber dafür hat man halt einfach mal <audio /> und <video /> gebastelt, weil man zu faul war object ordentlich zu erweitern.

Und was wäre in dem Fall mit der mangelnden Browserunterstützung? So wie ich es sehe wäre zwar ein Allround-object-Element möglich, aber gleichzeitig auch Überladen und daher mE komplizierter anzuwenden.

Was wäre z.B. mit einem object-Element, dass eine Audiodatei enthält, aber ein poster-Attribut besitzt?

Ich denke so ist es besser, weil dann jedes Element seinen eigenen Attribute und Prozesse verarbeiten kann. Auch wenn beide vielleicht gemeinsame Kontrollen teilen (was ein browser ja zweifelsohne Codesparent implementieren kann).

HTML5 hat im Gesamtbild vielleicht ein paar unschöne Ecken und Kanten, aber es löst viele der Probleme die wir nicht hätten, wenn HTML und XHTML mit mehr Sorgfalt spezifiziert worden wären.

HTML4 sagt zum Beispiel, dass leere p-Elemente ignoriert werden sollten (HTML401, 9.3.1 Paragraphs: the P element).

Frage: <p></p> ist leer, aber ist <p> </p> auch leer? Wird <p></p> im DOM dargestellt? Wenn nein, was passiert, wenn es dynamich mit Inhalt gefüllt wird? Wenn ja, darf es dargestellt werden, z.B. durch CSS-Manipulation?

DOM Core Level 3, createElement (und ein paar andere Methoden) sagt:

Return Value: A new Element object with the nodeName attribute set to tagName, and localName, prefix, and namespaceURI set to null.

Nun, HTML-Elemente besitzen den null-Namensraum, aber was ist mit XHTML-Dokumenten, diese besitzen den XHTML-Namensraum. Warum besitzt die selbe Sprache in unterschiedlichen Ausführungen eigentlich verschiedene Namensräume?

HTML5 definiert, dass HTML und XHTML den selben Namensraum teilen und dass createElement und andere DOM-Methoden in HTML-Dokumenten automatisch den XHTML-Namensraum anwenden. Die Unterschiede zwischen HTML und XHTML werden also verkleinert.

createElement ist da ein gutes Beispiel, da es bis vor einiger Zeit nicht interoperabel implementiert war (Webkit).

XHTML sagt, dass leere Elemente mit schließendem Endtag oder als selbstschließendes Element notriert werden müssen (XHTML 1.0 SE, 4.6. Empty Elements).

Mal ungeachtet der Tatsache, dass lange schlicht ignoriert wurde, dass Endtags für diese Elemente Darstellungsfehler bei TS-Parsern verursachen...

Endtags für leere Elemente und selbstschließende Elemente sind in HTML4 nicht erlaubt. Wie also hat ein HTML-Parser damit umzugehen? Ich würde in der SGML-Spezifikation nachlesen, aber dazu fehlt mir das Geld.

Mag sein, dass jetzt wieder die Leute angerannt kommen und ewtas von spielt-keine-Rolle-Spec/Implementierung faseln. Aber das sind nur drei von zahlreichen Beispiele, die sich direkt auf eine ... eher unvollständig durchdachte Spezifikation zurückzuführen sind.

[suit]

Was wäre z.B. mit einem object-Element, dass eine Audiodatei enthält, aber ein poster-Attribut besitzt?

Ist ein Animiertes gif ein img oder ein video? Was ist, wenn diesebe animation als flash eingebunden wird? ein object? Und was, wenn Ton dazu kommt, ist es dann video?

warum nicht immer object - mal mit type="image/gif" bzw application/x-shockwave-flash, video/mpeg oder wie auch immer?

[Gunnar Bittersmann]

@@suit:

nuqneH

warum nicht immer object - mal mit type="image/gif" bzw application/x-shockwave-flash, video/mpeg oder wie auch immer?

Na ohne @type!!

Der Medientyp ist im HTTP-Header der Ressource angeben, was hat der noch im aufrufenden HTML-Dokument zu suchen?

Und was ist, wenn per content negotiation eine aus mehreren Formatvarianten ausgewähl wird und gar kein einheitlicher Medientyp vorliegt?

Qapla'

[suit]

Na ohne @type!!

Der Medientyp ist im HTTP-Header der Ressource angeben, was hat der noch im aufrufenden HTML-Dokument zu suchen?

Damit der Client bereits vor dem request weiß was ihn erwartet: kann der Client wissentlich kein flash, braucht er application/x-shockwave-flash garnicht erst anfordern und spart Ressourcen.

Und was ist, wenn per content negotiation eine aus mehreren Formatvarianten ausgewähl wird und gar kein einheitlicher Medientyp vorliegt?

Defaultverhalten: mach so als wäre es ein iframe und biete ggf. einen downloaddialog an ;)

[Gunnar Bittersmann]

@@suit:

nuqneH

Der Medientyp ist im HTTP-Header der Ressource angeben, was hat der noch im aufrufenden HTML-Dokument zu suchen?

Damit der Client bereits vor dem request weiß was ihn erwartet: kann der Client wissentlich kein flash, braucht er application/x-shockwave-flash garnicht erst anfordern und spart Ressourcen.

Klarer Fall für den HTTP-Accept-Header. @type in HTML ist dafür nicht notwendig.

Qapla'

[Der Martin]

Hallo,

warum nicht immer object - mal mit type="image/gif" bzw application/x-shockwave-flash, video/mpeg oder wie auch immer?
Na ohne @type!!
Der Medientyp ist im HTTP-Header der Ressource angeben, was hat der noch im aufrufenden HTML-Dokument zu suchen?

was ist, wenn das Dokument bzw. die mit dem object-Element referenzierte Ressource nicht über HTTP übertragen, sondern -beispielsweise- aus dem Filesystem geladen wird?

Und was ist, wenn per content negotiation eine aus mehreren Formatvarianten ausgewähl wird und gar kein einheitlicher Medientyp vorliegt?

Auch das ist nur im üblichen HTTP-Kontext möglich.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

was ist, wenn das Dokument bzw. die mit dem object-Element referenzierte Ressource nicht über HTTP übertragen, sondern -beispielsweise- aus dem Filesystem geladen wird?

Das ist eine Spezialanwendung, nicht das WWW.

In dem Fall gibt es die Dateiendung.

Qapla'

[TomD]

Ist ein Animiertes gif ein img oder ein video?

Ein Bild, der Medientyp lautet image/gif

Was ist, wenn diesebe animation als flash eingebunden wird? ein object? Und was, wenn Ton dazu kommt, ist es dann video?

Flash ist ein zusammenspiel mehrerer Medien, Video, Audio, Bilder, Text. Es gibt keine eindeutige Medienzuordnung, daher ist object hier zimlich das einzige, was man vernüftig verwenden kann.

warum nicht immer object - mal mit type="image/gif" bzw application/x-shockwave-flash, video/mpeg oder wie auch immer?

Warum nicht immer <div>? mal mit class=h1, class=p und class=abbr?

[suit]

warum nicht immer object - mal mit type="image/gif" bzw application/x-shockwave-flash, video/mpeg oder wie auch immer?

Warum nicht immer <div>? mal mit class=h1, class=p und class=abbr?

Aus semantischer Sicht gäbe es keinen Unterschied, es ist nunmal aber anders gemacht worden.

[TomD]

Aus semantischer Sicht gäbe es keinen Unterschied, es ist nunmal aber anders gemacht worden.

Wer sagt das?

[suit]

Aus semantischer Sicht gäbe es keinen Unterschied, es ist nunmal aber anders gemacht worden.

Wer sagt das?

Wer sagt dass es nicht so ist?

Wenn jemand definiert hätte, dass die semantische Aussage eines Elements über seine Klasse(n) definiert wäre, gäbe es keinen Unterschied.

<foo type="paragraph" /> und <p /> oder <foo type="heading level1" /> und <h1 /> ist bei entsprechender definition absolut gleichbedeutend.

[TomD]

Wer sagt das?

Wer sagt dass es nicht so ist?

Nun, so las es sich. Darum ist es ja so wichtig, dass Spezifikationen eindeutig sind ;-)

Wenn jemand definiert hätte, dass die semantische Aussage eines Elements über seine Klasse(n) definiert wäre, gäbe es keinen Unterschied.

<foo type="paragraph" /> und <p /> oder <foo type="heading level1" /> und <h1 /> ist bei entsprechender definition absolut gleichbedeutend.

Stimmt, ich frage mich nur, warum du das akzeptieren würdest, nicht aber die Einteilung in video, audio und object.

[Gunnar Bittersmann]

@@TomD:

nuqneH

Nun, HTML-Elemente besitzen den null-Namensraum

Tun sie das? Gibt es das Konzept Namensräume denn überhaupt in SGML?

Warum besitzt die selbe Sprache in unterschiedlichen Ausführungen eigentlich verschiedene Namensräume?

Es sind unterschiedliche Sprachen (die gewolltermaßen nahezu identisch aussehen).

Qapla'

[suit]

Nun, HTML-Elemente besitzen den null-Namensraum

Tun sie das? Gibt es das Konzept Namensräume denn überhaupt in SGML?

Nein und sie sind (waren?) sogar ungültig.

[TomD]

Nun, HTML-Elemente besitzen den null-Namensraum

Tun sie das? Gibt es das Konzept Namensräume denn überhaupt in SGML?

Genau kann ich das aus genannten Gründen nicht Nachprüfen.

HTML definiert keinen eigenen Namensraum. Daher trifft die Definition per DOM zu. Diese sagt in etwa (jetzt aus der Erinenrung, da ich die relevante Stelle gerade nicht finde), dass Elemente ohne Namensraum in den null-Namensraum (oder wars der DOM-Standard-NR) versetzt werden.

Es sind unterschiedliche Sprachen (die gewolltermaßen nahezu identisch aussehen).

Alte Rechtschreibung, Neue Rechtschreibung und Reformierte Neue Rechtschreibung sind alle drei Deutsch, nur in einer anderen Serialisierung. Das Trifft auch auf HTML zu. Es ist die selbe Sprache, nur in andere Schreibweise.
Darauf deutet ja auch der Untertitel der XHTML-Spezifikation hin: Eine Reformulierung von HTML nach XML 1.0

Die von dir genannte Beschreibung trifft auf den leider nicht mehr existenten XHTML-2.0-Entwurf sowie XHTML 1.1 zu.

[Gunnar Bittersmann]

@@TomD:

nuqneH

XHTML sagt, dass leere Elemente mit schließendem Endtag oder als selbstschließendes Element notriert werden müssen (XHTML 1.0 SE, 4.6. Empty Elements).

Mal ungeachtet der Tatsache, dass lange schlicht ignoriert wurde, dass Endtags für diese Elemente Darstellungsfehler bei TS-Parsern verursachen...

Diese Tatsache wurde keinesfalls ignoriert, sondern ist sehr wohl in der XHTML-Spec erwähnt. [XHTML10 §C.2]

Qapla'

[Gunnar Bittersmann]

@@TomD:

nuqneH

Ach Kinder, immer das selbe unsinnige Gedöns. HTML5 hat im Gesamtbild vielleicht ein paar unschöne Ecken und Kanten, aber es löst viele der Probleme die wir nicht hätten, wenn HTML und XHTML mit mehr Sorgfalt spezifiziert worden wären.

Ja, endlich sind leere Listen, Tabellen, Tabellenzeilen etc. erlaubt. Das '+' anstelle von '*' in der DTD bspw bei
<!ELEMENT UL - - (LI)+                 -- unordered list -->
war mir schon immer ein Dorn im Auge.

Aber HTML5 würde noch viel mehr Probleme lösen, wenn es mit mehr Sorgfalt spezifiziert worden wäre. Das Problem des Fehlens des 'di'-Elements (zur Gruppierung zusammengehöriger 'dt' und 'dd') besteht weiterhin.

Qapla'

[TomD]

Aber HTML5 würde noch viel mehr Probleme lösen, wenn es mit mehr Sorgfalt spezifiziert worden wäre. Das Problem des Fehlens des 'di'-Elements (zur Gruppierung zusammengehöriger 'dt' und 'dd') besteht weiterhin.

Das ist mir auch ein Dorn im Auge. Ich bin schließlich kein verblendeter Fanboy.

[Klawischnigg]

Hi there,

ich habe eine Site in XHTML geschrieben.

Du hättest Dir vorher vielleicht das durchlesen sollen...

[suit]

ich habe eine Site in XHTML geschrieben.

Du hättest Dir vorher vielleicht das durchlesen sollen...

Da steht auch viel Mist drin - das liegt wohl daran, dass der Artikel bereits etwa 5 Jahre Buckel hat.

[Klawischnigg]

Hi there,

Da steht auch viel Mist drin

was genau meinst Du?

• das liegt wohl daran, dass der Artikel bereits etwa 5 Jahre Buckel hat.

Hm, da steht am Seitenende: "This work is copyright © 2010 David Hammond"
Aber selbst wenn es so wäre, was hat sich denn XTHML-mäßig in den letzten fünf Jahren so gross geändert?

[suit]

Hi there,

Da steht auch viel Mist drin

was genau meinst Du?

"HTML 4.01 is actually more future-compatible. A valid HTML 4.01 document written to modern support levels will be valid HTML 5, and HTML 5 is where the majority of attention is from browser developers and the W3C."

Auch HTML5 hat mittlerweile eine XML-serialisierung

"XHTML 1.x is not “future-compatible”."

XHTML 1.0 als text/html nicht weniger als HTML 4.01.

"If you serve it with the typical text/html content type, you are giving all browsers a thumbs-up to treat it exactly like classic HTML, meaning absolutely no progress is made."

Das Markup ist einfacher und klarer lesbar und lässt sich als XML weiterverarbeiten - z.B. durch eingebettete Flash die ihre eigenen Elterndokumente lesen und parsen. Die Dokumente lassen sich durch einen XML-Parser lesen und verarbeiten, egal ob im HTTP-Header text/html steht oder application/xhtml+xml.

"The most common problem is a white gap around your page if you have a background on the body, no background on the html element, ..."

Ja, ein Problem für Leute die nicht mit CSS umgehen können. Was kann da das HTML-Dokument dafür?

Hixie: "Authors intending their work for public consumption should stick to HTML 4.01"

Warum schreibt der Affe seine Seite dann nicht in HTML 4.01? :p

• das liegt wohl daran, dass der Artikel bereits etwa 5 Jahre Buckel hat.

Hm, da steht am Seitenende: "This work is copyright © 2010 David Hammond"
Aber selbst wenn es so wäre, was hat sich denn XTHML-mäßig in den letzten fünf Jahren so gross geändert?

Die Browserunterstützung?

Der Artikel geht von Firefox 2 und Opera 8.5 aus - hast du ihn gelesen? ;)

[johny7]

Moin allerseits,

Hm, da steht am Seitenende: "This work is copyright © 2010 David Hammond"
Aber selbst wenn es so wäre, was hat sich denn XTHML-mäßig in den letzten fünf Jahren so gross geändert?

Die Browserunterstützung?

Der Artikel geht von Firefox 2 und Opera 8.5 aus - hast du ihn gelesen? ;)

Wo kann ich mich denn über den aktuellen Stand der Dinge informieren? Gibt es irgeendwo eine Rekommendation, wie ich XHTML am Besten einsetzen kann? Oder muss ich ir das alles in den RFCs zusammenlesen? Gibt es denn dann irgendwo ein Tutorial, wie man mit RFCs umgeht und wie man da durchblickt, um den Wald nicht vor lauter Bäumen zu verlieren?

Grüße, JN

[Cheatah]

Hi,

• das liegt wohl daran, dass der Artikel bereits etwa 5 Jahre Buckel hat.

ich finde einige referenzierte Artikel, die offenbar 2006 veröffentlicht wurden, und sogar einen aus 2008 - was natürlich nichts über das Datum aussagt, an dem der Artikel verfasst wurde; Links kann man wunderbar auch später hinzufügen. Ein Großteil der Referenzen stammt eher von 2003 oder 2004.

Hm, da steht am Seitenende: "This work is copyright © 2010 David Hammond"

Hurra. Schau mal am 1.1.2011 um 0:00:00 Uhr (Ortszeit des Servers) wieder rein, ich wette dann hat sich das Jahr auf 2011 geändert.

Aber selbst wenn es so wäre, was hat sich denn XTHML-mäßig in den letzten fünf Jahren so gross geändert?

Gegenfrage: Was hat sich am Verständnis der Leute bezüglich der Sprache verändert? Der Artikel behauptet: "Most people who use and promote XHTML do so because they think it's the “next version” of HTML" - was bei Laien der Fall sein mag, aber auf die Gruppe derer, die etwas Ahnung von der Materie haben, trifft das wohl kaum noch zu.

Cheatah