nicht angemeldet molily
molily
Tim Tepaße
Tim Tepaße
Tim Tepaße
Gunnar Bittersmann
Tim Tepaße
Gunnar Bittersmann
molily
Gunnar Bittersmann
molily
molily
Tim Tepaße
Hi,
FF-3.1-Beta
Da ist die rede von neuen Tags: Video und Audio.
Besitzen diese Elemente besondere Möglichkeiten?
Ist das nur FF-spezifisch oder generell?
Mike
Yerf!
Besitzen diese Elemente besondere Möglichkeiten?
Gegenüber <object>? Ist mir nichts aufgefallen, dafür kann man aber keinen Alternativinhalt mehr angeben...
Ist das nur FF-spezifisch oder generell?
HTML 5
Gruß,
Harlequin
Besitzen diese Elemente besondere Möglichkeiten?
Gegenüber <object>? Ist mir nichts aufgefallen
Sorry, aber was ist dir denn bei der Lektüre der HTML-5-Spezifikation aufgefallen? Überhaupt etwas?
Diese hier offenbar vorherrschende fehlende Bereitschaft, sich vernünftig mit einem Thema auseinanderzusetzen, kotzt mich echt an.
Mathias
dafür kann man aber keinen Alternativinhalt mehr angeben...
Das stimmt so nicht. Natürlich kann man »Alternativinhalt« unterbringen. Nämlich insofern:
»Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browser informing them of how to access the video contents.«
Sprich: Wenn das Video nicht abgespielt werden kann, wird der Alternativinhalt berücksichtigt.
Es ist allerdings nicht Sinn der Sache, dass darin ein zugängliches textuelles Äquivalent, Untertitel und dergleichen untergebracht werden, die z.B. für Blinde/Sehbehinderte oder Taube gedacht sind. Schließlich kann bei denen das Video durchaus in technischer Hinsicht abgespielt werden.
»In particular, this content is not fallback content intended to address accessibility concerns. To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks) into their media streams.«
Sprich, Untertitel sollen in die Ressource selbst eingebunden werden. Bei Formaten wie Ogg ist das m.W. kein Problem. Oder sie sollen sonstwie bereitgestellt werden. Jedenfalls nicht im Video-Element selbst.
Das sind einfach zwei Sachen, die in HTML 5 erstmals getrennt werden.
Mathias
Yerf!
Das stimmt so nicht. Natürlich kann man »Alternativinhalt« unterbringen. Nämlich insofern:
»Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browser informing them of how to access the video contents.«
Ok, da muss ich zugeben, dass ich den Absatz bisher übersehen hab, vielleicht weil der nächste so extra hervorgehoben ist und einem erst einmal das Gegenteil nahelegt.
Sprich: Wenn das Video nicht abgespielt werden kann, wird der Alternativinhalt berücksichtigt.
Es ist allerdings nicht Sinn der Sache, dass darin ein zugängliches textuelles Äquivalent, Untertitel und dergleichen untergebracht werden, die z.B. für Blinde/Sehbehinderte oder Taube gedacht sind. Schließlich kann bei denen das Video durchaus in technischer Hinsicht abgespielt werden.
Mir geht es dabei mehr um technische Aspekte, aus denen das Video nicht dargestellt werden kann. Dann möchte ich dem Besucher einen Hinweis geben können, damit er evtl. später nochmals vorbeischaut, wenn das "Problem" beseitigt ist (er z.B. nicht mehr mit dem PDA sondern einem PC unterwegs ist)
Das sind einfach zwei Sachen, die in HTML 5 erstmals getrennt werden.
Wobei ich bisher aus den Richtlinien für Barrierefreiheit herausgelesen habe, dass man nur eine Ressource für alle bereitstellen sollte, eben mit entsprechenden Fallback-Mechanismen. Aber es gibt sicher auch gute Argumente für eine andere Herangehensweise.
Ich halte halt <object> für einen Leistungsfähigen Ansatz der auch zukünftige Anforderungen problemlos abdecken kann und frage mich, wieso man nicht darauf aufbaut (z.B. durch Standardisierung der <param>s)
Gruß,
Harlequin
Ich halte halt <object> für einen Leistungsfähigen Ansatz der auch zukünftige Anforderungen problemlos abdecken kann und frage mich, wieso man nicht darauf aufbaut (z.B. durch Standardisierung der <param>s)
genau das ist die sache, die auch ich nicht verstehe :D
Da ist die rede von neuen Tags: Video und Audio.
eigentlich sinds elemente
Besitzen diese Elemente besondere Möglichkeiten?
Ist das nur FF-spezifisch oder generell?
das ist nur dämlich ausgedrückt - die inhalte werden in html 4.01 und xhtml 1.0 nachwievor über das object-element mit korrektem mime-type eingebunden, können aber vom browser direkt angezeigt werden
lediglich audio, video und canvas sind neue elemente - daran sind aber die html5-entwickler schuld, alsob eine korrekte unterstütztung für object nicht reichen würde, muss man jetzt neben <img /> noch <video /> und <audio /> einführen
Hi,
wenn wir schon beim Erbsenzählen sind....
Da ist die rede von neuen Tags: Video und Audio.
eigentlich sinds elemente
Ich habe es ja auch nicht gesagt sondern auf den Bericht verwiesen, wo es
so ausgedrückt wird.
Besitzen diese Elemente besondere Möglichkeiten?
Wie man sieht benutze ich das Wort: Element
Aber warum ist TAG nicht richtig, denn Selfhtml nennt es ja auch oft so:
"....Tabelle mit sichtbaren Gitternetzlinien durch Angabe von border im einleitenden Tabellen-Tag,..."
Mike
Hi,
Aber warum ist TAG nicht richtig, denn Selfhtml nennt es ja auch oft so:
ja, aber in einem Zusammenhang, in dem es sich auch um einen Tag handelt.
"....Tabelle mit sichtbaren Gitternetzlinien durch Angabe von border im einleitenden Tabellen-Tag,..."
*Einleitender* Tabellen-Tag, also "<table>" - auch als Start-Tag bezeichnet. Der zugehörige End-Tag lautet "</table>". Keiner von beiden ist ein Element. Zusammengenommen inklusive ihrem Inhalt ist es jedoch eines. Als Element wird außerdem das abstrakte Konstrukt bezeichnet, welches unter Zuhilfenahme von Tags konkret ausgeprägt wird.
Cheatah
@@Mike:
Aber warum ist TAG nicht richtig,
↗ Elemente, Tags und Attribute [Meiert]
denn Selfhtml nennt es ja auch oft so:
"....Tabelle mit sichtbaren Gitternetzlinien durch Angabe von border im einleitenden Tabellen-Tag,..."
Hier ist ja auch ein Tag gemeint: Angabe von 'border' (ie. ein 'border'-Attribut) für ein 'table'-Element im einleitenden <table>-Tag
Live long and prosper,
Gunnar
alsob eine korrekte unterstütztung für object nicht reichen würde, muss man jetzt neben <img /> noch <video /> und <audio /> einführen
Kann das Forumspersonal sich nicht mal endlich informieren, bevor es Blödsinn über HTML 5 ablässt? Derartige Ressentiments auf plumpester Ebene scheinen hier echt Mode zu sein.
Lies doch einfach mal HTML 5 und versuche zu erfahren, welchen Zweck sie haben, wie man sie verwenden kann und welche API sie bieten:
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html
Zum Vergleich object:
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html
Eine korrekte Unterstützung von object bietet überhaupt nicht das, was die »media elements« audio und video bieten sollen. object ist einfach unspezifisch und kann keine spezifische API für audiovisuelle Medienwiedergabe bieten. Alle bisherigen APIs waren proprietäre von Plugins wie Windows Media Player, Quicktime und Co.
Mathias
Eine korrekte Unterstützung von object bietet überhaupt nicht das, was die »media elements« audio und video bieten sollen. object ist einfach unspezifisch und kann keine spezifische API für audiovisuelle Medienwiedergabe bieten. Alle bisherigen APIs waren proprietäre von Plugins wie Windows Media Player, Quicktime und Co.
das ist mir klar, aber ernsthaft: was spricht dagegen, das object-element entsprechend aufzuwerten?
was spricht dagegen, die entsprechenden kontrollattribute für das object-elemente hinzuzufügen und je nach mime-type die entsprechende darstellung zu bewirken?
<object type="image/gif" data="foo.gif">
<p>bild</p>
</object>
<object type="video/x-matroska" data="bar.mkv">
<p>video</p>
</object>
<object type="audio/mpeg" data="baz.mp3">
<p>audio</p>
</object>
die lustigen attribute wie autoplay, loopstart usw ließen sich ohne weiteres auch für das object-element hinzufügen
ich bin dir dankbar, wenn du mir erklärst, was der konkrete voreil von 3 verschiedenen elementen mit grundlegend den selben eigenschaften gegenüber EINEM element ist, welches seinen inhalt ohnehin durch die angabe des exakten mime-type spezifiziert
auf welche gestörten ideen kommen die noch? <pdf printsize="a5" /> oder sonstwas?
Yerf!
das ist mir klar, aber ernsthaft: was spricht dagegen, das object-element entsprechend aufzuwerten?
Das ist es, was ich mich auch frage. Die verlinkten HTML 5-Specs liefern mir da leider keine Antwort darauf.
die lustigen attribute wie autoplay, loopstart usw ließen sich ohne weiteres auch für das object-element hinzufügen
Und zwar schön als <param>, mit der Möglichkeit plugin-spezifische Angaben ebenfalls zuzulassen.
auf welche gestörten ideen kommen die noch? <pdf printsize="a5" /> oder sonstwas?
Sag das nicht zu laut, sonst hauen gleich noch mehr auf dich ein...
Gruß,
Harlequin
die lustigen attribute wie autoplay, loopstart usw ließen sich ohne weiteres auch für das object-element hinzufügen
Jein, dann müsste man Interfaces in Abhängigkeit vom MIME-Typ der verlinkten Ressource definieren. Aber wieso sollte object ein poster-Attribut bekommen, nur für den Fall, dass *auch* Videos abgespielt werden können. Gut, input hat auch ein checked-Attribut, selbst wenn es bei type=text keinen Sinn macht. Ich halte es für sauberer, ein Interface HTMLMediaElement zu definieren, was *immer* von einem Element implementiert wird, nicht abhängig vom MIME-Typ der Ressource.
Mathias
Jein, dann müsste man Interfaces in Abhängigkeit vom MIME-Typ der verlinkten Ressource definieren.
soweit ich das verstanden habe, funktioniert das jetzt aber auch einwandfrei
wenn ich jetzt object-element verwende und dort (wie im beispiel) ein matroska-video einbinde, wird der browser dies nich darstellen können - dafür brauch ich jetzt ein plugin - wo der unterschied zwischen einem integrierten player oder einem plugin ist, hab ich nicht verstanden
flash kann der browser doch auch nicht nativ darstellen und sobald etwas mit application/x-shockwave-flash daherkommt, springt das flashpugin an - wenn der browser - ist doch beim svg-viewer genauso, browser kanns nicht -> plugin und wenns der browser nativ kann, stellt ers halt dar
Aber wieso sollte object ein poster-Attribut bekommen, nur für den Fall, dass *auch* Videos abgespielt werden können.
das attribut ist doch optional - object hat auch ein width- und ein height-attribut, welches ich nicht zwingend angeben muss - ich verstehe die problematik nicht, wenn man einfach für alles defaultwerte setzt passt das doch
wenn ich jetzt object-element verwende und dort (wie im beispiel) ein matroska-video einbinde, wird der browser dies nich darstellen können - dafür brauch ich jetzt ein plugin - wo der unterschied zwischen einem integrierten player oder einem plugin ist, hab ich nicht verstanden
Da ist kein Unterschied. Dem Seitenautor soll es eben egal sein, wer letztlich das Video abspielt, ob das eine Browserkomponente ist, ein NPAPI-Plugin oder eine ActiveX-Control. Entscheidend ist nur, dass für den Autor eben diese standardisierte API zur Verfügung steht, d.h. diese standardisierte Möglichkeit der Einbettung, diese Art des Scripting-Interfaces.
flash kann der browser doch auch nicht nativ darstellen und sobald etwas mit application/x-shockwave-flash daherkommt, springt das flashpugin an - wenn der browser - ist doch beim svg-viewer genauso, browser kanns nicht -> plugin und wenns der browser nativ kann, stellt ers halt dar
Das klappt heutzutage aber nicht wirklich. Vielleicht bei Flash zufällig, aber andere offene Formate kann man nicht einfach so mit ihrem allgemeinen MIME-Typ einbinden, sondern muss immer einen bestimmten Player aufrufen, mit spezifischen params usw. ansprechen.
Mathias
wenn ich jetzt object-element verwende und dort (wie im beispiel) ein matroska-video einbinde, wird der browser dies nich darstellen können - dafür brauch ich jetzt ein plugin - wo der unterschied zwischen einem integrierten player oder einem plugin ist, hab ich nicht verstanden
Da ist kein Unterschied. Dem Seitenautor soll es eben egal sein, wer letztlich das Video abspielt, ob das eine Browserkomponente ist, ein NPAPI-Plugin oder eine ActiveX-Control. Entscheidend ist nur, dass für den Autor eben diese standardisierte API zur Verfügung steht, d.h. diese standardisierte Möglichkeit der Einbettung, diese Art des Scripting-Interfaces.
Wer implementiert die standardisierte API? Bisher sind ja die Pluginhersteller zuständig für APIs zu ihren Plugins. Eine Lösung wäre dann wohl, dass entweder die Browser einfach die API implementieren und dabei auf die Schnittstelle des Plugins zugreifen (eine Funktion "play" würde also auf die entsprechende Funktion des Plugins zugreifen) oder die Plugin-Hersteller müssen ihre Schnittstellen ändern. Ersteres hat den Nachteil, dass dem Browser das Plugin quasi bekannt sein muss, bei der zweiten Variante brauche ich kein video- oder audio-Element, eine Vereinheitlichung könnte auch so herbeigeführt werden.
Wie ist das eigentlich mit Plugins, die nicht in dieses Schema passen (PDF und Flash fallen mir da sofort ein)? Stellen die dann weiterhin eigene Schnittstellen zur Verfügung und führen das Ganze wieder ad absurdum? Wenn eigene Schnittstellen möglich sind, können die Hersteller von Video- und Audioplugins ebenfalls wieder eigene bereitstellen bzw. sie einfach so lassen, wie sie jetzt sind. Ich sehe durchaus die Idee hinter diesen neuen Elementen, aber halte sie für den falschen Weg und für unzureichend.
Wer implementiert die standardisierte API?
Anscheinend sind das bisher die Browserhersteller direkt unter Verwendung offener Bibliotheken. Aber ich habe mir die Implementierungen noch nicht angesehen.
bei der zweiten Variante brauche ich kein video- oder audio-Element, eine Vereinheitlichung könnte auch so herbeigeführt werden.
Ich kann es nachvollziehen, dass man einen sauberen Schnitt machen will. Mit dem object-Element habe ich tausende verschiedene proprietäre APIs, von denen sicher viele Sachen wie play() und pause() bieten, da kann man nicht noch konfliktlos eine weitere drüberlegen. Das erlaubt keine Abwärtskompatibilität, was eben ein Ziel von HTML 5 ist.
Wie ist das eigentlich mit Plugins, die nicht in dieses Schema passen (PDF und Flash fallen mir da sofort ein)? Stellen die dann weiterhin eigene Schnittstellen zur Verfügung und führen das Ganze wieder ad absurdum?
PDF hat wohl mit audio und video wenig zu tun, wenn das Flash-Plugin Abspieler für video- und audio-Elemente werden will, was ja in begrenztem Maße möglich wäre, müsste es natürlich die entsprechende API bereitstellen (wahrscheinlich könnte man die sogar in ActionScript implementieren - mal sehen, was sich da tut).
Wenn eigene Schnittstellen möglich sind, können die Hersteller von Video- und Audioplugins ebenfalls wieder eigene bereitstellen bzw. sie einfach so lassen, wie sie jetzt sind.
Möglich sind sie weiterhin bei object und embed.
Mathias
Hi,
Jein, dann müsste man Interfaces in Abhängigkeit vom MIME-Typ der verlinkten Ressource definieren.
was, nebenbei bemerkt, *extrem* schlechtes Interface-Design wäre.
Aber wieso sollte object ein poster-Attribut bekommen, nur für den Fall, dass *auch* Videos abgespielt werden können. Gut, input hat auch ein checked-Attribut, selbst wenn es bei type=text keinen Sinn macht.
Bei XForms ist dieses Problem dann gelöst. HTML ist historisch gewachsen - ich finde es gut, wenn ab und zu die Anfangs- und Anfängerfehler behoben werden.
Ich halte es für sauberer, ein Interface HTMLMediaElement zu definieren, was *immer* von einem Element implementiert wird, nicht abhängig vom MIME-Typ der Ressource.
Definitiv.
Cheatah
Ich halte es für sauberer, ein Interface HTMLMediaElement zu definieren, was *immer* von einem Element implementiert wird, nicht abhängig vom MIME-Typ der Ressource.
Definitiv.
wie schon erwähnt verstehe ich das nicht, da bisher auch abhängig vom mime-typ vom browser entscheiden wird, was damit gemacht wird und an welches plugin oder "interface" er das weiterzugeben hat
kommt etwas mit text/html daher, wirds gerendert - application/pdf wird ans pdf-plugin weitergereicht oder zum herunterladen angeboten
ich versteh die argumentation immer noch nicht
Hallo Suit,
wie schon erwähnt verstehe ich das nicht, da bisher auch abhängig vom mime-typ vom browser entscheiden wird, was damit gemacht wird und an welches plugin oder "interface" er das weiterzugeben hat
Es geht hier nicht darum, wie Resourcen anhand ihres MIME Medien Typs verarbeitet werden. Es geht darum, wie in einer HTML/XHTML Resource die textuelle Darstellung eines Elementes in ein DOM-Objekt im Arbeitsspeicher verwandelt wird. Und dort wird seit DOM 1 für HTML und anderen DOMs immer das Element selber als Indikator für das entsprechende DOM-Objekt und dessen implementierte Interfaces genommen. Nicht anhand von Werten in dessen Attributen, nicht anhand von Kindelementen.
Tim
Und dort wird seit DOM 1 für HTML und anderen DOMs immer das Element selber als Indikator für das entsprechende DOM-Objekt und dessen implementierte Interfaces genommen. Nicht anhand von Werten in dessen Attributen, nicht anhand von Kindelementen.
ich weiss nicht, ob mir das klar ist - darum versteh ichs eben nicht
bei einem object-element wird anhand des mime-type sehrwohl unterschieden, wie es dargestellt wird - ein pdf, ein flash oder ein png wird unterschiedlich behandelt (sogar von unterschiedlichen plugins), obwohl das element immer gleich ist
Hallo,
bei einem object-element wird anhand des mime-type sehrwohl unterschieden, wie es dargestellt wird - ein pdf, ein flash oder ein png wird unterschiedlich behandelt (sogar von unterschiedlichen plugins), obwohl das element immer gleich ist
Im DOM ist es aber immer ein HTMLObjectElement.
Tim
Hi!
bei einem object-element wird anhand des mime-type sehrwohl unterschieden, wie es dargestellt wird - ein pdf, ein flash oder ein png wird unterschiedlich behandelt (sogar von unterschiedlichen plugins), obwohl das element immer gleich ist
Im DOM ist es aber immer ein HTMLObjectElement.
Ja, was sollte es denn sonst sein?
Diesen Einwand verstehe ich jetzt nicht.
off:PP
Hallo,
Im DOM ist es aber immer ein HTMLObjectElement.
Ja, was sollte es denn sonst sein?
Ein HTMLMediaElement. Oder genauer ein HTMLVideoElement. Oder ein HTMLAudioElement. Oder ein HTMLImageElement. Natürlich sind dies alles Interfaces, aber bei größerer Interface-Zusammenfassung kommt dann ein Frankenstein'sches Monster heraus.
Tim
Hi!
Im DOM ist es aber immer ein HTMLObjectElement.
Ja, was sollte es denn sonst sein?
Ein HTMLMediaElement. Oder genauer ein HTMLVideoElement. Oder ein HTMLAudioElement. Oder ein HTMLImageElement. Natürlich sind dies alles Interfaces, aber bei größerer Interface-Zusammenfassung kommt dann ein Frankenstein'sches Monster heraus.
Ja, kenne ich nur verstehe ich Deinen Punkt jetzt noch weniger als vorher: bist Du für oder gegen die Einführung dieser Elemente?
Ich mag ja auf dem Schlauch stehen ... aber was spricht gegen suits Argumentation es bei einem object-element zu belassen?
off:PP
Ich mag ja auf dem Schlauch stehen ... aber was spricht gegen suits Argumentation es bei einem object-element zu belassen?
das konnte mir bisher auch noch niemand schlüssig erklären - es kommt immer nur die "dom-keule" die ich noch weniger verstehe
ich kann zb überhaupt nicht nachvollziehen, wo das problem liegt, wenn man das den attributknoten "type" eines "HTMLObjectElement" ausliest und entsprechend auswertet - warum muss der elementtyp selbst schon der richtige sein?
Hallo suit,
das ist mir klar, aber ernsthaft: was spricht dagegen, das object-element entsprechend aufzuwerten?
Das object-Element ist über ein Jahrzehnt alt und es gibt immer noch Probleme in der Interoperabilität unter verschiedenen Browsern. Angefangen bei dem ActiveX-classid-Quark bis hin zu anderen Problemen wie der Größe. Die Browserhersteller mögen <object> ganz und gar nicht und das aus Gründen. Deswegen wurde u.a. stark auf Wünschen der Browserhersteller (die Initialvorschläge kamen von Opera und Apple) eingehend entschieden mit speziellen Elementen voranzugehen.
die lustigen attribute wie autoplay, loopstart usw ließen sich ohne weiteres auch für das object-element hinzufügen
Warum nicht gleich ein generelles <element>? Plus siehe die DOM-Problematik.
ich bin dir dankbar, wenn du mir erklärst, was der konkrete voreil von 3 verschiedenen elementen mit grundlegend den selben eigenschaften gegenüber EINEM element ist ...
Für mich ist der Hauptvorteil schon die geringere kognitive Last für den Autor. Kannst Du aus dem Kopf die „korrekte“ Schreibweise für ein browserübergreifendes videotragendes object hinkriegen? Rezitierst Du Class-IDs im Schlaf?
Tim
Für mich ist der Hauptvorteil schon die geringere kognitive Last für den Autor. Kannst Du aus dem Kopf die „korrekte“ Schreibweise für ein browserübergreifendes videotragendes object hinkriegen? Rezitierst Du Class-IDs im Schlaf?
diesen class-id scheissendreck braucht man ja, bei einer korrekten standardisierung nicht ;) bei pdf und flash funzts ja auch einwandfrei
@@Tim Tepaße:
Warum nicht gleich ein generelles <element>?
Eben.
“In XHTML 2 _any_ element may have a src attribute, which specifies a resource (such as an image) to load instead of the element.” [XHTML2 §1.2]
Für mich ist der Hauptvorteil schon die geringere kognitive Last für den Autor.
XHTML 2 verringert die kognitive Last für den Autor erheblich: eine einheitliche Schreibweise für alles.
Live long and prosper,
Gunnar
Hallo,
XHTML 2 verringert die kognitive Last für den Autor erheblich: eine einheitliche Schreibweise für alles.
Ich finde die kognitive Last sehr viel größer wegen des mangelnden Zusammenhangs zwischen Elementname und DOM-Interfaces. Das DOM mit zu spezifizieren ist meines Erachtens eine der größten Stärken von HTML 5 und eine ziemliche Schwäche von XHTML 2.
Tim
@@Tim Tepaße:
XHTML 2 verringert die kognitive Last für den Autor erheblich: eine einheitliche Schreibweise für alles.
Ich finde die kognitive Last sehr viel größer wegen des mangelnden Zusammenhangs zwischen Elementname und DOM-Interfaces.
Mit Autor meinte ich in dem Zusammenhang XHTML-Autor. Was hat ein solcher mit dem DOM-Interface zu schaffen?
Nichts.
Es sei denn, er ist gleichzeitig auch Programmierer und nicht schizophren genug, beides voneinander zu trennen.
Live long and prosper,
Gunnar
Mit Autor meinte ich in dem Zusammenhang XHTML-Autor. Was hat ein solcher mit dem DOM-Interface zu schaffen?
Häh? Die ganze Existenz von HTML 5 basiert darauf, dass es den Autor interessiert, nämlich darin bestehen die meisten Innovationen. Wen es nicht interessiert, kann gerne bei object bleiben, irgendwelche Plugins mit params ansteuern und sich um den Rest keine Gedanken machen.
Mathias
@@molily:
Mit Autor meinte ich in dem Zusammenhang XHTML-Autor. Was hat ein solcher mit dem DOM-Interface zu schaffen?
Häh? Die ganze Existenz von HTML 5 basiert darauf, dass es den Autor interessiert, nämlich darin bestehen die meisten Innovationen.
Häh? Ich glaub nicht, dass ich dir was übers Schichtenmodell erzählen muss – über die Trennung von Struktur und Verhalten. Das kannst du bei Bedarf hier und dort nachlesen. >;-)
Es mag ja Fälle geben, wo HTML-/CSS-Autor, JavaScript-Programmierer, Backend-Programmierer und Webserver-Administrator in Personalunion zusammenfallen; gegeben ist das nicht. Also dröseln wir das mal auf.
Warum sollte einen HTML-Autor, der ausschließlich auf der Strukturebene arbeitet, das DOM-Interface interesieren? Er will die Inhalte eine Dokuments strukturell auszeichnen, sonst nichts.
Wenn also die Seitenüberschrift ein animiertes Firmenlogo ist (wie bspw. bei arTec Berlin), dann ist dieses Markup angebracht:
<h1 src="http://example.com/logo">example dot com</h1>
Den HTML-Autor sollte es nicht einmal interessieren, ob sich hinter der Ressource http://example.com/logo ein animiertes GIF oder ein Flash-Filmchen verbirgt. Und schon gar nicht, was der Browser anstellt, um die Animation darzustellen. Das ist allein Sache des Browsers, die er bitteschön anhand des Content-Types im HTTP-Header der Ressource zu regeln hat – ohne Zutun des Autors ('type'-Attribut oder dergleichen).
AFAIS scheint sich HTML 5 darauf zu konzentrieren, es Browsern leichter zu machen (stecken ja auch Browserentwickler dahinter). Ein Webseitenautor soll also mit einem animiertem GIF anders umgehen müssen als mit einem Flash-Filmchen? Anstatt die Technik den Bedürfnissen des Menschen anzupassen, soll sich der Mensch den Bedürfnissen der Technik anpassen? Das ist absurd.
Live long and prosper,
Gunnar
Yerf!
<h1 src="http://example.com/logo">example dot com</h1>Den HTML-Autor sollte es nicht einmal interessieren, ob sich hinter der Ressource http://example.com/logo ein animiertes GIF oder ein Flash-Filmchen verbirgt. Und schon gar nicht, was der Browser anstellt, um die Animation darzustellen. Das ist allein Sache des Browsers, die er bitteschön anhand des Content-Types im HTTP-Header der Ressource zu regeln hat – ohne Zutun des Autors ('type'-Attribut oder dergleichen).
Das wäre natürlich die schönste Lösung. Und die Attribute, die bei HTML5 für das Video-Element definiert wurden sind ja auch eher auf die Darstellung bezogen und gehören damit eigentlich ins CSS.
AFAIS scheint sich HTML 5 darauf zu konzentrieren, es Browsern leichter zu machen (stecken ja auch Browserentwickler dahinter). Ein Webseitenautor soll also mit einem animiertem GIF anders umgehen müssen als mit einem Flash-Filmchen? Anstatt die Technik den Bedürfnissen des Menschen anzupassen, soll sich der Mensch den Bedürfnissen der Technik anpassen? Das ist absurd.
Das ist leider auch der Eindruck, den ich beim lesen der HTML5 Mailingliste gewonnen hab...
Gruß,
Harlequin
Den HTML-Autor sollte es nicht einmal interessieren, ob sich hinter der Ressource http://example.com/logo ein animiertes GIF oder ein Flash-Filmchen verbirgt. Und schon gar nicht, was der Browser anstellt, um die Animation darzustellen.
Freilich gibt es viele Fälle, wo ich einfach nur die URI angeben könnte und den Rest dem Browser überlassen kann. Da mag eine solche Vereinfachung und Zentralisierung seinen Sinn haben. Das haut bei dem Beispiel hin, wenn man den Flash-Player wie bloße passive Darstellungsmodule wie libpng und Co. betrachtet. Nun ist ein Flash aber nicht bloß eine stumpfe Animation, sondern oftmals eine eigene Anwendung. Und noch weniger ist ein Video etwas, dessen Abspielen der Autor nicht steuern will. Was XHTML 2 nicht bedenkt bzw. kategorisch in DOM-Standards auslagern wollte, ist eben diese Schnittstelle zwischen den an der Dokumentdarstellung beteiligten Ressourcen. Natürlich nimmt HTML 5 ebenso eine einseitige Position ein, es geht vornehmlich um HTML-Dokumente als »Applications«.
AFAIS scheint sich HTML 5 darauf zu konzentrieren, es Browsern leichter zu machen (stecken ja auch Browserentwickler dahinter).
Das ist die Philosophie der Abwärtskompatibilität, die keine von Grund auf neue Sprache designt.
Ein Webseitenautor soll also mit einem animiertem GIF anders umgehen müssen als mit einem Flash-Filmchen? Anstatt die Technik den Bedürfnissen des Menschen anzupassen, soll sich der Mensch den Bedürfnissen der Technik anpassen?
Ideal ist das sicherlich nicht, weil es einfaches nicht unbedingt einfach macht. Aber es ist bei diesen HTML-Zusätzen qua ihrer Natur nicht möglich, in das bestehende HTML eine saubere Struktur hineinzubringen.
Mathias
Nun ist ein Flash aber nicht bloß eine stumpfe Animation, sondern oftmals eine eigene Anwendung. Und noch weniger ist ein Video etwas, dessen Abspielen der Autor nicht steuern will.
das argument verstehe ich wieder nicht - wenn jeder darzustellende mime-type ein eigenes, konfigurierbares (meinetwegen mit dem browser mitgeliefertes) plugin erhält, ist das doch kein problem
ja ich weiss, der flashplayer ist ein schlechtes beispiel - aber ein flash läuft auch einfach mal so los, ich als benutzer kann aber dennoch mein plugin so konfigurieren, dass das nicht passiert - ich kann die vergrößerungsstufe und die qualität bestimmen
warum sollte ein ähnliches verhalten nicht bei jedem anderen element auch funktionieren?
standardverhalten bei videos könnte ich mir so vorstellen:
* abspielverhalnte
- nach webseitenautorenvorabe richten (default)
- abspielen, dann stop
- abspielen in schleife
- pausiert beginnen aber bereites cachen
- pausieren, nicht cachen
* werkzeuge
- nach webseitenautorenvorabe richten (default)
- immer einblenden
- immer ausblenden
- einbleden beim darüberfahren
usw - ich sehe kein problem, welches sich durch ordentlich nachdenken und dann machen nicht lösen ließe
früher wurde vom seitenautor bestimmt, ob ein neues fenster geöffent wird oder nicht - jetzt interessiert sich mein browser einen scheissdreck dafür wenn ich das so einstelle und nimmt nur meine bevorzugten einstellungen
selbriges MUSS bei jedem anderen verhalten auch möglich sein
XHTML 2 verringert die kognitive Last für den Autor erheblich: eine einheitliche Schreibweise für alles.
Ach, wie kommt man vom Hölzchen (HTML 5) aufs Stöckchen (XHTML 2)?
Letzteres bietet keine Möglichkeit, aus HTML heraus das Einbinden irgendwie zu steuern. One attribute, no API to rule them all. Insofern kann man das src-Attribut in XHTML 2 wirklich nicht gegen video und audio ausspielen.
Mathias
Hi there,
das ist mir klar, aber ernsthaft: was spricht dagegen, das object-element entsprechend aufzuwerten?
Was spricht dafür? Hier wird ständig etwas von semantisch richtigem Markup gelabbert und jeder gesteinigt, der bspw. anstelle von <h1> eine Konstruktion <div id="UEBERSCHRIFT"> verwendet. (Zurecht, dafür ist es ja schliesslich da). Was also spricht dagegen, daß man die Dinge beim Namen nennt und sie als das auszeichnet, was sie einmal sind?
@@Klawischnigg:
Hier wird ständig etwas von semantisch richtigem Markup gelabbert und jeder gesteinigt, der bspw. anstelle von <h1> eine Konstruktion <div id="UEBERSCHRIFT"> verwendet. (Zurecht, dafür ist es ja schliesslich da). Was also spricht dagegen, daß man die Dinge beim Namen nennt und sie als das auszeichnet, was sie einmal sind?
Eben. Ein animiertes Firmenlogo ist eine Überschrift, kein Video. Man sollte es als das auszeichnen, was es nun einmal ist:
<h1 src="http://example.com/logo">example dot com</h1>
↗ https://forum.selfhtml.org/?t=178129&m=1174507
Live long and prosper,
Gunnar
Hi,
Da ist die rede von neuen Tags: Video und Audio.
Besitzen diese Elemente besondere Möglichkeiten?
Ist das nur FF-spezifisch oder generell?
sie sind wohl dem noch entstehendem HTML/5.0 entlehnt.
Cheatah
Hallo,
Ist das nur FF-spezifisch oder generell?
Webkit/Safari unterstützen das schon seit einiger Zeit. Opera hat wohl interne Builds mit der Unterstützung und plant in näherer Zukunft es auch zu veröffentlichen.
Tim