Timed Text Markup Language 2 (TTML2)

[ylafon]

The Timed Text WG would like to request a horizontal review of TTML2. ( See https://www.w3.org/2016/09/19-tt-minutes.html#action03 )
The spec is at http://w3c.github.io/ttml2/spec/ttml2.html

[torgo]

Discussed on TAG telecon 12 oct 2016: https://github.com/w3ctag/meetings/blob/gh-pages/2016/telecons/10-12-agenda.md

[dbaron]

Given that this is a large spec, is there a description somewhere (e.g., in an explainer document) of what the major changes are relative to TTML1, and what use cases led to those changes?

There are some things that do appear concerning at first glance, such as the addition of more profiles than TTML1 when profiles generally haven't worked well for widespread interoperability of Web specifications, and the increased styling attribute vocabulary (substantially larger than the vocabulary in TTML1) that includes a bunch of attributes that look a lot like CSS and a bunch that don't.

[nigelmegitt]

Thanks for beginning this process. I Chair this activity in TTWG. We do intend to provide a high level summary of the differences between TTML1 and TTML2 to aid the review process. You're looking at the current ED, which is fine to get started with; we plan to publish a new WD in November which the review request is targeted at.

The profile mechanism in TTML1 is working okay and has adoption to a greater or lesser extent; there is certainly a benefit in indicating which features a processor needs to process any given document, and potentially to choose which processor to use given a document. Usually this is not done in detail in-band at a granular level in the document but by reference to an external profile definition document or other specification such as IMSC 1. The additional functionality in TTML2 addresses specific points raised by external groups wanting to adopt specific profiles of TTML, such as the difference between the signalling of document instance conformance to one or more profiles vs processor capability to process documents from one or more profiles.

The styling attribute vocabulary is in general based on CSS; in some cases there is styling functionality absent from CSS where TTML2 fills the gap, for example some of the detailed Ruby and text emphasis layout semantics, and tighter control of the sizing of blocks. We do have a Charter requirement to coordinate with the CSS WG and will seek review there also.

[torgo]

scheduled for 11-23 call

[nigelmegitt]

A non-normative section listing vocabulary differences relative to TTML1 has been added to the ED at http://w3c.github.io/ttml2/spec/ttml2.html#changes-from-ttml1-vocabulary

[nigelmegitt]

A new TTML2 WD has been published at https://www.w3.org/TR/2016/WD-ttml2-20161117/

Here is a brief descriptive overview of the changes between TTML1 and TTML2:

The TTML2 specification updates the TTML1 specification by adding vocabulary and semantics to address more of its core requirements.

In summary it supports continuous animation of styling and positioning, dereferencing and use of embedded or externally located resources such as images, fonts, and audio, a more easily extensible metadata mechanism, the ability to specify alternate initial values for styling, a more useful profile mechanism, a conditional processing mechanism and a serialisation format for resolved temporal subsections (intermediate synchronic documents). The styling vocabulary has been increased to support advanced text layout requirements such as Ruby, text emphasis, images, backgrounds, shadows and in the next iteration we plan to support basic audio mixing by specifying gain and pan.

At a functional level this means that TTML2 supports text layout requirements for every script globally, is more fit for purpose in terms of profiling and use by other downstream systems, supports audio (video) description workflows and allows for more predictable rendering by means of referencing specific fonts to use. Conditional processing, such as semantic or transformation processing, based on parameters, media queries, language selection etc are now also possible.

Several semantics defined non-normatively in TTML1 have been promoted to being normative. All TTML1 documents are valid TTML2 documents; however, TTML2 documents that specify @Version 2, may not be valid TTML1 documents. Where there is feature overlap between deprecated and new features, such as tts:origin and tts:position, precedence rules are defined. Where appropriate references have been updated, including normative references.

[skynavga]

+1

[torgo]

To be discussed on today's cal.

[skynavga]

I wouldn't mind participating on #tagmem.

On Wed, Nov 23, 2016 at 11:27 AM, Daniel Appelquist <
notifications@github.com> wrote:

To be discussed on today's cal.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXCbyOVDQ1GxHuj_8yzW1yILsO6pA61ks5rBIV_gaJpZM4KMsFV
.

[nigelmegitt]

Is there a source of minutes for the TAG call that I can link to publicly?

[torgo]

Sorry this coming so late @nigelmegitt but https://github.com/w3ctag/meetings/blob/gh-pages/2016/telecons/11-23-agenda.md. Is there anything else you'd like to bring to our attention? Otherwise we will probably close this issue.

[nigelmegitt]

@torgo by closing this issue are you saying that the TAG review is complete and there are no items of feedback? That seems surprising to me given where we landed when this was discussed in November, specifically that there was concern that styling is aligned with CSS; since that time TTWG has begun to build a set of features that is unsupported in CSS but that is required for many of the use cases of TTML. We can handle that out of TAG via CSS WG if that's the view here.

For information, since TAG last looked, there is a new WD at https://www.w3.org/TR/2017/WD-ttml2-20170106/ and we plan a further one before CR.

Issues on TTML2 are tracked at https://github.com/w3c/ttml2/issues

There is now an issue to add a security and privacy section, at w3c/ttml2#224 which issue includes a basic summary of the kind of things we think needs to be in that section.

[torgo]

https://w3c.github.io/ttml2/spec/ttml2.html

[dbaron]

Since it's related, I did make a more detailed list of correspondence with CSS.

[torgo]

Discussed at Tokyo f2f. @nigelmegitt sorry for the long delay. On the CSS alignment issue: we do think it would be best for you to work with CSS to help resolve this. As far as we know this hasn't got onto the CSS group's agenda. We suggest you talk to @astearns @atanassov. We are happy to help facilitate that discussion if needed.

[torgo]

Question 2 which was raised: how much can TTML be polyfilled? This is related to layering of this technology. /cc @slightlyoff

[palemieux]

@torgo A complete polyfill exists at https://github.com/sandflow/imscJS for IMSC1, which a broadly adopted practical subset of TTML1. An example app is at http://sandflow.com/imsc1proc/index.html. Let me know if you need additional information.

[palemieux]

@torgo @slightlyoff Any questions/comments re TTML polyfill in general, and IMSC1 polyfill in particular. There is also a test suite for IMSC1 that includes examplar renderings (as PNG images).

[nigelmegitt]

Following up on the CSS alignment issue we have created a wiki page listing all the styling features in TTML with their mapping to CSS where available, for review, with each classified as unsupported/partial mapping/direct mapping as appropriate.

Disclaimer: there may be some errors in understanding in which case the mappings might be inappropriately classified. Review comments/fixes welcome.

Thanks also to @dbaron for his email that began this assessment for us back in November.

[astearns]

@nigelmegitt could you send a link to this wiki page to www-style? I was about to, but then thought you might already be crafting that email.

[nigelmegitt]

@astearns done!

[dbaron]

We had an hour-long discussion of this in today's TAG face-to-face meeting, 11am-noon, with @nigelmegitt .

[torgo]

@nigelmegitt - we're just reviewing status of this issue at our F2F. Can you let us know how things have progressed since our discussion with you at our last F2F?

[nigelmegitt]

Hi @torgo you got me at a lucky moment - we're working on CSS semantics. This is being tracked at w3c/ttml2#406 - we have also invited CSS WG to join TTWG at our f2f at TPAC to discuss progress on the styling features that are not present in CSS - at the Paris f2f of the CSSWG we were asked for use cases and descriptions of those features, which we are working on too (slight delay due to people changing jobs in contributing organisations).

[torgo]

Discussed at london f2f. Unclear where current state is, although some progress seems to have been made at TPAC. @nigelmegitt are your current issues going to reflect the work on alignment with CSS? Can you point us to the relevant issues here in this issue? Thanks!

[nigelmegitt]

Sorry for the long pause. w3c/ttml2#406 is an umbrella issue for adding the CSS properties equivalent to TTML2 style attributes. They're all present in https://w3c.github.io/ttml2/#style-attribute-derivation

The current set of relevant open CSS issues for dealing with things that cannot be mapped is:

• [compositing] SDR and HDR compositing w3c/csswg-drafts#554
• [css-inline][css-text-4] Allow padding to be applied at line start and end w3c/csswg-drafts#1973
• [css-inline] Allow background of an inline area to extend to before-and after-edges of the line area w3c/csswg-drafts#1974
• [css-sizing][css-align][css-text] Aligning an aligned block of text within its container w3c/csswg-drafts#1975

There's been a hiatus working on these from the TTWG perspective because we've been working hard on getting TTML2 to CR, as well as backporting some fixes into TTML1 and generating a TTML1 3rd Edition CR, and updating the IMSC 1.0.1 profile to include TTML2 features, which will be IMSC 1.1.

A key part of the discussion was how we handle styling features that are in IMSC extensions but not supported by CSS yet. The main driver of discussion was actually namespaces and backwards compatibility in IMSC, but there's a strong correlation between the sets of features that fell into those two categories.

The TTWG's decision was to omit some features from TTML2 and defer their inclusion to a future version of TTML not before a clear mapping to CSS properties can be used. This has reduced the level of incompatibility between TTML2 and CSS somewhat, without removing the need for the styling features, and allowing existing extensions defined in IMSC (or EBU-TT-D) to continue being used.

Additionally, thanks to feedback from i18n, some advanced ruby support defined in TTML2 but not n CSS was removed from TTML2, on the basis that the immediate requirement was too weak and that there were some edge cases lacking clarity about exactly what implementations should do.

TTWG intends to keep working with CSS WG on the styling features required for subtitles and captions, and in addition the Media and Entertainment IG is setting up a task force to look at a similar or overlapping topic, so there may be additional input from others.

[hadleybeeman]

Hey Nigel! We're excited about your progress!

Our original concern was to make sure that TTML and CSS (as working groups and as web features) were converging (rather than diverging) re: styling. It looks like this is happening, and we appreciate the level of effort and care put into this work.

We're going to close this issue, on the grounds that all discussions seem to be taking place directly between the CSS and TTML WGs. Please feel free to ping us again (or open another issue) if anything else comes up that we can weigh in in constructively.

Thanks again for all the hard work.

[nigelmegitt]

Hi Hadley, thank you for the note. It's true that TTWG and CSSWG are working together to get styling convergence, so this seems fair.

One additional data point is that TTWG discussed styling requirements for some future version of TTML and the possibility of opening up more general CSS support in the future, a discussion which resulted in no dissent. I expect the result to be something like:

• inclusion of a class attribute
• a way to specify a generic set of CSS style properties on a TTML content or style element
• a profile feature designator to indicate whether the document author wants only processors that can handle generic CSS to present the document