RE: HTML charter and Timed tracks

That a timed text format merits standardisation in the W3C has been decided, there are already two. Whether WebSRT is a useful third addition is the moot point, but if it is, then as chair of the TTWG and as much as I can speak for that group, I personally would be interested in working on it in that forum with the participation of the TTML opponents, and to see what if anything could be done to reconcile it with TTML. 

It would be far more productive to have this debate over TTML in the TTWG, rather than in private blogs and this forum, I'm very much interested in moving forward to a solution. There are wider industry implications of the W3C backing away from TTML at this stage, especially in favour of such an underpowered replacement, and the best place to have that discussion is I believe the Timed Text WG. I would encourage those that have been vocal in their criticism to join the TTWG, and while it is  very late in the process, we may be able to make some adjustments to make TTML more palatable.

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.

WebSRT is of course largely undefined at this point, but from a TTWG point of view doesn't seem to be very  XML friendly, in fact one might say it is almost going out of its way to be a problem by using the XML comment closing sequence as a separator. It is claimed that CSS will be applied to WebSRT, however it is not structured in a way which would be amenable to CSS selectors. It is apparently going to introduce yet more definitions of writing mode and alignment which would pre-empt CSS3, and also ignore the CSS box model for layout. It does not provide for language identification at anything other than the whole stream level, which is a problem both for text layout and TTS systems. No doubt these issues and others can be ironed out, and IMO the TTWG is the place to do that.

Sean Hayes <TTWG chair hat>

-----Original Message-----
From: Sam Ruby [mailto:rubys@intertwingly.net] 
Sent: Tuesday, May 11, 2010 1:30 AM
To: Sean Hayes
Cc: Ian Hickson; Paul Cotton; Maciej Stachowiak (mjs@apple.com); public-html@w3.org; Chris Lilley
Subject: Re: HTML charter and Timed tracks

On 05/07/2010 05:52 AM, Sean Hayes wrote:
> On the issue of charter, I see nothing in the HTML charter about 
> developing a timed text format, there are other places in the W3C for 
> that. While specifying how a timed track is referenced by HTML as 
> embedded content does seem to me legitimate, I think the current 
> direction goes well beyond this.
>
> I respectfully  ask that the chairs and the Hypertext Coordination 
> Group clarify whether they think developing a timed track format is in 
> scope for HTML or whether it more properly falls in the remit of the 
> Timed Text WG, the SYMM WG (or both) to further work on a suitable 
> timed text format based on SRT, should that be deemed necessary.

As this appeared in the document without prior discussion or presentation of rationale, I would first like to have a discussion of whether or not this effort merits standardization at the W3C before entering into a discussion about possible venues.

I gather that there is some interest with Opera[1] for this feature.  I am curious if there are other browser vendors interested in implementing this in the near term, or if there is sufficient interest in participating in the development of the standard -- where participation can be any level from reviewing to writing tests to implementing it. 
Similarly I would be interested if there was any vendors were indicated that they would NOT implement this for any reason.

If it fails to meet any of the tests mentioned above, then the venue question is moot.

The final question I would like to tee up is whether there is a working group that is ready, willing, and able to pick up this work, should there be interest.  From my perspective, if there is interest in standardizing this, and there is a group of people who have a credible plan to follow through, then don't think that there will be a problem.

The reason why I would prefer to proceed in this fashion: should this turn out to be the type of thing the W3C should standardize, and should there be sufficient interest in participating in the development of such a standard, and should there be no obvious other home for this effort, then I would be inclined to work the charter issue.

- Sam Ruby

[1] http://annevankesteren.nl/2010/05/websrt

> -----Original Message----- From: public-html-request@w3.org 
> [mailto:public-html-request@w3.org] On Behalf Of Ian Hickson Sent:
> Friday, May 07, 2010 8:00 AM To: public-html@w3.org Subject: Re:
> Timed tracks
>
> On Fri, 7 May 2010, Philip Jägenstedt wrote:
>>
>> (Hixie has participated very little in these discussions, so it's 
>> hard to frame this as his creation alone.)
>
> For the record, I have followed the very same strategy I have used for 
> everything else in the spec: I have read, carefully and in detail, 
> every e-mail ever sent on the subject to the mailing lists (p-h-a11y, 
> p-h, and whatwg), I have publicly collected concrete use cases [1][2] 
> and invited everyone to contribute their own [3][4], I have researched 
> the vast number of options available to us, e.g. all the various timed 
> track formats [5], again in public, and I have used all this 
> information to try to come up with solutions that satisfy all the use 
> cases without introducing unncessary complexity and without closing 
> off future avenues for extensions, again with all of the proposals 
> done in public [6]. These proposals are, as Philip says, based on the 
> ideas in the aforementioned mailing list discussions, for example 
> those documented in the bugs for which I am doing all this work in the 
> first place [7][8], and those documented in task force polls [9].
>
> The work is far from done; maybe WebSRT isn't a good solution, and 
> then it'll be thrown out and something better used instead. However, 
> the working group charter calls for me to make proposals in the form 
> of spec text [10], and the working group process for issues with these 
> proposals to be raised in bugs [11], and I intend to follow exactly 
> this model, just as I have with everything else.
>
> [1]
> http://wiki.whatwg.org/wiki/Use_cases_for_timed_tracks_rendered_over_v
> ideo_by_the_UA
>
>
[2]
http://wiki.whatwg.org/wiki/Use_cases_for_API-level_access_to_timed_tracks
> [3]
> http://lists.w3.org/Archives/Public/public-html/2010Apr/1103.html [4] 
> http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0189.html
>
>
[5] http://wiki.whatwg.org/wiki/Timed_track_formats
> [6] http://wiki.whatwg.org/wiki/Timed_tracks [7]
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9452 [8]
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9471 [9] 
> http://www.w3.org/2002/09/wbs/44061/media-text-format/results [10] 
> http://www.w3.org/2007/03/HTML-WG-charter#decisions [11] 
> http://dev.w3.org/html5/decision-policy/decision-policy.html
>

Received on Tuesday, 11 May 2010 16:17:51 UTC