[whatwg] Introduction of media accessibility features

[Jonas Sicking]

On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> 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.
>
> If TTML creates specs that cannot be mapped, then those are ignored.
> All we are basically committing to would be that a best effort is done
> on the mapping. Just like with SRT we would do a best effort on the
> mapping - there are SRT files now that have more than just plain text
> in them. But we would not commit to interpreting every special markup
> that some author came up with that worked in his particular player.
>
> I think the dependencies between external timed text formats and HTML5
> are much less than e.g. the dependency on SVG. TTML is not supposed to
> be a native Web format in my eyes. It is just interpreted for the Web.

I'm not sure I understand what you mean by "TTML is not supposed to be
a native Web format"? Once browsers add support for it, it becomes a
native web format. No matter if the implementation behind the scenes
map xsl:fo to CSS or through some other means. Netscape 4 implemented
CSS by mapping it to JSSS [1], however for all any web developer ever
knew, Netscape 4 supported CSS. Poorly.

I really do hate to come up with a new format. But I think TTML is
severely off the mark for what we want. Am I wrong in that marking up
dialogue vs. sound effects vs. narrator vs. descriptions is important?
Or at least more useful than for example the ability to set the text
outline blur radius?

I agree with Philips email on many points, so I'll reply there instead
of bringing up more details here.

[1] http://en.wikipedia.org/wiki/JavaScript_Style_Sheets

/ Jonas