14:59:40 RRSAgent has joined #tt 14:59:44 logging to https://www.w3.org/2026/06/18-tt-irc 14:59:44 RRSAgent, make logs Public 14:59:45 Meeting: Timed Text Working Group Teleconference 15:01:17 scribe: nigel 15:01:17 Agenda: https://github.com/w3c/ttwg/issues/341 15:01:41 Previous meeting: https://www.w3.org/2026/06/04-tt-minutes.html 15:01:41 Present: Nigel 15:02:13 Present+ Gary, Andreas 15:02:41 Chair: Gary, Nigel 15:03:45 atai has joined #tt 15:04:21 Topic: This meeting 15:04:44 Nigel: Today we have one DAPT issue and pull request to consider, 15:05:03 .. a possible consequence for the TTML Media Type and Profile Registry 15:05:11 .. Two issues on WebVTT 15:05:16 .. TPAC planning 15:05:34 .. AI impacts 15:05:41 .. and WebVTT Interop 15:05:52 .. Anything else for the agenda? 15:06:02 Present+ Cyril 15:06:26 Present+ Atsushi 15:07:15 Topic: DAPT 15:07:17 Subtopic: Profile identifier and TTML registry w3c/dapt#248 and w3c/dapt#337 15:07:32 github: https://github.com/w3c/dapt/issues/248 15:08:42 cpn has joined #tt 15:08:46 present+ Chris Needham 15:08:48 scribe+ 15:08:48 Nigel: [summarises most recent comment on the issue] 15:09:40 Nigel: The Content Profile and the Processor Profile have different designators. Why? 15:10:26 ... I've been looking into it. The reason for having two profiles, is because we have two dispositions in DAPT, they're not supported in TTML for inferring a processor profile from a content profile 15:11:23 ... The only safe way I found, back in Dec 2022, to express what we wanted is to have two separate profiles 15:12:06 ... We introduced the designators in March 2023. We gave them different designators as there's text in TTML that says the designator URIs may be any URI that references a profile document 15:12:12 ... Those are in the profile and in the spec 15:12:53 ... So you if try that in the browser, the server returns an HTML document, but it's not presented properly as it uses text/plain 15:13:23 ... All that the documents do is point you to the bit of the spec that defines them. They're in the ns space in w3.org 15:13:40 ... I think we have a couple of options 15:14:13 ... One is to do what the PR says: keep two designators. We wouldn't need a new CR snapshot, but we should fix the content type that's served 15:14:50 ... Find a way to add a note to say that this if you're looking at a DAPT document 15:15:28 ... The second option is to merge the PR that makes it a single designator, then change the PR on the TTML type profile registry to point to the single value, and make it so the new URI dereferences to a sensible page 15:15:35 ... At the moment it's just a 403 15:16:06 ... We'd meet the TTML requirement for it to feasibly dereference by serving a page 15:16:21 ... There'd be a double dereference 15:16:42 ... In DAPT we'd need to determine which class of change it is and whether that needs a new CR snapshot 15:17:45 ... It's a class 3 change, which are considered substantive, so needs a CR snapshot to be published? 15:17:52 ... Does that all make sense? Any views? 15:18:09 Cyril: So one solution needs a new CR snapshot, and one doesn't? 15:18:14 Nigel: That's right 15:18:31 Cyril: So we update the page served by the designator 15:18:59 Nigel: The type profile registry would need an extra note about the existence of the profile, and the two pages served by the designator URIs need fixing 15:19:17 ... That might be just fixing the content-type used to be text/html 15:20:00 q+ for even if we need to do another CRS, delta HR shall pass almost without any review (since just change on descriptor), and shall be right,,,?? 15:20:06 Cyril: If we don't change anything, the document that defines the profile registry can be changed and there's no publication process to follow? 15:20:09 Nigel: Yes 15:20:42 Cyril: It seems there's a choice between doing things in a clean way, and doing something quickly 15:20:57 ... I think I favour publishing faster, so prefer avoiding a new CR 15:21:16 Nigel: Makes sense. Any other views? 15:21:27 Andreas: Cyril's proposal makes sense 15:22:08 Nigel: That's fine for me as well 15:23:03 Nigel: Issue 248 is about differentiating different document types. I think we can close that too 15:23:26 Cyril: Yes 15:23:38 SUMMARY: Close this issue with no change, close the related pull request without merging 15:23:56 SUMMARY: Update the related TTML Type Definition and Profile Registry pull request 15:24:19 SUMMARY: An action is needed to fix up the pages served at the profile designator URIs 15:24:27 q- 15:25:28 Atsushi: If we made that minor change, the process shouldn't be heavy. Any strong concern about doing another CRS? 15:25:56 Nigel: The time it takes, and any implementation that generates valid documents would have to be updated to change the designator they use 15:27:06 ... I'll open an action item for you to fix the pages 15:28:01 ... Any other thoughts on this, or DAPT? 15:28:03 (Nothing) 15:28:20 Topic: WebVTT 15:29:01 Subtopic: Add WebVTT header metadata to disambiguate metadata cues (#511) w3c/dapt#548 15:29:14 github: https://github.com/w3c/webvtt/pull/548 15:29:23 Gary: The new PR is out, in good shape but needs more reviews 15:30:28 Nigel: You had a comment about something being too restrictive without benefit? 15:31:15 Gary: It says that if you see a type that you don't recognise, you must not display it too the user. Is that necessary, as the expectation for metadata is that you don't display it 15:31:35 ... But if the user forces metadata to be visible this would conflict with that. It seems unnecessary 15:32:27 Gary: Does this assumes a new type value means a new form of metadata. But it could parse as VTT cues and be presented? 15:32:35 s/Gary/Nigel/ 15:32:51 Gary: I think it's associated with kind metadata, but that may be an unnecessary restriction as well 15:33:20 Nigel: I don't have a view right now, but something to think about 15:33:44 Gary: You also made a clarification request, on the parsing steps 15:34:31 Nigel: The rule is that a given rule key must not appear more than once in a WebVTT file. The first will be used. But what happens if it does appear more than once, is there an error state? 15:34:37 Gary: Makes sense 15:34:58 ... The parsing rules say there isn't an error generator 15:35:35 Chris: Is the "must" guidance to authors? 15:35:47 Gary: It's a lower-case "must" rather than an upper-case MUST 15:36:00 Chris: If that's the case maybe it should explain that. 15:36:28 Chris: Suggest rephrasing it to say "Authors should ... " as it's actually guidance to authors 15:36:34 Gary: Yes 15:37:27 ... We'll probably need WPTs for this 15:37:36 Nigel: Having tests along with PRs is helpful 15:38:07 Gary: I think that's everything on this PR 15:39:11 Nigel: There are a few actions to take, based on the comments. One thing is subtle, about an unordered list. James said he'd modify that. 15:39:41 Gary: So I don't think there's anything major left 15:40:34 SUMMARY: Review and edits to continue; group reminded to check this PR. 15:40:42 Topic: Add properties of Fill and Stroke spec plus paint-order to properties that apply to ::cue and ::cue() w3c/dapt#545 15:40:48 github: https://github.com/w3c/webvtt/issues/545 15:41:09 Gary: This is a request to a couple more CSS properties to the cue 15:41:25 ... It seems reasonable to me, but want others' opinions on it 15:41:38 ... Specifically, the paint order related properties, and the fill and stroke properties 15:41:55 Nigel: Why bring in a property from SVG? 15:42:29 ... Does anyone expect WebVTT to be rendered as SVG? 15:42:54 ... [Reads the spec] Ah, it applies to text, so makes sense 15:43:35 Gary: That paintOrder property does apply to text, as it's referred to in the fill stroke spec 15:44:10 Nigel: Is that needed, to do something different from the default? 15:44:32 Gary: I think it sounds reasonable if we're expanding it to allow for all relevant related properties 15:45:30 ... That might make sense. [Shows example in the spec]. The default behaviour is to paint the fill then paint the stroke 15:45:43 ... The one on the right looks much nicer 15:46:40 q+ 15:47:17 Andreas: The spec is an Editor's Draft, so it's not yet a stable version? 15:47:33 Nigel: The latest FIll and Stroke is a Working Draft 15:48:31 ... The SVG spec is CR. It's a good point, though, because I think W3C allows CRs and Recs to normatively reference CRs but having a normative reference to something only in WD should block publication as Rec 15:48:49 Gary: So technically we couldn't add it anyway 15:49:38 Nigel: We could defer this and ask them to come back when Fill and Stroke is in CR 15:49:40 Gary: Sounds reasonable 15:50:10 ... Is it possible for WebVTT to specify more broadly, to allow any class of properties that might be available rather than have an explicit allow list? 15:50:24 q+ 15:50:31 ... How to make it specific enough while allowing new properties? Or maybe that opens many new issues? 15:51:18 Nigel: I remember vaguely that part of the intent of the restricted set of style properties was to make it more feasible and straightforward to implement WebVTT outside a web environment 15:52:03 Gary: WebVTT does say if you're outside a web context, you don't need to worry about the CSS styling, Maybe that came after when the restricted set was made? 15:52:52 ... I think there's a potential benefit to restricting the CSS, but that means whenever's a new property we have to add it, or we can't reference that CSS spec if we want to progress our spec if it's in WD 15:53:04 Andreas: Go back to the browser vendors to ask the reason? 15:53:35 ... I remember about making an HTML version of the cue, which restricted everything by a wildcard 15:54:15 Gary: Yes, I'd like to get their opinion 15:54:16 q+ 15:54:46 ... We probably don't want to allow all CSS, so difficult to specify a subset of CSS we'd be OK with that's generic enough to add new CSS that we do want 15:55:20 Andreas: I remember that Nigel brought an idea to apply CSS to TTML 15:55:33 Nigel: It's something I wondered about, no specific proposal 15:56:05 ... There is no class attribute in TTML. You could imagine a variant of TTML that allows a class attribute, and style with CSS 15:56:37 ... The other possibility is to come up with a document that more normatively defines the mapping from the current style attributes (in IMSC) to CSS 15:57:01 ... What we do now is point to related CSS things from TTML and leave the mapping to others 15:57:44 Andreas: As a general question, how to bring the power of CSS rendering to TTML and WebVTT 15:58:07 Nigel: There are things we need, e.g., how background areas are drawn, somewhere between inline and block 15:59:38 SUMMARY: These properties sound like a good idea but we cannot reference a WD - please come back when this is in CR 15:59:58 Subtopic: Interop update 16:00:30 -> https://github.com/web-platform-tests/interop-webvtt/issues/18 Meeting next Wednesday 16:00:46 Dana: There's a meeting on Wednesday, for anyone with interest improving the WebVTT test suite 16:01:09 Andreas: Share on the group's public mailing list 16:01:28 Nigel: public-tt@w3.org 16:01:34 Dana: I'll do that, thank you 16:01:38 Topic: Meeting close 16:01:49 Nigel: Thank you all, we're over time, let's adjourn. 16:03:27 .. Next meeting is in two weeks, 2026-07-02 https://github.com/w3c/ttwg/issues/342 16:03:31 .. [adjourns meeting] 16:03:36 rrsagent, make minutes 16:03:37 I have made the request to generate https://www.w3.org/2026/06/18-tt-minutes.html nigel 16:10:08 i/Topic: DAPT/no other agenda items 16:10:52 s/for inferring a processor profile from a content profile/for inferring a processor profile from a content profile on a feature-by-feature basis 16:11:36 s/not presented properly as it uses text/not presented properly as its header says text 16:12:16 s/One is to do what the PR says/One is to ignore what the PR says 16:12:59 s/a note to say that this if you're looking at a DAPT document/a note to say that there's a different content profile designator if you're looking at a DAPT document 16:13:27 s/TTML type profile registry/TTML Type Definition and Profile Registry 16:14:02 s/so needs a CR snapshot to be published?/so needs a CR snapshot to be published because it would affect the conformance of content. 16:15:08 s/Makes sense. Any other views?/Makes sense. I'm not fully decided on which is the cleaner way. Any other views? 16:16:40 s/This is a request to a couple more CSS/This is a request to add a couple more CSS 16:17:05 s/it applies to text/it applies to text too 16:17:18 s/paintOrder/paint-order/g 16:18:10 s/... That might make sense/Nigel: That might make sense 16:19:18 s/that means whenever/that means whenever there 16:19:52 s/and style with CSS/and style with CSS instead of using TTML's applicative styling vocabulary 16:20:12 s/leave the mapping to others/leave the mapping to implementers 16:20:36 s/There are things we need/There are missing things in CSS that we need 16:20:58 s/how background areas are drawn/how backgrounds are drawn on line areas 16:21:16 rrsagent, make minutes 16:21:17 I have made the request to generate https://www.w3.org/2026/06/18-tt-minutes.html nigel 16:22:38 rrsagent, make minutes 16:22:40 I have made the request to generate https://www.w3.org/2026/06/18-tt-minutes.html nigel 16:23:14 scribeOptions: -final -noEmbedDiagnostics 16:23:19 zakim, end meeting 16:23:19 As of this point the attendees have been Nigel, Gary, Andreas, Cyril, Atsushi, Chris, Needham 16:23:21 RRSAgent, please draft minutes v2 16:23:22 I have made the request to generate https://www.w3.org/2026/06/18-tt-minutes.html Zakim 16:23:28 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:23:29 Zakim has left #tt 16:23:43 Present+ Dana 16:23:49 rrsagent, make minutes 16:23:51 I have made the request to generate https://www.w3.org/2026/06/18-tt-minutes.html nigel 16:24:13 Present- Chris 16:24:18 Present- Needham 16:24:20 rrsagent, make minutes 16:24:21 I have made the request to generate https://www.w3.org/2026/06/18-tt-minutes.html nigel 16:39:31 rrsagent, excuse us 16:39:31 I see no action items