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.
Update XSL and DTD for TTML1 and TTML3 w3c/ttwg#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.
Make VTTRegion lines be a long.
Update region lines parsing to round to +/- MAX_VALUE
New snapshot with new at-risk items
Added unbounded TextTrackCue.endTime
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: https://
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> HTML issue for Add TextTrackCue end time representing end of media
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]