Meeting minutes
This meeting
Nigel: For today, we have some TTML2 items to discuss, and I've left the 2021 workplan placeholder in.
… Also switching master to main git branch names
… Any other business? Or points to make sure we cover?
TTML2 Open PRs
github: https://
Nigel: As far as I can tell we have consensus on this.
… The pull request is 1216. https://
Andreas: I looked at the discussion and the imscJS change. Looks good to me.
… Clarifies what is implied, how lineHeight is computed.
… When looking through I wondered, and we could discuss perhaps.
… Why in 10.2.27 tts:lineHeight, there is a very detailed algorithm for "normal" and how the different properties work together,
… but we don't have it for other values.
… I think that was part of the confusion before. Now it is clear that fontSize applies to p, that's fine.
… But in the lineHeight section it is not that clear how fontSize is used when the value is not "normal".
Glenn: Are you commenting on this PR or raising this issue to discuss again? I thought we had consensus on how to handle it.
Andreas: It's a question, not an opposition to the PR.
Glenn: Okay then you support the PR?
Andreas: I would like to discuss the question first.
… It's of course related. If we fix this problem, I would like the explanation why we don't have some explanation in this section.
Glenn: Okay. I agree we don't say anything about the non-normal case specifically.
… It isn't covered by the multi-point algorithm.
… The only thing that could mean is that the semantics of line height (see the note about line stacking too) is the derivation section,
… refers to XSL-FO which refers to CSS. So the only thing one can do is interpret it from that information.
… There's also a statement about the intent underneath the derivation.
… It discusses the idea of being compatible with XSL-FO 1.1 and CSS 2.
… I interpret that intention to be that it comes from the derivation, and that's for both normal and non-normal.
… That generally applies to many of our other properties like fontFamily, fontSize, fontWeight.
… We don't go into a whole discussion of the semantics. We effectively delegate to XSL-FO as a default.
Nigel: The question that would excite me, additional to this issue and PR, is has CSS moved on from the CSS2 semantic, and what are the deltas,
… and what should we do about them?
Pierre: Changing imscJS to make these attributes applicable to p, and regenerating all the text vectors, it results in sometimes
… significant change, in a way that isn't always easily predictable. So the algorithm is likely not trivial.
Andreas: The issue is really complex. It's not easy to go through XSL-FO etc and it isn't intuitive.
… The PR solves this concrete implementation problem where fontSize was not applied to p and there was an undesired rendering behaviour.
… The Pull Request is fine.
… But in general for the general reader it is not really clear how fontSize on p is really used.
… I agree with Nigel that it is a bigger problem, and again, like in writingMode, the combination of TTML, XSL-FO, CSS2 (not 2.1!) and what
… CSS does now and what is used for rendering. As it seems, I think I have heard or read that on purpose it is possibly a bit weak.
… It is maybe not deterministic what is going on there. For a spec it is not satisfying, but I don't have an answer.
Glenn: To comment on it not being intuitive, I would agree wholeheartedly and I would go farther and say it is highly impractical to do
… anything about it. It is such a complex piece of semantics that it is never going to be intuitive. Even if you only look at CSS this is true.
… So you're asking for something we can't deliver if you want an intuitive explanation.
… However historically we had information about derivation about each style property, that refers to a particular section of XSL-FO or CSS.
… Nigel did a lot of work to move it into the appendix and elaborate it.
… We have a normative table entry from the style to the derivation appendix information, which happens to be non-normative,
… because we did not want to demand it, but in effect we do demand it. That's an area where we could entertain making the derivation
… section normative in the future, because in practice we treat it as normative.
… The other thing, regarding Nigel's comment about changing from CSS2 to CSS3, that is also impractical. We're so embedded to
… XSL-FO semantically, which is tied to CSS2, so I think what we would have to do practically is consider on a case by case basis some specific
… upgrades to semantics. But if we did that we would have to find a way to accommodate any breaking changes that would reflect in our
… tests. Then we would need a migration path that does not invalidate existing content. You can't simply change that and invalidate the old
… behaviour (or deprecate). It would need to be a new major version, maybe even a different namespace URI to distinguish the semantic change.
Draft language to address font fingerprinting mitigation (#1202). w3c/ttml2#1210
github: https://
Nigel: I reviewed this (opened since July), and think it is an improvement and a step on the way but maybe not the end of the changes we need.
Andreas: I added one comment to the pull request where the addition is to strongly recommend not to dereference external fonts.
… In the current pull request it says "should consider not dereferencing"
… I think the "consider" should be removed.
… The reasoning is that we had a long discussion with PING, who asked for more, they wanted it normative.
… It is now strong language in a non-normative section.
… I think we should not weaken it more, and it would be better to say "should not do it".
Nigel: I think Glenn already indicated he would accept it, and I certainly would.
Glenn: I don't like it but I could live with it.
Nigel: I can't see Andreas's comment on the pull request, only my proposal.
Andreas: I commented it but I maybe need to complete the review.
Nigel: If we make that change then my change would not be needed.
… I would like to merge this - any requests for more time to review?
group: [no requests for more time]
Nigel: In that case when Andreas's change has been processed we should be good to merge.
SUMMARY: Andreas's proposal to be applied
Exiting TTML2 CR
Nigel: I made the modifications to the IR we discussed last time.
… I didn't remove the other content but that would be my next step.
Nigel: [shows new table]
… For example #audio points to two tests, and has one pass per test, and I would be claiming that particular change is a pass for CR exit.
… One question is: does this help?
… Second question: would it be improved by subdividing further by pull request?
Cyril: Not sure the pull request would bring anything
Nigel: I am wondering if there are any other implementations we could add?
Pierre: I need to look in detail. I need to see what's needed and how much work it is.
Nigel: Note that in some cases tests are listed multiple times when they apply to multiple features.
Pierre: Basically all of them?
Nigel: Yes!
Pierre: Thanks.
Glenn: I expect to fill in the presentation for at least the Skynav implementation.
… Most of those that are blank under presentation are implemented. I need to verify those and enter them into this table.
Pierre: Okay, thanks.
Glenn: That doesn't help us with the second implementation.
Nigel: Thanks, just wanted to share progress.
TTML2: Publish updated CR?
Nigel: Given that we have two worthwhile pull requests to merge, and it is unlikely to practically affect our exit date,
… I propose to publish a new CR.
Glenn: Seems like a good idea. I believe all the changes since last CR are editorial.
Nigel: I haven't reviewed but I think that's true.
Glenn: I agree, and can roll it out as soon as we wrap up these current PRs.
… There may be some other issues we don't have PRs for, but we can do those later.
Nigel: Agreed. Any other views?
Cyril: I'm wondering if we want to take the opportunity to mark features as at risk?
Nigel: We can't easily mark a feature as at risk because all the features are in TTML2 already. They're just changes to the features
… and we don't have an easy way to indicate the change as being at risk.
Cyril: Ok I will think about it, thank you.
PROPOSAL: After merging the open pull requests, republish TTML2 2nd Ed CR with earliest exit date as publication date + 4 weeks.
Nigel: Any objections?
Resolution: After merging the open pull requests, republish TTML2 2nd Ed CR with earliest exit date as publication date + 4 weeks.
Nigel: There will be our 2 week decision review period starting now.
Switching master to main branch names
Nigel: Atsushi has been preparing this.
Atsushi: I hope you all read my email. Most of all it is work my side, and you just need to change your local changes to be against main not master.
… Change your local checkout from github.
Gary: Also any forks if you have them
Atsushi: Yes
Nigel: I think we should just go ahead and do this now, and deal with any problems later.
… It's for all TTWG's repos.
… Any reason not to?
<glenn> need to drop off
Atsushi: One point - I have opened a PR to add w3c.json on the webvtt.js - it is related to WebVTT. Is this fine?
Nigel: I've never heard of that repo.
Gary: Me neither. I have seen the page it links to, but I did not realise it was a w3c repo.
Nigel: Is it a fork?
<gkatsev> webvtt.js
Atsushi: No
<atsushi> https://
Nigel: I have no view
… Looks like Dom has been working on this
Nigel: In conclusion, please go ahead with changing master to main.
Atsushi: Sure, it will be tomorrow.
Nigel: Thank you, and you'll let us know when you've done it.
Atsushi: I did a similar thing on Immersive Web CG so no issues should happen, I believe.
Meeting close
Nigel: The 2021 workplan topic was a placeholder - it seems we have nothing to discuss there, so we've completed our agenda.
… So let's adjourn. See you in two weeks everyone. [adjourns meeting]