<chair hat off>
On May 11, 2010, at 1:47 PM, Robert O'Callahan wrote:
> On Wed, May 12, 2010 at 4:17 AM, Sean Hayes
> <Sean.Hayes@microsoft.com> wrote:
> What seems to be an issue with TTML is that it is based on XML, puts
> style attributes in its own namespace and extends CSS2 in a manner
> which might conflict with the application of CSS3. Why this is such
> an issue I'm not sure, given that the browser vendors' have public
> support for SVG, which also has XML attributes for style in its own
> namespace, also extends CSS in a manner that might conflict with
> CSS3 (and indeed far more extensively than TTML does), and whose
> implementation includes pretty much all that is needed for TTML.
>
> SVG is not greatly loved by Mozilla developers, to be honest. The
> SVG support in Gecko (and I think Webkit too) was contributed by
> volunteers, at a time when there was no other proposed standard for
> vector graphics, no resources available to develop an alternative,
> and SVG's flaws were not as well understood as they are now. So,
> being no worse than SVG isn't compelling.
That's pretty accurate as to WebKit.
I also think Sean's premise is incorrect. SVG's presentational
attributes are in the null namespace, not in a namespace, as is the
case with TTML. SVG also supports CSS for styling, and defines most of
its presentational attributes in terms of mapping to CSS, in contrast
to TTML, which maps to XSL-FO and has a completely custom syntax for
styling. SVG's style resolution uses the CSS inheritence/cascade
model, whereas TTML does not. So TTML's styling model is less
compatible with browser engine infrastructure than SVG's.
Even so, SVG has some problems in the browser context. SVG 1.2 Tiny
had a proposal for a multiline text element (<textArea>) and browser
engines have been generally uninterested in supporting it because it's
not consistent with CSS layout. TTML has the same issue as
svg:textArea for text layout. That's in addition to the styling issues.
Regards,
Maciej