- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 18 May 2011 11:35:51 +1000
- To: Bob Lund <B.Lund@cablelabs.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>, Eric Winkelman <E.Winkelman@cablelabs.com>, David Agranoff <d.agranoff@cablelabs.com>
On Wed, May 18, 2011 at 12:44 AM, Bob Lund <B.Lund@cablelabs.com> wrote: > Hi Silvia, > > I had considered @data- attributes but was unsure of the implications of this statement in section 3.2.3.8 of the current HTML5 spec (http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data-with-the-data-attributes): > > "User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values." > > In the case of in-band tracks, the user agent will have to create the DOM equivalent of the @data- attribute for metadata tracks. This appeared to me as being in conflict with the second sentence of the above quote. Is this not the case? Where would a UA get the information about the special track type from from in-band metadata tracks? Do you know fields in MP4, Ogg and WebM that provide such information? If there is such a field that you need exposed on top of what is already there, then it would indeed make sense to include that. But I honestly doubt that you will find in-band tracks that will tell you that they contain adinsertion information or syncwebcontent data. This is all very application-specific and therefore can only be solved with external text tracks IMHO. Always open to hear a real-world use case though! Cheers, Silvia.
Received on Wednesday, 18 May 2011 01:36:39 UTC