On Mon, 12 Apr 2010 08:47:33 +0800, Silvia Pfeiffer
<[email protected]> wrote:
On Mon, Apr 12, 2010 at 7:59 AM, Jonas Sicking <[email protected]> wrote:
On Sun, Apr 11, 2010 at 5:30 AM, Silvia Pfeiffer
<[email protected]> 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
