Check dependency on CSS 3 Color.

[swickr]

The (normative) reference to CSS3 Color is out of date. Noticing this led me to look at how the CSS Color reference was used. In 8.2.13 the prose might be interpreted as an informative reference but it's not clear to me that the specification of opacity in 8.2.13 is sufficient on its own for an implementor; i.e. the CSS3 Color specification of opacity is important material for the developer.

Please clarify this dependency; if the specification of tts:opacity does depend on CSS3 Color then the reference should be updated as well.

[nigelmegitt]

That the reference is out of date was missed in the thick of CR publication and implementation report preparation.

I am uncertain how we arrived at this state, but it seems that all of the references to [CSS3 Color] are in non-normative sections, butthe bibliographic entry is in the Normative list in Appendix G.

In itself that is not harmful; placing an informatively referenced document in a normative reference list does not make the reference normative.

The situation was the same in TTML1 2nd Edition, so in that sense it has not become worse in 3rd Edition.

However I expect the TTWG to push back against making any changes now due to time pressures if that requires us to go around a further CR loop; rather, from previous discussions, I expect we would consider this for an erratum or future edition.

From a technical perspective, considering changing the reference to point to the 2018 Rec of CSS3 Color, I have not (so far) heard or seen any indication that such a change would cause any problems, since the clarifications in CSS3 Color have minimal if any impact on TTML implementations. My only concern would be if doing so would trigger a process delay to publication of TTML1 3rd Edition.

Further info on this specific change:

• tts:opacity is the only TTML1 style attribute that references CSS3 Color.
• It is also the only TTML2 style attribute that references CSS3 Color.
• The changes made to CSS3 Color's opacity property in the 2018 version vsthe 2011 version appear to be essentially editorial clarifications wherethe intent is unchanged but the language is improved.
• The use of tts:opacity in TTML1 applies only to region elements, which are positioned.
• The change in CSS3 Color's opacity property can be viewed most easily using the diff tool

Whenever we fix the reference, it should also be applied to TTML2. For reference, IMSC 1.1 does not reference CSS3 Color.

[nigelmegitt]

Relating to the specific point about clarifying the dependency, I think the most straightforward change to make would be to move the reference definition from the normative References appendix to the non-normative Other References appendix. Would that single change satisfy you in terms of this issue @swickr ?

[skynavga]

@nigelmegitt regarding

That the reference is out of date was missed in the thick of CR publication and implementation report preparation.

