<xmp> vs. <pre>

[Siggi]

Nur mal so eine Frage am Rande.

Der Tag <xmp> soll doch abgeschafft werden, bzw. nicht
empfohlen zur Benutzung. Stattdessen soll <pre>
verwendet werden.

Aber ist <pre> wirklich in der Lage <xmp> zu ersetzen ?

Nehmen wir folgenden Quelltext:

<pre>&auml;</pre>  Ausgabe im Browser = ä
<xmp>&auml;</xmp>  Ausgabe im Browser = &auml;

Und genau diese Ausgabe von xmp ist , was ich sehen möchte.

Warum ?
Hauptsächlich zu Test-  und Formatierungszwecken,
aber tut nichts zur Sache.

Gerade im Hinblich auf die unzählgen Browser Format Einstellungen
UTF-8 iso-? , und die daraus resultierende verfälschte
Ausgabe, interessiert mich ganz besonders:
WAS STEHT WIRKLICH IM QUELLTEXT.
(ohne erst den quelltext anzuschauen)

Insofern zeigt mir bisher nur <xmp> die "Wahrheit" an.
Unabhängig von codierungen und sonstiges.

Aber wenn doch alle echten und selbsternannten Experten
diesen netten <Tag> in grund und boden reden, und man
solle <pre> verwenden, Ja wie soll das gehen, dass ich das
gleiche Ergebniss mit <pre> erhalte ?

Sehe ich das falsch und kann <pre> die Ausgabe
genau so anzeigen wie <xmp> ?

Danke fürs Lesen
Stefan

[Genie]

Hi

Ja wie soll das gehen, dass ich das
gleiche Ergebniss mit <pre> erhalte ?

<pre>&amp;auml;</pre>  Ausgabe im Browser = &auml;
                                            ^ wird durch &amp; maskiert

mfg
Genie

[Stefan]

Hi Genie,

Ja wie soll das gehen, dass ich das
gleiche Ergebniss mit <pre> erhalte ?
<pre>&amp;auml;</pre>  Ausgabe im Browser = &auml;
                                            ^ wird durch &amp; maskiert

Das kanns ja nicht sein. So müsste ich ja den Inhalt
jedesmal maskieren. Mag ja bei statischen Seiten noch gehen,
wenngleich es damit <xmp> nicht gleichkommt.
Aber bei einem Formular das diesen Buchstaben (ä) übermittelt
und dann angezeigt wird gehts nicht.

Klar kann ich mit PHP das ganze bearbeiten vor der Ausgabe,
aber das war nicht meine Frage.

######## Die eigentliche Frage ##########

Es ist so ich kapiere nicht warum  <xmp> schlecht sein
soll und auf eine alternative <pre> verwiesen wird, die
das aber nicht kann. Also warum ?

#########################################

Gruss
Stefan

[Markus]

Das kanns ja nicht sein. So müsste ich ja den Inhalt
jedesmal maskieren. Mag ja bei statischen Seiten noch gehen,
wenngleich es damit <xmp> nicht gleichkommt.
Aber bei einem Formular das diesen Buchstaben (ä) übermittelt
und dann angezeigt wird gehts nicht.

Wenn du ä anzeigen möchtest und das nicht maskiert verwende doch Unicode, das ist nämlich kein Browserformat, sondern eine Standardisierte Zeichenkodierung. Beis dieser ist die maskierung von umlauten nicht notwendig.

Klar kann ich mit PHP das ganze bearbeiten vor der Ausgabe,
aber das war nicht meine Frage.

Warum tust du es dann nicht?

######## Die eigentliche Frage ##########

Es ist so ich kapiere nicht warum  <xmp> schlecht sein
soll und auf eine alternative <pre> verwiesen wird, die
das aber nicht kann. Also warum ?

#########################################

xmp ist in keinem Standard verankert (und so weit ich weis war es das auch nie). Die richtige Anzeige ist also nicht garantiert.
Es gibt gute Gründe, warum dieser Tag kein HTML Standard ist: Wenn ein Browser &auml; nun als ä anzeigt wäre das Beispiel (xmp = Example) sinnlos. Daher muss man diese Zeichen maskieren, damit sie immer und überall verstanden werden.
pre hat nicht die Aufgabe von xmp. Du kannst gerne mit <samp> etwas als Beispiel auszeichnen, aber die richtige maskierung ist immer noch nötig.

Gruss
Stefan

[Ashura]

Hallo Markus.

xmp ist in keinem Standard verankert (und so weit ich weis war es das auch nie).

Doch, ist es. Siehe HTML 2.0.

Einen schönen Freitag noch.

Gruß, Ashura

[Markus]

Hallo Markus.

xmp ist in keinem Standard verankert (und so weit ich weis war es das auch nie).

