{Minutes} TTWG Meeting 2020-03-04

Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2021/03/04-tt-minutes.html


In text format:

   [1]W3C

      [1] https://www.w3.org/

                Timed Text Working Group Teleconference

04 March 2021

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2021/02/04-tt-minutes.html
      [3] https://github.com/w3c/ttwg/issues/175
      [4] https://www.w3.org/2021/03/04-tt-irc

Attendees

   Present
          Atsushi, Cyril, Gary, Nigel, Nigel., Pierre

   Regrets
          -

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]TTML2 - publication of updated CR
    3. [7]WebVTT status
    4. [8]WebVTT Outstanding Pull Requests
    5. [9][WebVTT] Added unbounded TextTrackCue.endTime
       w3c/webvtt#493
    6. [10]WebVTT next steps
    7. [11]GitHub Pages after switching master to main branch
       names
    8. [12]AOB - DST
    9. [13]Meeting close

Meeting minutes

  This meeting

   Gary: Today we have TTML2, to discuss the updated CR.
   … Then WebVTT, to discuss the current status, talk about
   outstanding PRs
   … and a new feature request, and what the next steps are.
   … We have GitHub Pages updates and then AOB.

   Nigel: You added DST Gary.
   … I would also, if time allows, give an update on the AD
   profile of TTML2 and implementation state as AOB.

   Atsushi: For info share, I need to work on the config updates
   for some repos.

   Nigel: Any other other business?

  TTML2 - publication of updated CR

   Atsushi: I've updated the transition req with the completed
   document
   … I hope for approval on Friday East Coast US time, and then
   plan to republish next Tuesday
   … which is the next slot.
   … For now I've run all checks including pubrules and link
   validator
   … so we're only waiting for approval.

   Nigel: Great, thank you.

   Atsushi: Sorry for taking time to fix the XSL.

   Nigel: Significant changes?

   Atsushi: Yes, pubrules have changed for process 2020 so we had
   to change some headers
   … and some metadata lines, and all of them are handled by the
   XSL and the DTD.
   … We may need to think about disseminating those changes to
   TTML1 and TTML3 for the future.

   Nigel: Sounds like a good idea!
   … Would be helpful if you could pull request them in.

   Atsushi: Yes, you can raise an action item against me.

   [14]Update XSL and DTD for TTML1 and TTML3 w3c/ttwg#181

     [14] https://github.com/w3c/ttwg/issues/181

   Nigel: Thank you!

  WebVTT status

   Gary: The current status is: last time WebVTT was updated there
   was a new CR marking some items as at risk.
   … There are more things to mark as at risk, and those items are
   being built off snapshots of HTML in the repo
   … and are published on /TR, but that output is slightly
   different than the gh-pages output.
   … I think to make it easier to work on it we probably need to
   figure out how to bring those two back in line.
   … I don't really know much about the specifics. Maybe for me
   and Atsushi offline to figure it out.
   … Basically we need to get the changes in that fix the
   implementation report inline so that we can start progressing
   the spec forward.
   … However there are a couple of feature requests as well.
   … On the bright side if I understand correctly with P2020 we
   can republish CRs as often as we want until we want to move to
   the
   … next step, and then we need to move to the larger CR review.
   Is that right?

   Atsushi: I suppose we need to go through the CR process.

   Gary: It sounds like the next update will need to go through
   the CR process, but updates to that
   … won't need it until we try to go past CR.

   Atsushi: I propose to publish as a CR Draft.

   Gary: Yes, that's exactly what I was thinking.

   Atsushi: Then the CR Draft could be a good pointer for wide
   review.

   Gary: Yes, which I think would be useful because of the feature
   changes.

   Atsushi: Yes, a CRD (not a CRS) can be published by group
   decision here.

   Gary: Perfect, yes. I think probably we'd want to go through
   several iterations of CRD as we bring
   … in some of these features, until we're ready to proceed.
   … I think that's it for that agenda item.

  WebVTT Outstanding Pull Requests

   Gary: I mainly brought them up to remind people they exist, and
   if anyone has any objection or support, to
   … allow them to voice them. I think they've all been approved,
   by Silvia.
   … Should I list them here? They're all in the agenda.

   [15]Make VTTRegion lines be a long.

     [15] https://github.com/w3c/webvtt/pull/461

   [16]Update region lines parsing to round to +/- MAX_VALUE

     [16] https://github.com/w3c/webvtt/pull/470

   [17]New snapshot with new at-risk items

     [17] https://github.com/w3c/webvtt/pull/460

   [18]Added unbounded TextTrackCue.endTime

     [18] https://github.com/w3c/webvtt/pull/493

   Gary: The end time is the new feature.
   … The items being marked at risk are text-wrap: balance, which
   I think everyone agrees might be nice but not
   … implementable or verifiable, so just remove it.
   … Then there's text-combine: upright, which might be worth
   looking at. At the time it was marked at risk because of
   insufficient
   … browser support, and CSS WG said not to consider vendor
   prefixes as a good alternative.
   … The snapshot PR adds the new features and adds those at risk
   items to the existing list.

   Nigel: The text-combine: upright - not sure the impact of that?

   Gary: Yes, it's not great for Japanese support, and things
   might have improved, but this may be one where we remove
   … it for the initial release and then add it back in as an
   "evergreen" feature.

   Nigel: I think the term is "candidate feature", i.e. a CR-stage
   feature that can be marked like that in the Rec.

   Gary: Yes, and eventually I think you can do a new snapshot to
   mark it as a regular feature.

   Nigel: Yes, I think there's a process for that.

  [WebVTT] Added unbounded TextTrackCue.endTime w3c/webvtt#493

   github: [19]https://github.com/w3c/webvtt/pull/493

     [19] https://github.com/w3c/webvtt/pull/493

   Gary: The idea is that a cue can start with a defined time but
   with an undefined (infinity) end time.
   … The idea is for live streams where a cue, say a chapter, can
   show up, but then because the end isn't in the live stream yet
   … you want the cue to reflect the end time of the video, which
   is also infinity for the video.
   … It also aligns it with WebVMT which is a fork of WebVTT which
   has done that already.
   … I think the change makes sense and is fairly uncontroversial.

   Nigel: Is the semantic well defined for updating the end time
   to a definite value?

   Gary: I believe it is, but the fun part is that is defined in
   HTML!
   … I think it does account for updating the times of the cue.

   Nigel: So the change was already made in HTML and we are just
   tracking it here, is that right?

   Gary: There's a pull request out for it, so I guess they want
   to get it all in at once.

   Cyril: Just a remark - do you know that there's a related
   change request on the carriage of WebVTT in MP4 by Dave Singer,
   to match this?

   Gary: I do not

   Cyril: I can tell you there is!

   Gary: Makes sense.

   Cyril: I see that the HTML pull request is not approved -
   should we wait for that before we do it in case they make a
   change?

   Gary: Given that the change in WebVTT is 3 words, basically, we
   can wait to merge it until the WebVTT HTML part is approved.
   … It would be good to make sure all the ducks are in a row on
   WebVTT, which means figuring out the IPR and checking no-one
   objects to the change.

   Nigel: Unless there is a circular reference it must be clear
   which one has to move first.

   Gary: They sound kind of separate. The HTML one updates Text
   Track Cue constructor and object to allow the end time to be
   unbounded.
   … VTTCue is separate. No, I guess you need both.

   Nigel: I can see that the change is to the type of the end
   time, to be unrestricted double, and defining the
   interpretation.

   Gary: Yes

   Cyril: I don't see a change to the serialisation - how would it
   be shown, as Infinity?

   Pierre: JSON cannot represent infinity

   Nigel: Right, but this is not JSON

   Pierre: Right, but having gone through something similar
   recently, unbounded/infinity is poorly supported.
   … There's no widely accepted representation - just a data
   point.
   … For instance as long as you stay within Javascript you can
   deal with Infinity, assuming the underlying platform supports
   IEEE floats.

   Gary: I think the way WebVMT does it is by omitting the end
   time after the ->

   Cyril: For WebVTT that's a breaking change though.

   Gary: Yes, it's possible this is why it is just in the contract
   for the value, and not in the actual syntax itself.

   Cyril: Maybe there should be information about ignoring the end
   value or having a special value or something?

   Gary: Yeah you're right we should figure out whether and how we
   want to have a syntax for this.
   … Maybe not having the end time, even though it is a change,
   maybe it can be added on top without breaking things, I'm not
   sure.

   Nigel: Is the requirement only for constructing the VTTCue
   object in client code, or for providing a serialised fragment
   of WebVTT?

   Gary: Yeah if we only care about the javascript the current
   change should be enough, and maybe that's a good place to
   separate it.
   … Do the Javascript contract first and then figure out the
   syntax.

   Nigel: Cyril, does the change you mentioned before about MP4
   imply some form of serialisation requirement?

   Cyril: I'll have to check.

   Gary: Chris Needham's example is Javascript code constructing
   the cue object.

   <gkatsev> [20]HTML issue for Add TextTrackCue end time
   representing end of media

     [20] https://github.com/whatwg/html/issues/5297

   Cyril: The text I can see doesn't talk about serialisation - it
   talks about what to do if a cue with indefinite duration
   exists.
   … I don't understand it - it will need review. I don't think it
   answers your question Nigel, and it raises more.

   Nigel: Perhaps it's just explaining how to handle the case,
   without saying how it might happen, so it's future-proof in
   that case!

   Nigel: Interesting to know how a syntax change would be handled
   by existing parsers.

   Pierre: Have any tests been provided? That might help answer
   the question.

   Gary: The requested change is only to the Javascript contract.

   Pierre: So there are no tests.

   Gary: No, [checks wpt] there are no tests.

   Nigel: Is it testable?

   Gary: Yes, it's just create a new VTTCue with an infinite end
   time and verify that one was created with infinity for end
   time.
   … For the syntax it is possible that if we add the syntax of no
   end time the error correction might just ignore that cue. I
   need to check.

   Nigel: Good shout about tests - our working model changed a
   couple of years ago to try to write tests alongside substantive
   … changes at the time of the PR, so we're not rushing to
   back-fill the IR at the end when we've forgotten the context.

   Gary: Yes

   SUMMARY: 1. Make sure we have tests for the change; 2. Enquire
   whether a syntax change is needed, and if so, investigate if it
   can be added in a non-breaking way.

  WebVTT next steps

   Gary: Some potential steps for moving forward - merge all the
   outstanding PRs,
   … update the snapshot, go through the CfC process for a new
   CRS.

   Nigel: CRS not CRD?

   Gary: I think once everything is in we'd want to go to a CRS
   before PR.
   … The one thing I'm unsure about is the stuff we want to remove
   as at risk.
   … Would that be before or after we make the CR.

   Nigel: Need to decide whether to remove those features
   altogether or just mark them as a candidate feature.

   Gary: Yeah I think remove text-wrap:balance but mark the
   text-combine: upright as a candidate feature.
   … That would make it easier than adding it back in later.

   Nigel: Would be worth making explicit proposals for each one of
   these at risk features.

   Gary: Yes, I'm describing my view of what I think makes sense
   to progress WebVTT.
   … Another thing we need to consider is the WebVTT headers -
   that's another feature I think we should bring in,
   … so that e.g. HLS doesn't need to define its own WebVTT header
   and can just reference our spec.

  GitHub Pages after switching master to main branch names

   Nigel: I noticed a couple of repos using gh-pages were
   returning 404s on their published URLs, ADPT and IMSC.
   … I haven't checked the others. I managed to kick GitHub Pages
   into reprocessing them and then they were fine.

   Atsushi: 2 things:
   … 1. I found discontinuities in the GitHub Pages API's log.
   There might be some issue on the GitHub side.
   … 2. I listed 4-5 repos in the agenda+ that refer 404s for
   GitHub Pages but have a setting. So we need to do a similar
   operation for them.
   … I somehow doubt that the current configuration for some of
   these repos is right - that they are pointing to the wrong
   branch names.
   … Let me check offline with you Nigel for what is the correct
   config for these repos.

   Nigel: Ok - and the difference is whether to publish the main
   branch or a separate gh-pages branch?

   Atsushi: Yes, some are pointing at gh-pages but there's no
   branch, only a main.
   … I think we need to check one by one.
   … Detailed list is in my email to you - please check.

   Nigel: I just had a hard time parsing it! I will have another
   look.

   Atsushi: I have no idea what happened yet.

   Nigel: I think there's no point in having a separate gh-pages
   branch unless there's a build script that makes a separate web
   page.
   … If it's just respec then we can publish the main branch
   directly.

   Atsushi: I checked the branches and the config, and there were
   discontinuities, from 2017 to Feb 2020.
   … When a change is made GitHub takes the commit and builds
   something to be provided to the GitHub Pages web server.
   … If we use some build script like for TTML, once the CI
   commits the build result to gh-pages GitHub takes that commit
   into web server storage.
   … I will check the history of that.

   Nigel: All I'm saying is that for respec or markdown documents
   we can publish main directly.

   Atsushi: Yes exactly, I need to check for each repo.

   Nigel: Thanks.

  AOB - DST

   Gary: DST changes in the US on March 14th, between this meeting
   and our next scheduled meeting.

   Nigel: And it will change in Europe on a later date.
   … Probably Sunday 28th March.

   Nigel: Need to confirm offline - I think we will most likely
   adjust our time to track DST, the only question is when.

   Atsushi: I am fine to open a PR to update the calendar files.

   Nigel: The only difference between previous DST switches is
   that we have Atsushi active in Japan. If we adjust to keep
   local time the same
   … in US and Europe then it will be 1 hour earlier in places
   like Japan without DST.
   … Will that cause a problem for you Atsushi?

   Atsushi: I'm not sure - I will check.

   Gary: The EU passed ending DST, but I don't know when that
   change will happen. The UK is doing something independently.

   Nigel: I like to deal with each change as it comes and not
   worry about it too much in advance!
   … Gary, if you can get round to sending an email today, great,
   otherwise I will try to get around to it tomorrow.

  Meeting close

   Nigel: Thanks everyone! [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [21]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

     [21] https://w3c.github.io/scribe2/scribedoc.html