Meeting minutes
This meeting
Nigel: Today: DAPT, IMSC 1.3, WebVTT, TPAC 2025 planning
… Anything else, or points to make sure we cover?
nothing extra
IMSC 1.3
Nigel: We're waiting for Wide Review here.
Pierre: We're only waiting for HR from Accessibility
… The TAG delegated it to internationalisation, who are satisfied, so they're both closed.
… Privacy and Security, I think were not unhappy, but have not closed their issue.
… The ones we've not heard from are folks in the accessibility group.
Gary: Looks like no response on the privacy ticket, only on the security request.
Pierre: We had requested for a response before Sep 16 so you or I could ping the privacy folk
… and also remind the accessibility folks.
Nigel: It was assigned 2 weeks ago so someone is looking at it.
Nigel: Feels like a "friendly reminder" message.
Pierre: Yes, we should do that on both privacy and accessibility
Nigel: I feel like I should do it.
Pierre: Thanks.
Gary: I don't know if you want to close the security request ticket since it sounds resolved.
Nigel: I've added a message to that ticket asking if okay to close.
… I've also added friendly reminders to the other two open tickets
Nigel: Anything else for IMSC?
Pierre: Nothing that I know of.
DAPT
Nigel: Seems like current status is that Atsushi raised HR issues for the CR snapshot and we're
… waiting for responses.
… They're logged under w3c/dapt#307
… Seems like he did that last week
… I think we're just waiting now.
… Anything else on DAPT?
Cyril: No, no updates on DAPT
WebVTT open issues
Interop meetings
Gary: I wanted to mention the Interop meetings
Dana: If it would be helpful I can send another email.
… We've had 2 meetings so far.
… Every other Wednesday.
… Next is Sep 10
… Goal is to clean up the test suite enough that we can eventually be an Interop focus area
… We've been going through the tests all the browsers are failing
… and identifying test issues.
… Found a few, and raised some issues.
… The first is one that's been open a while, which is 531.
Nigel: A reminder of that interop work might be helpful
<gkatsev> interop webvtt repo
Dana: WebVTT was accepted as an Interop investigation area which means that work is needed
… to fix up the test suite before it can be a focus area.
… We're going through the tests one by one and checking if it is valid, up to date, and bug free
… We're looking for as many people who are interested to join.
… Next meeting is Sep 10.
Gary: I posted the repo
Dana: Even if someone doesn't have time to go through tests, they're still welcome to
… go to the meetings and join in on discussions about what to do about faulty tests
Nigel: Any questions?
Pierre: I maintain ttconv which is a timed text conversion library.
… Folk have bugged me and provided pull requests to add support for vertical text in WebVTT,
… and that had not been done originally because the support levels in players didn't allow for testing.
… Last time someone suggested this and added a pull request they mentioned that their
… reference player is video.js.
… Is that a good reference? I'm trying to avoid merging something that turns out not to be valid
… or contains the wrong WebVTT.
Gary: video.js uses the most maintained version of vtt.js and I believe (not checked recently)
… that it has the correct vertical positioning.
Pierre: Is video.js going to be included in the interop testing?
Gary: The main focus is the native browser user agents
Pierre: I'm trying to resist the temptation to add something that works great in video.js
… only to find out that no browser implements it and then we've done worse.
Gary: That's a downside of the web platform tests vs the implementation report.
… The WPT is more aimed at browsers, whereas the implementation report is about "any" implementations at all.
… The first step is what Dana mentioned, figuring out if the tests are correct.
Pierre: Theoretically you could use ttconv to convert TTML tests to WebVTT tests but then
… you're introducing another variable.
… There's obviously a need for this but I've been reluctant to committing something that's bad.
Gary: I'm pretty sure Safari does vertical text correctly, because I fixed it.
Pierre: Maybe you could add to that issue?
Pierre: Thanks for the wisdom!
Can ::cue(selector) match a list of webvtt node objects? w3c/webvtt#533
github: w3c/
Dana: This is about ::cue pseudo element.
… You can add a selector to that as an argument.
… We're finding that all of the browsers are failing the tests where the selector is * or :root
… When we consult the WebVTT specification we find that it's ambiguous.
… It's not spelled out if those selectors are supposed to be supported.
… One idea that I think I agree is to have the only allowed type selectors be the explicit VTT classes
… like bold, underline, voice, language, ruby text, so we have a concrete list of type selectors,
… and the universal or root selector wouldn't be supported.
Gary: The issue is that the spec implies that bare text nodes should be selected, but it's not clear.
… Should the * match those as well as the explicit tags.
… No browser implements selection of the explicit tags without the text nodes ("internal node objects")
… But whether it should is unclear.
Nigel: What are the use cases?
Dana: It's for styling the internal nodes within the cues, e.g. make all bold elements green.
… The use case for the * selector is covered by the pseudo element without the selector argument,
… because that already matches to the cues.
Andreas: Thanks for bringing this up.
… For confirmation, if you have cue text and you want to apply CSS styles to all of them,
… then you can already do that by using ::cue without a selector?
nods
Andreas: And the * selector most likely is supposed to do the same thing?
… But it's ambiguous if it includes text enclosed by tags.
… It's questionable why you should exclude it.
… Why should the * selector give the same results as no selector?
Gary: Given that it's covered, unclear in the spec and not implemented, we can remove it
… from the spec and call it a day.
Dana: Would the spec change be to say that the 8 or so type selectors are the only allowed ones?
Gary: I think that might be the best course of action, to be as explicit as possible.
Nigel: Are you saying that * selector applies to tagged text only, or to remove *?
Gary: The first, that it applies to tagged text only.
Nigel: What's the relationship between that and Dana's suggestion of limiting the set of tags?
… Sounds like an orthogonal issue.
Gary: The spec lists the node objects, which are the untagged text objects.
… Simon suggested the root element never match. I guess that would be an alternative,
… to say that internal node objects don't match the * selector.
Andreas: I'm also a bit confused. I thought that your approach would be to remove the * completely,
… but you're now saying to keep it but make the semantics only apply to text inside tags?
Gary: Yes, I don't know if we can remove it completely.
Andreas: If it's ambiguous and not properly implemented then this way is also not properly implemented, right?
… Why are you using this kind of solution?
Nigel: you mean what is the * for at all?
Andreas: Yes, if it's ambiguous and not properly implemented, why target a specific different meaning?
… What points you to this solution?
… If it's used already and people have a different interpretation, then some existing WebVTT
… files might then have a different presentation, and users would not be happy.
Dana: That's a good point. I'm not sure which solution I like best.
… I'm thinking, in terms of ease of implementation, there could be a potential problem to have
… the * only apply to internal text and not the root, because then we have other selectors
… like the id selector that would need to match the root.
Gary: One of the ambiguities is that it says, maybe we used the terms incorrectly,
… that it matches any internal node object and that includes both tags with existing names
… and those without explicit names, like times.
… and then it says leaf nodes are not matched, and those include text or fragments of text.
… There's that ambiguity that fragments seem to be listed as matchable but then later on it says
… leaf node objects cannot be matched.
Dana: Are you talking about how the spec says in one place that leaf node objects are separate
… from internal node objects and then later on it says they are a subset of internal node objects?
Gary: Yeah, I guess this isn't straightforward.
… I think the main question is that in the cue selector it has a table of things it should be able
… to match and the question is what it means by "other elements".
… I think we need to review the spec again because it's very likely that we still need a clarification
… but maybe the spec is clearer than on first reading, and the tests may not be correct.
Andreas: As a suggestion, you might want to consult the meeting archives to find a better hint
… on the intent.
Nigel: Good point, why is it written the way it is written?
Dana: I'm curious if we say that a selector matches a leaf node object, like a text node object,
… is that referring to the text content within a span, which you cannot style?
… When they said you cannot target the leaf node objects maybe that's what they're talking about.
Gary: It could be the same as HTML where you cannot target text but you can target the span that they're in.
Dana: If you can't target that then you target the root.
Gary: Yes, that would be the ::cue
Dana: Another way is to say it matches both the root and any internal nodes.
Nigel: Another way is to say the * matches on the tag name, and not on null, so the root would be excluded.
Gary: That's what it seems like it wants to do.
… Then :root would not be allowed as a selector, and * would not match against :root
Nigel: Why not allow :root?
… From an implementation perspective would you not have the default selector for ::cue be ::cue(:root)?
Gary: The options are either * and :root are allowed or explicitly not allowed.
… Since it's also a CSS extension and the implementations are lacking we can decide to simplify it.
Nigel: What's the next step?
Gary: Immediate next step is to read through the spec again to exactly understand what it means
… by internal node objects and leaf node objects and see if there's any history about the intent.
SUMMARY: @danae404 and @gkatsev to re-read the spec about nodes, and check the archives for history about the intent.
Dana: Are there publicly available notes about the development of WebVTT spec?
Gary: I think they are, and there's discussion on GitHub.
Andreas: Some of it will be in the text track community group. There may have been
… some in the WHATWG too so you may have to look at different sources.
Gary: Some of the old FOMS websites when WebVTT was first developed have some notes too.
WebVTT should allow pages to modify the caption display area w3c/webvtt#531
Dana: There's no good way to test that WebVTT cues move out of the way when controls are showing
… because every browser has different default controls. The spec doesn't state anything about
… where the cue should be so it's up to the implementation to check where the cue moves to
… when controls show.
… We deleted 3 tests that had arbitrary positioning that didn't correspond with any real implementation.
… We're hoping to accurately test that cues move out of the way of controls.
… One way is to expose a pseudo-element for the controls bar so we can query its location
… and make sure it doesn't overlap with the cue.
TPAC 2025 planning
Nigel: The schedule has been published.
… Typically we create a wiki page for TPAC, for the group.
… I may have taken an action to do that last time.
… The key thing we need is a list of agenda topics.
… It's also useful to know who will be attending.
Andreas: I will be attending, and was thinking about discussing DVB work that has happened lately.
… 2 years ago we discussed a proposal for signalling subtitles.
… There's now an ETSI publication on that.
… That could be addressed, and some other new developments in DVB.
… We can check with Chris Needham - it may fit in the joint meeting with the MEIG,
… but the signalling of the purpose of subtitling could good to discuss at TPAC.
Nigel: Thank you.
… TPAC must be 9-10 weeks away so now is the time to focus on this.
Gary: I won't be there in person but the beginning of the sessions are in my evening and not too
… late so I plan to join remotely.
Nigel: That might affect the ordering of our topics.
… We typically list in person attendees, I will send a link when I have made it.
Dana: I will be remote too.
Gary: The timezone should be better for you on West Coast than me.
Dana: I would like to continue discussing WebVTT interop.
Meeting close
Nigel: Thanks all, we're out of time for today. Next meeting is in 2 weeks, on 2025-09-11.
… [adjourns meeting]