Doch, ist es. Siehe HTML 2.0.

Hm, wenn man sich zu sehr auf die kleinen Bildchen verlässt. Aber jetzt habe ich mir den inhalt wieder ins Gedächtnis gerufen :-)

Einen schönen Freitag noch.

Gruß, Ashura

[Orlando]

Hallo Markus,

xmp ist in keinem Standard verankert (und so weit ich weis war es das auch nie).

Doch, ist es. Siehe HTML 2.0.

Hm, wenn man sich zu sehr auf die kleinen Bildchen verlässt.

Danke für den Hinweis. Ich habe den Abschnitt in SELFHTML ergänzt und bei der Gelegenheit gleich <pre><code>…</code></pre> erwähnt.

Sollte dir noch eine Ungenauigkeit auffallen, melde sie bitte formlos.

Grüße
 Roland

[MudGuard]

Hi,

Sollte dir noch eine Ungenauigkeit auffallen, melde sie bitte formlos.

Hm. Wieso ist die verlinkte Seite in deutscher Sprache? Das en vor dem selfhtml.org sollte doch eigentlich auf eine englisch-sprachige Seite hinweisen ;-)

cu,
Andreas

[Gunnar Bittersmann]

Hello out there!

Doch, ist es. Siehe HTML 2.0.

Auch in HTML 3.2 gab’s das noch. Allerdings:

“XMP, LISTING and PLAINTEXT […] These are obsolete tags for preformatted text that predate the introduction of PRE. User agents may support these for backwards compatibility. Authors should avoid using them in new documents!” [HTML32]

See ya up the road,
Gunnar

[Sven Rautenberg]

Moin!

Wenn du ä anzeigen möchtest und das nicht maskiert verwende doch Unicode, das ist nämlich kein Browserformat, sondern eine Standardisierte Zeichenkodierung. Beis dieser ist die maskierung von umlauten nicht notwendig.

Eine Maskierung von Umlauten ist niemals notwendig, wenn die gewählte Zeichencodierung erlaubt, den Umlaut direkt anzugeben.

- Sven Rautenberg

[迪拉斯]

Hey,

ich weiß, worauf du hinauswillst. <xmp> ist so bequem für diesen Zweck, Inhalte einfach durchzureichen.

Leider war es ein Fehler in der Spezifikation. :( Bedenke, dass du kein </xmp> innerhalb eines <xmp>-Blocks angeben kannst, damit ist das Prinzip der Symmetrie verletzt.

Also benutze <pre>. Ein Suchen und Ersetzen von
    & nach &amp;
    < nach &lt;
    > nach &gt;
im eingebetteten Text bringt dich nicht um.

[Siggi]

hi,

ich weiß, worauf du hinauswillst. <xmp> ist so bequem für diesen Zweck, Inhalte einfach durchzureichen.

Endlich einer der uns versteht ;-)

Schade dass die entsprechenden Konsortien das nicht
auch begreifen und einen entsprechenden <tag> dafür
bereitstellen.

Übrigens es geht hier nicht nur um suchen und ersetzen.
Mich ärgert dass schon lange und immer mal wieder stosse
ich darauf, dass es keine wirklich Alternative zu <xmp>
gibt. Oft sind es Kleinigkeiten. Heute zb. ziehe ich ein
umfangreiches Script aus dem  Netz. Das Monstrum hat aber
Probleme bei der Darstellung.

Headerangaben utf-8 iso vermischen sich, formular/aus/eingaben
zeigen bei umlauten verrückte zeichen an.

Nun ist es meine Aufgabe heruszufinden wieso und wo
diese Ausgaben erzeugt werden und zu korregieren.

Das geht nich mal eben so onthefly hierbei hilft mir
ungemein dieser arme kleine <xmp> tag. So sehe ich alles was
ich sehen möchte ohne grossartig in den quelltext eingreifen
zu müssen, insbesondere wenn ein grossteil aus der Datenbank
kommt.

Nichts und ich meine wirklich nichts hilft mir da besser
als <xmp>, denn ansonsten müsste ich die Ausgabe parsen.

Gruss
Siggi

[Sven Rautenberg]

Moin!

Schade dass die entsprechenden Konsortien das nicht
auch begreifen und einen entsprechenden <tag> dafür
bereitstellen.

Wieso, das tun sie doch. <xmp> existiert.

Das geht nich mal eben so onthefly hierbei hilft mir
ungemein dieser arme kleine <xmp> tag. So sehe ich alles was
ich sehen möchte ohne grossartig in den quelltext eingreifen
zu müssen, insbesondere wenn ein grossteil aus der Datenbank
kommt.

