{Minutes} TTWG Teleconference 2022-03-31

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