- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 8 Sep 2013 09:20:13 +1000
- To: Glenn Adams <glenn@skynav.com>
- Cc: Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
On Sun, Sep 8, 2013 at 3:56 AM, Glenn Adams <glenn@skynav.com> wrote: > > On Sat, Sep 7, 2013 at 2:11 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> > wrote: > >> >> > TTMLCue will have at least: >> >> > >> >> > interface TTMLCue { >> >> > DocumentFragment getCueAsTTML(); // obtain TTML intermediate >> >> > synchronic >> >> > document (ISD) >> >> >> >> >> >> I would expect that to end up in .text - makes more sense to me. >> > >> > >> > That would be a waste of effort, i.e., to serialize XML into text only >> > to >> > expose it to JS which would have to deserialize it from text as XML >> >> I follow you up to here - after this, JS would interpret the XML and >> render it. >> >> > to >> > modify then mutate deserialize by setting text attribute than have >> > implementation deserialize once more into XML. >> >> I don't know why you would need to do all this. > > > TTMLCue will have already parsed the XML into a Document Fragment. The JS > client will manipulate this fragment. It would be very inefficient to force > the client to manipulate as a serialized text representation. So what you're saying is that TTMLCue will not allow JS developers to change the TTML cue content and get the browser in-built parser & renderer to render the changed content for them. I.e. it also won't be possible for JS developers to author TTML cues by in script? > However, that isn't to say that an UnparsedTTMLCue parent interface couldn't > expose as text, or, in case UA doesn't parse, then expose only as > UnparsedTTMLCue instances. > > If HTML spec doesn't define an {Unparsed,Generic}Cue interface, then we'll > define a TTML specific version of this in TTML2. It would be better to have .text represent the same in TTMLCue as well as GenericCue for TTML. > Conclusion: if TTML isn't parsed, then it should be exposed in text > (serialized XML) form, either by some generic|unparsed cue object or a TTML > specific unparsed cue object. It should not be exposed from a VTTCue as > WebVTT metadata text. If VTTCue is renamed to TextCue and part of the HTML spec (and thus could be made the parent of TTMLCue), would you still oppose exposing TTML content in browsers that don't implement TTMLCue as @kind=metadata in .text in TextCue? Silvia.
Received on Saturday, 7 September 2013 23:21:00 UTC