W3C home > Mailing lists > Public > public-html@w3.org > May 2010

Re: Timed tracks

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 8 May 2010 04:45:16 -0700
Message-ID: <o2o63df84f1005080445he20ddedfu3215682cb372ba44@mail.gmail.com>
To: Sean Hayes <Sean.Hayes@microsoft.com>
Cc: Philip Jägenstedt <philipj@opera.com>, "public-html@w3.org" <public-html@w3.org>
On Sat, May 8, 2010 at 3:24 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> >From a standards perspective, the status of the specs matter a lot.  A real standards organisation wouldn't contemplate a reference to a working draft. TTML is being advanced in real standards orgs too, as getting captioning done is about much more than just the end player capability.
>
> To quote Maciej " Standards experts will be *extremely* picky about whether the layout behaviour in a browser precisely matches the spec, ... There isn't really room to fudge it." That doesn't jibe very well with " the status of the specs matters very little, what matters is that it is already implemented and shipped in browsers ".  So which is it?
>
> If the CSS specs change, as seems likely from a WD status, then those implementations will not be compliant. However, be that as it may, if as you say the CSS3 text and box specs are widely implemented, and the same  in Opera and Gecko, WebKit and IE, then you already have the tools to implement TTML - so all is goodness.
>
> I'm also not convinced by your arguments on the one hand to throw out styling in TTML but then require exactly the same styling be applied to an as yet undefined format. I can't offer any kind of argument to that kind of doublespeak.

Personally I'm not sure what TTML brings that we want. As far as I can
see it's about as accessible as a PDF is. Instead of marking up the
semantic meaning of its contents it basically just says that text
should be displayed with various layout properties at various times.
There is no way to for example find every instance when a specific
person says "hello", or to style all narrator text in italics and
surrounded by '[' ']'.

Compared to HTML it seems like a big step backwards accessibility wise.

This is the first reason that I think TTML is uninteresting format for
our needs. And this is the styling language aside.

Second, for the web, using XSL:FO isn't very interesting. The number
of web authors that know XSL:FO is tiny compared to the number of
authors that know CSS. So why should we ask everyone that wants to
style captions to use XSL:FO?

Neither of these reasons have anything to do with implementation
effort. If we want to look at the implementation effort then XSL:FO is
also clearly wrong for a web browser. I understand that it might have
desirable properties in environments where the web doesn't matter. I
wouldn't be surprised if implementing the subset of XSL:FO that TTML
uses is easier than implementing CSS if you're starting from scratch.

However any browser that want to support styling will already support
CSS. So adding XSL:FO support is clearly more costly than simply using
an existing CSS implementation.

I understand if the TTML designers though that the mature parts of CSS
wasn't enough to fill their needs. It didn't fulfill their needs to
they used a different technology. I feel the same way towards TTML. It
doesn't fulfill our needs to we should use a different technology.

That said, I definitely don't think putting this language into the
HTML5 spec is the right thing to do. I think everyone (with possible
exception of editor) would be served by having it be in a separate
spec. This will help people reviewing the spec and people implementing
the spec. And if as a side effect we'll end up with a format that can
be used in other environments, such as DVD players and streaming media
centers, then all the much better.

/ Jonas
Received on Saturday, 8 May 2010 11:46:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:02 UTC