15:01:12 RRSAgent has joined #tt 15:01:12 logging to https://www.w3.org/2022/03/31-tt-irc 15:01:15 RRSAgent, make logs Public 15:01:17 Meeting: Timed Text Working Group Teleconference 15:01:20 atsushi has joined #tt 15:01:20 Agenda: https://github.com/w3c/ttwg/issues/213 15:01:31 Previous meeting: https://www.w3.org/2022/03/17-tt-minutes.html 15:01:53 Present: Andreas, Philippe, Nigel, Atsushi, Pierre 15:01:57 Chair: Nigel 15:01:58 scribe: nigel 15:02:18 atai has joined #tt 15:03:46 Topic: This meeting 15:03:59 Chair: Nigel, Gary 15:04:02 Present+ Gary 15:04:27 Nigel: Today we have quick updates on IMSC HRM and DAPT REQs 15:04:32 .. Rechartering status update 15:04:42 Present+ Cyril 15:05:04 .. I kept the behaviour with controls agenda on the agenda. 15:05:08 Gary: Might be something to discuss 15:05:33 Nigel: I did not add a topic that Mike raised on the reflector, about low latency contribution requirements 15:05:41 .. so I suggest we add that for next meeting. 15:05:49 .. Is there any other business? 15:05:57 [no other business] 15:06:36 Topic: IMSC HRM WR Status update 15:06:49 Nigel: The action is with me to send Wide Review comms out on the IMSC HRM. 15:07:01 .. It was waiting on some issues to be resolved, and I think they are now all done. 15:07:12 .. So this is in my pipeline to do as soon as I can. 15:07:31 list of remaining open issues at imsc-hrm -> https://github.com/w3c/imsc-hrm/issues 15:07:38 .. Anything else to say? 15:07:55 .. I don't think any of the open issues stops us from requesting wide review. 15:07:57 Pierre: I agree 15:08:58 Philippe: You already have some HR issues open. 15:09:18 Nigel: Yes, this is about wider review than just HR. 15:09:34 a+ do we need to update draft liaison text following HRs? 15:09:35 .. We wanted to do the internal HR first to improve the quality of what we're asking the wider community to review. 15:09:54 s/a+/q+/ 15:10:03 Nigel: I don't think any change is needed, Atsushi, no. 15:10:35 Pierre: Do you need anything from me to get started? 15:10:38 Nigel: I think I'm good. 15:10:49 Pierre: Awesome, thanks for all the input on the introduction. Good to go! 15:11:32 Nigel: For info, we don't believe any further change is needed to resolve the privacy issue, and are waiting for those guys to come back to us. 15:11:36 Philippe: OK 15:11:47 Topic: DAPT REQs 15:12:03 Nigel: I think we can publish this on /TR now. 15:12:11 .. We resolved the issues we said we would. 15:12:20 .. Thank you Andreas in particular for your diligence. 15:12:34 .. Ok with you Cyril? 15:12:45 Cyril: No, it's purely editorial and I'm happy if it helps readers. 15:13:06 Andreas: Thanks for your efforts Nigel, I think it is overall more accessible and readable. 15:13:28 Atsushi: I wrote in #4 that we have a group resolution to request transition to Draft Note when we close the issue. 15:13:39 .. Just to confirm, is it fine to request the transition now? 15:14:02 Nigel: Yes, I can confirm that I've received no objections to the resolutions made 2 weeks ago and the Decision review period 15:14:13 .. according to our decision review policy has now closed. 15:14:23 .. So those resolutions are WG Decisions as of now. 15:14:31 .. Please go ahead Atsushi. 15:14:48 Atsushi: After I do some document structure checks I will file a transition request for Draft Note. 15:15:28 .. I will configure the repo to auto-publish on PR merge to the default branch as per the resolution. 15:15:39 .. Same as IMSC-HRM but as Draft Note instead of Working Draft. 15:15:43 Nigel: Makes sense, thank you. 15:16:34 .. On a related note, I have begun getting review feedback from my colleagues in BBC Studios, who seem 15:16:45 .. happy with it and may come back with more feedback. 15:17:01 Topic: Rechartering status update 15:17:29 Nigel: I sent an email to members describing the situation as it is now. 15:17:42 -> https://lists.w3.org/Archives/Member/member-tt/2022Mar/0000.html Nigel's email about the AC review of the draft charter 15:17:50 .. Where do we go next? 15:19:04 cyril has joined #tt 15:19:12 rrsagent, pointer 15:19:12 See https://www.w3.org/2022/03/31-tt-irc#T15-19-12 15:19:26 .. [summarises contact attempts made so far] 15:20:15 .. I don't know how to treat Mozilla's objection sent after the deadline to ac-forum. 15:20:27 Philippe: Strictly speaking they don't have an objection, because it was after the deadline. 15:20:31 .. The deadline is for a reason. 15:20:36 .. There are several ways here. 15:20:50 .. We could have a call with them - you tried with Apple? 15:20:59 Nigel: No response yet, 3 contacts. 15:21:05 Philippe: You didn't yet email Chris? 15:21:09 Nigel: No, not yet. 15:22:17 Philippe: Your proposal is to do PR #75 and see if that is enough? 15:22:32 Cyril: Did you try David Singer? 15:22:37 Nigel: I did not, but I could. 15:22:47 Pierre: I also tried to reach Tess multiple times without success. 15:22:55 .. Before going around Tess they should answer their own email. 15:23:05 .. It's not cool to file an objection and then not reply. 15:23:38 Philippe: I suggest that Nigel you email Tess and CC David. 15:23:42 Nigel: That's fine. 15:23:58 https://www.w3.org/Member/ACList 15:24:17 Philippe: You also need to email Tantek CC Eric - I'm looking at the above list to get the AC reps and seconds. 15:24:36 .. Look at that list to see for each, and point to pull request 75 and ask if it addresses their concern. 15:24:49 .. And if not, are you able to discuss? 15:25:01 Nigel: Exactly what I did with Apple - the others came in late and I haven't had time. 15:25:19 Philippe: If you send an email to Chris before Monday then he'll know what I'm talking about when I bring it up with him. 15:25:28 .. Also CC me, Atsushi and Gary too 15:26:36 .. My understanding from what you said earlier is that it is not that you're unwilling to change, but you need more information? 15:26:57 Nigel: Correct. We don't know if the issue is about the factors of verification being independent, which we're happy to state, 15:27:05 .. or if they don't believe that they all count as "implementations". 15:27:17 Philippe: You can also invite them to the next call. 15:29:45 .. Does lack of Charter stop you from making progress? 15:29:52 Pierre: I don't know, does it? 15:29:58 Nigel: That's our question to you! 15:30:14 Philippe: Is there anything you want to do that is out of scope of your current charter? 15:30:26 Nigel: No - DAPT is covered by the AD spec in the current charter. 15:30:38 Philippe: We can extend the current charter then. 15:30:48 ACTION: Philippe to request charter extension 15:31:06 Philippe: I will let W3M decide 3 months or 6 months. 15:31:35 Nigel: I don't see why we would not have resolved the FOs in 3 months, to be honest. 15:32:08 .. Until we know the details of the FOs we can't know how hard it is to address them. 15:32:18 Pierre: I've asked that question too. 15:32:24 Philippe: I suspect it will be some principle. 15:32:44 Gary: The easy way to resolve it is just to bring back the 2 independent implementation text 15:32:50 .. but we don't really want to do that. 15:33:03 Pierre: Suggest we move on before having the discussion without understanding the FOs. 15:33:09 Gary: Yes, more information if possible. 15:34:19 Nigel: OK, the actions are clear: Philippe to extend charter, me to contact the orgs who raised FOs. 15:34:25 .. Nothing more we can say right now. 15:34:54 Topic: Behavior with controls, particularly non-native controls, overlap w3c/webvtt#503 15:35:06 github: https://github.com/w3c/webvtt/issues/503 15:35:42 Nigel: Gary, you added a comment about rewriting the collision avoidance from scratch. 15:35:49 .. I'm not familiar enough to understand the impact. 15:36:07 Gary: Yes. This is about the potential for making it appear that two active cues are out of order. 15:36:17 .. It's very likely not a good user experience. 15:36:33 .. If the lines show up backwards it could be confusing. 15:36:52 .. That comes from collision avoidance which renders a cue at a time, and 15:36:59 .. when rendered, the cue should not be moved again. 15:37:12 .. The first cue gets rendered, then the second cue can't render in the expected location 15:37:20 .. because of controls and the first cue, so it moves up. 15:37:40 Nigel: Do you have an alternative algorithm in mind? 15:37:57 Gary: I don't, but conceivably you could do something smarter like not rendering a cue at a time. 15:38:05 .. Might not be backwards compatible. 15:38:17 .. Changing such a big thing, what's the likelihood of browsers picking up the change? 15:38:23 Pierre: What do browsers do today? 15:38:36 Gary: The issue is that they do things slightly differently. 15:38:44 .. In terms of collision avoidance? 15:39:00 Pierre: What I overheard is that the collision avoidance algorithm makes other issues more complicated to solve. 15:39:11 .. If it was not there would it make things easier or harder, or is it orthogonal? 15:39:18 Gary: I think it is orthogonal. 15:39:36 .. Without the collision avoidance it would not be an issue, but then you'd have the issue of the controls overlaying the captions. 15:39:38 Pierre: Thank you. 15:39:48 .. And it is not possible to pick one implementation and capture what it does? 15:39:54 Gary: They do it differently. 15:39:57 Pierre: Could you pick one? 15:40:09 Gary: The control size in different browsers is different so the thresholds differ. 15:40:12 Pierre: Got it 15:40:34 Gary: I mean to create an example to see how Safari and Firefox handle it. 15:40:44 q+ to talk about writing order 15:40:57 .. There are bugs across browsers where they handle it a bit differently in some cases. 15:40:59 ack n 15:40:59 nigel, you wanted to talk about writing order 15:42:16 Nigel: We've never found a bottom-to-top writing mode script so far, so we should 15:42:37 .. probably be trying to position the lowest cue first, then the next further up, etc. 15:42:43 .. So just reverse the order? 15:42:55 Gary: I think that some implementations like hls.js already do something like that. 15:43:02 Nigel: So there's already an implementation of this? 15:43:16 Gary: It sounds like a good way to avoid a complete rewrite. 15:43:31 .. They render the 2nd cue first, then the 1st cue, so that the 1st cue ends up getting pushed on top. 15:43:34 Nigel: Yes, makes sense. 15:43:58 Gary: But now the issue becomes: if we change the spec then those workarounds might render incorrectly. 15:44:01 Nigel: Would they? 15:44:11 Gary: Yes because they'd be double-reversed. 15:44:45 .. If the browser hands the cues to the renderer in reverse order and hls.js reverses it then the outcome will be wrong. 15:44:52 Nigel: Well something has to change! 15:44:59 Gary: It might not be a blocker, but worth considering. 15:45:02 Nigel: Fair enough. 15:45:41 Gary: It sounds like for this part of it investigating changing it to do reverse rendering makes sense. 15:46:00 .. But then there's the other part which is how to handle the overlap with non-native controls. 15:46:11 Nigel: Yes, that's quite a bit harder. 15:46:25 Gary: It would probably end up meaning changes to HTML as well, potentially. 15:47:14 Nigel: One of my questions is how people position non-native controls. 15:47:28 .. HTML doesn't allow any children of video elements so tracking layout changes is awkward 15:47:55 Gary: One thought is an API on the video element to indicate where it's rendering to, so the calling code 15:48:02 .. could say where to avoid drawing captions. 15:48:14 .. I was talking to a friend who suggested the captions layer should always be on top of everything. 15:48:26 Pierre: It'd be backwards to have the application ask where the controls are. 15:48:37 .. The browser is going to put controls there, so it should make sure things are out of the way. 15:48:54 Gary: Yes. In the WebVTT spec it says when the controls show create a CSS box for where the controls are 15:49:08 .. and consider that box to know whether the cue render location is valid or not. 15:49:22 .. The simple solution is to be able to add more boxes to consider, from outside. 15:49:30 Nigel: That would make sense. 15:49:48 .. It doesn't solve the wider problem of how you position anything relative to the video element. 15:50:00 Pierre: Right, you might want to position other stuff, that could also be impacted by the controls. 15:50:04 .. That's a bigger issue. 15:50:17 Gary: Yes, if you're laying stuff out yourself then you're on the hook for avoiding overlap. 15:50:30 .. But if you're relying on native caption rendering with non-native controls... 15:50:46 Pierre: Right but in my simple model you'd say captions render over the related video element, 15:51:00 .. the entire thing. If the browser wants to show controls over the video then it needs to scale that region 15:51:15 .. to make it so that there's no overlap, or use transparency, or move controls somewhere else. 15:51:30 .. In my mind the timed text rendering algorithm should not try to guess what weird shapes the controls take. 15:51:38 q+ 15:51:39 Gary: Yes. I'm not suggesting it should guess automatically. 15:51:48 .. This is about native caption rendering and custom controls. 15:51:56 Pierre: From a caption standpoint we should keep it simple. 15:52:08 .. Someone authors captions with the expectation that they fill the related video. 15:52:23 .. If the browser or the application wants to take over part of the related video element it's their responsibility 15:52:36 .. to rescale captions, move them off screen etc. 15:52:48 .. Trying to anticipate that in the caption and subtitle specs is the wrong way around. 15:52:52 .. They're not authored that way. 15:53:04 .. Position is important. 15:53:15 Andreas: For control bars it is also very important to be accessible. 15:53:27 .. If you say that captions always render on top, which happened in an implementation we did, 15:53:38 .. you may end up being unable to interact with the control bar. 15:53:41 ack at 15:54:02 Gary: That is why I'm not sure it is necessarily the best direction. 15:54:14 .. To Pierre's point, I'm not proposing changing something in WebVTT necessarily. 15:54:25 .. I think the question is right now, with native controls and native captioning, 15:54:34 .. it handles it so that captions don't overlap the control bar. 15:54:45 .. At least in the standard captions if you're not positioning them especially. 15:55:04 Pierre: By default in WebVTT if you do just times and text like SRT the browser will be helpful 15:55:21 .. and will use the absence of explicit positioning to set its own position to avoid the clash. 15:55:39 Gary: Right. The question is if we can help people using native captioning but non-native controls to do the same thing. 15:55:59 Pierre: Maybe the reason I'm having difficulty is it is not clear if there is good semantics in the DOM and HTML and CSS to 15:56:07 .. position things on top of video in a reliable way? 15:56:26 Nigel: My conclusion is there is not - I tried to do this and it is super difficuly. 15:56:30 s/ly/lt 15:56:58 Pierre: If there were a way then you could scale the caption element to avoid overlapping the control element. 15:57:02 q+ 15:57:10 Gary: Chrome and Safari provide a pseudo element for the text track display. 15:57:27 .. That could be a solution, to codify that as a thing browsers should expose, so that applications 15:57:33 .. could apply styles to it. 15:57:50 Pierre: Then you could start exposing ancillary content, like TTML if not supported, or other things, reliably on top of video elements. 15:57:52 ack at 15:58:05 Andreas: There is the bigger question that could be resolved, but the control bar 15:58:17 .. one is the most prominent because customising control bars is very common. 15:58:33 .. I see an issue that the HTML spec puts controls out of scope, but I think at least it needs to be a first class 15:58:39 .. citizen, because it will be there. 15:59:20 Pierre: I like the idea of trying to standardise the way browsers allow explicit control over what is overlaid on the video, 15:59:26 .. maybe just starting with the control bar. 15:59:41 .. Then the custom controls can do style changes to resolve the overlap problem. 15:59:58 Gary: Right, that's what we do in video.js, we squish the text track display area when controls are present. 16:00:15 Pierre: I can see other use cases, like insertion of ads during credits, or other things, 16:00:26 .. that need to be on the video area without killing the captions. 16:00:36 Gary: Yes. We're out of time for today. 16:01:09 SUMMARY: Look into the reverse rendering of cues at the same time for collision avoidance; Continue to think about handling non-native controls and overlays. 16:01:12 Topic: Meeting close 16:01:57 Nigel: Thanks everyone, see you in two weeks. [adjourns meeting] 16:01:57 atai has left #tt 16:02:02 rrsagent, draft minutes 16:02:02 I have made the request to generate https://www.w3.org/2022/03/31-tt-minutes.html nigel 16:08:52 scribeOptions: -final -noEmbedDiagnostics 16:08:55 zakim, end meeting 16:08:55 As of this point the attendees have been Andreas, Philippe, Nigel, Atsushi, Pierre, Gary, Cyril 16:08:57 RRSAgent, please draft minutes v2 16:08:57 I have made the request to generate https://www.w3.org/2022/03/31-tt-minutes.html Zakim 16:09:00 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:09:05 Zakim has left #tt 16:09:57 rrsagent, excuse us 16:09:57 I see 1 open action item saved in https://www.w3.org/2022/03/31-tt-actions.rdf : 16:09:57 ACTION: Philippe to request charter extension [1] 16:09:57 recorded in https://www.w3.org/2022/03/31-tt-irc#T15-30-48