Add generic CSS property functionality

First take at this:

Add a class attribute to support CSS selectors;
Add a "supports generic CSS properties" feature designator;
Add an attribute (hopefully, rather than an element) that allows generic semicolon-separated CSS property lists to be included on content, style and region elements;
Work out what the order of precedence is between TTML styles and CSS properties when they overlap, e.g. what colour should the text in <span tts:color="white" css="color: red;">text</span> be in - white or red?

What is the motivation for this feature, i.e. what problem is it trying to solve?

Thanks for the prompt @palemieux - I did describe this at TPAC but didn't write it down, so I will do so here:

The motivation is that we have a use case where we want to present on-video captions on video in an HTML5 context using advanced styling features not currently available in TTML2, but available in CSS. This is for "narrative text" captions branded to look similar to our video graphics captions, rather than being our traditional subtitle style.

There is a specific list of CSS properties that we would use now or soon if they were available, but attacking the problem one property at a time is brittle, and takes too long if we have to go round a non-guaranteed standardisation loop each time, which could easily take a year. There could be a branding change at any time that can be achieved in CSS but needing a few more properties. Hence the need to open up the ability to access generic CSS properties where processors can use them, and to put the processor requirement to support that behind a feature designator.

Essentially this is for presentation of timed text using styles that go beyond what is needed for translation or hard of hearing subtitle and caption presentation.

I'm not so much concerned with syntax here, but with semantics. It may not be so simple to map the semantics of CSS style properties into TTML presentation semantics. In particular, it could potentially require writing specific semantic mapping rules for each CSS property that is used in this fashion.

As for syntax, I would suggest tts:cssStyle and tts:cssClass or perhaps ttsx: insteady of tts:.

@nigelmegitt CSS styling features that are useful for timed text should simply be added to TTML as native styling properties, where they can be made to work with existing styling properties without ambiguities and inconsistencies. This process can start today if it is true that there is a specific list of CSS properties that we would use now or soon if they were available.

Completing as per the issue template:

Is your feature request related to a problem? Please describe.

Advanced styling

As a broadcaster we want to present captions over video in an HTML5 context using advanced styling features not currently available in TTML2, but available in CSS. This is for "narrative text" captions branded to look similar to our video graphics captions, rather than being our traditional subtitle style.

Enhanced styling

In some cases the CSS properties needed would be the same as existing TTML style attributes but allowing an additional level of detail; for example tts:borderdoes not allow each edge to be specified differently whereas this is possible in CSS. Another potential conflict is with animations, where CSS animations may be preferred authorially to use of the animate element in TTML, or both may be used, in which case the semantic needs to be defined.

Timeliness of adoption

We want to be able to change the look and feel to meet editorial change timetables and want to be able to access CSS properties not currently available in TTML without waiting for those properties to be added to the TTML specification, because that takes too long.

Describe the solution you'd like We don't have a solid view of exactly how this should work. However it works, it should be behind a profile feature designator, with a fallback behaviour to "normal TTML" (whatever that means) if not supported and the profile states that support for the feature is optional.

Some ideas include:

Adding a class attribute and embedded or linked stylesheets to allow generic CSS styling. We would need a semantic for resolving clashes with existing TTML style attributes that map to the same CSS properties.
Providing a "quick turnaround" service for checking that CSS properties do not conflict with existing TTML style attributes and adding them to a registry with a mapping to a TTML style attribute name.
(probably unworkable, here for completeness:) Providing a way to deprecate all or almost all TTML styles and use a CSS approach in place of TTML styling.

Describe alternatives you've considered

We considered:

mapping each new desired CSS property to a TTML style attribute and going around the Recommendation loop. This would take too long to be practically useful.
adding custom attributes and handling them as style attributes. This is possible but not more widely useful.

State if you intend for this requirement to be met by a particular specification This would need to be in TTML and also in IMSC.

Does this requirement represent a change in scope No change in scope.

Additional context None.

You should note SVG's support for CSS stylesheets alongside SVG presentation attributes ("SVG styles"), a situation that effectively mirrors this proposal. Regarding semantics for combining the two systems, see SVG 1.1 §6.4.

Thanks for that @skynavga - we should certainly look at SVG for inspiration at least.

Thanks @nigelmegitt! I think this is an important issue. It is relevant for the general strategy in enhancing TTML. There are different options and in the longrun I would not rule out this idea from @nigelmegitt:

(probably unworkable, here for completeness:) Providing a way to deprecate all or almost all TTML styles and use a CSS approach in place of TTML styling.

