- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 8 May 2010 04:45:16 -0700
- 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