Re: WebVTT Spec Question

On Apr 16, 2013, at 9:21 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> I agree with avoiding prefixes - they have been a disaster wherever you go, including in networking.

What's a disaster is when spec writers try to pretend that this need will never arise, and ad-hoc solutions are therefore used, such as embedding data in comments, fill structures, or other similar places.

It's clearly better to have clearly delineated 'sandboxes';  in, for example, H.264 (AVC) there are extension packets that are labelled with UUIDs, enabling non-conflicting non-registered experimental or other use.  Other systems use reverse DNS, and so on. 

> Instead, we should start an explicit list of metadata headers that we support and what they mean.

No argument from me on that.

> Then if somebody needs additional ones for use with a specific customer, they can put them in a COMMENT section.

Free-form comments (or fill elements, or other places that are documented for another purpose) aren't a good way to handle experimental, vendor, or other machine-to-machine tagging.

> I'm suggesting to add this straight to the spec. It will need updating at regular intervals anyways.

What is 'this'?  "Please use NOTEs for any ancillary data you might need in VTT files, and hope you don't clash with other uses of NOTEs or true human-readable comments?"

> 
> Cheers,
> Silvia.
> 
> On Tue, Apr 16, 2013 at 2:49 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 15 Apr 2013, David Singer wrote:
> > On Apr 15, 2013, at 13:03 , Ian Hickson <ian@hixie.ch> wrote:
> > >
> > > CSS
> >
> > has vendor prefixes.
> 
> ...which are pretty much uniformly regarded as a disaster, which is why at
> least two browser vendors have changed policy to stop using them.
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 16 April 2013 08:54:01 UTC