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