[whatwg] Introduction of media accessibility features
philipj at opera.com
Sun Apr 11 23:00:03 PDT 2010
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
>>>> 'starting with the simplest profile', being the transformation
>>>> profile. Does
>>>> this mean only the transformation profile is needed to provide
>>>> 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
>>> 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
For the record, I am also not enthusiastic about TTML, specifically the
styling mechanism which even makes creative use of XML namespaces. An
example  for those that haven't seen it before:
<style tts:extent="306px 114px"/>
<style tts:padding="3px 40px"/>
<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!
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
More information about the whatwg