[whatwg] Introduction of media accessibility features

[Philip Jägenstedt]

On Mon, 12 Apr 2010 08:47:33 +0800, 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?
>

For the record, I am also not enthusiastic about TTML, specifically the  
styling mechanism which even makes creative use of XML namespaces. An  
example [1] for those that haven't seen it before:

<region xml:id="r1">
   <style tts:extent="306px 114px"/>
   <style tts:backgroundColor="red"/>
   <style tts:color="white"/>
   <style tts:displayAlign="after"/>
   <style tts:padding="3px 40px"/>
</region>
...
<p region="r1" tts:backgroundColor="purple" tts:textAlign="center">
   Twinkle, twinkle, little bat!<br/>
   How <span tts:backgroundColor="green">I wonder</span> where you're at!
</p>

While I don't have any suggestions about what to use instead, I'd much  
prefer something which just uses CSS with the same syntax we're all used  
to.

[1]  
http://www.w3.org/TR/ttaf1-dfxp/#style-attribute-backgroundColor-example-1

-- 
Philip Jägenstedt
Core Developer
Opera Software