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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13359

--- Comment #9 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-08-20 13:07:50 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > (In reply to comment #4)
> > > > > (In reply to comment #3)
> > > > > To expand, consider 3rd party P adding three in-band signaling tracks: IB1 -
> > > > > content advisories for parental control, IB2 - SCTE35 segment descriptors for
> > > > > targeted advertising and IB3 - EISS for interactive television. The user agent
> > > > > executing Page O recognizes these in-band tracks and sources them as three
> > > > > different track elements with kind = metadata as described in [1]. Since the
> > > > > user agent knows how to recognize these in-band tracks it can inform JS of the
> > > > > metadata type by a new TextTrack.type IDL attribute. Without this new
> > > > > attribute, JS will have to contain logic to infer the metadata type, redoing
> > > > > what the UA has already done.
> > > > 
> > > > How would a general-purpose UA (such as Opera, Chrome, Safari or Firefox)
> > > > recognize IB1, IB2, and IB3? They are not specified in HTML so there is no
> > > > requirement for them to be able to decode them and I haven't seen any moves
> > > > that spans across these and other UAs to make IB1-3 a standard-supported format
> > > > in them. If there is, then it would make a lot more sense to have actual
> > > > kind=IB1-3 values as part of the spec IMHO.
> > > 
> > > There is no requirement that an HTML5 UA decode PNG files, JPEG files, MPEG
> > > video, or even JavaScript or CSS for that matter. So what's the point of your
> > > question?
> > 
> > There is also no field in HTML that provides a hint on which image file format
> > is being used. Why would there need to be one that hints on which metadata
> > format is being used?
> 
> Because we are not talking about the UA interpreting the metadata here, we are
> talking about client JS interpreting the metadata (track). The utility of
> TextTrackCue.getCueAsSource() is put in question unless some information is
> provided on type. The alternative is that the JS client code must perform
> content sniffing on the result of getCueAsSource().


Why not just use a data-type attribute that provides this information?
JS-interpreted data is what the data-* attributes are made for.



> Also, I believe the request here is not for a markup supplied hint of type, but
> a UA determined actual type (presuming the UA has an embedded sniffer or access
> to other content type metadata in the transport or content) in order to supply
> actual type information via an IDL attribute.


"it is proposed that a @type attribute be added to the track element and an
associated IDL attribute be added to the TextTrack interface" - that's a
request for a content attribute IIUC.

-- 
Configure bugmail: http://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 Saturday, 20 August 2011 13:07:55 UTC