- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 4 Feb 2021 17:30:16 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <DB8PR01MB613961A90445B1AAE0FDDA0CCAB39@DB8PR01MB6139.eurprd01.prod.exchangelabs>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2021/02/04-tt-minutes.html
We made 1 Resolution:
Resolution: After merging the open pull requests, republish TTML2 2nd Ed CR with earliest exit date as publication date + 4 weeks.
Under our Decision Policy, the review period for this resolution ends in 2 weeks, on 2021-02-18.
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
04 February 2021
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2021/01/21-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/173
[4] https://www.w3.org/2021/02/04-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Glenn, Mike, Nigel,
Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]TTML2 Open PRs
3. [7]Draft language to address font fingerprinting mitigation
(#1202). w3c/ttml2#1210
4. [8]Exiting TTML2 CR
5. [9]TTML2: Publish updated CR?
6. [10]Switching master to main branch names
7. [11]Meeting close
8. [12]Summary of resolutions
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: [13]https://github.com/w3c/ttml2/issues/1215
[13] https://github.com/w3c/ttml2/issues/1215
Nigel: As far as I can tell we have consensus on this.
… The pull request is 1216. [14]https://github.com/w3c/ttml2/
pull/1216
[14] https://github.com/w3c/ttml2/pull/1216
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: [15]https://github.com/w3c/ttml2/pull/1210
[15] https://github.com/w3c/ttml2/pull/1210
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.
[16]TTML2 IR
[16] https://www.w3.org/wiki/TimedText/TTML2SecondEditionImplementationReport
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> [17]webvtt.js
[17] https://github.com/w3c/webvtt.js
Atsushi: No
<atsushi> [18]https://github.com/w3c/webvtt.js/issues/29
[18] https://github.com/w3c/webvtt.js/issues/29
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]
Summary of resolutions
1. [19]After merging the open pull requests, republish TTML2
2nd Ed CR with earliest exit date as publication date + 4
weeks.
Minutes manually created (not a transcript), formatted by
[20]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[20] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 4 February 2021 17:30:33 UTC