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> list of remaining open issues at imsc-hrm
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.
Nigel's email about the AC review of the draft charter
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> https://
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: https://
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]