nicht angemeldet
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
MudGuard