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

RE: Timed tracks

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Sat, 8 May 2010 10:24:14 +0000
To: Philip Jägenstedt <philipj@opera.com>
CC: "public-html@w3.org" <public-html@w3.org>
Message-ID: <8DEFC0D8B72E054E97DC307774FE4B911A526427@DB3EX14MBXC315.europe.corp.microsoft.com>
>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.

-----Original Message-----
From: Philip Jägenstedt [mailto:philipj@opera.com] 
Sent: Saturday, May 08, 2010 6:22 AM
To: Sean Hayes
Cc: public-html@w3.org
Subject: Re: Timed tracks

As Robert says, the status of the specs matters very little, what matters is that it is already implemented and shipped in browsers.

If TTML is limited by the status of various specs at the W3C then we could of course fork it and throw out all the things we don't want (styling, superfluous namespaces) and keep the good stuff, but would this be an acceptable solution? It would be largely incompatible with TTML, and not reap any benefits from compatibility with existing tools.

Philip

On Sat, 08 May 2010 02:02:11 +0800, Sean Hayes <Sean.Hayes@microsoft.com>
wrote:

>>> As Tab said, the point is to use only CSS, using the CSS syntax (not 
>>> a subset of CSS mapped from some other syntax).
>
> When CSS catches up; TTML style can be defined in terms of CSS only.   
> The CSS syntax is of course applicable to any XML format already, so 
> there is nothing stopping you using anything in the CSS3 drafts with 
> TTML today, just like you would with HTML, you just wouldn't be able 
> to do it as inline style in the TTML namespace.
>
>>> webfonts, text-shadow, text-outline, transitions, and translations
> Again none of this is in CSS2; and thus mostly at WD/Editors draft  
> status. When they are done TTML style can reference them if necessary.   
> But even if TTML did not include inline attributes for these 
> properties, that would not preclude a user agent that was CSS3 aware 
> being able to apply them.
>
> Webfonts has been folded into CSS3 Fonts and is at WD.
> Text-shadow and text-outline are in CSS3 Text - at Editors draft. (NB 
> Text outline was considered an important enough use case that we added 
> it into TTML directly) Transitions are still at editors draft too, but 
> TTML can do style animation, so you can get much of the effect now.
> Transforms - Editors draft.
>
> I would point out however that a lot of the resistance TTML has had in 
> the past is due to the perception that it is already too complex, so 
> adding all this CSS3 stuff, while fun and in some cases justifiable; 
> will only serve to make it more so.  I'm also somewhat confused as to 
> why on the one hand you want SRT, which is utterly minimalist and on 
> the other you want this extreme complexity.
>
> -----Original Message-----
> From: Philip Jägenstedt [mailto:philipj@opera.com]
> Sent: Friday, May 07, 2010 6:17 PM
> To: Sean Hayes
> Cc: public-html@w3.org
> Subject: Re: Timed tracks
>
> On Fri, 07 May 2010 23:59:15 +0800, Sean Hayes 
> <Sean.Hayes@microsoft.com>
> wrote:
>
>> Philip Jägenstedt>> "From what I have read of the TTML spec, I do not 
>> want to support it in Opera, mainly because it fails to make use of 
>> CSS for styling".
>>
>> I keep hearing that this is a big problem and I'm not understanding 
>> it, TTML does "make use of CSS for styling", it just happens to also 
>> make use of parts of XSL:FO and SMIL.
>>
>> Could you elaborate on exactly what it is you are looking for from CSS?
>> And more particularly what version of CSS. TTML could use CSS 
>> selectors to apply its style properties, but that can't be it; 
>> because CSS selectors won't work on a text format like SRT, which you 
>> seem to think is a good direction.
>>
>>  If it's the generalised box model to support vertical text you are 
>> objecting to in TTML, then can we take it Opera will not be 
>> implementing
>> CSS3 when it's done, as it is busily migrating those XSL 
>> modifications to CSS that TTML styling relies on. What advantage 
>> would you see in moving TTML back to a non-internationalised text 
>> model? Especially when an example of vertical text is included as a 
>> use case in 
>> http://wiki.whatwg.org/wiki/Use_cases_for_timed_tracks_rendered_over_
>> v
>> ideo_by_the_UA
>
> As Tab said, the point is to use only CSS, using the CSS syntax (not a 
> subset of CSS mapped from some other syntax).
>
> As for actual features, I'd want to be able to use at least webfonts, 
> text-shadow, text-outline, transitions, and translations, as well as 
> any other new innovations made in CSS, without having to change 
> anything about the caption format (which a mapping would require).
>
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
>
>


--
Philip Jägenstedt
Core Developer
Opera Software
Received on Saturday, 8 May 2010 10:24:52 UTC

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