14:58:39 RRSAgent has joined #tt 14:58:43 logging to https://www.w3.org/2026/04/23-tt-irc 14:58:43 RRSAgent, make logs Public 14:58:44 Meeting: Timed Text Working Group Teleconference 14:58:57 Agenda: https://github.com/w3c/ttwg/issues/332 14:59:03 scribe: nigel 14:59:09 Previous meeting: https://www.w3.org/2026/03/26-tt-minutes.html 14:59:40 Present+ Nigel 14:59:49 rrsagent, make minutes 14:59:50 I have made the request to generate https://www.w3.org/2026/04/23-tt-minutes.html nigel 15:01:17 Present+ Eric_Carlson, Andreas, Simon_Pieters 15:01:34 Present+ Gary 15:01:37 Chair: Nigel, Gary 15:01:53 Present+ Cyril 15:02:00 Topic: This meeting 15:02:22 Present+ James_Craig 15:02:32 Present+ Pierre 15:03:33 Nigel: Today we have: 15:03:44 .. * DAPT - though that's an empty topic I think 15:03:52 .. * IMSC 1.3 15:04:00 .. * WebVTT 15:04:15 .. * Impact of AI technologies on TTWG's mission 15:04:24 .. Is there any other business, or things to make sure we cover? 15:04:41 Present+ Dana 15:04:48 zcorpan has joined #tt 15:04:55 present+ 15:05:13 jcraig has joined #tt 15:05:26 present+ 15:05:27 atai has joined #tt 15:05:39 Topic: DAPT 15:06:00 Cyril: I see you added another implementation. Still waiting for 1 more for the audio parts? 15:06:18 Nigel: Yes that's right, the EBU's Eurovox product generates DAPT transcripts and translations. 15:07:05 Cyril: That's the only blocker for transition to Rec? 15:07:14 Nigel: Yes, that and final decisions about what to do with the at risk features. 15:07:20 Topic: IMSC 1.3 15:07:35 Subtopic: Rec transition AC Review 15:07:46 Dana has joined #tt 15:07:58 Nigel: The AC WBS poll is open, please ask your AC rep to vote, if you are in a member organisation! 15:08:10 .. I can see that several have voted already. 15:08:28 Subtopic: Namespace document 15:09:00 .. There's a PR open on w3/ns to add the IMSC 1.3 namespace, link in the agenda. 15:09:08 Pierre: It's been merged 15:09:20 Nigel: Great, that's this subtopic closed then! 15:09:29 Subtopic: TTML Profile Registry 15:09:40 Nigel: Should we add IMSC 1.3 Text as im4t? 15:10:01 .. I can raise a pull request for that. 15:10:04 Cyril: Why 4? 15:10:23 Nigel: Because 3 is taken up by IMSC 1.2. Because of IMSC 1.0.1 I think 15:10:35 .. Any objections? 15:10:40 Cyril: No 15:10:49 no other objections 15:11:11 Nigel: OK I'll do that. 15:11:20 Topic: WebVTT 15:12:17 Gary: The main topic is the ATTRIBUTES block PR. 15:12:35 eric-carlson has joined #tt 15:12:41 .. Background is Apple wanting to add a new metadata type for their Dim Flashing Lights feature. 15:12:58 James: Currently you might see just a warning at the beginning, 15:13:10 .. it would be better to take action during the content. 15:13:23 .. The metadata issue and PR are pre-requisites for shipping that feature to other platforms 15:13:40 .. and to open up VTT metadata to being a broader more reusable metadata structure. 15:13:51 .. Sounds like we're really close to a resolution here. 15:14:03 Gary: I think we're close. Thanks for providing a summary of the main open questions. 15:14:16 .. The main one is whether to be a new block or part of the header location. 15:14:23 James: [shares window] 15:14:43 i/Gary: The main/Subtopic: New ATTRIBUTES block 15:14:51 github: https://github.com/w3c/webvtt/pull/523 15:16:03 James: If there's no concern of webcompat then I'm not concerned about not having a new block, 15:16:17 .. and just moving the newly proposed data into the header. 15:16:36 Simon: That's my preference, it's what that was intended for. 15:17:00 Gary: I think it would be good to have the = permitted even if not recommended. 15:17:20 .. I don't know if there's any precedence for this in W3C specs, but in Javascript the __proto property 15:17:26 .. was added with a note to tell people not to use it. 15:17:52 Simon: HTML has similar precedent, for various elements that were never standardised but browsers implemented 15:18:04 .. were specified in HTML with the "obsolete" status immediately applied. 15:18:09 q+ 15:18:21 James: Is that a list, or a recommendation against using any prior non-standard way. 15:18:32 Simon: Here it's using = instead of : as a separator. 15:18:50 James: Use = as a separator but say it's not recommended. 15:18:52 ack at 15:19:10 Andreas: For context, is this the same issue that James presented in TPAC in Seville more than 2 years ago? 15:19:13 James: Yes 15:19:25 Andreas: I liked the proposal at the time but haven't followed it. 15:19:43 .. We made some comments, but in this case will there be a 2 weeks review period so I can check it? 15:19:48 q+ 15:20:00 q+ 15:20:03 James: I have some time off next week so can't promise 2 weeks. 15:21:13 Nigel: [explains TTWG working mode] 15:21:28 James: I'm planning to summarise the discussion from today and then add it as a comment to the PR 15:21:41 .. So if people want to clarify any details or I've misunderstood then people can see that. 15:21:50 .. I'll leave it as a draft PR until then. 15:22:45 q? 15:22:47 ack n 15:22:51 ack zcorpan 15:23:11 Simon: Case sensitivity: currently WebVTT is mainly case sensitive, so it would be consistent to 15:23:19 .. be case sensitive here as well. Is there a reason not to be? 15:23:24 Gary: For the attribute names? 15:23:28 Simon: Yes 15:23:47 James: Yes there is pre-existing use by YouTube and others who have capitalised attribute names. 15:23:59 Simon: Are those attribute names the same as the standard ones we're trying to add? 15:24:20 Gary: It depends on which one - like kind etc. 15:24:39 .. The case-insensitive part comes up later in the summary of bullets. 15:24:49 .. The next point is how we want to define parsing of the attribute names. 15:25:23 .. Right now what is implemented is ASCII+, other proposals include XML Name or HTML attribute name. 15:25:30 .. My question is: does it need to be ASCII only? 15:25:53 .. In WebVTT we already have IDs like cue and region identifier, where any character except --> or space 15:26:05 .. is permitted. It already specifies that the cue identifier needs to be unique in the file, 15:26:21 .. so the parser would need to do unicode normalisation and other things to make sure the IDs are unique. 15:26:22 q? 15:27:04 James: The only concerns I brought up are bidi and reverse chars, look-alike characters, or zero-width joiners, or emoji variant combinations? 15:27:24 Simon: At the higher level do we need to make it conforming to use non-standard metadata attributes 15:27:36 .. in the first place. If not this is moot, we just list the permitted attribute names. 15:27:57 James: The reason for this is, depending on the type that is chosen, I think it is appropriate for the TTWG 15:28:11 .. to be the keyholder of what the type is, but once that type is defined it could be some other standards 15:28:20 .. body that defines the keys. 15:28:27 .. Maybe we don't need to do that. 15:28:44 .. At the same time I put in the concept of a custom metadata block that is freeform, not standardisable, 15:28:49 .. but parsed, so the implementation could use it. 15:29:05 .. If that's the case we should allow freeform characters of whatever character set we define. 15:29:12 Gary: I think it would be helpful to allow custom attributes. 15:29:31 .. The reason we had the previous issue is because WebVTT didn't have an official way to include metadata. 15:29:47 .. If there was something official then e.g. HLS could have used that for the timestamp map. 15:30:14 .. Now I wonder if we want to limit the official names, with an x- prefix, to make it easier for us to add new attributes. 15:30:24 James: Or use the HTML pattern data- 15:30:35 Simon: Or just a - at the beginning, like in HTML. 15:30:48 Gary: In that case would it make sense to point to the HTML attribute parsing, or do we still 15:30:55 .. need to specify the - for custom names. 15:31:12 Simon: It's not so much that, which we may need to define ourselves, but we can be aligned that 15:31:21 .. no dash means it's defined by the standard. 15:31:35 James: For Gary's question, do we want to point it to the HTML attribute name for parsing? 15:31:39 Simon: I think no. 15:31:58 .. We need to ban --> for example, although > is not allowed in attribute names, but it's a different rule. 15:32:14 Gary: We probably want to be similar to how region identifiers are implemented. 15:32:16 q+ 15:32:33 Simon: I don't think we need to worry about lookalike characters. These are all possible in identifiers right now 15:32:37 .. I think. 15:34:44 Nigel: +1 to aligning with HTML attribute name syntax, because we want to allow the attributes to be reused in HTML. 15:34:45 q+ 15:34:50 ack n 15:36:21 Simon: Non-standard attributes would be invalid HTML unless they begin with data- 15:36:41 Nigel: OK, imagine people want to push WebVTT attributes into the HTML for their own reasons. 15:37:02 James: Are you proposing some model for tunnelling these attributes through from VTT to HTML? 15:37:17 Nigel: We haven't discussed that as a processing model, but I don't think we need to. But we should 15:37:25 .. make the path easy in case people do want to do that. 15:37:34 q? 15:38:19 James: Are we saying any Unicode char except bidi and --> ? 15:38:30 Gary: I think so, yes. Just remove the "ASCII only" part. 15:38:37 ack gk 15:38:55 .. Being case-sensitive is probably easiest. The potential benefit of being case-insensitive is if we were 15:39:12 .. to allow language for the lang attribute, because that will allow the current YouTube metadata to work 15:39:19 .. without any further work on their part. 15:39:32 Simon: Making YouTube's content magically do something should be a non-goal. 15:39:44 .. They can update that in an afternoon. We shouldn't complicate the language for that. 15:39:57 .. Maybe that means we should not care about case-insensitive or the = sign either. 15:40:12 .. If we were using the ATTRIBUTES block then the existing headers would still do nothing in the standard 15:40:23 .. implementation, so we can decide that if the syntax doesn't match then it still does nothing. 15:40:33 .. It's not breaking any more than it's broken today if we ignore it. 15:40:54 James: Follow-on question: if any of these attribute lines is invalid do we invalidate the whole block or just that line? 15:41:09 Gary: Just that line. Looking at the HLS timestamp map there is a colon used. 15:41:37 .. It wouldn't match exactly, but the attribute name would not just be the [scribe missed] 15:41:55 .. The main reason is that it's so ubiquitous in HLS content that having it be valid would be helpful. 15:42:03 Simon: HLS compat is more compelling than YouTube compat. 15:42:29 Gary: Yes. If and when we have a follow-up of a GetAttributes() method then we could decide how to handle 15:42:36 .. non-standard attribute names from being returned. 15:42:45 .. We could just not worry about them at the moment. 15:43:00 Simon: If the intent is that they should be usable from Javascript then there needs to be a way for them 15:43:09 .. to be usable other than fetching and parsing the file again. 15:43:19 Gary: Yes but that doesn't need to be part of this PR. 15:43:41 James: Sounds like we're aligned on 2, moving on, to the question of the reserved kay name being lang or language. 15:46:40 Nigel: I can't recall my original comment, and I can't find it! 15:47:06 .. Matching HTML attributes in the track element makes sense, I have some recollection that care was needed 15:47:21 .. for translation subtitles when indicating the language from which they were translated. 15:47:37 James: I'll see if I can find that comment, but work on the basis of `lang` for now. 15:48:04 .. Item 4 is about if `kind` is required, or should `kind: metadata` be required in order to use metadata type. 15:48:25 .. I feel that we should require it but if we only require it with a metadata value then it seems complex, 15:48:36 .. and I'd appreciate advice on how to do that, if that is what we decide. 15:48:45 Gary: It doesn't seem worth requiring it, to me. 15:49:05 .. If you have a type then potentially you could assume kind: metadata but even that seems unnecessary, 15:49:19 .. because what if in the feature we decide to have multiple types of captions, or something like that. 15:49:26 .. We could extend it for other kinds as well. 15:49:35 q+ 15:49:38 James: Then the parsing rule I will attempt to write will be: 15:49:49 .. if there is a type, then we would need a kind as well, in order to use the type. 15:50:00 .. if there is a type but no kind then the implementation wouldn't be sure how to use it. 15:50:01 q+ 15:50:12 .. It might be some future type with an unidentified kind. 15:50:29 Simon: Isn't there always a `kind` when sourced from HTML even if it is the default? 15:50:36 James: Yes, so the implementation can fall back. 15:50:46 Simon: Yes, the UA will have a kind even if it is the default. 15:51:07 James: One of the primary use cases is in Apple's services that could be used on other non-Apple hardware 15:51:21 .. such as the AppleTV app on another brand of TV, or HBO's content on AppleTV hardware. 15:51:34 .. I feel we need to know this outside the context of just the web. 15:51:39 q+ 15:51:41 .. I'll try to write it up logically in the PR. 15:51:45 ack z 15:51:54 ack n 15:52:41 q+ 15:52:41 ack g 15:52:55 Nigel: Until we define a processing model for all this metadata then we should not restrict anything. 15:53:07 .. We can add the syntax but then add restrictions later if we define a processing model. 15:53:25 Gary: I was going to say the same thing. 15:53:43 Simon: Just to comment on the processing model, at least for the standard attributes that we're adding then 15:54:00 .. it makes sense to specify the processing model in HTML, then you can use the file-provided attributes 15:54:15 .. as fallback. Then in WebVTT all you need to do is make that data available so that other specs can look into it. 15:54:35 James: To make sure I understand "the value provided", the kind attribute in HTML would override the value 15:54:53 .. in the WebVTT if provided, otherwise the WebVTT value would be used? 15:54:57 Simon: Potentially, yes. 15:55:21 James: So there'd be no need for a parser warning? 15:55:26 Gary: I agree 15:56:00 Nigel: I'd be more concerned about errors than warnings. I'd only expect a warning if there's a SHOULD 15:56:04 .. and I don't think there are any here. 15:56:10 James: I'll check that. 15:56:35 Gary: If the line is invalid from a parsing perspective we would skip it. 15:56:47 Simon: But if --> is present then it would be invalid so we would expect some parser message 15:56:59 Gary: Even then the parser might just ignore it and move on. 15:57:15 Simon: Sure, sometimes the parser has errors even if it also ignores. 15:57:42 James: The final point is about the examples, and I'm happy to concede to consensus. 15:57:54 Gary: You could add subtitles to an existing example. 15:57:58 James: Fair point. 15:58:37 Subtopic: Spec ownership and auto-publication status 15:58:54 Nigel: I think we need Atsushi for this. 15:59:30 .. For those who haven't been following there was a question about TTWG officially taking ownership of WebVTT. 15:59:46 Gary: There was a CfC that had no objections so we need Atsushi's help to figure out the next steps. 15:59:53 Topic: Meeting close 16:00:12 Nigel: Thanks all, we didn't cover the TTWG mission related to AI, for another time when Atsushi is present. 16:00:48 .. See you in 2 weeks. [adjourns meeting] 16:01:01 rrsagent, make minutes 16:01:02 I have made the request to generate https://www.w3.org/2026/04/23-tt-minutes.html nigel 16:02:00 present- zcorpan, jcraig 16:05:27 s/[explains TTWG working mode]/The TTWG working mode is to treat open (non-Draft) PRs as CfCs, and apply the TTWG Decision policy to them, so if there's an Approve and no Request Changes after 2 weeks, it can be merged. 16:08:00 s/reserved kay name/reserved key name 16:10:22 rrsagent, make minutes 16:10:24 I have made the request to generate https://www.w3.org/2026/04/23-tt-minutes.html nigel 16:12:13 scribeOptions: -final -noEmbedDiagnostics 16:12:17 zakim, end meeting 16:12:17 As of this point the attendees have been Nigel, Eric_Carlson, Andreas, Simon_Pieters, Gary, Cyril, James_Craig, Pierre, Dana, zcorpan, jcraig 16:12:19 RRSAgent, please draft minutes v2 16:12:20 I have made the request to generate https://www.w3.org/2026/04/23-tt-minutes.html Zakim 16:12:26 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:12:27 Zakim has left #tt 16:12:39 rrsagent, excuse us 16:12:39 I see no action items