MudGuard: document.open("text/plain") will nicht so wie ich

Hi,

folgendes simples HTML-Dokument mit integriertem Javascript

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">  
<html><head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /><title>test</title>  
<script type="text/javascript">  
var theFrame = null; var theFramedoc = null;  
window.onload = function() {  
            theFrame = window.frames["debugoutput"];  
            theFramedoc = theFrame.document;  
            theFramedoc.open("text/plain");  
        };  
function schreibwas() {  
    theFramedoc.writeln("testausgabe");  
    theFramedoc.writeln("<b>testausgabe</b>");  
}  
</script>  
</head><body>  
<iframe name="debugoutput" width="100%" height="200"></iframe>  
<input type="button" onclick="schreibwas()" value="schreib was">  
</body></html>  

sollte m.E. bei jedem Klick auf den button 2 Zeilen in den iframe (anhängend) schreiben - da für das document im iframe ja text/plain gesetzt wird.

Wie ich gerade erstaunt festgestellt habe, ist das Ergebnis genau umgekehrt zu dem, was ich erwartet hatte.

Firefox und Opera betrachten den iframe-Inhalt trotz text/plain als HTML - die zweite Zeile der Ausgabe ist fett, die tags nicht mehr zu sehen, beide Ausgaben erscheinen nebeneinander.

Der IE dagegen tut - obwohl er sich doch sonst nicht an content-types hält - ausnahmsweise mal das erwartete:
die beiden Ausgaben erscheinen in zwei Zeilen, die tags sind sichtbar.

Mach ich was falsch?
Wie bekomme ich es hin, daß auch Firefox/Opera den content-type beachten?

Es hat auch nichts geholfen, vor dem Öffnen des documents das Dokument explizit erstmal zu schließen.

Der DOM-Inspector des Firefox zeigt als Inhalt des iframes (nach einmaliger Button-Betätigung)

#document
  HTML
    HEAD
      TITLE
    BODY
      #text
      B
        #text

Auch "replace" als zweiter Parameter des open() hilft nichts.

cu,
Andreas

