Re: WebVTT spec

On Sat, 23 Mar 2013, Silvia Pfeiffer wrote:
> On Tue, Mar 19, 2013 at 9:13 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Tue, 19 Mar 2013, Silvia Pfeiffer wrote:
> > > >
> > > > I moved them because I'm not sure all text track languages will 
> > > > want to define this. We can always move it back later if it turns 
> > > > out other formats do always want it.
> > >
> > > I don't think the format matters. What matters is what the web devs 
> > > need and these are the two core functions a web dev would use IMHO.
> >
> > The format clearly matters, since if it's not defined for a language, 
> > there's no way for the developers to use the API...
> 
> .text provides the uninterpreted content of a cue - every format will 
> have such.

Not necessarily. DVD subtitles wouldn't have one, they'd likely have 
something that returned an ImageBitmap or some such. TTML probably 
wouldn't have one, since their format is structured DOM and might never 
have had a textual form (think script-created DOMs) -- they'd just have a 
way to get a pointer to the relevant node in the actual DOM tree, I'd 
guess. Other formats might have other needs, e.g. EBU might want to just 
expose the Text Field as a raw 112 byte ArrayBuffer; I don't know how 
you'd really expose an unparsed DOMString for EBU.


On Sat, 23 Mar 2013, Silvia Pfeiffer wrote:
> > >
> > > So how does the browser get informed about the format if the cues? 
> > > Which rules it has to use to interpret then?
> >
> > This is already defined in the spec, no? I'm confused about what is 
> > ambiguous here. Why would it be unclear?
> 
> In the spec where addTextTrack(kind, label, language) is defined [1] it 
> says:
> 
> "Initially, the text track list of cues is not associated with any rules 
> for updating the text track rendering. When a text track cue is added to 
> it, the text track list of cues has its rules permanently set 
> accordingly."
> 
> So I go to the definition of TextTrackCue() and it contains no 
> information on the "rules for updating the text track rendering".

Not sure why the constructor (assuming that's what you mean by 
"TextTrackCue()") would be where that would be defined. These objects can 
be created in many ways; most commonly, they're created by the WebVTT 
parser directly, without the constructor.

The definition of the WebVTT data model says of WebVTT cues:

# The associated rules for updating the text track rendering of WebVTT 
# text track cues are the rules for updating the display of WebVTT text 
# tracks.


> So I go and check the addCue() function [2], which says:
> 
> "If the text track list of cues does not yet have any associated rules 
> for updating the text track rendering, then associate the text track 
> list of cues with the rules for updating the text track rendering 
> appropriate to cue."
> 
> However, what does "appropriate to cue" mean? How is the browser 
> supposed to distinguish between a cue in a WebVTT format or a cue in a 
> TTML format or anything else?

A WebVTT cue isn't a TTML cue. Why would distinguishing them be difficult?


> Is it supposed to guess from the tags used in the cue?

Why would it need to guess? I don't understand.


On Sun, 24 Mar 2013, Silvia Pfeiffer wrote:
> 
> I've copied the spec text to a new HTML file and uploaded it to the W3C 
> Mercurial repository - it's now staged at:
> 
> https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html

Do you have a diff of this spec to the existing one? I'd like to make sure 
that the diff is zero before we actually hand things over.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 25 March 2013 19:56:04 UTC