W3C home > Mailing lists > Public > public-texttracks@w3.org > April 2012

Re: [RFC] WebM temporal metadata

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 9 Apr 2012 23:11:05 -0500
Message-ID: <CABirCh_EfihTfDb3m9FWYC95p=Cqc0y2eEe8aOk_rrv=h-y-wQ@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: public-texttracks@w3.org, jzern@google.com
On Mon, Apr 9, 2012 at 10:22 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> I think we are all pretty much agreed that the browser should in
> principle ignore all headers.


I disagree.  It makes sense to have a copy of the <track> metadata, which
implementations would use.  That allows WebVTT files to be applied to video
files without an encloding HTML wrapper.  (Video players often load
.SRT/.SSA files if they're next to a video file in a directory and have a
similar filename, but they usually show up as "language: unknown".  This
would be worse with VTT, since it wouldn't be able to detect the data kind.)

It also gives muxers a source for that metadata, so it's easier to create
eg. WebM files with that data embedded.  (Having to manually tell muxers
what the contents of caption files are because the files don't have this
sort of metadata is awful.)

This means we need to think about namespacing, too, so future standardized
headers can be less likely to clash with user headers.  Making everyone
prefix their custom attributes, like "data-*" attributes is ugly (which
means many people won't do it), so maybe the standardized fields should
look like:

VTTKind: subtitles
VTTLanguage: en
VTTSourceLanguage: zh_CN
VTTLabel: English

with headers not prefixed with "VTT" being user-defined.  That makes these
headers ugly, though, which is a bit annoying since every VTT file should
have them.

Therefore, I would propose introduction of an interface function to
> the TextTrack object [1] that provides the list of headers:
> DOMString getHeader();
> In this case, the JS programmer can parse the text into a list of
> name-value pairs and determine what to do with it.
>
Alternatively, this could be improved through introducing a
> TextTrackHeader object which is a list of name-value pairs.
>

I'd prefer a proper API like this over than something I have to pick apart
by hand.  The cookie DOM API is one of the ugly bits of the platform; let's
not repeat that.

If we don't care about allow duplicates or preserving order, it could just
return a dictionary:

{ VTTKind: "subtitles", VTTLanguage: "en", VTTSourceLanguage: "zh_CN",
VTTLabel: "English" }

which is about as convenient as JS APIs get.

-- 
Glenn Maynard
Received on Tuesday, 10 April 2012 04:11:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:41 UTC