--
Warum nennt sich Andreas hier MudGuard?
Schreinerei Waechter
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
  1. hi,

    warum gibt der server kein text/plain aus?

    wenn du eine serverseitige scriptsprache hasst kannst du ja html <> etc.. in die html codierungen umwandeln.

    p.s.
    die sache mit den frames fand ich immer sehr umständlich und unflexibel.
    bin vor kurzem auf AJAX gestoßen

    1. Hi,

      warum gibt der server kein text/plain aus?

      Weil das Dokument im iframe nicht von einem Server kommt, sondern per Javascript geschrieben wird.

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      Schreinerei Waechter
      Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
    2. hi,

      warum gibt der server kein text/plain aus?

      wenn du eine serverseitige scriptsprache hasst kannst du ja html <> etc.. in die html codierungen umwandeln.

      warum in HTML-schreibweise umwandeln, wenn es doch plain text sein soll?

      gruß,
      wahsaga

      --
      /voodoo.css:
      #GeorgeWBush { position:absolute; bottom:-6ft; }
  2. Tag MudGuard.

    folgendes simples HTML-Dokument mit integriertem Javascript [...] sollte m.E. bei jedem Klick auf den button 2 Zeilen in den iframe (anhängend) schreiben - da für das document im iframe ja text/plain gesetzt wird.

    Nein, da irrst du, wie ein Blick in die Dokumentation zeigt:
    http://www.w3.org/TR/2000/WD-DOM-Level-2-HTML-20001113/html.html#ID-72161170
    http://www.w3.org/TR/2000/WD-DOM-Level-2-HTML-20001113/html.html#ID-75233634

    Der Standard sieht keinerlei Parameter vor, insbesondere keinen Content-Type. Die Geckos und Opera verhalten sich also richtig, nur der IE kocht mal wieder sein eigenes Süppchen, obwohl die Referenz etwas anderes aussagt:

    http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/open_1.asp

    Wie bekomme ich es hin, daß auch Firefox/Opera den content-type beachten?

    Ich denke, dass dir nur über den Umweg über HTML-Entities bleibt.

    Siechfred

    1. Hi,

      folgendes simples HTML-Dokument mit integriertem Javascript [...] sollte m.E. bei jedem Klick auf den button 2 Zeilen in den iframe (anhängend) schreiben - da für das document im iframe ja text/plain gesetzt wird.
      Nein, da irrst du, wie ein Blick in die Dokumentation zeigt:

      Da irre nicht ich, sondern SelfHTML:

      Zitat aus http://de.selfhtml.org/javascript/objekte/document.htm#open:

      Kann ohne, mit einem oder mit zwei Parametern aufgerufen werden. Folgende Parameter sind möglich:
      1. Mime-Typ = Eine Bezeichnung des Mime-Typs für die Art der Daten, [...]

      Keinerlei Hinweis darauf, daß das nur für un-Browser gilt.

      Ich hoffe, daß das aufgrund von http://bugs.selfhtml.org/bug.php?op=show&bugid=997 bald korrigiert wird.

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      Schreinerei Waechter
      Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
      1. Hallo ihr beiden,

        Der Standard sieht keinerlei Parameter vor, insbesondere keinen Content-Type. Die Geckos und Opera verhalten sich also richtig, nur der IE kocht mal wieder sein eigenes Süppchen

        Klassischer Fall von Vorverurteilung. Man kann nicht auf Basis der bisherigen Erfahrung auf zukünftige Fälle schließen, ohne dass man irgendwann irrt. ;)

        Keinerlei Hinweis darauf, daß das nur für un-Browser gilt.
        Ich hoffe, daß das aufgrund von http://bugs.selfhtml.org/bug.php?op=show&bugid=997 bald korrigiert wird.

        Nicht so voreilig, bitte erst gründlich recherchieren.

        Korrekt ist, dass DOM HTML den Parameter nicht vorsieht.
        (Übrigens habt ihr den Working Draft verlinkt. DOM 2 HTML ist schon längst Recommendation. http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-72161170 ist die korrekte URI, die besagt aber dasselbe, insofern ist es hier egal.)

        Trotzdem handelt es sich nicht um ein IE-proprietäres Feature. Denn Netscape JavaScript definiert den Parameter schon in Version 1.0 (hier 1.1, ist die älteste, die ich finden konnte, bei 1.3 ist keine Anmerkung, dass er später eingefügt wurde). Man könnte also annehmen, dass jeder Browser, der behauptet, er könne JavaScript, dies beherrscht.

        SELFHTML bezieht sich also auf Netscape JavaScript 1.0. Wir können gerne einen Hinweis einfügen, dass sich Gecko und Opera wohl auf das neuere DOM HTML beziehen mit ihrer Nicht-Unterstützung und die ältere Tradition JavaScript 1.0 in dem Punkt außer Acht lassen.

        Mathias

        1. Tag molily.

          Klassischer Fall von Vorverurteilung. Man kann nicht auf Basis der bisherigen Erfahrung auf zukünftige Fälle schließen, ohne dass man irgendwann irrt. ;)

          Ach, du erst noch ;-))

          SELFHTML bezieht sich also auf Netscape JavaScript 1.0. Wir können gerne einen Hinweis einfügen, dass sich Gecko und Opera wohl auf das neuere DOM HTML beziehen mit ihrer Nicht-Unterstützung und die ältere Tradition JavaScript 1.0 in dem Punkt außer Acht lassen.

          Ich habe das jetzt mal getestet, die einzigen der bei mir verfügbaren Browser, die es korrekt umsetzen, sind der Netscape Navigator 4.78 und der IE 6.0. Weder Netscape 6, Opera 7.11 & 8, Mozilla 1.3 & 1.4 und Firefox 1.0.x beachten die Angabe des Content-Type. Vor dem Hintergrund, dass diese Funktionalität in http://de.selfhtml.org/javascript/objekte/document.htm#open u.a. als in Netscape ab 2, Opera und Mozilla/Firefox verfügbar gekennzeichnet ist, halte ich es tatsächlich für einen Fehler, da weder Netscape ab Version 6, Opera ab Version 7 und Mozilla/Firefox ab Version 1.3 bzw. 1.0.x dieses Feature unterstützen. Und DOM ist es ja wohl offensichtlich auch nicht.

          Konsequenter wäre es m.E., open() in diesem Kontext DOM-gerecht als parameterlos zu kennzeichnen und den jetzigen Teil in die Hinweise zu verschieben. Wenn du es für die mir nicht zugänglichen Browser testen möchtest, habe ich mal eine kleine Testseite hochgeladen.

          Siechfred

          1. Hi,

            Ich habe das jetzt mal getestet, die einzigen der bei mir verfügbaren Browser, die es korrekt umsetzen, sind der Netscape Navigator 4.78 und der IE 6.0. Weder Netscape 6, Opera 7.11 & 8, Mozilla 1.3 & 1.4 und Firefox 1.0.x beachten die Angabe des Content-Type.

            Konqueror 3.4.1 (unter Cygwin/KDE) macht's auch nicht.

            cu,
            Andreas

            --
            Warum nennt sich Andreas hier MudGuard?
            Schreinerei Waechter
            Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
            1. Hallo MudGuard.

              Ich habe das jetzt mal getestet, die einzigen der bei mir verfügbaren Browser, die es korrekt umsetzen, sind der Netscape Navigator 4.78 und der IE 6.0. Weder Netscape 6, Opera 7.11 & 8, Mozilla 1.3 & 1.4 und Firefox 1.0.x beachten die Angabe des Content-Type.

              Konqueror 3.4.1 (unter Cygwin/KDE) macht's auch nicht.

              Ich weiß nicht genau, ob es etwas nützt, aber wie steht es hiermit?

              Einen schönen Freitag noch.

              Gruß, Ashura

              --
              Selfcode: sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:) fl:( ss:) ls:[ js:|
              30 Days to becoming an Opera8 Lover -- Opera Mini on Treo
              Meine Browser: Opera 8.02 | Firefox 1.0.6 | Lynx 2.8.5 | Netscape 4.7 | IE 6.0
              [Deshalb frei! - Argumente pro freie Software]
              1. Tag Ashura.

                Ich weiß nicht genau, ob es etwas nützt, aber wie steht es hiermit?

                Interessant, das mit "data:text/plain" war mir neu, das könnte man direkt in Selfhtml aufnehmen. Allerdings dürfte das im vorliegenden Fall vermutlich wenig zielführend sein, da ja [window.]document.open() zum Zwecke des Beschreibens eines Dokumentes verwendet werden soll, während dein Code window.open() verwendet, womit ein neues Fenster generiert wird (in der Ausgangsfrage ging es ja um ein bereits existentes Frame). Und wenn man mit document.write() etwas in dieses Popup schreibt, sind wir wieder beim gleichen Problem.

                Siechfred

                1. Hallo Siechfred.

                  Allerdings dürfte das im vorliegenden Fall vermutlich wenig zielführend sein, da ja [window.]document.open() zum Zwecke des Beschreibens eines Dokumentes verwendet werden soll, [...]

                  Ja. Ich wollte nur auf die Möglichkeit aufmerksam machen.

                  Einen schönen Freitag noch.

                  Gruß, Ashura

                  --
                  Selfcode: sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:) fl:( ss:) ls:[ js:|
                  30 Days to becoming an Opera8 Lover -- Opera Mini on Treo
                  Meine Browser: Opera 8.02 | Firefox 1.0.6 | Lynx 2.8.5 | Netscape 4.7 | IE 6.0
                  [Deshalb frei! - Argumente pro freie Software]
                  1. Tag Ashura.

                    Allerdings dürfte das im vorliegenden Fall vermutlich wenig zielführend sein, da ja [window.]document.open() zum Zwecke des Beschreibens eines Dokumentes verwendet werden soll, [...]
                    Ja. Ich wollte nur auf die Möglichkeit aufmerksam machen.

                    Jupp, deswegen auch mein Vorschlag, das in Selfhtml aufzunehmen :-)

                    Siechfred

                2. Hi,

                  Interessant, das mit "data:text/plain" war mir neu, das könnte man direkt in Selfhtml aufnehmen. Allerdings dürfte das im vorliegenden Fall vermutlich wenig zielführend sein, da ja [window.]document.open() zum Zwecke des Beschreibens eines Dokumentes verwendet werden soll, während dein Code window.open() verwendet, womit ein neues Fenster generiert wird (in der Ausgangsfrage ging es ja um ein bereits existentes Frame).

                  Naja, das wäre noch nicht wirklich das Problem - wenn data:text/plain ... als URL bei einem Popup funktioniert, funktioniert es auch bei iframe.location.href.

                  Und wenn man mit document.write() etwas in dieses Popup schreibt, sind wir wieder beim gleichen Problem.

                  Richtig. Und das ist der eigentliche Knackpunkt. Egal ob Popup oder iframe, es sollte eigentlich eine möglichst simple Konstruktion sein, die es erlaubt, jederzeit noch Text dazuzufügen (wie der Name "debugoutput" andeutet, soll das Ding für ein Javascript als Ausgabefenster dienen, dem jederzeit Ausgaben hinzugefügt werden können).

                  Es wird wohl darauf rauslaufen, daß ich doch eine HTML-Seite in das Fenster/Frame schreiben muß mit einem pre oder einer textarea, um dann dessen Inhalt zu erweitern (mit dem Zusatzaufwand, daß < und & umgewandelt werden müssen und der bisherige Inhalt erst wieder ausgelesen werden muß.

                  Der Versuch, ein <pre> beim Initialisieren ins Dokument zu schreiben und bei den nachfolgenden Ausgaben nur die < und & umzuwandeln funktioniert in IE und FF, aber Opera stellt sich quer - keinerlei Ausgabe, keinerlei Fehlermeldung.

                  Beim Versuch, jede einzelne Ausgabe in ein <pre></pre> zu packen, führte dazu, daß der Opera die erste Ausgabe macht und ab der zweiten Ausgabe nichts mehr funktioniert im Dokument-Fenster (andere Fenster reagieren noch). Wieder kein Hinweis in der Javascript-Konsole.

                  cu,
                  Andreas

                  --
                  Warum nennt sich Andreas hier MudGuard?
                  Schreinerei Waechter
                  Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
                  1. Tag MudGuard.

                    Und wenn man mit document.write() etwas in dieses Popup schreibt, sind wir wieder beim gleichen Problem.
                    Richtig. Und das ist der eigentliche Knackpunkt. Egal ob Popup oder iframe, es sollte eigentlich eine möglichst simple Konstruktion sein, die es erlaubt, jederzeit noch Text dazuzufügen (wie der Name "debugoutput" andeutet, soll das Ding für ein Javascript als Ausgabefenster dienen, dem jederzeit Ausgaben hinzugefügt werden können).

                    Das ist doch mal etwas detaillierter :-) Also eine Art "JS-Konsole", oder? Könntest du mal ein bisschen genauer werden, einen Link oder den relevanten Code posten?

                    Siechfred

        2. Hi,

          Keinerlei Hinweis darauf, daß das nur für un-Browser gilt.
          Ich hoffe, daß das aufgrund von http://bugs.selfhtml.org/bug.php?op=show&bugid=997 bald korrigiert wird.
          Nicht so voreilig, bitte erst gründlich recherchieren.

          Vielleicht hast Du mich falsch verstanden.
          Ich wünsche mir nur eine Korrektur der Tatsache, daß keinerlei Hinweis auf das nicht-Funktionieren der Parameter in den meisten Browsern existiert.

          Ob das nun nach dem einen oder anderen Standard vielleicht zulässig ist oder nicht, ist ja nochmal was anderes.

          SELFHTML bezieht sich also auf Netscape JavaScript 1.0. Wir können gerne einen Hinweis einfügen, dass sich Gecko und Opera

          und Konqueror (3.4.1 unter Cygwin) - also vermutlich auch Safari?

          wohl auf das neuere DOM HTML beziehen mit ihrer Nicht-Unterstützung und die ältere Tradition JavaScript 1.0 in dem Punkt außer Acht lassen.

          Ja, genau. Das ist es, was ich wollte. Einen Hinweis, daß das nicht in allen Browsern funktioniert. Denn die Browsersymbole obendrüber deuten an, daß es in all diesen Browsern funktionieren würde wie angegeben.

          cu,
          Andreas

          --
          Warum nennt sich Andreas hier MudGuard?
          Schreinerei Waechter
          Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
          1. Hallo Andreas

            Ja, genau. Das ist es, was ich wollte. Einen Hinweis, daß das nicht in allen Browsern funktioniert.

            Diesen Hinweis wird es in der Version 8.1.1 dann mit Sicherhait auch geben.

            Denn die Browsersymbole obendrüber deuten an, daß es in all diesen Browsern funktionieren würde wie angegeben.

            Die Browsersymbole sagen ersteinmal aus, dass die Methode selbst,
            unterstützt wird. Die Browsertests wurden üblicherweise mit den angegebenen
            Beispielen durchgeführt. Nur wenn sich ein Browser bei diesem Beispiel
            merkwürdig verhielt, wurden weitere Tests durchgeführt.
            Wenn dies vorkam, wurde anhand dieser Tests entschieden, ob das
            entsprechende Browsersymbol ganz weggelassen wurde, oder ein Hinweis unter
            "Beachten Sie" eingefügt wurde.

            Du kannst dir sicher vorstellen, welchen Aufwand dies allein bedeutet hat,
            bei der Anzahl der Beispiele in Selfhtml und der Menge der Browser und
            Browserversionen unter verschiedenen Betriebssystemen.

            Wenn wir für jeden möglichen Parameter für jede Methode, jedes Objekts noch
            extra ein Testscript erstellt hätten, um damit komplette Browsertests
            durchzuführen, wären diese wohl noch nicht abgeschlossen und Selfhtml 8.1
            noch nicht veröffentlicht.

            Auf Wiederlesen
            Detlef

            --
            - Wissen ist gut
            - Können ist besser
            - aber das Beste und Interessanteste ist der Weg dahin!
          2. Hallo,

            Danke für eure Tests.

            Vielleicht hast Du mich falsch verstanden.
            Ich wünsche mir nur eine Korrektur der Tatsache, daß keinerlei Hinweis auf das nicht-Funktionieren der Parameter in den meisten Browsern existiert.

            Das habe ich schon so verstanden und die Bug-Beschreibung entsprechend angepasst. Wie Detlef sagt bleiben die Browsericons wahrscheinlich so und es wird ein »Beachten Sie«-Hinweis eingefügt.

            Zu Siechfreds Posting:

            Konsequenter wäre es m.E., open() in diesem Kontext DOM-gerecht als parameterlos zu kennzeichnen und den jetzigen Teil in die Hinweise zu verschieben.

            Naürlich wäre das konsequenter, aber open() ist ein Symptom für einen allgemeinen Mangel. Momentan sind sehr viele JavaScript-Eigenheiten beschrieben, ohne dass jeweils genau geklärt ist, was DOM HTML dazu sagt. Netscape JavaScript ist die Grundlage der Objektreferenz, DOM HTML ist eher angehängt und Überschneidungen sind nicht korrekt gekennzeichnet (schon auf der ganz trivialen Ebene der Standard-Icons).
            In 8.1.x werde ich nicht damit anfangen, punktuell Beschreibungen umzudrehen, sodass DOM HTML im Vordergrund steht und Netscape JavaScript zum Beiwerk wird.
            Es geht nicht um einzelne Eigenschaften oder Methoden, sondern um die Gesamtstruktur der Objektreferenz. Zum Beispiel verweist /javascript/objekte/forms.htm in keinem Wort auf DOM HTML, obwohl das alles in DOM HTML neu definiert ist. Es werden auch nicht alle Attribute von form-Elementen dort aufgeführt, sondern nur die in JavaScript definierten. Es wird nicht gesagt, dass document.forms eine Collection von form-Elementknoten ist, dass man darüber Zugriff auf alle in HTML erlaubte Attribute hat.
            In 8.1.1 werde ich einige Querverweise einfügen, dass das jetzige Konzept »Netscape JavaScript plus DOM HTML« vervollständigt wird. Es aber umzukehren, benötigt eine komplette Neuordnung, die dann natürlich konsequent aus der DOM-Perspektive passiert.

            Mathias

            1. Tag molily.

              Zu Siechfreds Posting:
              In 8.1.x werde ich nicht damit anfangen, punktuell Beschreibungen umzudrehen, sodass DOM HTML im Vordergrund steht und Netscape JavaScript zum Beiwerk wird.

              Das fände ich aber im ganz konkreten Fall sinnvoller als deinen Vorschlag, einfach aus der Tatsache heraus, dass außer dem Steinzeitbrowser NN 4.7x und dem IE offensichtlich keiner der anderen genannten Browser den Content-Type als Parameter unterstützt.

              In 8.1.1 werde ich einige Querverweise einfügen, dass das jetzige Konzept »Netscape JavaScript plus DOM HTML« vervollständigt wird. Es aber umzukehren, benötigt eine komplette Neuordnung, die dann natürlich konsequent aus der DOM-Perspektive passiert.

              Anderer Vorschlag:
              Wie wäre es, im Bereich Javascript weitestgehend auf die Browser-Icons zu verzichten und statt dessen nur Icons nach dem Schema zu verwenden, wie es bspw. auf HTML World verwendet wird, ergänzt um Buttons für DOM Level 1 und DOM Level 2. Damit würde man dem ganzen Browser-Gedöns elegant aus dem Weg gehen.

              Siechfred

              1. Hallo,

                In 8.1.x werde ich nicht damit anfangen, punktuell Beschreibungen umzudrehen, sodass DOM HTML im Vordergrund steht und Netscape JavaScript zum Beiwerk wird.

                Das fände ich aber im ganz konkreten Fall sinnvoller

                Bezweifle ich »im ganz konkreten Fall« auch gar nicht, eigentlich in gar keinem Fall. ;) Mir geht es um die Einheitlichkeit. Ich will, solange ich nicht alle Fälle im Hinblick auf DOM HTML überarbeitet habe, nicht vereinzelt suggerieren, dass generell DOM HTML bei den Beschreibungen Pate stand, schließlich steht nirgendwo außer bei den paar neu hinzugefügten Anmerkungen, dass sich die Dokumentation explizit auf Spezifikation X oder Standard Y bezieht. Das soll in SELFHTML 9 anders werden, aber dazu muss das ganze Fundament erneuert werden.

                als deinen Vorschlag, einfach aus der Tatsache heraus, dass außer dem Steinzeitbrowser NN 4.7x und dem IE offensichtlich keiner der anderen genannten Browser den Content-Type als Parameter unterstützt.

                Ja, die zentrale Definition der Parameter werde ich natürlich entsprechend abschwächen, sodass direkt deutlich wird, dass das nur für Netscape JavaScript gilt und DOM HTML und dementsprechend die Browser das anders sehen.

                Anderer Vorschlag:
                Wie wäre es, im Bereich Javascript weitestgehend auf die Browser-Icons zu verzichten und statt dessen nur Icons nach dem Schema zu verwenden, wie es bspw. auf HTML World verwendet wird, ergänzt um Buttons für DOM Level 1 und DOM Level 2. Damit würde man dem ganzen Browser-Gedöns elegant aus dem Weg gehen.

                Ganz allgemein finde ich die Browserangaben enorm wichtig und halte sie für einen besonderen Wert von SELFHTML, auch wenn sie naturgemäß nur ungefähr sagen können, ob ein Browser grundsätzlich mit dem Feature klarkommt. Außer SELFHTML gibt es leider nur wenige Dokus, die solche Tests gewissenhaft durchführen.
                Klar ist, dass die Browserunterstützung bei JavaScript-Fähigkeiten schwer aufzuzeichnen ist, da man unzählige Anmerkungen »unter genau diesen Umständen funktioniert die besagte Methode/Eigenschaft in genau diesr Browserversion genau soundso« aufnehmen muss, die entsprechende klein Tests und Untersuchungen erfordern. Zumal die Beispiele didaktischen Wert haben sollen und nicht z.B. mit typeof(), if-Anweisungen und sonstigen Überprüfungen zum Ziel haben, den Grad der Unterstützung und die korrekte Funktionsweise zu überprüfen.
                Dadurch ufern die »Beachten Sie«-Hinweise natürlich aus. Für SELFHTML 9 muss hier eine Möglichkeit gefunden werden, wie die Ergebnisse des jeweiligen Beispiels und Ergebnisse mit Tests, die über das Beispiel hinausgehen, aufgezeichnet werden können. Das heißt bei Methoden unter anderem, dass auch zumindest die wichtigsten optionalen Parameter zumindest rudimentär durchgetestet werden. Bei vielen Unter- und Teiltechniken halte ich es allerdings nicht für nötig, die Unterstützung in allen denkbaren Zusammenhängen zu testen. Daher reicht in vielen Fällen, wie Detlef auch sagt, der Test mit einem guten Beispiel aus. Was den Rest angeht, so müssen wir irgendwo schlichtweg die Regel aufstellen: Browserangaben beziehen sich auf das Beispiel; wenn das Beispiel nicht im besagten Browser funktioniert, aber das Objekt, das Konstrukt, die Eigenschaft, die Methode usw. trotzdem in anderen wichtigen Zusammenhängen funktioniert, ist es i.d.R. angemerkt. Alles darüber hinaus gehende wollen wir gar nicht mit den Browserangaben abdecken (zumindest nicht direkt in der Dokumentation).

                Mathias

                1. Tag molily.

                  Anderer Vorschlag: [...]
                  Ganz allgemein finde ich die Browserangaben enorm wichtig und halte sie für einen besonderen Wert von SELFHTML, auch wenn sie naturgemäß nur ungefähr sagen können, ob ein Browser grundsätzlich mit dem Feature klarkommt. Außer SELFHTML gibt es leider nur wenige Dokus, die solche Tests gewissenhaft durchführen.

                  Für Techniken wie (X)HTML und CSS gebe ich dir uneingeschränkt Recht. Aber gerade in einem Bereich wie Javascript ist das eben schwierig (bereits der Name des Bereichs ist unmöglich zu wählen: JavaScript? ECMAScript? DOM?). Wenn ich hier Browserangaben verwende, suggeriere ich dem Leser, ich hätte es geprüft und für in Ordnung befunden. Nur wie dieses Beispiel zeigt, ist dem eben nicht so; wir hatten das schonmal bei document.title.

                  Klar ist, dass die Browserunterstützung bei JavaScript-Fähigkeiten schwer aufzuzeichnen ist, da man unzählige Anmerkungen »unter genau diesen Umständen funktioniert die besagte Methode/Eigenschaft in genau diesr Browserversion genau soundso« aufnehmen muss, die entsprechende klein Tests und Untersuchungen erfordern.

                  Genau das würde man mit der von mir vorgeschlagenen Kennzeichnung umgehen. Man bräuchte dazu natürlich eine Übersicht, welche Browser was unterstützen, ggf. mit dem Hinweis "teilweise".

                  Zumal die Beispiele didaktischen Wert haben sollen und nicht z.B. mit typeof(), if-Anweisungen und sonstigen Überprüfungen zum Ziel haben, den Grad der Unterstützung und die korrekte Funktionsweise zu überprüfen.

                  Ja, verständlich. Aber wird der didaktische Wert nicht dadurch geschmälert, dass man dem Leser "vorgaukelt", dass die beschriebenen Codestückchen in den genannten Browsern funktionieren? Es ist nunmal so, dass der Lernende erstmal den Code ausprobiert, es im Vertrauen auf die Kompatibilitätsangaben so programmiert, wie es die Doku erklärt, um dann feststellen zu müssen, dass es doch nicht so funktioniert, wie es beschrieben ist.

                  Was den Rest angeht, so müssen wir irgendwo schlichtweg die Regel aufstellen: Browserangaben beziehen sich auf das Beispiel; wenn das Beispiel nicht im besagten Browser funktioniert, aber das Objekt, das Konstrukt, die Eigenschaft, die Methode usw. trotzdem in anderen wichtigen Zusammenhängen funktioniert, ist es i.d.R. angemerkt. Alles darüber hinaus gehende wollen wir gar nicht mit den Browserangaben abdecken (zumindest nicht direkt in der Dokumentation).

                  Genau diesem Grundgedanken entsprang meine Idee.

                  Siechfred

    2. Hi,

      folgendes simples HTML-Dokument mit integriertem Javascript [...] sollte m.E. bei jedem Klick auf den button 2 Zeilen in den iframe (anhängend) schreiben - da für das document im iframe ja text/plain gesetzt wird.
      Nein, da irrst du, wie ein Blick in die Dokumentation zeigt:

      Nachtrag: danke für den Hinweis, jetzt brauch ich nicht weiter nach der Ursache des "Fehlers" zu suchen.

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      Schreinerei Waechter
      Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.