W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2011

Re: [media] issue-152: documents for further discussion

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 18 May 2011 11:35:51 +1000
Message-ID: <BANLkTik6yKVBW7aOtBmcotR5RGP6szpodw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:38 GMT