TTML has diverged from the HTML5 ecosystem in the past. From the styling perspective it is in a kind of parallel galaxy. Very close and easy to travel to and from HTML+CSS, but still in a different space.

From the discussions in the past it became obvious that some stakeholders would welcome a close relationship between TTML and CSS.

The approach you suggest looks tempting at first sight, but as mentioned by others: concepts in XSL-FO/TTML are very close to TTML, but not the same. So for mapping you may need to check every single CSS property.

Therefore it could indeed be one alternative to completely re-write TTML and to use directly CSS for styling timed text.

In the meantime the approach by @nigelmegitt could be used by a profile, that may not be specified by TTWG but for example an organisation as the BBC. It could be a profile that applies as a postprocessing step to TTML after it was rendered to HTML. The CSS syntax could be encapsulated by an attribute in a non-TTML namespace.

Re: https://github.com/w3c/tt-reqs/issues/2#issuecomment-457615638

TTML has diverged from the HTML5 ecosystem in the past.

This statement is inaccurate and misleading. TTML was explicitly NOT designed to be part of the HTML ecosystem in the sense that it should be an integrable language (i.e., integrate with HTML/CSS language constructs).

It was designed to be an XML language independent of a web browser context where HTML is dominant. What you are proposing is essentially to create another, non TTML language, let us call it HTTML, a language which (by your stated intent) will be closely bound to HTML5/CSS, as opposed to XML and an independent style system. While I don't have anything in principle against doing this, it should be made clear that this would not be a profile of TTML nor would it be compatible with it, and, therefore, it would provide a diverging path away from a practice that now has a nearly 20 year legacy.

Something else to consider here is that TTML has always been to some extent loose about the specifications of style attributes - although we assert that the basis is XSL-FO, this semantic basis has so far always been informative only. In TTML2 we also introduced an informative basis on CSS, observing that on all the style attributes where we did this, which also existed in TTML1, the XSL-FO definition defers to CSS.

The point I am seeking to make here is that any implementation that does something sensible has been considered valid up to now, and "something sensible" can be based on XSL-FO, CSS or something completely different. In my view this gives us some freedom which we can take advantage of.

I agree in general, with the exception that (1) in some cases XSL-FO added/clarified semantics to what it brought in from CSS, and (2) TTML has done the same with respect to properties it derived from both XSL-FO and CSS.

The Timed Text Working Group just discussed Add generic CSS property functionality tt-reqs#2, and agreed to the following:

SUMMARY: Group agrees to look for ways to add new style properties with minimal overhead and to try to solve this in 2019.

The full IRC log of that discussion

