Re: TextTrackCue discussions

On Sat, Sep 7, 2013 at 5:11 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Sun, Sep 8, 2013 at 3:43 AM, Brendan Long <self@brendanlong.com> wrote:
> > On 09/06/2013 06:04 PM, Silvia Pfeiffer wrote:
> >
> > but they need to know the type of cue to get anything useful.
> >
> > That's information that the @inBandMetadataTrackDispatchType of
> > TextTrack contains.
> >
> > The information is there, but it's unreasonably difficult to get to.
> Would
> > you create an image format where the only way to access pixel data is a
> > giant if/else block to figure out what kind of image it is?
>
> Sure. That's what you do with image formats that the browser doesn't
> support and that you have to pull in via XHR.
>
>
> > Yes, I wrote the other WebKit implementation of text tracks, where we
> > convert everything into WebVTT. It works pretty well, and should be a
> good
> > way to support obscure formats like Kate, but we throw a lot of
> information
> > away in the conversion. For important formats like CEA708, it's entirely
> > reasonable to make a special case so you can present it perfectly.
>
> Agreed.
>
> > If you do want to make WebVTT the only cue format, and put it in the HTML
> > spec, then that would also resolve my concern about the interfaces
> though.
>
> If that's what all browser vendors implement and want, I'll do that.
> It means mapping all cue formats to WebVTT in the browser and using
> the WebVTT rendering algorithm to present them, except for those that
> get their own special interface. That would then be exactly how the
> WHATWG spec currently works.
>

Forget about trying to base your direction on what you think "all browser
vendors implement and want". There is no single answer to what they
implement and want for any feature in HTML. Furthermore, they are just one
stakeholder here, and indeed, one farther down the totem pole. Users and
authors have higher priority.

In any case, when are you going to stop talking about mapping all cue
formats to WebVTT in the browser? That is not a viable solution. And there
will be many objections to such a path. Also, it is not what the WHATWG
spec says. The WHATWG spec wouldn't have divided functionality into a
VTTCue and an abstract TextTrackCue if that were the case. Furthermore, the
WHATWG spec doesn't have priority here either.


>
> > I haven't seen this GenericCue format in the specs, but yes, that's
> > basically what I want.
>
> It's proposed in the other active TextTrackCue thread on this list and
> currently under discussion.
>
> > I find it hard to believe that there's any cue format
> > that can't be represented in HTML, and I think to make things reasonable
> for
> > JS developers, we should force that format to always be available
> (although,
> > for efficiency, an implementation could choose to create it lazily of
> > course).
>
> Binary cue formats don't have a HTML representation, e.g. DVD subtitles.
>

Sure they do. See <img>.


>
> Cheers,
> Silvia.
>
>