Added unbounded TextTrackCue.endTime

[rjksmith]

Added support for unbounded TextTrackCue - see https://github.com/whatwg/html/pull/5953 Whitespace removed by Atom

---

Preview | Diff

[rjksmith]

@nigelmegitt @gkatsev I was asked to raise this PR to maintain VTTCue alignment with the proposal for TextTrackCue.endTime = +Infinity. The change was previously discussed in issue https://github.com/whatwg/html/issues/5297 and has now progressed to PR https://github.com/whatwg/html/pull/5953.

I now see that there's an IPR issue as I'm not a member of TTWG, though I am an IE in SDWIG and have been working with MTE TF for a while. There's no urgency at the moment, but I'd like to resolve this blocking issue and would welcome your guidance on how best to proceed. Thanks.

cc @chrisn

[tidoust]

@rjksmith, index.html is automatically generated from index.bs, using Bikeshed. In other words, the PR should update index.bs, not index.html.

Regarding the IPR issue, an easy way to solve this would be to have you sign a non-participant contribution commitment.

[gkatsev]

Thanks @tidoust!

I think updating index.bs` would also trigger the PR Preview feature.

[rjksmith]

@tidoust @gkatsev Thanks for your guidance.

I've reverted my changes (7e4b64c) to index.html and updated index.bs to generate equivalent modifications with Bikeshed (17626fd).

I suspect that the Bikeshed tool has been updated since index.html was last officially generated and I've split these changes into a separate commit (f0323cb) for clarity.

Please let me know the process to sign a non-participant contribution agreement to cover IPR so we can resolve the blocking issue. Thanks.

[himorin]

Error is from WebIDL change at https://github.com/heycam/webidl/pull/798, which is supposed to be fixed by https://github.com/w3c/webvtt/pull/492

[dontcallmedom]

@himorin let me know if you need any assistance with the non-participant contribution agreement process - it should be relatively well-identified starting from https://labs.w3.org/repo-manager/pr/id/w3c/webvtt/493

[himorin]

@himorin let me know if you need any assistance with the non-participant contribution agreement process

ah, yes. For now, this is kept stop for repo management side (reorg, webidl alignment...), but should be fixed shortly.

[gkatsev]

We've updated the main branch, this PR would need to be updated/rebased against the latest changed there.

[css-meeting-bot]

The Timed Text Working Group just discussed [WebVTT] Added unbounded TextTrackCue.endTime w3c/webvtt#493, and agreed to the following:

• 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.

The full IRC log of that discussion

<nigel> Topic: [WebVTT] Added unbounded TextTrackCue.endTime w3c/webvtt#493
<nigel> github: https://github.com/w3c/webvtt/pull/493
<nigel> Gary: The idea is that a cue can start with a defined time but with an undefined (infinity) end time.
<nigel> .. 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
<nigel> .. you want the cue to reflect the end time of the video, which is also infinity for the video.
<nigel> .. It also aligns it with WebVMT which is a fork of WebVTT which has done that already.
<nigel> .. I think the change makes sense and is fairly uncontroversial.
<nigel> Nigel: Is the semantic well defined for updating the end time to a definite value?
<nigel> Gary: I believe it is, but the fun part is that is defined in HTML!
<nigel> .. I think it does account for updating the times of the cue.
<nigel> Nigel: So the change was already made in HTML and we are just tracking it here, is that right?
<nigel> Gary: There's a pull request out for it, so I guess they want to get it all in at once.
<nigel> 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?
<nigel> Gary: I do not
<nigel> Cyril: I can tell you there is!
<nigel> Gary: Makes sense.
<nigel> 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?
<nigel> Gary: Given that the change in WebVTT is 3 words, basically, we can wait to merge it until the WebVTT HTML part is approved.
<nigel> .. 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> Nigel: Unless there is a circular reference it must be clear which one has to move first.
<nigel> Gary: They sound kind of separate. The HTML one updates Text Track Cue constructor and object to allow the end time to be unbounded.
<nigel> .. VTTCue is separate. No, I guess you need both.
<cyril> rrsagent, pointer
<RRSAgent> See https://www.w3.org/2021/03/04-tt-irc#T16-30-44-1
<nigel> Nigel: I can see that the change is to the type of the end time, to be unrestricted double, and defining the interpretation.
<nigel> Gary: Yes
<nigel> Cyril: I don't see a change to the serialisation - how would it be shown, as Infinity?
<nigel> Pierre: JSON can represent infinity
<nigel> s/can/cannot
<nigel> Nigel: Right, but this is not JSON
<nigel> Pierre: Right, but having gone through something similar recently, unbounded/infinity is poorly supported.
<nigel> .. There's no widely accepted representation - just a data point.
<nigel> .. For instance as long as you stay within Javascript you can deal with Infinity, assuming the underlying platform supports IEEE floats.
<nigel> Gary: I think the way WebVMT does it is by omitting the end time after the ->
<nigel> Cyril: For WebVTT that's a breaking change though.
<nigel> Gary: Yes, it's possible this is why it is just in the contract for the value, and not in the actual syntax itself.
<nigel> Cyril: Maybe there should be information about ignoring the end value or having a special value or something?
<nigel> Gary: Yeah you're right we should figure out whether and how we want to have a syntax for this.
<nigel> .. 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> Nigel: Is the requirement only for constructing the VTTCue object in client code, or for providing a serialised fragment of WebVTT?
<nigel> 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.
<nigel> .. Do the Javascript contract first and then figure out the syntax.
<nigel> Nigel: Cyril, does the change you mentioned before about MP4 imply some form of serialisation requirement?
<nigel> Cyril: I'll have to check.
<nigel> Gary: Chris Needham's example is Javascript code constructing the cue object.
<gkatsev> -> https://github.com/whatwg/html/issues/5297 HTML issue for Add TextTrackCue end time representing end of media
<nigel> Cyril: The text I can see doesn't talk about serialisation - it talks about what to do if a cue with indefinite duration exists.
<nigel> .. I don't understand it - it will need review. I don't think it answers your question Nigel, and it raises more.
<nigel> 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> Nigel: Interesting to know how a syntax change would be handled by existing parsers.
<nigel> Pierre: Have any tests been provided? That might help answer the question.
<nigel> Gary: The requested change is only to the Javascript contract.
<nigel> Pierre: So there are no tests?.
<nigel> s/?//
<nigel> Gary: No, [checks wpt] there are no tests.
<nigel> Nigel: Is it testable?
<nigel> 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.
<nigel> .. 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> Nigel: Good shout about tests - our working model changed a couple of years ago to try to write tests alongside substantive
<nigel> .. 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.
<nigel> Gary: Yes
<nigel> 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.

[rjksmith]

WebVMT already handles unbounded cues as they are a common use case for live streaming.

The cue end time is simply omitted as in the Tower of London example. This has the advantage that an end time can easily be added to make the cue bounded when it becomes known at some future time.

[gkatsev]

@rjksmith yeah, I brought up how WebVMT does it. For WebVTT there the API and the format. This PR currently only changes the API for VTTCue, which is necessary for the programmatic metadata cues as notes in the examples. It probably makes sense for WebVTT to be able to represent it in its text format too, but then it must do so in a backwards compatible manner, which is what (2) in the summary above refers to. Though, I think a syntax change can come in separately from the API change.

For the tests, we'd want to make a PR against web-platform-tests to update the constructor to allow endTime to be Infinity https://github.com/web-platform-tests/wpt/blob/master/webvtt/api/VTTCue/constructor.html.

[gkatsev]

Oh, just realized that maybe TextTrackCue has tests too and sure enough it does. https://github.com/web-platform-tests/wpt/blob/master/html/semantics/embedded-content/media-elements/interfaces/TextTrackCue/endTime.html I'll add a comment on the html repo PR too.

[gkatsev]

Also, I just verified that adopting WebVMT's syntax for unbounded cues can happen in a backwards compatible way. Parsers that don't recognize a time header without an end time (i.e. all current webvtt parsers) ignore that entire cue block but still show all subsequent ones. Tested in Chrome, Firefox, Safari, and vtt.js.

[rjksmith]

Also, I just verified that adopting WebVMT's syntax for unbounded cues can happen in a backwards compatible way. Parsers that don't recognize a time header without an end time (i.e. all current webvtt parsers) ignore that entire cue block but still show all subsequent ones. Tested in Chrome, Firefox, Safari, and vtt.js.

@gkatsev Thanks for confirming. That sounds encouraging. I'll take a look at the web-platform-tests too.

[rjksmith]

@himorin let me know if you need any assistance with the non-participant contribution agreement process

ah, yes. For now, this is kept stop for repo management side (reorg, webidl alignment...), but should be fixed shortly.

Is there any news on this or can you post a link to the agreement? Thanks

[himorin]

@himorin let me know if you need any assistance with the non-participant contribution agreement process

ah, yes. For now, this is kept stop for repo management side (reorg, webidl alignment...), but should be fixed shortly.

Is there any news on this or can you post a link to the agreement? Thanks

I think you might have received an email from W3C non-participant contribution system at Mar 11, 2021, to an email address you registered to W3C account.

[gkatsev]

@gkatsev Thanks for confirming. That sounds encouraging. I'll take a look at the web-platform-tests too.

It would be interesting to know whether it's useful to have a way to represent unbound end-time in a way that old parsers handle things intelligently. But it may not be. I think this was discussed a bit at the M&EIG meeting that, unfortunately, had to miss.

[nigelmegitt]

Also, I just verified that adopting WebVMT's syntax for unbounded cues can happen in a backwards compatible way. Parsers that don't recognize a time header without an end time (i.e. all current webvtt parsers) ignore that entire cue block but still show all subsequent ones. Tested in Chrome, Firefox, Safari, and vtt.js.

I'm not convinced that skipping the entire cue counts as "backwards compatible". I'd suggest a more backwards compatible approach here is one where a cue end time is specified, that works for all parsers, and additional syntax is available, that is ignored by parsers that don't recognise it, and used by those that do, where that syntax has the semantic "set the end time to infinity".

Then authors can specify a fallback end time of their choosing.

I'd propose a new WebVTT Cue Setting to satisfy this, because unknown cue settings should be ignored by parsers that don't recognise them.

For example:

00:30.000 --> 99:59.999 end-time-override: infinity
This cue is supposed to last effectively forever.

Current parser generates a cue whose end time is 99:59.999. Parser that understands end-time-override: infinity generates a cue whose end time is Infinity.

[gkatsev]

I think it counts as backwards compatible, but it's definitely not the best behavior. I was verifying whether the current syntax that WebVMT used could be used and not wreak havoc on existing parsers, like having it fail to parse the rest of the file or something. Behavior-wise, a new option definitely fits better with graceful degradation, which is definitely better than all or nothing. (For a similar reason, WebVTT really needs to add the rp element for ruby parentheticals).

[rjksmith]

I think you might have received an email from W3C non-participant contribution system at Mar 11, 2021, to an email address you registered to W3C account.

@himorin Many thanks. I've found it.

[rjksmith]

Using unbounded cues is not compulsory. If backward compatibility is an issue then a long bounded cue can be used instead.

00:30.000 --> 99:59.999
This cue is supposed to last effectively forever.

This is fully backward compatible and is the current solution.

WebVMT also allows unbounded cues to be superseded which is an integral part of interpolation for live streaming use cases as discussed at TPAC 2020.

[nigelmegitt]

Using unbounded cues is not compulsory.

Indeed, but this issue is to allow the semantic of an unbounded cue to be expressed, right?

[dwsinger]

I think that Nigel's point is that it's hard to tell for all cases what the best backwards-compatible behavior should be:

1. If you can't display it indefinitely, don't display it at all.
2. If you can't display it indefinitely, display it for a really long but finite time.

However, I am not sure what the effect of (2) would be. Experiment is needed. It might cause players to conclude that the presentation really is 99 years long, and display e.g. a scroll-bar that long.

[rjksmith]

Yes I agree. However, displaying an unbounded cue indefinitely may not be the correct behaviour.

An unbounded cue is defined as a cue with an unspecified future end time. The current WHATWG spec represents the duration of an unbounded stream with Infinity: media.duration = Infinity. The stream demonstrably has a finite duration, so Infinity is being used to represent an unspecified future end time and the same definition applies to an unbounded cue - as previously discussed.

This can be illustrated with a simple use case. For example, the score during a live sporting event is "0-0" at the start of the game. This may change to "1-0" or "0-1" at an unknown future time or may stay the same, and the duration of the match may be extended. There is no way of knowing the duration of the "0-0" cue until the score changes or the game ends, so this is an unbounded cue.

The point is that it is not possible to predict the end time of an unbounded cue (or stream) because it is unspecified by definition, which is reflected in the WebVMT cue syntax:

00:30.000 -->
This cue is unbounded

This is a new HTML feature and if there is a requirement for backward compatibility, bounded cues can be used instead to ensure the desired result.

[dwsinger]

Um, the example you give doesn't seem to work, unless there is some provision to update a cue that's already been issued, decoded and acted on. The score 0-0 will last forever, even after a goal is scored.

Using captions for state is, I think, problematic.

[nigelmegitt]

@dwsinger I agree - there has been talk (in the MEIG) of creating a way to update the end time of a cue, but no proposal so far for how to do it. One of the problems is how to identify which cue's end time needs to be updated, given that the uniqueness of any cue identifier is only constrained within a single WebVTT file.

If I understand correctly there has been some consideration of handling unbounded end times in the context of ISOBMFF? I wonder how the group looking at that imagined this working - can you tell us anything more?

[rjksmith]

Yes it requires an update mechanism which exists in the HTML DOM. I agree that WebVTT would require modification to support this too.

WebVMT is designed to handle this issue for moving object trajectories, regions and sensors. Perhaps there's a way to apply this to text cues too.

[dwsinger]

In the file format, we're merely addressing how to handle cues that are marked as indefinite; any update of end-time would be something we'd reflect if it were in the base spec.; I don't think we want to invent provisions at the MP4 level, merely encapsulate.

[nigelmegitt]

we're merely addressing how to handle cues that are marked as indefinite

I don't quite follow: there is no current way to mark a cue as indefinite in a file, so what is it that needs to be addressed?

[dwsinger]

I mean, we're considering how to address cues that have an unbounded end time, which is this pull.

[nigelmegitt]

I mean, we're considering how to address cues that have an unbounded end time, which is this pull.

I'd be interested in @gkatsev 's views here, but it feels like we'll keep spinning until we have a clearer notion of what the use cases and requirements are, and if there are different groups hoping to get something out of the notion of an unbounded end time, they should probably sit down together in some way and share what their goals are.

[dwsinger]

My impression was that this was settled and likely to land soon, and since ISO moves really slowly, we should start on the encapsulation work. If that's not the case, let me know. (Though text on "how to handle a wombat invasion" when in fact, there is no provision for wombats at all, is harmless).

[nigelmegitt]

I'm more concerned that there could be conceptual differences in the models in our heads for how this might work, so there could indeed be harm - some people might be trying to handle a wombat invasion, and others might be trying to work out how to house wombats in a safe way, and nobody is asking the wombats.

[gkatsev]

So, I think there are two things here.

1. update VTTCue API to allow Infinity for the endTime. This aligns it with the outstanding PR against TextTrackCue (https://github.com/whatwg/html/pull/5953) and comes from this issue https://github.com/whatwg/html/issues/5297. Based on the original issue, I think this is mostly for request programmatic access and is mostly agreed upon, afaik.

(I was actually trying to test whether you can update a VTTCue live and how it updates but running into weird bugs, I'll try again another day)

2. As part of this PR, in the TTWG discussion, the question came up whether we wanted/needed syntax in WebVTT to represent this, and I think this is where a lot of the issues are coming up with. I think it would definitely be valid to decide that WebVTT can't represent unbounded cues, though, given that WebvTT is supposed to be also used for metadata, I think it probably should but can and should be addressed separately from this PR.

[rjksmith]

One solution is to update the end time of an unbounded cue by superseding it with a bounded cue which has matching start time and content.

For example:

NOTE Unbounded cue

00:30.000 -->
This cue lasts until...

NOTE Subsequent cues go here

00:40.000 --> 00:50.000
This is a later cue

NOTE When known, update the unbounded cue end time

00:30.000 --> 01:30.000
This cue lasts until...

NOTE Cues after update time go here

01:30.000 --> 01:35.000
...now.

This would not require an identifier and has the advantage of including a valid bounded cue in the stream at the earliest moment when all its attributes are known - for compatibility. @gkatsev has already confirmed that unbounded cues will be ignored by current WebVTT parsers. WebVTT cue time ordering would need to be relaxed for this exceptional case and could be used as an efficient mechanism for identifying updates.

[gkatsev]

At FOMS in previous years we discussed how WebVTT should be used for live and segmented vtt files, particularly around cues that span multiple segments. One of the things that came out there is that you could match up cues with the same text and start time across segments and update the end time to that of the last cue that you got, kind of like @rjksmith shows above. This actually also fits well with the unbounded cue with the missing end time thing.

[eric-carlson]

We already have the situation where a cue's end time is "unbounded" at first and is updated later, because some in-band text track formats deliver cues with only a start time. In these formats a cue ends when the next cue or empty edit is delivered.

We support this in WebKit by giving these cues an end time of positive-infinity when they are delivered, and updating the end time when it is known

[nigelmegitt]

We already have the situation where a cue's end time is "unbounded" at first and is updated later, because some in-band text track formats deliver cues with only a start time. In these formats a cue ends when the next cue or empty edit is delivered.

That works in a semantic model where only one "cue" can be active at once, but WebVTT's model does not enforce that constraint, so I don't understand how it helps here?

[eric-carlson]

We already have the situation where a cue's end time is "unbounded" at first and is updated later, because some in-band text track formats deliver cues with only a start time. In these formats a cue ends when the next cue or empty edit is delivered.

That works in a semantic model where only one "cue" can be active at once, but WebVTT's model does not enforce that constraint, so I don't understand how it helps here?

I was merely pointing out that cues are being delivered on the web today whose duration is unknown when they are delivered, in case this isn't widely known.

[rjksmith]

We already have the situation where a cue's end time is "unbounded" at first and is updated later, because some in-band text track formats deliver cues with only a start time. In these formats a cue ends when the next cue or empty edit is delivered.

We support this in WebKit by giving these cues an end time of positive-infinity when they are delivered, and updating the end time when it is known

@eric-carlson Thanks for your constructive feedback. Highlighting another valid use case is helpful and this could also be supported by WebVTT using the syntax proposed above. WebVMT has a similar use case for live streaming.

[nigelmegitt]

Highlighting another valid use case is helpful and this could also be supported by WebVTT using the syntax proposed above.

@rjksmith There are a lot of unanswered questions implied by the syntax proposal. First on my list is: given that WebVTT does not prohibit multiple cues with the same begin time, begin time seems to be unsuitable for use as a key to match the cue. How would you resolve this?

[rjksmith]

So, I think there are two things here.

1. update VTTCue API to allow Infinity for the endTime. This aligns it with the outstanding PR against TextTrackCue (whatwg/html#5953) and comes from this issue whatwg/html#5297. Based on the original issue, I think this is mostly for request programmatic access and is mostly agreed upon, afaik.

2. As part of this PR, in the TTWG discussion, the question came up whether we wanted/needed syntax in WebVTT to represent this, and I think this is where a lot of the issues are coming up with. I think it would definitely be valid to decide that WebVTT can't represent unbounded cues, though, given that WebvTT is supposed to be also used for metadata, I think it probably should but can and should be addressed separately from this PR.

@gkatsev I agree.

1. There is a proposal to include unbounded cues in HTML TextTrackCue (https://github.com/whatwg/html/pull/5953) and this Pull Request addresses the minimum update required to WebVTT as a direct result of that change.
2. Four use cases have been highlighted above - WebKit, FOMS, 0-0 and WebVMT - which relate to unbounded cues so there is an identified requirement which WebVTT could address in future. Syntax has been proposed to represent unbounded cues in WebVTT which demonstrates feasibility for inclusion, though I'm sure this first draft could be improved. These issues should be explored constructively as inputs to any decision to include unbounded cue support in WebVTT and are beyond the scope of this Pull Request. I'll raise an issue for unbounded cue use cases to progress that discussion separately and decouple it from this PR.

[css-meeting-bot]

The Timed Text Working Group just discussed WebVTT - Added unbounded TextTrackCue.endTime w3c/webvtt#493, and agreed to the following:

• SUMMARY: 1. No objections to this PR as is, though we are blocked on tests. 2. Move the unbounded cue syntax question into a separate issue.

The full IRC log of that discussion

<nigel> Topic: WebVTT - Added unbounded TextTrackCue.endTime w3c/webvtt#493
<nigel> github: https://github.com/w3c/webvtt/pull/493
<nigel> Gary: Two issues that are discussed in the pull request. I think we should be clear on what the PR is
<nigel> .. and whether there are any objections about that progressing and then we can talk about the other part.
<nigel> .. The PR is about updating the VTTCue API to be able to have an unbounded end time, i.e. set to infinity.
<nigel> .. It lines up with the HTML spec for TextTrackCue, and was brought up mostly as a way for metadata but I think it makes sense for anything.
<nigel> .. Since this PR only covers that, are there any objections for that part of it?
<nigel> Nigel: Note we discussed this 28 days ago at https://github.com/w3c/webvtt/pull/493#issuecomment-790758189
<nigel> .. We wanted tests, and to ask if a syntax change is needed.
<nigel> .. Formally, I think it is _not_ required to have a syntax change to agree to this change.
<nigel> Gary: Yes, and as the discussion brought up, there are a lot of complications to doing that, and what it would mean,
<nigel> .. so it is good to decouple it so we are not holding up this change elsewhere while we figure out the syntax.
<nigel> .. As David Singer said, even in ISOBMFF, they don't really specify how these unbounded cues might come to be.
<nigel> Nigel: We need to be careful - ISOBMFF is only a file format wrapper, so for them to be even considering unbounded VTT cues without
<nigel> .. any syntax to represent them is a bit disturbing.
<nigel> Gary: I think there are use cases for the syntax change but figuring them all out and the semantics is definitely not just slapping a change in
<nigel> .. to the cue settings - it's probably not good enough on its own.
<nigel> Nigel: Are there any tests?
<nigel> Gary: I don't know if there are yet. Rob Smith did say he would write some. I don't know if he's got around to it yet.
<nigel> .. I think we can wait for tests, and that can be the only blocker for this PR.
<nigel> Nigel: Makes sense.
<nigel> Gary: Do we want to discuss syntax, or punt on it for now?
<nigel> Nigel: I think raise it as a separate issue.
<nigel> Gary: Yes, makes sense.
<nigel> .. If Rob doesn't make that issue then I will make one.
<nigel> SUMMARY: 1. No objections to this PR as is, though we are blocked on tests. 2. Move the unbounded cue syntax question into a separate issue.

[rjksmith]

Highlighting another valid use case is helpful and this could also be supported by WebVTT using the syntax proposed above.

@rjksmith There are a lot of unanswered questions implied by the syntax proposal. First on my list is: given that WebVTT does not prohibit multiple cues with the same begin time, begin time seems to be unsuitable for use as a key to match the cue. How would you resolve this?

@nigelmegitt I agree that using only start time to match the cue is unsuitable which is why I proposed matching by start time and content as stated previously.

As promised above, I've now raised issue #496 for discussion of use cases and syntax changes separately and suggest we continue this conversation there. Thank you.

[rjksmith]

I think you might have received an email from W3C non-participant contribution system at Mar 11, 2021, to an email address you registered to W3C account.

@himorin Many thanks. I've found it.

Thanks for your help. I can confirm that I've now signed this.

[rjksmith]

Oh, just realized that maybe TextTrackCue has tests too and sure enough it does. https://github.com/web-platform-tests/wpt/blob/master/html/semantics/embedded-content/media-elements/interfaces/TextTrackCue/endTime.html I'll add a comment on the html repo PR too.

@gkatsev Having written suitable tests in web-platform-tests/wpt#28394, I noticed that https://github.com/web-platform-tests/wpt/blob/master/html/semantics/embedded-content/media-elements/interfaces/TextTrackCue relies on the VTTCue constructor so whatwg/html#5953 and #493 (this) are interdependent. I don't foresee a problem, but these changes need to be properly co-ordinated because of the Web Platform Tests. Hope this helps.

[rjksmith]

@himorin I've signed the non-participant agreement but still see a failing check on this issue.

Acceptable: no Contributor: @rjksmith needs to submit their non-participant licensing commitment via the link they received by email.

Please advise if there are further actions I need to take to resolve this. Thanks.

[rjksmith]

Rebased to main

[rjksmith]

Excellent. You're welcome and thanks for your guidance @foolip

[rjksmith]

@gkatsev This PR is now ready for review and merge - as are whatwg/html#5953 and web-platform-tests/wpt#28394. Please co-ordinate with @foolip to synchronise these changes and let me know if there are any problems. Thanks.