- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 6 Mar 2013 20:53:08 +0000 (UTC)
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- cc: public-texttracks@w3.org
On Thu, 7 Mar 2013, Silvia Pfeiffer wrote: > On 7 Mar 2013 06:53, "Ian Hickson" <ian@hixie.ch> wrote: > > > > On Mon, 25 Feb 2013, Silvia Pfeiffer wrote: > > > > > > I was actually wondering about the split and was considering the > > > opposite, namely to pull more back into HTML. The TextTrack API and > > > TextTrackCue etc should continue to stay in HTML, because you can > > > create text tracks and cues without WebVTT. > > > > Well, the current interface is very WebVTT specific. I could buy > > splitting the interface in two, though, with the WebVTT parts in > > WebVTT and the generic parts in HTML. Would that work? > > Yes, that's what I was trying to say. For example the rules for > rendering WebVTT cues become the rules for rendering TextTrackCues and > then WebVTT can reference them. Is that what you meant? I meant more the other way around. The rules for rendering WebVTT cues are specific to WebVTT (e.g. you wouldn't use them for TTML), and so all the bits on TextTrackCue relating to them, e.g. snapToLines, are WebVTT- specific as well. So I would propose splitting TextTrackCue in half, with WebVTT having a WebVTTTextTrackCue that inherits from TextTrackCue and contains all the WebVTT-specific bits, leaving only the generic format-agnostic stuff (that is as useful for WebVTT as any other text track format) in HTML. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 6 March 2013 20:53:33 UTC