- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 11 Dec 2013 10:42:13 +1100
- To: Glenn Adams <glenn@chromium.org>
- Cc: "public-texttracks@w3.org" <public-texttracks@w3.org>, John Luther <jluther@google.com>, Victor Carbune <vcarbune@chromium.org>, David Singer <singer@apple.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Silvia Pfeiffer <silviapf@chromium.org>
On Wed, Dec 11, 2013 at 10:37 AM, Glenn Adams <glenn@chromium.org> wrote: > > On Wed, Dec 11, 2013 at 7:32 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> > wrote: >> >> On Wed, Dec 11, 2013 at 10:26 AM, Glenn Adams <glenn@chromium.org> wrote: >> > >> > >> > >> > On Wed, Dec 11, 2013 at 6:59 AM, Silvia Pfeiffer >> > <silviapfeiffer1@gmail.com> >> > wrote: >> >> >> >> Some corrections inline since there seem to be some misunderstandings. >> >> >> >> >> >> On Wed, Dec 11, 2013 at 8:20 AM, Glenn Adams <glenn@chromium.org> >> >> wrote: >> >> > >> >> > On Wed, Dec 11, 2013 at 5:08 AM, Silvia Pfeiffer >> >> > <silviapfeiffer1@gmail.com> >> >> > wrote: >> >> >> >> >> >> >> >> >> On 11 Dec 2013 07:56, "Glenn Adams" <glenn@chromium.org> wrote: >> >> >> > >> >> >> > >> >> >> > On Wed, Dec 11, 2013 at 3:34 AM, David Singer <singer@apple.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> On Dec 9, 2013, at 11:36 , Glenn Adams <glenn@chromium.org> >> >> >> >> wrote: >> >> >> >> >> >> >> >> > But not as well as you could it would seem: on Chrome, WebVTT >> >> >> >> > is >> >> >> >> > simply translated to cues referring to a CSS styled HTML >> >> >> >> > fragment. >> >> >> >> > Why not >> >> >> >> > simple define an HTMLCue, and dispense entirely with VTTCue and >> >> >> >> > the WebVTT >> >> >> >> > parser. The WebVTT could be translated to a sequence of HTML >> >> >> >> > cues >> >> >> >> > on the >> >> >> >> > server or using client JS. >> >> >> >> > >> >> >> >> >> >> >> >> This is probably stating the obvious, but you asked. >> >> >> >> >> >> >> >> for at least two reasons: >> >> >> >> >> >> >> >> * we want this to be only one of many possible implementation >> >> >> >> choice >> >> >> >> and >> >> >> >> * we want there to be a simple expression of the timed cues that >> >> >> >> is >> >> >> >> not >> >> >> >> dependent on an implementation choice >> >> >> > >> >> >> > >> >> >> > Which would require the "simple expression" to be a >> >> >> > semantic/stylistic >> >> >> > superset of formats, which HTML/CSS is, but WebVTT isn't. >> >> >> >> >> >> Allowing all of html and css in cues is madness. >> >> > >> >> > >> >> > I don't recall ever saying to allow "all" of html/css. The fact of >> >> > the >> >> > matter is that VTT implementations translate VTT cues to some subset >> >> > of >> >> > HTML/CSS. We are also defining a mapping from TTML to some subset of >> >> > HTML/CSS. >> >> > >> >> > This process begs the question of whether any translation from an >> >> > input >> >> > format like TTML or VTT into HTML/CSS should be implemented in the >> >> > browser >> >> > rather than in, say, JS client code. >> >> >> >> Yes, that's what we're doing with VTT when VTT is used in the browser >> >> - we map it to HTML and CSS for rendering. Non-browsers can decided to >> >> use a different approach for rendering. >> >> >> >> >> >> > Going one step further, it is natural >> >> > to ask if it makes sense to have servers deliver cues using HTML/CSS >> >> > directly, thus even avoiding the need for JS client translation. >> >> >> >> That makes browsers have to support all of HTML/CSS in cues, which, as >> >> I said above, makes no sense. >> > >> > >> > Repeat again: I did not say "all of HTML/CSS", and what I did suggest >> > does >> > not imply "all". If one were to define direct delivery of HTML/CSS based >> > cues, there is no reason it could not be a subset of HTML/CSS. >> >> >> Do you want to define a HTMLCue that supports all of HTML or a >> PartialHTMLCue? Since cues can be created by any authoring system, >> including by JavaScript in the browser, you can't just say that >> HTMLCue supports all of HTML/CSS, but you're only ever sending it a >> subset of HTML/CSS. That's not how it works. > > > It is if that's how you define it. Right now you have a method > getCueAsHTML() not getCueAsPartialHTML(). Whether it is everything or > partial is rather besides the point of this discussion anyway. My point is > there might be utility in defining some Cue type (I don't care what to name > it) that allows JS client code to populate a track's cues with HTML/CSS (at > whatever subset we want to enforce). Going beyond that, there may be utility > in defining a way to deliver such cues directly (without requiring client > JS). Maybe. I'm not opposed to a HTMLCue. It's not something that's useful for VTT, but it may be a useful addition to HTML. As I said: make a JavaScript implementation using DataCue and prove to the HTML WG that it's useful. This is not the right forum to discuss this. Regards, Silvia.
Received on Tuesday, 10 December 2013 23:43:00 UTC