[whatwg] Introduction of media accessibility features

[Silvia Pfeiffer]

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.