Ich verfolge diese Liste sonst nicht aktiv, nur ein paar Anmerkungen dazu: On Wed, Dec 20, 2017 at 03:34:58PM +0100, Christian Imhorst wrote: > Ich bin da aber leider zu wenig Experte, um das einschätzen zu können, > würde aber auch sagen, > dass HTML5 in diesem Sinn besser ist als JavaScript.
Der Begriff HTML5 ist diesbezüglich leider ein völliger Rohrkrepierer. Die tatsächliche Markup-Spezifikation hat eine Handvoll Features standardisiert, die von Browsern ohnehin schon mehr oder weiniger unterstützt wurden. Am berühmtesten ist dabei das Video-Tag. Vor allem aber erschien HTML5 im Paket mit einer Revision verschiedener Webstandards. Darunter CSS3, SVG und eine (mehr oder minder) einheitliche Spezifikation einer ECMA-Script-API (aka. JavaScript). HTML5 ist damit im Sprachgebrauch zu einem Sammelbegriff von allem geworden, was Browser in den letzten Jahren irgendwie angefangen haben zu unterstützen. Insbesondere ist es eine Entschuldigung geworden Browserseitiges Scripting einzusetzen, weil das ja jetzt "standardisiert" sei. Wenn du heute einen Webdev HTML5 sagen hörst, heißt das häufiger als nicht: "wir werfen da jetzt ganz viel JavaScript drauf". Möglicherweise ist das das Gegenteil von dem was du dir vorstellst. Klar ist dass du an dem Begriff eigentlich garnichts festmachen kannst. Ich empfehle ihn zu vermeiden. > Da Basis "mediaelement.js" denke ich nicht, dass es funktioniert. Wie ich > das sehe, wird JavaScript > für die Steuerung benötigt und für das Flash bzw. Silverlightfallback für > ältere Browser, die kein > HTML5 unterstützen. Wahrscheinlich denken die Entwicker sowas in der Richtung, das ist aber quatsch. Das <video>-Tag ist mit einem Fallback spezifiziert, das in eben den Browsern wirksam wird, die das Tag nicht unterstützen (da unbekannte Tags schon immer quasi wie ein <div> behandelt werden). Darin kann z.B. das breit unterstützte, aber dazumal inoffizielle <embed>-Tag untergebracht werden, oder ein iFrame oder einfach ein Download-Link zum Video - all das geht auch als Kette von Fallbacks, die absolut kein Scripting benötigt. > > * Wie kann ich verschiedene Sprachversionen unterstützen? Bei der > > aktuellen Seite können wir je nach Spracheinstellung der Besucher ein > > unterschiedliches Video einbinden [1]. Binde ich den vorgestellten > > Player ebenfalls einfach per HTML-Snippet ein (bei dem ich ja ggf. den > > Videolink modifizieren kann), oder liegt das in irgendeiner Datei, die > > dynamisch geladen wird? Videodateien und externe Untertitel lassen sich genau so per language negotiation selektieren, wie wir es mit html-Dateien machen. > Könnte man sich anschauen, wenn nicht das eigentliche K.O.-Kriterium käme, > nämlich: > > Ein weiterer Punkt ist natürlich der Aufwand. Schon jetzt sind > > professionell gestaltete Videos ein hoher Kostenaufwand, die Untertitel > > zeitaufwändig für unsere ehrenamtlichen Übersetzer. Zusätzlich bräuchten > > wir ein Video für Gebärdensprache (und gibt es da nicht auch > > verschiedene Sprachen?) sowie eine Tonspur mit Audiodeskription. Richtig. Ist dieser Aufwand geleistet, braucht es allerdings kein JavaScript um verschiedene Varianten zur Auswahl zu stellen. Ich weiß ehrlich nicht was man da Scripten wollen würde, oder warum das Vorteile bringen soll. Wenn die Aktion Mensch natürlich zu einer JavaScript-Klitsche geht und sagt, die sollen ein JavaScript bauen, das dies und jenes macht, nehmen die das Geld. Der Fehler liegt in der Spezifikation. Der Hauptgrund, warum so viele Webseiten JS verwenden um damit das <video>-Tag zu erzeugen, das sie eigentlich gleich hätten in die Seite schreiben können, ist wahrscheinlich, dass sich das im Workflow so ähnlich anfühlt wie damals den Flash-Player einzubinden. Das gepaart mit Copy-und-Paste-Programmierung aus Unwissenheit. Erschwerend kommt hinzu, dass Youtube ja auch JavaScript zur Video-Einbettung benutzt, auch im sogenannten HTML5-Player. Der interessierte Beobachter kommt dann schnell auf die Idee, dass das so sein muss. Eigentlich macht Youtube das aber nur aus DRM-Gründen. Meine Erfahrung ist, dass man dieser Unwissenheit meist mit wenig Aufwand abhelfen kann. Webdevs verstehen die Problematik, wenn man sie anspricht, und sind schnell bereit auch aus einer anderen Quelle zu Copy-Pasten. -- Paul Hänsch █▉ Webmaster, System-Hacker █▉█▉█▉ Jabber: p...@jabber.fsfe.org ▉▉ Free Software Foundation Europe
signature.asc
Description: PGP signature
_______________________________________________ FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de