Töne im Opera / Fenster in den Vordergrund

Hallo, bei mir sind kürzlich zwei Probleme aufgetaucht.

Ich möchte auf meiner Webseite eine Audiodatei abspielen, was mit dem -Tag auch ganz gut funktioniert, ausser im Opera. Dort wird zwar der Player angezeigt, die Datei kann aber nicht abgespielt werden. Das Problem scheint nich an meinem html zu liegen, wenn ich mit Opera (v12.01) diese Testseite öffne, geht es auch nicht. Gibts noch eine andere Lösung, um im Opera Audiodateien abzuspielen, oder kann dieses Problem irgendwie behoben werden?

Als nächstes wollte ich ein Fenster, das zuvor mit open() geöffnet wurde, zurück in den Vordergrund holen, nachdem ein setTimeout() abgelaufen ist. Wahrscheinlich wird das irgendwie mit focus() gelöst, wie man das genau anwendet konnte ich aber nicht rausfinden.

Also obwohl audio etc ja (noch) keinem Standard entspricht, wiehert bei meinem Opera 12.01
bei der Testseite ein Roß, nachdem man bei der Kontrollkonsole den Pfeil anklickert - zumindest
auf dem notebook, wo ich eine Tonausgabe habe.
Das Roß wiehert auch gleich los, wenn ich direkt die URI der Datei aufrufe (OGG-Datei).

Die Standardvariante mit dem Element object ist insofern etwas alltagstauglicher als das aus
einem Arbeitsentwurf stammende und nicht besonders gut durchdachte audio, weil man da
beliebige Alternativen verschachteln kann, notfalls eben auch reinen Text oder einen direkten
Verweis auf die Audio-Datei. Allerdings haben die gängigen Darstellungsprogramme bei
objekt nie die Option implementiert, die einen interaktiven Start ermöglich, die Audio-Datei
legt also gleich los, wenn man da nicht weiter ausholt, während audio so geplant ist, daß man
das Abspielen erst über die Kontrollkonsole explizit starten muß.

Vielleicht ist bei dir ja irgendwo der Ton abgestellt oder du hast Opera so eingestellt, daß
er keine Tonausgabe macht, Interpretation von OGG prinzipiell verboten?

Ich hab Opera deinstalliert und neu runtergeladen, jetzt gehts auch dort, danke für die Hilfe :wink:

kann man halt einfach mit js steuern und generieren, ich hoffe mal, dass das noch Standard wird.

Jetzt brauche ich nur noch eine Lösung für das zweite Problem.

Es ist ein neues Problem aufgetaucht. Wenn ich die Datei mit dem audio-Tag hochlade, funktioniert es überall, ausser im IE. Offline geht es im IE, ich habe die Seite zum testen noch auf den Server einer anderen Page (nicht bei bplaced) hochgeladen, dort gehts ebenfalls.

Der benutzte Testcode: (im IE sieht man nur den Text)

[code]

Your browser does not support the audio element. [/code]

Kann man das Problem irgendwie umgehen, damit der Ton auf bplaced auch im IE funktioniert?

Anders als bei object, was eben gut durchdachte Rückfallmechanismen hat für den Fall,
daß das Format nicht interpretiert wird, ist der Text in audio nur für die Programme gedacht,
die das Element audio selbst nicht kennen - müssen sie auch nicht, ist ja kein Standard.

Wenn der MSIE also den Text anzeigt (sinnvoller wäre es vielleicht, dort Veweise auf die
Audio-Dateien zu notieren statt irgendwelchen englischen Text, der dem Nutzer ja auch nicht
weiterhilft), kennt er das Element audio selbst nicht, unabhängig davon, was da für Formate
verwendet werden.

Wenn der MSIE das Element wirklich plötzlich kennt, wenn der Kram auf andere Seiten
hochgeladen wird, ist das zunächst mal erstaunlich, weil es da keinen Zusammenhang gibt.
Es muß in dem Falle also irgendetwas anderes anders sein - man könnte zum Beispiel
gucken, ob die server den gleichen Inhaltstyp senden und dann gegebenenfalls diesen
anpassen (PHP oder .htaccess). Ist der Dateiinhalt wirklich derselbe? Könnte bei einem
Unterschied besonders im Kopfbereich ja auch sein, daß der MSIE irgendwo in den
Quirksmodus umschaltet, in dem er das Element dann eben kennt oder auch nicht mehr kennt.

Könntest natürlich auch mal gucken, ob die MP3-Datei wirklich den angegebenen
Dateinamen hat, denn microsoftware kann z.B. Groß- und Kleinschreibung nicht
auseinanderhalten. Wähend das auf deinem lokalen Rechner dazu führen kann, daß ein
Fehler beim Dateinamen übersehen wird, findet der server natürlich nicht existierende
Dateien nicht, server auf Basis von microsoftware mögen hingegen den gleichen Fehler
haben wie der Rest von denen, wodurch sie Unterschiede bei der Groß- und Kleinschreibung
ignorieren.
An sich sollte das jedenfalls nicht dazu führen, daß der MSIE deswegen den Text anzeigt,
vielleicht ist das nicht standardisierte audio dort aber auch nicht so implementiert, wie im
Arbeitsentwurf vorgeschlagen, da kann der MSIE natürlich machen, was er will, das Element
ist ja erst in einer Testphase, wo herumprobiert werden kann.

