Race Condition?

[ChrisB]

Hi,

Ich hänge im allgemeinen Elemente nicht blind ins Dom, sondern an vordefinierten Stellen.

Das sehe ich als Selbstverständlichkeit an.

Ein erlaubter Kontext kann im HTML zum Beispiel durch die explizite classe versichert werden.

Nein, überhaupt nicht.

In <h1 class="..."> wirst du kein DIV oder TABLE einhängen können - ganz egal, was du für die ... als realen Wert des class-Attributes einsetzt.

Meine Funktion würde eher
<div class="mp3player"><a .../></div>
voraussetzen,

Gut, könnte sie machen.

Das macht sie aber nicht "sicherer" gegen Fehler, wenn sie auf ein Element trifft, welches diese Voraussetzung erfüllt, aber trotzdem technisch ungeeignet ist, entsprechend behandelt zu werden.
Dass dieser Fall nicht auftreten „kann”, ist aber reine Konvention - von dir ist *ausserhalb* des Einflussbereiches des Scriptes definiert, dass nur solche Elemente überhaupt diese Klasse besitzen dürfen, die sich auch für die vorgesehene Bearbeitung eignen.

und müsste zumal nicht einmal das a Element ersetzen. display:none reicht ja, wobei ich mich im konkreten Fall auch Frage, warum man den Downloadlink eigentlich entfernen muss.

Ob man das macht oder nicht, ist für diese Diskussion nebensächlich.

Verallgemeinert würde ich jedoch eine Lösung bevorzugt, welchen den Kontext, in welchem das zu ersetzende Element steht, überprüft.

Wie weit in welche Richtung man den Schieberegler, der auf der einen Seite mit "vorgegebener Kontext, in dem die Funktion korrekt arbeitet" und auf der anderen mit "eierlegende Wollmilchsau" beschriftet ist, verschiebt, macht man auch vom konkreten Einsatzzweck abhängig.

Ich würde in einem Fall wie dem vorliegenden dazu tendieren, die Anforderungen an den Kontext konkreter und restriktiver vorzugeben, anstatt eine Funktion/Methode zu schreiben, die zwar mit wirklich "allem", worauf man sie eventuell zur Anwendung bringen könnte, umgehen kann, dafür aber auch entsprechend "bloated" ist.

Das macht der Browser.
Der Versuch, ein Element im DOM an einer Position einzuhängen, wo es nicht stehen darf, wird mit einem Laufzeitfehler quitiert.

dem man mit try/catch behandeln vorbeugen muss.

Diese Notwendigkeit habe ich eigentlich noch so gut wie nie gesehen.
(Darüber, wofür man try/catch benutzen sollte, und wofür nicht, hatten wir hier auch schon umfangreichere Diskussionen.)

Das ist für mich vergleichbar damit, in jedem Script erst mal mit
if(document.getElementById) { ...
zu beginnen.
Ja, mag nach „reiner Lehre” vielleicht angebracht sein - halte ich in der Praxis aber für Nonsense.
In einem Browser, der nicht mal diese Methode kennt, möchte ich mit DOM Scripting gar nicht erst anfangen.
Ob irgendein Nutzer, der heutzutage noch einen archaischen Browser benutzt, mit dem schon der T-Rex nach oben-ohne-Bildchen von Artgenossinen im damals noch jungen Internet gesucht hat, eine Script-Fehlermeldung zu sehen bekommt, weil ich auf diese essentielle Prüfung verzichte, ist mir absolut egal.
Der Wunsch nach (Abwärts-)Kompabilität zu noch so absurden und widrigen Umgebungsbedingungen wird irgendwann zu einem Aufwand, der sich einfach nicht mehr lohnt.

Und ähnlich sehe ich das auch hier.
Wenn die Bedinungen, unter denen das Script laufen soll, hinreichend klar umrissen sind, und auch bei der Erstellung der HTML-Dokumente schon berücksichtigt werden - dann prüfe ich mir keinen Wolf an Stellen, an denen ich das gar nicht für notwendig erachte.
Die universelle Verwendbarkeit meiner Lösung mag darunter etwas leiden - aber wie schon gesagt, wie weit man den erwähnten Schieberegler schiebt, ist vom jeweils aktuellen Fall abhängig.

MfG ChrisB