- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 16 Apr 2010 01:44:18 -0700 (PDT)
"Silvia Pfeiffer" <silviapfeiffer1 at gmail.com> wrote: > I believe it is possible today, but of course cannot prove it right > now. Also, future evolution of TTML will be directed by the Web in > the > future if it gets integrated, as it would be its main use. Also: it's > a W3C standard, so probably would have the requirement not to break > the Web. As Jonas already pointed out, the W3C has a long history of incompatible specs. Defining things in terms of XSL-FO instead of CSS is a warning signal that the design prioritizes something other than Web-friendliness. > I personally have no issue with introducing a new format - even > experimented with one some time ago, see > http://wiki.xiph.org/Timed_Divs_HTML . There are challenges with > this, too, and they are not only political. For example, I think we would > need to restrict some things from appearing in timed sections: e.g. > would we really want to allow multiple layers of video rendered on > top of video? What I suggested earlier on public-html navigated around this problem by refining only the "Ogg-internal TDHT" case (to limit the lifetime of pieces of timed text in the DOM and to avoid having new CSS pseudo-class behavior) and by defining things in terms of existing infrastructure (in simple enough a way to fit in an email without having to have a mapping spec from an alien format to the existing infrastructure). What I suggested defined things in terms of setting innerHTML in a nested browsing context (aka. anonymous iframe) from a task on the main thread. All behavior follows from this and is well-defined to the extent innerHTML setter and iframe behavior are well-defined. So <video> in timed text would behave the way it behaves if you set innerHTML to markup that has <video>. There are many things that don't make sense to do in timed text, but their behavior would be well-defined so the implementation wouldn't have to enforce new rules. If we get well-defined behavior "for free" by using existing functonality, I think we shouldn't add spec rules and implementation code to try to disable the parts of that existing functionality that seem non-sensical in the new context. Things become more complicated if per-video frame time alignment is needed and rendering has to happen ahead of time. In that case, you'd have to define more things like disabling all declarative animation (innerHTML already prevents <script>s from running) and defining how long to wait for uncached external resources to load. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi
Received on Friday, 16 April 2010 01:44:18 UTC