Wie man sieht, gibt es bei nicht standardisierten Elementen viel Spielraum für Spekulationen,
man ist eben effektiv als Autor dabei, Testarbeit für die browser-Anbieter zu leisten ;o)

Am Dateinamen liegts nicht. Wenn der falsch sein sollte, wird der Player trotzdem angezeigt, aber mit ner Fehlermeldung.

Hier mal die Links zu den Testseiten:

Und wie schon gesagt, bei xampp gehts auch.
Wie man einen Inhaltstyp analysiert weiss ich nicht, .htaccess hab ich bisher immer nur für 404er gebraucht.

EDIT: Problem gefunden, bei bplaced wechselt der IE automatisch in den Kompatibilitätsmodus. An was kann das liegen und warum macht er das bei anderen Hostern nicht?

Tja abgesehen vom zusätzlichen java-script bei dem zweiten Beispiel sehe ich da auch keinen
relevanten Unterschied, das bedeutet, beide Beispiele sind inhaltlich unsinnig - audio etc gibt es
nicht in XHTML1.1, dieses sollte man ferner als application/xhtml+xml ausliefern, nicht als
text/html.
Wenn man das tut, werden neuere MSIEs das auch nie im Quirksmodus interpretieren,
ältere auch nicht (die verlangen dann allerdings nach einem anderen Programm zu Anzeige).
Alt text/html wird der Inhalt zwangsläufig immer als fehlerhaftes Zeug interpretiert, nicht aber
notwendig im Quirksmodus - der MSIE kann besonders bei XHTML1.1 komplexe Regeln
haben, weil das eigentlich gar nifcht als text/html auftauchen sollte. Wenn man das macht,
ist das allenfalls eine Notfallbehandlung des MSIE, wo man sich nie drauf verlassen sollte,
das irgendwas einen Sinn ergibt, was nach Erscheinen des MSIE 5 irgendwo entwickelt
oder korrigiert wurde.

Da audio etc zu keinem (X)HTML-Standard gehört, sollte man da ganz sicher keine DTD für
irgendeinen definierten Standard hinschreiben - keine DTD für HTML oder XHTML enthält so
ein Element. Der Arbeitsentwurf für HTML5 schlägt ja so einen verballhornten Doctype vor, der
im Wesentlichen leer ist und jegliche Zugehörigkeit zu irgendeiner Version von (X)HTML
verschweigt - vielleicht geht es ja damit einheitlicher - im Trüben und Unkonkreten zu fischen,
liegt microsoft doch eigentlich ganz gut ;o) Zumindest kann man formal nicht angeben,
daß man ein HTML5-Dokument hat, man kann nur gezielt leugnen, daß man überhaupt ein
irgendwie definiertes (X)HTML verwendet - was dann natürlich auch beliebig interpretierbar ist,
unter anderem nach den Vorschlägen gemäß dem HTML5-Entwurf.
Mag sein, daß der MSIE besonders bei XHTML1.1 Probleme mit seiner Umschaltung des
HTML-Markierungssuppen-parsers hat, was dann von nicht sofort erkennbaren Merkmalen
abhängig sein kann - man guckt ja nicht rein, was die da verprogrammiert hat, um die
Markierungssuppe irgendwie zu interpretieren, kann ja auch vom Mondstand abhängen ;o)

Kurzum - für den Quelltext sicher keinen Doctype von XHTML1.1 verwenden, das ist grober
Unfug, was immer für einen Unfug damit die browser dann anstellen, wenn man das dann auch
noch als text/html versendet ;o)
Das garantiert natürlich nicht, daß es bei dem verballhornten doctype besser klappen wird,
vielleicht steckt ja auch irgendwo ein versteckter BOM oder solch ein Unfug drin, der im MSIE
irgendeine weitere Verwirrung bewirkt.
Jedenfalls zeigt der W3C-Validator bei beiden Varianten die gleichenParameter und Fehler an,
plausibel ist es mal abgesehen vom java-script also nicht, wenn es da ein anderes Verhalten
gibt - kann ich leider nicht testen, weil ich keinen MSIE verfügbar habe.

Danke für den Hinweis, die Doctypes musste ich wirklich noch anpassen, jetzt bekomme ich auch wieder einen grünen Validator.

EDIT: Jetzt klappts, wahrscheinlich ist der IE wegen dem falschen Doctype in den Kompatibilitätsmodus gesprungen. Danke nochmal für deine Hilfe! Ich behalte den Thread noch ein Weilchen im Auge, vielleicht findet noch jemand eine universelle Lösung für das zweite Problem in meinem Anfangspost.