- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 14 Apr 2010 16:33:00 +1000
On Wed, Apr 14, 2010 at 1:28 PM, Robert O'Callahan <robert at ocallahan.org> wrote: > On Mon, Apr 12, 2010 at 12:47 PM, Silvia Pfeiffer > <silviapfeiffer1 at gmail.com> wrote: >> >> Understood. But what is actually the cost of implementing all of TTML? >> The features in TTML all map onto existing Web technology, so all it >> takes is a bit more parsing code over time. > > When implementing one complex spec (TTML + XSL-FO) in terms of another > complex spec (HTML + CSS), you have to be very very lucky to find that all > the features map perfectly, even if the specs were designed to work together > that way, which in this case they are not. Even if you're lucky today, > evolution of the specs could easily accidentally break things. 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. So, I don't buy that latter argument. But I guess until there is a mapping for all of DFXP, there probably aren't enough facts to support/reject DFXP. > We could make that problem go away by normatively defining something that > looks like TTML in terms of a translation to HTML + CSS. It wouldn't really > be TTML though, and where's the added value for authors? > > I understand the deep political problems here, but I think it's most logical > for styled content for the Web to use (possibly a subset of) HTML and CSS. > Server-side tools to translate between TTML and HTML+CSS would be one way to > address the desire to interoperate with TTML. 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? But we could develop a new format - just like we have developed microdata. Introducing a new format would indeed be mainly a political problem. Not just would it go "against" all other existing formats. It would also be a challenge to get other applications to support it, in particular applications that do not contain a Web framework. Thus, my thinking was that what we do internally is basically HTML+CSS on time sections. And all formats that we read from externally will be mapped to that. We would already do that with SRT, too. Cheers, Silvia.
Received on Tuesday, 13 April 2010 23:33:00 UTC