<nigel> Topic: Add generic CSS property functionality tt-reqs#2
<nigel> github: https://github.com/w3c/tt-reqs/issues/2
<nigel> Nigel: [summarises requirement]
<nigel> Glenn: The title says "CSS property" which I'm happy to see because it does not say "CSS Selectors".
<nigel> .. I want to confirm here that the ask does not include CSS selectors, which would make things enormously
<nigel> .. more complicated.
<nigel> .. I can see a straightforward path to supporting CSS properties.
<nigel> Nigel: What's that path?
<nigel> Glenn: 1. Put it in a separate module.
<nigel> .. Define a new attribute tts:cssStyle= and then a value space that is a set of CSS properties, and define
<nigel> .. the semantics so that if both apply in some circumstance then the TTML property... we'd have to
<nigel> .. establish a priority for when there's an intersection, let's say tts:color and tts:cssStyle="color: XXX;".
<nigel> .. If a system did not support the CSS style mechanism then I would presume that the TTML property applies.
<nigel> .. If it supports the CSS property applies then the CSS property could be designated to win, but I'm open
<atai1> xq+
<nigel> .. to it being the other way around. I don't have a strong opinion on that.
<atai1> q+
<nigel> .. That would be the simplest path.
<nigel> s/xq+//
<nigel> ack a
<nigel> Andreas: That sounds like a feasible approach. Two comments also on the thread. First, we need to make
<nigel> .. sure that there's really a defined behaviour if you apply CSS properties inside the TTML style and layout
<nigel> .. system so that there is a deterministic rendering behaviour. That does not have to be true always because
<nigel> .. TTML does not rely on CSS but on XSL-FO. The second thing is I would like our long term strategy
<nigel> .. to align TTML and CSS. We had discussions with CSS WG 2 years ago and we had agreement to bring
<nigel> .. it closer however it may look. The target was TTML3 at that time.
<nigel> .. I think this first idea could be a transition phase. In general it would be worthwhile to meet the CSS WG
<nigel> .. about this approach and in the long term plan consider how CSS could be handled, if it could be a way
<nigel> .. to make timed HTML rather than TTML.
<nigel> Glenn: I would like us to limit the scope of this particular requirement to what the title says, which is
<nigel> .. adding generic CSS properties. Andreas it sounds like we're on similar thinking in that regard, details
<nigel> .. to be worked out. What I do not want to mix in with this is any discussion of general long term
<nigel> .. migration to a new as yet defined language that would not be TTML if it is intended to diverge from
<nigel> .. an XML based language. I do not want to include that in this issue.
<nigel> .. I don't object to someone opening a new issue defining a timed version of HTML5 with a migration
<nigel> .. path from TTML but in my opinion that's not part of TTML standardisation, it is part of a new language
<nigel> .. that could potentially be done in this working group. It would certainly require a new Charter entry, and
<nigel> .. strong buy-in from the content community. Personally I think it's a bad idea and would divert precious
<nigel> .. resources from an already diverse implementation field by introducing yet another language
<nigel> .. ostensibly with the same goals but a different syntax. If that ever comes up under a proposal for a
<nigel> .. new Charter Skynav will object to it formally because we don't think it is justified by the industry or any
<nigel> .. particular use case.
<nigel> Nigel: Thanks, Glenn that's my 3rd bullet effectively. Another is to add a feature designator, which I
<nigel> .. don't think is contentious.
<nigel> .. Another was to add a class attribute to allow external stylesheet support. That would need us to define
<nigel> .. how to populate the class attribute of every element in an ISD.
<nigel> Glenn: I think supporting external CSS stylesheets and selectors would be a step further and would like
<nigel> .. to exclude it for now. It would make it harder to get consensus - I would object to it, for example!
<nigel> .. I'm sort of in the middle on the properties themselves. I am trying to be amenable to your proposal Nigel,
<nigel> .. I see the utility in having a system that facilitates rapid adoption of CSS properties without going through
<nigel> .. a language iteration on TTML, and it would facilitate future modules where if we see a particular
<nigel> .. property being very important we could bring it in to TTML directly as a TTML style attribute.
<nigel> .. That would certainly enable some movement on your requirements Nigel.
<nigel> .. It does make things complicated and creates interoperability problems, for example TTT is probably
<nigel> .. never going to support CSS style properties.
<nigel> .. It would have to be behind a feature for sure.
<nigel> Nigel: That is part of the proposal.
<nigel> Glenn: On your last bullet about precedence, it would obviously depend on whether your system supports
<nigel> .. CSS properties. I'm open to either direction for precedence.
<nigel> .. I feel that CSS is somewhat of an overwrite and am not convinced on that yet.
<nigel> Pierre: What happens with inheritance? Do you inherit CSS styles like you do TTML styles?
<nigel> .. What if the inheritance rules are not the same in CSS and TTML? What about different length units?
<nigel> .. What's the interaction? What's the viewport?
<nigel> Glenn: Exactly, there's a whole different terminology.
<nigel> Pierre: Directions and padding are both different.
<nigel> Glenn: Individual properties are challenging. Syntactically it is easy, testing is hard.
<nigel> Pierre: The thing I have never fully understood is, in order to import additional styles, that can be done
<nigel> .. with extension attributes, literally tomorrow. BBC can experiment to its heart's content, and if it is
<nigel> .. successful and useful it can be added later. With a use, implementation, examples, semantics it is
<nigel> .. trivial to add. I do not understand why this does not meet the requirement.
<nigel> Nigel: One of the requirements is low overhead of adoption, what you're describing sounds like high overhead.
<nigel> Pierre: From an imsc.js perspective it is always high overhead - the property has to be parsed, inherited etc.
<nigel> Andreas: [scribe missed]
<nigel> Pierre: The hard part is mapping the semantics of e.g. viewport related units. The hard part is not in the
<nigel> .. syntax of the attribute.
<nigel> Glenn: Adding the modularisation system might make it much easier to add new style properties than
<nigel> .. has been the case in the past.
<atai1> q+
<nigel> q+
<nigel> Pierre: Exploring modularisation, the modules can use the TT namespace, so the module can introduce
<nigel> .. a new property, get it to FPWD, experiment with it, tweak it, then publish it, without having to change
<nigel> .. namespace and all that stuff.
<nigel> Glenn: This goes to the modularisation framework. We enumerate all the style properties in a table. We
<nigel> .. are going to have to do something to make that table extensible so that we don't have to change that
<nigel> .. table every time we add a module that defines a new property.
<nigel> .. When we have the modularisation framework in place it should be a much easier process to push out
<nigel> .. a spec for one or a few related properties. I can see it being used on a group of semantically related
<nigel> .. properties.
<nigel> .. I could see this turning into three requirements: 1. class and selector, 2. new language, 3. CSS property support.
<nigel> .. It would be much easier to process these if we divide it into multiple issues or requirements.
<nigel> ack a
<nigel> Andreas: First I think what is different from Pierre and Glenn is to have a clear selection of what can be
<nigel> .. supported specifically, i.e. which CSS properties. And then figure out what are the problems with
<nigel> .. applying it to TTML and finding a good way to represent it syntactically. I'm not sure if we need to agree
<nigel> .. on this today, but maybe we do need to agree today is that it is worthwhile not just to open the door
<nigel> .. but make a selection of what needs to be supported and deal with the difficulties of each property.
<nigel> .. I would also see it as a different module and a list of style properties. Would that satisfy your original
<nigel> .. intention NIgel?
<nigel> Nigel: I think it could, potentially. One other idea as a sort of middle ground is to create a module that
<nigel> .. defines some generic ways to add CSS properties, and maybe adds some available CSS units, and then
<nigel> .. via a registry we could whitelist specific CSS properties, adding them by consensus of this group, and
<nigel> .. for each understanding the potential overlap and clash with TTML style attributes and how to handle
<nigel> .. any such clash.
<nigel> Pierre: How do you see that a registry would be less work than updating a working draft?
<nigel> Nigel: I wouldn't propose to keep updating a WD, because that never gets to any kind of standard.
<nigel> .. I'd propose a generic Rec and then a dynamic registry.
<nigel> Pierre: From an implementation standpoint you haven't solved anything.
<nigel> Andreas: What would the publishing process be for the modules? I thought they would not be Rec track?
<nigel> Glenn: They would have to be Rec track.
<nigel> Pierre: That's the idea.
<nigel> Nigel: +1
<nigel> Andreas: Then each time you want to update you have to iterate.
<nigel> Pierre: Sure.
<nigel> Glenn: You might have one module defining property 1 and another defining property 2 and each time
<nigel> .. you rev that you have a certain level of work to do, but we can control the granularity.
<nigel> .. The TTML3 document itself would need to have some framework and mechanisms to enable the
<nigel> .. modularisation process.
<nigel> Andreas: Then I agree if the module goes through the process then a separate registry would be duplicate
<cyril> RRSAgent, pointer
<RRSAgent> See https://www.w3.org/2019/01/31-tt-irc#T14-18-13
<nigel> .. work.
<nigel> Glenn: Let's say the CSS extensions module exists and just refers to a registry, in which we bless the CSS
<nigel> .. properties for use.
<nigel> .. Then there's a quasi-generic module that does not enumerate the properties but refers to a registry.
<nigel> .. Technically speaking we don't need the registry but that gives us a process for blessing uses which
<nigel> .. makes it better for testing. If we make it completely open ended then we have no control over testing
<nigel> .. or blessing uses. Given there may be semantic issues with impedance mismatches to deal with.
<nigel> Pierre: I would make it a WD that we update rather than a registry.
<nigel> Glenn: The other option is just to define new TT style properties directly in new modules.
<nigel> Pierre: I would go down that path from the beginning, because the work will be the same in the end, no
<nigel> .. matter how you cut it.
<nigel> Glenn: Then that is an alternative option, to promote fine granular modules for making extensions to
<nigel> .. the existing suite of style properties by having, say a border style extension module and that we define
<nigel> .. some number of tts: property names that deal with the border issues that Nigel wants to deal with.
<atai1> q+
<nigel> .. The turnaround on that module could be much shorter, for, say, flex.
<nigel> Nigel: Bad example in the context of TTML!
<nigel> Glenn: You're right Pierre the work has to be done somewhere no matter what.
<nigel> ack n
<nigel> acnk a
<nigel> s/acnk a//
<nigel> Andreas: What is different, the work may be similar, but the turnaround time to publication is different.
<nigel> .. The general mechanism like Nigel proposed could be done fairly easily, camelcasing and so on, and we
<nigel> .. could bring this through the process to Rec, but if you combine it with a first list of features, then you
<nigel> .. possibly get stuck with each feature to add. If we separate it then the general mechanism is first, and
<nigel> .. if someone wants to do it then they can do in a standardised manner.
<nigel> Glenn: The risk is with interop where content authors start throwing in CSS properties right and left and
<nigel> .. make use of application specific processors and JS code to do this.
<nigel> .. Then interoperability might decrease as a result. We would have less control over testing.
<nigel> Pierre: The argument I hear is that the Rec track is too slow?
<atai1> q+
<nigel> Nigel: Yes, we want to be able to access CSS features that already on Rec track with minimal additional delay.
<nigel> Pierre: TTML is not HTML, you cannot just adopt CSS properties so easily.
<nigel> Nigel: CSS is not restricted to HTML either!
<nigel> Andreas: Concerned about time for this and other issues we have to cover. Also as an AC rep there's a
<nigel> .. large number of Recs to review.
<nigel> .. We haven't dealt with this modularisation yet, so we should not try to solve it now.
<nigel> Nigel: Thanks for that, I think other organisations are interested in the requirement too but we don't
<nigel> .. yet know the acceptable solution.
<nigel> Glenn: I just want to make clear that if we do semantic mapping it is a non-trivial process that we cannot
<nigel> .. put in a generic module definition. It would have to be on a per-property basis. Otherwise the only
<nigel> .. option is to put the semantic mapping nowhere or in a registry.
<nigel> Nigel: Where are we up to here?
<nigel> Pierre: I haven't heard anyone speak against an easy path to adding style properties to TTML.
<nigel> .. The obstacle to doing this on the Rec track should be minimal overhead and we're talking about how
<nigel> .. to make it happen.
<nigel> SUMMARY: Group agrees to look for ways to add new style properties with minimal overhead and to try to solve this in 2019.
<nigel> Cyril: There are two parts - adding new style properties and adding the class attribute. Are they both in scope?
<nigel> Nigel: There was some push-back against adding class
<nigel> Glenn: The overall goal to reduce overhead is shared.