This is not an accurate characterization IMO. Our policy has been to make reference to specific, dated reference documents (for reasons of stability), which means that we do not (at least in the history of TTML) have a policy of updating referenced documents simply because they have changed. [And from what I can see in this place, it hasn't even changed yet, but is in the process of being revised at some future date.]

The only reasons we have updated specific, dated references is when there is a normative requirement to do so, and no such requirement has been put forward in this case.

Finally, I would note that TTML2 uses the same reference as presently in TTML1, and that changing the latter would create an inconsistency with the latter.

My proposal is TAKE NO ACTION. If someone wants to file a issue in the future that would drive updating both TTML1 and TTML2 references, then they can do so, but it should be based on substantive reasons, and not merely because the specification has been updated.

[skynavga]

@swickr @nigelmegitt May I ask why [1] reports that an "Edited Recommendation is in progress!" as opposed to having [1] report being superseded, e.g., by [2]?

[1] https://www.w3.org/TR/2011/REC-css3-color-20110607/ [2] https://www.w3.org/TR/css-color-3/

[skynavga]

@swickr @nigelmegitt I have had more time to review this, and have concluded that

1. there is no problem (IMO) with continuing to keep the reference in the normative references section, but I agree that it is not used in a normative fashion by the normative text of TTML1 (or TTML2), in which case it could easily be moved to the informative references section;

2. regarding whether to update the reference to point at the newer June 2018 document, it doesn't matter either way, as the only reason the reference here is to informatively define its historical derivation; as such, I am neutral on updating the reference;

3. if updating the reference, or moving it to the informative references section would prevent us from going to PR now (on either or both TTML1 and TTML2), then we should not make these changes now, but instead wait for the next edition;

[nigelmegitt]

This is not an accurate characterization IMO

@skynavga You're right it's not the full picture. It is true that nobody raised the fact that CSS3 Color had been republished, but it is also true that tts:opacity did not fall within the scope of the issues that we wished to address in this edition of TTML1, and thus we made no change either to the section on tts:opacity or to the reference made from that section.

I agree with your assessment in https://github.com/w3c/ttml1/issues/370#issuecomment-425574737

@swickr To summarise:

• we are seeking to update an existing Recommendation with improvements to those sections that have given rise to issues so far;
• this is a new issue, not yet considered by the wider TTWG;
• we are also seeking to make the delta between TTML2 and this new edition of TTML1 as small as possible, and to avoid introducing incompatibilities with previous versions of TTML without strong cause;
• prior to this issue being raised, we received no wide review feedback or implementation feedback suggesting that either the status of the reference is an issue or that the referenced text is an issue;
• nevertheless, an update to the CSS3 Color reference (in both TTML1 3rd Edition and TTML2) would most likely not in itself be problematic (see review of options below);
• due to dependencies with other standards bodies (e.g. MPEG) it would be problematic to introduce process delays to the transition of PR, unless a significant problem is discovered;

Our options to resolve this issue seem to be:

1. defer to a future edition, of both TTML1 and TTML2;
2. impose with only a partial WG review some changes to both TTML1 3rd Edition and TTML2, where those changes could include (not mutually exclusively): a. Moving the reference to CSS3 Color to the Other References appendix; b. Updating the referenced CSS3 Color spec to the 2018 Recommendation.

The risk of 2a. appears minimal in both impact and likelihood. The risk of 2b. appears very small in both impact and likelihood. The impact, if any, is that the clarified CSS3 Color text might introduce some discrepancies between existing TTML presentation implementations and the CSS semantics. We have had no opportunity to assess the likelihood because this change was not introduced in a CR. Nevertheless, from reading the changes to the specification text, it is my strong impression that it doesn't matter either way as @skynavga concluded above.

Since you've raised this as Director in assessing the transition request to PR, I think we need to hand this back to you to make the call on which options to take.

[palemieux]

I would not rush to change the reference to REC-css3-color-20110607, unless using this reference is fatal.

I would instead study and resolve this issue at the next opportunity, e.g. next edition.

[swickr]

If the WG prefers not to update the reference at this time, that's OK. My deeper question was whether there actually is a normative dependency or not; i.e. is full understanding of the TTML1 specification for opacity dependent upon understanding the CSS specification as well.

This issue is not critical path advancement to Proposed Recommendation.

[nigelmegitt]

@swickr Thank you for that.

[css-meeting-bot]

The Timed Text Working Group just discussed Check dependency on CSS 3 Color. ttml1#370, and agreed to the following:

• RESOLUTION: Defer this issue to a future edition unless there is a strong call from the AC review to make a change, in which case we may revisit this based on whatever AC review comment applies.

The full IRC log of that discussion

<nigel> Topic: Check dependency on CSS 3 Color. ttml1#370
<nigel> github: https://github.com/w3c/ttml1/issues/370
<nigel> Glenn: Background here would be useful. The reason we made it a normative reference
<nigel> .. was that at the time we published TTML1 there was no formal definition of opacity in
<nigel> .. either CSS-land or XSL-land. The only thing we could go from was the CSS3 color work
<nigel> .. that was under way and was just arriving at Rec in its first edition.
<nigel> s/n./n
<nigel> .. as we were coming to close on TTML1 (1st edition).
<nigel> .. There was some discussion about whether to make it informative or normative.
<nigel> .. One of the comments was that there was potential dependency. Being conservative we
<nigel> .. decided to bump it up to be a normative reference.
<nigel> .. Looking back, that was probably not the best thing to do. It falls into the category
<nigel> .. of some of the other CSS specs we have used for derivation purposes.
<nigel> .. Also, earlier, some of the derivations were not in notes; now they all are in notes.
<nigel> .. That's the history. My conclusion after going through this cycle with Ralph would be
<nigel> .. that it wouldn't hurt to make it an informative reference and be aligned with our other
<nigel> .. derivation references.
<nigel> .. XSL is a normative reference because we used a lot of its terminology and model, so
<nigel> .. we do have normative derivations from XSL.
<nigel> .. I wouldn't mind keeping the reference in the normative section or moving it to the
<nigel> .. informative section. I would probably give preference to moving to informative for
<nigel> .. consistency, in the next edition, not now unless someone is screaming for it now.
<nigel> .. If a commenter says "support but only with these changes" then that could trigger
<nigel> .. making changes to the spec.
<nigel> .. We can't rule that out.
<nigel> Nigel: Thanks, that makes sense.
<nigel> .. In my view the reference is only made from informative sections so it is an informative
<nigel> .. reference. It is moot whether the bibliography entry is in the normative or informative
<nigel> .. section. We could move it with no change in status.
<nigel> Glenn: I agree, for consistency we should move it to the informative references section.
<nigel> Nigel: If we think this is only an editorial change, could we make this change?
<nigel> Pierre: For the record, I think we should not touch the document.
<nigel> Glenn: Unless someone is really calling for it, outside this group, I agree.
<nigel> Thierry: If we have an AC rep complaining then we could look at this.
<nigel> Glenn: Yes
<nigel> Nigel: My question Thierry was really about the possible, not what we should do.
<nigel> Thierry: If its an editorial change, we could do it, but if its a bigger change then that's different.
<nigel> Nigel: Okay I think I'm hearing consensus for making no change immediately, and deferring
<nigel> .. this to a future edition, unless there is a strong call from the AC review to make a change,
<nigel> .. in which case we will review based on the AC review comments we receive.
<nigel> RESOLUTION: Defer this issue to a future edition unless there is a strong call from the AC review to make a change, in which case we may revisit this based on whatever AC review comment applies.