Mit eiemn Mausklick eine Mid. Datei starten und einen inhalt in einem Iframe anzeigen ?

Um klick events abzufangen brauchst du normalerweise immer JS
Beispiel hier (codepen)

//Variablen initalisieren
var button,
    audio,
    iframe;




//Funktion definieren die sich um den Button kümmert
function button_init(){
  button.onclick = function(event){//wenn der Button geklickt wurde
    event.preventDefault();//normales Verhalten stoppen (wie z.B. das Ausführen eines Links (wenn der Button ein Link wäre))

    //AUDIO
    audio.play();//das Audio abspielen
    //siehe http://www.w3schools.com/tags/ref_av_dom.asp

    //IFRAME
    iframe.src = 'neue/datei.html';//die Quelle des Iframes neu definieren
  }
}




//wenn das DOM geladen ist und manipulierbar
document.addEventListener("DOMContentLoaded", function(event) {
  //die variablen definieren
  button = document.getElementById("button");
  audio = document.getElementById("audio");
  iframe = document.getElementById("frame");

  button_init();//die Funktion für den Button aufrufen
});

Wie Wolf schon schrieb, wird es ohne JS nicht gehen. Es sind aber nur wenige Zeilen. Ein Problem ist nur die midi-Datei. Heute werden Musikdateien durch das audio-Tag abgespielt und das benötigt das MP3-Format. Du musst deine midi-Datei konvertieren.

<iframe id="idiframe" src="dein_urspruenglicher_inhalt.html"></iframe>
<audio id="idaudio" src="deine_sound_datei.mp3"></audio>
<img src="deine_grafik.jpg" onclick="change();">

function change() {
	document.getElementById("idiframe").src = "dein_neuer_inhalt.html";
	document.getElementById("idaudio").play();
}

Ups, da haben sich Wolfs Edit und mein Posting überschnitten.

Zitat von Sempervivum

onclick="change();"

Das spart zwar eine Zeile JS ist aber meiner Meinung nach 'n echt schlechter Stil.. biiitttteee bring das Leuten nicht bei

Hier noch in stark reduzierter Form

document.addEventListener("DOMContentLoaded", function(event) {
  document.getElementById("button").onclick = function(){
    document.getElementById("audio").play();
    document.getElementById("frame").src = 'neue/datei.html';
  }
});

oder alles in einer Zeile .. sind dann immerhin noch 207byte

document.addEventListener("DOMContentLoaded",function(){document.getElementById("button").onclick=function(){document.getElementById("audio").play(),document.getElementById("frame").src="neue/datei.html"}});

Warum? Nur weil es einfach und übersichtlich ist? Sind nur kryptische Formulierungen "guter Stil"? Der TO schrieb:

Zitat

mit nur einer kleinen js

Bin trotzdem der Meinung das es nicht so nice ist
Die 50byte mehr kann man verkraften wenn man dafür übersichtlicher bleibt

Das mischen von zwei Sprachen im Code ist meiner Meinung nach schlechter Stil z.B. im HTML stylen aber eben auch im HTML JS schreiben..

Was ist denn an Wolf's Beispiel nicht klein? Man schaue mal in den Umfang des jQuery Frameworks / dessen Plugins, die laden auch in kürzester Zeit.

Code braucht Platz, was will man da alles möglichst klein halten?

Die Wiki von SelfHTML stellt beide Varianten wertfrei nebeneinander:
http://wiki.selfhtml.org/wiki/JavaScript/Event-Handler
Ich habe den Eindruck, dass bei der Einschätzung, was "guter Stil" ist, außertechnische Motive im Vordergrund stehen: Dogmatismus und das Streben nach Profilierung statt Praxisrelevanz und Verständlichkeit. Welche Blüten das treiben kann, kann man sich hier ansehen:
https://www.tutorials.de/threa…array-mit-scandir.401675/

Warum soll ich erst Dinge verstehen die mir später im Weg stehen? Fakt ist: Ich ändere lieber eine Javascript Datei als etliche HTML Dateien wobei auch noch mehrere Elemente betroffen sein können und das gilt für alle mit gesundem Menschenverstand

Sempervivum: Warum die Trennung von Inhalt, Design und Dynamisierung durch JavaScript kein guter Stil sein sollte musst du mir aber mal erklären..

Ein Aspekt, der noch gar nicht zur Sprache gekommen ist, ist folgender: Ein großer Teil der Besucher, die in Computerforen Fragen stellen, sind Einsteiger, die nur geringe oder gar keine Kenntnisse in der Programmierung haben. Und ich bin der Meinung, dass man diesen einfache und leicht zu verstehende Lösungen anbieten und sie nicht mit fortgeschrittenen Techniken überfordern sollte. Genau das war meine Absicht bei dem Code, den ich am Anfang gepostet hatte. Andernfalls sehe ich die Gefahr, dass der betr. die Lösung kopiert, ohne sie zu verstehen und dann nicht in der Lage ist, sie selbständig weiter zu entwickeln. Ich selber habe, als ich am Anfang der Einarbeitung in JS war, anonyme Funktionen undurchsichtig und schwer zu verstehen gefunden. Im Verlauf der Entwicklung habe ich sie dann verstanden und mich damit angefreundet. Ebenso das Vermeiden von globalen Variablen: Hat auf jeden Fall seine Berechtigung für umfangreichere Projekte aber nicht für Einsteiger und wenn es sich um ein Skript von ein paar Zeilen handelt.

Wie bereits gesagt: Wenn schon lernen, warum nicht gleich praxisnah und logisch? Wenn du von Anfang an gemieden hast was du nicht verstehst, ist es kein Wunder das du es erst später verstanden hast.

Gerade dieser Kram mit globalen Variablen, Skript in einer DOM-Sprache und anderes sind die Mechanismen die wenig später den Lernprozess blockieren, wenn man tiefer in die Materie einsteigen will.

Man muss es nur richtig erklärt bekommen und anonyme Funktionen sind nun wirklich kein weltbewegendes Thema, gerade was Events angeht, intern ist das HTML-script-Attribut auch eine anonyme Funktion..

Ich sehe dagegen die Gefahr, dass Einsteiger resigniert aufgeben, wenn man sie mit fortgeschrittenen Techniken überfordert und es dann gar nicht zu einem fortgeschrittenen Lernprozess kommt.

Du setzt bei deinen Postings immer die Gültigkeit von Definitionen des "guten Programmierstils" voraus, die teilweise axiomatisch und praxisfremd sind (wie bei den Lösungen für das Problem des TO). Aber dazu habe ich ja schon in Posting #8 geschrieben.

Glücklicher Weise habe ich neben der Webprogrammierung noch einige andere Interessen, wo es meistens entspannter zugeht. Und dadurch kann ich diese Dinge aus einer gesunden Distanz beurteilen und das bringt mich zu der Einschätzung, dass ich ihnen nicht so eine große Bedeutung beimesse. Wichtig finde ich jedoch das, was in #11 geschrieben habe.