[whatwg] Introduction of media accessibility features

[Jonas Sicking]

On Sun, Apr 11, 2010 at 5:47 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> On Mon, Apr 12, 2010 at 7:59 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Sun, Apr 11, 2010 at 5:30 AM, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>> f>> Is it expected that all of TTML will be required? The proposal suggests
>>>> 'starting with the simplest profile', being the transformation profile. Does
>>>> this mean only the transformation profile is needed to provide subtitle
>>>> features equivalent to SRT?
>>>
>>> That is also something that still has to be discussed further. Initial
>>> feedback from browser vendors was that the full TTML spec is too
>>> complicated and too much to support from the start. Thus, the
>>> implementation path with the TTML profiles is being suggested.
>>>
>>> However, it is as yet unclear if there should be a native parsing
>>> implementation of TTML implemented in browsers or simply a mapping of
>>> TTML markup to HTML/CSS/JavaScript. My gut feeling is that the latter
>>> would be easier, in particular since such a mapping has been started
>>> already with Philippe's implementation, see
>>> http://www.w3.org/2009/02/ThisIsCoffee.html . The mapping would need
>>> to be documented.
>>
>> Personally I'm concerned that if we start heading down the TTML path,
>> browsers are ultimately going to end up forced to implement the whole
>> thing. Useful parts as well as parts less so. We see this time and
>> again where if we implement part of a spec we end up forced to
>> implement the whole thing.
>>
>> Things like test suites, blogging advocates, authoring tools, etc
>> often means that for marketing reasons we're forced to implement much
>> more than we'd like. And much more than is useful. This is why spec
>> writing is a big responseibility, every feature has a large cost and
>> means that implementors will be working on implementing that feature
>> instead of something else.
>
> 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. And if we chose not to
> implement TTML, we will have to eventually support some other format
> that provides formatting and positioning capabilities, seeing how the
> legal landscape has evolved for traditional media (e.g. TV, set-top
> box technology). Since TTML was originally developed to be the
> exchange format for all such formats, it should have a sensible set of
> features for this space. So, I personally think it's not a bad choice
> for the purpose. Which other format did you have in mind to replace
> it?

The mere fact that the proposal suggests "just start by implementing a
subset" indicates to me that things have gotten too complicated. I
think unless we can say "here is what you should implement, go forth
and do it", we've constructed something too complex.

And as Maciej points out, it does not appear that TTML uses CSS for
styling, which is the technology used for styling on the web today.
This both means extra work for authors familiar with web technologies
today, and extra work for implementations which currently support CSS.

/ Jonas