Jeder Browser hat die Möglichkeit, den Quelltext einer HTML-Seite anzuzeigen. Das ist aus mehreren Erwägungen extrem sinnvoll, denn <xmp> wandelt lediglich Entities nicht um - aber normale Zeichen, die laut Zeichencodierung interpretierbar sind, wird es dennoch anzeigen wollen.

Nun siehst du also im Browser ein "ä" oder ein "€". Aber: Ist das Zeichen nun in ISO-8859-1, Windows-1252, ISO-8859-15 oder UTF-8 codiert? Was meint der Browser? Da hilft dir <xmp> nicht weiter.

Nichts und ich meine wirklich nichts hilft mir da besser
als <xmp>, denn ansonsten müsste ich die Ausgabe parsen.

Es spricht ja nichts dagegen, zum Debugging <xmp> zu benutzen. Und mit den entsprechenden DOCTYPES ist es dauerhaft erlaubt. Erwarte nur nicht, dass du XHTML 1.1 benutzen kannst, und <xmp> erlaubt ist.

- Sven Rautenberg

[MudGuard]

Hi,

Erwarte nur nicht, dass du XHTML 1.1 benutzen kannst, und <xmp> erlaubt ist.

Da braucht man gar nicht so extrem weit gehen, schon der (erste?) Working Draft zu HTML 4.0 kennt <xmp> nicht mehr - schon vor gut 9 Jahren (http://www.w3.org/TR/WD-html40-970708/) hat man die Schwächen von <xmp> erkannt und es deshalb verbannt ...

cu,
Andreas

[Gunnar Bittersmann]

Hello out there!

Schade dass die entsprechenden Konsortien das nicht
auch begreifen und einen entsprechenden <tag> dafür
bereitstellen.

2× nein. Zum einen begreift das entsprechende Consortium das; zum anderen stellt es dafür etwas zur Verfügung.

Aber etwas weiter ausgeholt:

<!ENTITY % literal "CDATA"  
        -- historical, non-conforming parsing mode where  
           the only markup signal is the end tag  
           in full  
        -->  
  
<!ELEMENT (XMP|LISTING) - -  %literal>  
<!ELEMENT PLAINTEXT - O %literal>
~~~ [[HTML32](http://www.w3.org/TR/REC-html32#xmp)]  
  
Das heißt, dass der Inhalt der Elemente der Typen XMP, LISTING und PLAINTEXT vom Typ CDATA ist, also nicht geparst wird, ergo Entity-Referenzen nicht aufgelöste werden.  
  
Gleiches erreichst du in XHTML mit [CDATA-Abschnitten](http://de.selfhtml.org/xml/regeln/zeichen.htm#cdata); allerdings nur, wenn das als XML (application/xhtml+xml) verarbeitet wird.  
  
See ya up the road,  
Gunnar

-- 
“Remember, in the end, nobody wins unless everybody wins.” (Bruce Springsteen)

[迪拉斯]

Schade dass die entsprechenden Konsortien das nicht
auch begreifen und einen entsprechenden <tag> dafür
bereitstellen.

Naja, aber <xmp> war ja wie gesagt schon entwurfstechnisch kaputt. Ich habe mal eben fünf Minuten lang intensiv drüber nachgedacht, wie man's besser machen kann, wenn ich die Gewalt über die Spazifikation hätte, aber mir fällt nichts Gescheites ein. Forum, Vorschläge dazu?

[Debugging]
Das geht nich mal eben so onthefly hierbei hilft mir
ungemein dieser arme kleine <xmp> tag. So sehe ich alles was
ich sehen möchte ohne grossartig in den quelltext eingreifen
zu müssen, insbesondere wenn ein grossteil aus der Datenbank
kommt.
Nichts und ich meine wirklich nichts hilft mir da besser
als <xmp>, denn ansonsten müsste ich die Ausgabe parsen.

In diesem Falle schalte ich immer von text/html nach text/plain um. Probier's aus, vielleicht sagt dir das genauso zu wie mir.

[Auge]

Hallo

Das geht nich mal eben so onthefly hierbei hilft mir
ungemein dieser arme kleine <xmp> tag. So sehe ich alles was
ich sehen möchte ohne grossartig in den quelltext eingreifen
zu müssen, insbesondere wenn ein grossteil aus der Datenbank
kommt.

Nichts und ich meine wirklich nichts hilft mir da besser
als <xmp>, denn ansonsten müsste ich die Ausgabe parsen.

Da du das offensichtlich zum Debuggen und nicht für die Ausgabe beim Besucher nimmst, tue es einfach. Dein Browser kann damit umgehen, nur du willst es zur Bereinigung von Programmierfehlern benutzen[1], wozu also die Aufregung?

[1] Etwaige Vermischungen der Zeichensatzcodierung wirst du damit aber nicht zweifelsfrei klären können, wie auch schon Sven ansprach.

Tschö, Auge