16:04:57 <RRSAgent> RRSAgent has joined #tt
16:04:57 <RRSAgent> logging to https://www.w3.org/2020/11/12-tt-irc
16:04:59 <Zakim> RRSAgent, make logs Public
16:05:00 <Zakim> Meeting: Timed Text Working Group Teleconference
16:05:26 <nigel> Agenda: https://github.com/w3c/ttwg/issues/158
16:05:56 <nigel> Previous meeting: https://www.w3.org/2020/11/05-tt-minutes.html
16:06:10 <nigel> Present: Andreas, Cyril, Gary, Pierre, Nigel
16:06:14 <nigel> Chair: Gary, Nigel
16:06:46 <nigel> scribe: nigel
16:06:49 <nigel> Topic: This Meeting
16:07:08 <atsushi> (will come shortly)
16:07:29 <nigel> Nigel: [iterates through agenda] TTML2 - maybe we need to discuss the pull request for 1212
16:07:49 <nigel> .. Do we need to discuss MPEG liaison?
16:08:07 <nigel> Cyril: I don't think you've received it yet, I'm trying to track it down. I don't think we need
16:08:20 <nigel> .. it on the agenda, I think I have an action to work with Pierre on the wording, which we
16:08:25 <nigel> .. can discuss next time maybe.
16:08:42 <nigel> Nigel: Ok, let's remove that from the agenda.
16:09:03 <nigel> .. Next is 2 Process2020 topics, default branch name, and AOB.
16:09:09 <nigel> .. Is there any other business?
16:09:18 <nigel> Present+ Atsushi
16:09:37 <nigel> Cyril: There was a Media WG meeting the other day and I raised the idea of text track
16:09:43 <nigel> .. support in MSE and there was some good feedback.
16:09:51 <nigel> Nigel: OK, AOB+ that.
16:10:08 <nigel> .. One from me: status of TTML Profile Registry publication.
16:10:42 <atai> atai has joined #tt
16:11:02 <nigel> Topic: Remove applicability of tts:direction on <p> w3c/ttml2#1214
16:11:09 <nigel> github: https://github.com/w3c/ttml2/pull/1214
16:12:11 <nigel> Pierre: My summary: long discussion on #1211. Boils down to what does tts:direction
16:12:20 <nigel> .. actually do when applied to p. 4 options available:
16:12:36 <nigel> .. 1. Keep things exactly as is by having tts:direction on p have no effect on the inline progression direction.
16:12:58 <nigel> .. This is probably what TTML and XSL-FO have in mind but is incompatible with CSS3.
16:13:14 <nigel> .. 2. Make things consistent with current CSS by having tts:direction on p override the inline
16:13:26 <nigel> .. progression direction set by the writing mode.
16:13:35 <nigel> .. This is inconsistent with existing TTML and XSL-FO.
16:13:49 <nigel> .. 3. Make tts:direction not applicable to p and instead set the paragraph embedding levels differently.
16:14:08 <nigel> .. 4. Keep things as is but note that the result of applying tts:direction on p is implementation-dependent.
16:14:17 <cyril> cyril has joined #tt
16:14:26 <nigel> .. The PR I propose is a compromise, option 3 here.
16:14:44 <nigel> .. It makes tts:direction not applicable on p, removes the opportunity for inconsistency.
16:15:04 <nigel> .. Instead the paragraph embedded level is set from the computed value of the
16:15:24 <nigel> .. writingMode on region, so it is always set to the inline progression direction as determined on region.
16:15:44 <nigel> .. It's consistent with the spirit of TTML, and compatible with modern CSS, and if we ever
16:15:55 <nigel> .. change our mind we can make tts:direction applicable again and maybe then it will be
16:15:58 <nigel> .. more obvious what to do.
16:16:13 <nigel> .. As an aside, we have to decide what to do with unicodeBidi on p, which should be easier
16:16:16 <nigel> .. to deal with.
16:16:16 <atai> q+
16:16:20 <nigel> ack at
16:16:39 <nigel> Andreas: I have minor comments on the pull request but in general I fully agree with the
16:16:46 <nigel> .. intent, for the reasons Pierre mentioned.
16:16:50 <nigel> q+
16:16:56 <nigel> ack nige
16:17:24 <nigel> Nigel: What's the impact in terms of potentially breaking existing documents?
16:17:50 <nigel> Pierre: It's really hard to tell. I've not seen many if any right to left IMSC documents in the wild.
16:18:01 <atai> q+
16:18:13 <nigel> .. The few I have seen I think just set the writingMode and that's it, without any direction.
16:18:20 <nigel> .. I don't know, in terms of hard numbers.
16:18:28 <nigel> .. If we're going to settle on something now is a good time.
16:19:01 <nigel> Nigel: Not quite what I meant - rather, if there were a document with direction on p, and
16:19:06 <nigel> .. we made this change, what would be the impact?
16:19:24 <nigel> Pierre: If the author set direction to explicitly set the paragraph embedding level explicitly,
16:19:35 <nigel> .. presumably that would be consistent with the writingMode, because it would be unusual
16:19:45 <nigel> .. to set the two unequal, so there would be no change.
16:19:57 <nigel> .. If an author had used tts:direction on p to override the inline progression direction set
16:20:07 <nigel> .. by writingMode that would break those documents. Why would someone do that? Maybe
16:20:20 <nigel> .. because they think they're in CSS? This approach would break those documents, possibly.
16:20:31 <nigel> ack a
16:20:51 <nigel> Andreas: If you specify tts:direction on p or reference a style through some inheritance then
16:21:06 <nigel> .. it is actually specified for p. It is not an error - you can do it even if there is no effect.
16:21:23 <nigel> .. The question about the change breaking, my interpretation is that you would set direction
16:21:35 <nigel> .. on p and there is a deterministic behaviour expected for the rendering. From the long
16:21:48 <nigel> .. long thread we had on that, where all the experts were discussing and could not really
16:22:01 <nigel> .. get a grip on it and agree, it seems to be agreed that there's no deterministic behaviour
16:22:25 <nigel> .. so therefore it doesn't break anything. On the contrary, if you do that, it might not even
16:22:38 <nigel> .. break an existing application. I would argue that if an application would render it the
16:22:48 <nigel> .. way CSS3 does it, it would maybe be okay, but at least not an error.
16:23:03 <nigel> .. If you now fix and make normative a deterministic behaviour then it is very clear that
16:23:09 <nigel> .. some implementation is no longer conformant.
16:23:32 <nigel> Nigel: Thanks, that's a good point, definitely food for thought.
16:24:47 <nigel> .. I think what you're saying is that this change removes from reachability some features
16:25:18 <nigel> .. of CSS, in that you couldn't get a mapping from a TTML2 document by a processor
16:25:31 <cyril> q+
16:25:35 <nigel> .. conformant to this PR, which would end up setting the direction property on a p element.
16:25:47 <nigel> .. If you're mapping from TTML to HTML + CSS, say.
16:25:57 <nigel> .. Is that fair?
16:27:06 <nigel> Pierre: exactly. The only place where you would set the direction property would be the
16:27:18 <nigel> .. equivalent of the region TTML element, which is fine because that's where the inline
16:27:22 <nigel> .. progression direction is set.
16:27:25 <nigel> ack cy
16:27:45 <nigel> Cyril: When Pierre said he hadn't seen Arabic documents in the wild I was wondering what
16:27:58 <nigel> .. we do at Netflix. We have 100,000s Arabic documents. I picked one completely at random
16:28:04 <nigel> .. and it uses direction on p.
16:28:08 <nigel> .. I will paste the example.
16:28:18 <nigel> .. The document I have has no writingMode on the region at all.
16:28:22 <cyril>       <p xml:id="p1" begin="00:02:15:02" end="00:02:16:16"><span tts:unicodeBidi="embed" tts:direction="rtl">اجعل نوم أخيك...</span></p>
16:28:40 <pal> pal has joined #tt
16:28:52 <nigel> Andreas: The direction is on span not p
16:28:59 <nigel> Cyril: Sorry, I need to wake up!
16:29:04 <nigel> Andreas: Exactly how it should be used.
16:29:15 <nigel> Cyril: I will try to see if we ever use direction on a p
16:29:20 <nigel> Pierre: In general that's the question.
16:31:15 <nigel> Nigel: It seems like Netflix is the best placed to give us real world data.
16:31:34 <atai> q+
16:31:35 <nigel> Cyril: I'm looking. I think the difficulty is checking various vendors. I suspect that if all
16:31:48 <nigel> .. vendors use the same tool, given there's a restricted set of production tools, once we have
16:32:01 <nigel> .. looked at the output of all those tools, if none of them use direction on p then we're
16:32:04 <nigel> .. probably in good shape.
16:32:10 <cyril>       <p style="style.default" region="region.after.center" begin="00:00:12:00" end="00:00:14:07"><span tts:direction="rtl">مسلسلات NETFLIX الأصلية</span></p>
16:32:25 <nigel> Pierre: If they use it on a p and it is consistent with writingMode then it's not terrible.
16:32:38 <nigel> Cyril: Another example above, again nothing on the p or region
16:32:55 <nigel> .. I will run some queries before expressing an opinion on the change.
16:32:57 <nigel> ack at
16:33:10 <nigel> Andreas: It's also important to see what would happen if you removed it if you do find it.
16:33:27 <nigel> .. It should be an interoperable behaviour, and at least it should be tested.
16:33:57 <nigel> Pierre: I will work on implementing Andreas's suggestions - they don't change really the
16:34:01 <nigel> .. fundamental proposal.
16:34:05 <atai> q+
16:34:14 <nigel> .. I do want to understand why the group concluded that unicodeBidi is not applicable on p
16:34:27 <nigel> .. when CSS does say some values are applicable to p. I'm happy either way. It would be
16:34:32 <nigel> .. good to get confirmation there.
16:34:35 <nigel> ack at
16:34:47 <nigel> Andreas: I've seen in your comments you asked for a reference. I couldn't find the discussion
16:34:59 <nigel> .. part but in one of Glenn's latest comment he said he considered removing the application
16:35:15 <nigel> .. of unicodeBidi from p in a later version and that's my recollection from the discussion as
16:35:30 <nigel> .. well, and there's issue #1212 that says to do this.
16:35:44 <nigel> Pierre: If you go to the latest CSS drafts, some values of unicode-bidi that do have an impact
16:35:58 <nigel> .. on p, including embed. We should point to some discussion or assessment in the PR I think.
16:36:16 <nigel> Andreas: There is a part of the minutes where Elika explained what they do if it is applied to p.
16:36:30 <nigel> Pierre: yes, it's in the CSS spec. I think that's less urgent.
16:36:35 <nigel> .. My goal is to close this by end of year.
16:37:13 <nigel> Nigel: Good discussion on this given the PR is only 11 hours old so already a massive step
16:37:18 <nigel> .. forward, let's keep reviewing.
16:37:28 <nigel> SUMMARY: Continue reviewing
16:38:01 <nigel> Topic: Process 2020 - Living Standards
16:38:14 <nigel> Gary: I wanted to get your thoughts on Living Standards in particular because of how
16:38:26 <nigel> .. tied WebVTT is to the web platform, and because of how it seems that living standards,
16:38:38 <nigel> .. if you've never been a Rec then it's a bit easier to become a living standard.
16:38:39 <nigel> q+
16:38:55 <nigel> .. It seems like adopting it for WebVTT makes sense, since it allows us to get a minimal
16:39:02 <nigel> .. release out and then add features as we go along.
16:39:09 <nigel> ack ni
16:39:41 <nigel> Nigel: By living standard do you mean continual CR or a Rec that can be updated.
16:40:02 <nigel> Gary: I imagined Rec that allows us to update, and provides a path for moving ahead with WebVTT.
16:40:11 <nigel> .. It allows new features to be added.
16:40:26 <nigel> Nigel: Thanks, any views?
16:40:42 <nigel> Andreas: Just for my understanding, isn't this what Nigel calls a continuously updated CR?
16:40:53 <nigel> .. The other way round would be to come to Rec status, but is that what you mean?
16:41:00 <atsushi> https://www.w3.org/2020/Process-20200915/#publishing-crrs
16:41:35 <nigel> Gary: Process2020 does have a new feature for Recs where you say that new features
16:41:37 <nigel> .. can be added.
16:41:49 <nigel> Nigel: My reading is that both models exist.
16:42:02 <atsushi> https://www.w3.org/2020/Process-20200915/#rec-track
16:42:05 <nigel> Gary: Atsushi put a link above - there's a section about it
16:43:25 <nigel> Nigel: My understanding is that P2020 allows new features to be added to a Rec but
16:43:40 <nigel> .. labelled as being like CR status features, and when they've met the requirements
16:43:46 <nigel> .. for Rec the labels can be removed.
16:44:02 <nigel> Atsushi: The group can publish CR snapshots
16:44:11 <nigel> Nigel: I think Gary's proposal is not about CR snapshots?
16:44:21 <nigel> Andreas: Currently WebVTT is still in CR status?
16:44:23 <nigel> Gary: yes
16:44:30 <nigel> Andreas: But you still intend to bring it to Rec?
16:44:35 <nigel> Gary: Yes that would be good for it.
16:44:46 <nigel> Andreas: And then you have the possibility to add features after Rec?
16:45:03 <nigel> Gary: Yes so you can add features individually instead of going through the entire process.
16:45:52 <nigel> Nigel: Imagine turning the clock back for IMSC 1.1 and allowing this to be done to add the
16:46:03 <nigel> .. font feature - it would have made things much easier. As long as there's a dated versioned
16:46:10 <nigel> .. link that can be referenced externally.
16:46:22 <nigel> q?
16:46:49 <nigel> Nigel: I think there has to be something in the document itself that says it will use this model?
16:47:00 <nigel> Gary: Yes there's a whole bunch of things that need to be updated and incorporated before
16:47:13 <nigel> .. it can be moved on, and the new end time request from Rob that we can discuss another day.
16:47:34 <atsushi> might be this one(?): https://www.w3.org/2020/Process-20200915/#revised-rec-features
16:47:40 <nigel> Nigel: CfC or proposal to make this change and allow people to consider it?
16:47:59 <nigel> Gary: Yes.
16:48:06 <nigel> .. Atsushi that link above is the one to start with.
16:48:33 <nigel> Atsushi: Sorry I misunderstood - it's not CRRS but a way to add new features to Recs, and
16:48:37 <nigel> .. allow the change to be reviewed.
16:48:58 <nigel> Nigel: Yes, it would involve incorporating "Candidate Changes"
16:49:05 <atsushi> s/CRRS/CRS/
16:49:13 <nigel> Atsushi: Yes, 6.2.11.4 and 6.2.11.5 would need to be applied.
16:49:45 <nigel> Nigel: Suggest emailing a list of steps and CfC to allow people to think about it?
16:49:49 <nigel> Gary: Yes sounds good
16:50:07 <nigel> Atsushi: P2020 is already applied, and this is also about revising a Rec after publication.
16:50:28 <nigel> Nigel: I think the document itself needs to explain the working mode.
16:50:37 <nigel> Gary: I believe so, if we want to do it at Rec.
16:50:51 <nigel> Atsushi: First we need to go to Rec, and after that add in new features.
16:51:07 <nigel> Gary: Yes that's the plan, to get the pared down thing to Rec with the addition that says
16:51:14 <nigel> .. new features can be amended, and then we can add new features.
16:51:51 <nigel> Nigel: Is your plan to move "at risk" features to Candidate Changes to allow transition to Rec
16:51:54 <nigel> .. more easily?
16:52:04 <nigel> Gary: Yes I think so, at least the ones we think should definitely stay in.
16:52:16 <nigel> Nigel: Thanks that would be useful to explain.
16:52:27 <nigel> Gary: One final thing: maybe it makes sense to transitioning IMSC to this working mode.
16:52:48 <nigel> .. I know it is more complicated but would be good for any other specs being maintained.
16:53:04 <nigel> Pierre: Gary, I think it's really worth exploring and look forward to seeing how it works for WebVTT!
16:53:24 <nigel> Gary: It should be easier for WebVTT because it isn't at Rec.
16:53:41 <nigel> Pierre: I would like to know what the game plan is for version numbers. Just a year, or a date?
16:53:53 <nigel> .. Or a 1st Ed, 2nd Ed, etc. It's worth thinking about how we're going to do this.
16:53:56 <nigel> Gary: Good thought.
16:54:10 <nigel> Pierre: I don't particularly think that the CSS way is very helpful - I find it confusing.
16:54:26 <nigel> Gary: I'm not sure how it's done for the Rec. For the CR model there are dated snapshots.
16:54:35 <nigel> Pierre: That's clear at least. You pick one snapshot and implement it.
16:54:49 <nigel> Gary: That's something I will figure out before sending the email.
16:55:01 <nigel> Pierre: I'm happy to kick around ideas if you want to ping me. That's been a challenge for
16:55:14 <nigel> .. IMSC, so maybe there's a better way of doing this going forward. Right now we're discussing
16:55:29 <nigel> .. a potential change to TTML2 which is in CR. Do we withhold it, put it in the CR... The way
16:55:38 <nigel> .. the world is going how to update the spec is really important.
16:56:23 <nigel> Topic: Process 2020 - Patent Policy 2020
16:56:30 <nigel> Atsushi: We need to ask the question to W3M whether we need to do something.
16:56:50 <nigel> .. Two options:
16:57:05 <nigel> .. 1. W3C batch update on various WG Charters to update to patent policy 2020, soon.
16:57:19 <nigel> .. or 2. postpone application until our next rechartering in 2022.
16:57:30 <nigel> .. There will be a WBS on this.
16:57:50 <nigel> Nigel: From a practical perspective I'm not sure the impact on us?
16:58:03 <nigel> Pierre: Isn't there an interaction between the new patent policy and the ability to do CR snapshots etc?
16:58:18 <nigel> .. To the extent that we want to consider the new mode of work we might need to switch.
16:58:32 <nigel> Atsushi: For CRD / CRS we would need Patent Policy 2020.
16:58:39 <nigel> Nigel: Nobody is proposing to use that at the moment.
16:58:57 <atsushi> https://lists.w3.org/Archives/Member/chairs/2020OctDec/0028.html (survey email)
16:59:33 <nigel> Topic: AOB - text tracks and MSE
16:59:46 <nigel> Cyril: Quick update: the Media WG met and started triaging issues for MSE v2.
16:59:55 <nigel> .. Three categories: editorial, in scope and out of scope backlog.
17:00:06 <nigel> .. The Media WG encourages people to review the issues in scope, and the out of scope
17:00:24 <nigel> .. ones if they care about them. The list doesn't include Text Track support in MSE in scope or
17:00:38 <nigel> .. out of scope. I asked the group - they were curious to know what it meant but there was
17:00:45 <nigel> .. no immediate position so I take it as a good sign.
17:01:07 <nigel> .. I encourage TTWG participants who are also Media WG to create an issue if they are interested.
17:01:19 <nigel> Nigel: Maybe I could talk to you about this offline Cyril?
17:01:23 <nigel> Cyril: Yes
17:02:04 <nigel> Topic: Meeting close
17:02:26 <nigel> Nigel: Thanks, we haven't managed to cover Default Branch Name or the AOB on TTML Profile
17:02:41 <nigel> .. Registry publication so will postpone those or cover offline. We're out of time for today,
17:02:49 <nigel> .. so I'll adjourn. Thanks everyone! [adjourns meeting]
17:02:53 <nigel> rrsagent, make minutes v2
17:02:53 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/12-tt-minutes.html nigel
17:20:08 <nigel> scribeOptions: -final -noEmbedDiagnostics
17:20:11 <nigel> zakim, end meeting
17:20:11 <Zakim> As of this point the attendees have been Andreas, Cyril, Gary, Pierre, Nigel, Atsushi
17:20:13 <Zakim> RRSAgent, please draft minutes v2
17:20:13 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/12-tt-minutes.html Zakim
17:20:16 <Zakim> I am happy to have been of service, nigel; please remember to excuse RRSAgent.  Goodbye
17:20:20 <Zakim> Zakim has left #tt
17:20:36 <nigel> rrsagent, excuse us
17:20:36 <RRSAgent> I see no action items