W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

[Bug 13359] <track> A way is needed to identify the type of data in a track element

From: <bugzilla@jessica.w3.org>
Date: Sun, 09 Sep 2012 01:30:43 +0000
Message-Id: <E1TAWMF-0007sx-Jp@jessica.w3.org>
To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13359

--- Comment #67 from Glenn Adams <glenn@skynav.com> 2012-09-09 01:30:42 UTC ---
(In reply to comment #66)
> (In reply to comment #65)
> > If all the page generator (human author or otherwise) has is the URL to the
> > content then how will it know the type of content?
> 
> That's what mime types are for.

Mime type metadata is merely a hint. Only the decoder of the data (in this case
the UA) can determine the actual type.

> 
> > > If the author doesn't know the media type/can't find out through probing, why
> > > would the browser get it right?
> > 
> > The browser has access to the content-type when it tries to play the content,
> > right?
> 
> The JS developer has that access, too, via the getResponseHeader() function,
> see http://www.w3.org/TR/XMLHttpRequest/#the-getresponseheader-method .

That doesn't work when track data is embedded in a container format that
doesn't expose metadata about its component content. It also doesn't work when
you aren't using XHR, and it doesn't work if you are using XHR and the response
doesn't match the actual type.

> Is that sufficient or do you have a use case beyond this?

Track data embedded in the user private data of a MPEG-2 TS.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Sunday, 9 September 2012 01:30:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 9 September 2012 01:30:47 GMT