[whatwg] Introduction of media accessibility features

[Tab Atkins Jr.]

On Tue, Apr 13, 2010 at 11:33 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> 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.

I'd rather not be in charge of keeping them aligned perfectly.  I'd
also never want to be put in a situation where someone objects to a
useful change in CSS because it doesn't work for TTML.  Just
integrating CSS and SVG is a pain, and there's measurable *benefit*
there.


>> 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.

+1 to Henry's suggestion of just using two formats: SRT, and SRT +
(possibly some subset of) HTML+CSS, where the latter is simply a
normal SRT file with HTML allowed where it would normally only allow
plaintext for the caption.

That seems to be the minimal change that can address this case, and
appears to be a fairly logical extension of an existing widespread
format.

~TJ