The Timed Text Working Group just discussed Add generic CSS property functionality tt-reqs#2.

The full IRC log of that discussion

<nigel> Topic: Add generic CSS property functionality tt-reqs#2
<nigel> github: https://github.com/w3c/tt-reqs/issues/2
<nigel> Nigel: Been discussing with implementers for BBC.
<nigel> .. Thinking about adding a "decorations" approach to embellish existing semantics without affecting
<nigel> .. layout.
<nigel> .. One thing that we probably will ask for though is a change to the value of the tts:fontWeight
<nigel> .. attribute, to allow numbers as per XSL-FO and CSS, because the current two options weren't enough
<nigel> .. for the implementers.
<nigel> Glenn: I know Vlad is not on the call, but I imagine he would suggest something like using the
<nigel> .. fontVariant style by adding more richness to its value space to support parameterised fonts.
<nigel> .. One dimension or axis of those is weight along with width for example, narrow vs wide, and heavy vs light.
<nigel> .. Those are in a number of fonts, as continuous parameters that can be passed to the font
<nigel> .. rendering system to produce a continuous range of weight.
<nigel> .. If we assign integer numbers then I don't know how interoperable that would be in terms of saying
<nigel> .. which integer maps to a keyword used in the industry for labelling points on the continuous weight
<nigel> .. axis. One thing we did not do in TTML2 with fontVariant, though it was on my list and I think there's
<nigel> .. a TTML3 issue, is to bring in some of the more rich capabilities that CSS had discussed that tie it to the
<nigel> .. OpenType and other font systems to allow you to specify low level feature labels and parameters
<nigel> .. to those labels, one of which could be weight.
<nigel> .. Before we decide to add integer values to the fontWeight attribute we need to look at the bigger picture.
<nigel> Nigel: Interesting, thank you for that.
<nigel> .. I just wanted to note that thinking is ongoing.

The Timed Text Working Group just discussed Add generic CSS property functionality tt-reqs#2 (continued).

The full IRC log of that discussion

<nigel> Topic: Add generic CSS property functionality tt-reqs#2 (continued)
<nigel> github: https://github.com/w3c/tt-reqs/issues/2
<nigel> Glenn: On the class attribute, it seems to require a link to a stylesheet.
<nigel> .. If we add a class attribute we would need some way to reference it.
<nigel> Nigel: Yes we could add it as a resource like audio or font.
<nigel> Glenn: That's an interesting idea, I kind of like it, it would be different from the way SVG does it.

w3c / tt-reqs