00:27:22 RRSAgent has joined #tt 00:27:27 logging to https://www.w3.org/2025/11/11-tt-irc 00:27:27 RRSAgent, make logs Public 00:27:28 Meeting: Timed Text Working Group Teleconference 00:27:49 Meeting: Timed Text Working Group hybrid meeting TPAC 2025 00:28:14 Agenda: https://github.com/w3c/ttwg/issues/323 00:30:55 Previous meeting: https://www.w3.org/2025/10/09-tt-minutes.html 00:31:09 Present: Nigel, Dana, Andreas 00:31:14 Chair: Nigel, Gary 00:31:17 scribe: nigel 00:31:24 rrsagent, make minutes 00:31:26 I have made the request to generate https://www.w3.org/2025/11/11-tt-minutes.html nigel 00:40:06 alwu has joined #tt 00:40:22 wschildbach has joined #tt 00:40:37 Igarashi has joined #tt 00:40:42 present+ 00:41:21 present+ 00:43:33 Alastor Wu present+ 00:44:08 rrsagent, make minutes 00:44:09 I have made the request to generate https://www.w3.org/2025/11/11-tt-minutes.html nigel 00:44:15 atai has joined #tt 00:44:15 present+ 00:44:18 present+ Tatsuya_Igarashi 00:44:28 Bernd has joined #tt 00:44:33 Present+ Alastor Wu 00:44:40 Dana4 has joined #tt 00:44:40 Niko has joined #tt 00:44:47 present+ Gary 00:44:49 present+ Dana 00:44:59 Present+ Alastor_Wu 00:44:59 s/Alastor Wu present+// 00:44:59 present+ Andreas Tai 00:45:08 rrsagent, make minutes 00:45:09 I have made the request to generate https://www.w3.org/2025/11/11-tt-minutes.html nigel 00:45:15 present+ Bernd 00:45:18 present+ Nikolaus_Färber 00:45:25 Adam_Page has joined #tt 00:45:26 present+ Alastor_Wu 00:45:28 present+ Bernd_Czelhan 00:46:07 Present- alwu, Andreas 00:46:35 Present+ Atsushi, Tess 00:46:48 jernoble has joined #tt 00:46:52 present+ 00:47:14 Topic: Introductions and Agenda bash 00:47:16 atsushi has joined #tt 00:47:38 eric-carlson has joined #tt 00:48:33 Nigel: Good morning, welcome everyone. 00:49:09 hober has joined #tt 00:49:15 present+ 00:49:27 .. Agenda for today 00:49:29 wschildbach has joined #tt 00:49:33 present+ 00:49:34 present+ 00:49:55 nigel: presents the agenda. 00:50:00 scribe+ 00:50:13 q+ 00:50:48 ack Iga 00:51:42 Igarashi: attending as guest. Adding one topic. 00:51:42 Igarashi: 5 minutes AOB to talk about the Process from the AB perspective 00:51:42 https://www.w3.org/wiki/AB/2026_Priorities 00:51:46 s/guest/AB member/ 00:52:16 atai: subtitle formats in general, and W3C position, can we cover as part of interop testing? 00:54:22 nigel: any issues with the agenda and timing? Seems no. 00:54:44 Present+ Pierre 00:55:38 nigel: please introduce yourself, name, who you work for. 00:55:47 atsushi has joined #tt 00:58:19 Topic: Process (AB) 00:58:21 Igarashi: The process taskforce can be joined by everyone. 00:58:40 .. to improve process. We are visiting every group to get feedback. 00:58:59 .. we don't have much time to go into detail but please approach myself or Dana4. 00:59:09 s/Dana4/Tess 00:59:17 Dana4: we heard from a lot of people that aspects of the process are cumbersome, convoluted. 00:59:27 s/Dana4/Tess 00:59:38 .. we don't have a lot of detail about what that means, that is why we make the rounds. 01:00:23 .. we are not looking for a series of grievances, if there are specific aspects that should be preserved or changed, we need to hear that too. 01:00:50 .. that is the pitch. If you see people with purple badge, they are obligated to talk to you and listen. 01:01:03 Igarashi: I am available as well. 01:01:10 q? 01:01:11 tidoust has joined #tt 01:01:12 eric-carlson has joined #tt 01:01:15 .. any thoughts? 01:01:30 present+ Francois_Daoust 01:01:55 nigel: has a lot of additional feedback. I am largely OK with how things are. One thing to keep is if people are wokring on rec-track spec, 01:02:26 .. the goal needs to be to get to spec. If that is not the goal, if they don't need wide review to complete, don't waste W3Cs time. 01:02:42 .. That would give the document a false sense of authority. 01:03:05 Pierre: that is worth a longer discussion, there are many repo issues. Should we set time aside later for this? 01:03:33 Tess: if you have specific feedback, or know people on the AB, track us down. Let's not take up working group time. 01:03:49 Pierre: let's make a proper agenda item for it. 01:04:00 nigel: it might end up being quite late. 01:04:11 tess: can be back at 4:30 01:04:40 nigel: maybe before afternoon break but let's not prioritize over the agenda. 01:04:50 .. thanks for the input. 01:05:24 .. editing the agenda to insert process feedback at 15:15. 01:05:42 Topic: IMSC 1.3 01:05:55 nigel: status is we are in working draft. 01:06:13 .. wanting to move to CR snapshot 01:06:45 .. (shows the repo) working draft is from September. We have a PR open, which we should cover. 01:07:09 .. in terms of wide review it is complete in my view. Is that right? 01:07:49 nigel: we are waiting on accessibility. 01:08:13 pierre: don't understand what that means. 01:08:28 .. what more do we need to do? 01:08:52 nigel: we did not say in the issue that it was early draft review. Just a WD review. 01:09:27 .. we have not had a response back 01:09:34 pierre: this is purely editorial 01:09:37 -> https://github.com/w3c/a11y-tracking/issues/252#issuecomment-3334994063 01:10:04 .. i think we are done. In terms of process, and practically 01:10:07 nigel: agree 01:10:18 pierre: what is the objection? 01:11:23 tidoust: The review was understood to be a WD review only, Janina says she has no objection. 01:11:43 pierre: they can revisit at any time. This is purely editorial. They can file an issue. 01:12:07 tidoust: to close wide review, an ack from their side is all that is needed. 01:12:17 .. just announce that the review is to be closed. 01:12:22 pierre: agrees. 01:12:45 .. comment on process: a minor imrpovement stalls process unduly. 01:14:00 s/imrpovement/improvement/ 01:14:31 .. this is a truly minor issue. If this was fundamental then things would be different. This is an informative note to a small feature 01:14:39 .. of a spec that has been around for years. 01:15:38 nigel: we will say "review complete, no substantive changes". Discussion around subscript/superscript is editorial. Is that fair? 01:16:48 .. any other things we need to discuss on 1.3? Will come to a proposal to discuss CRS, will get later to it today. 01:17:00 pierre: substantive question is PR 614. 01:17:13 Subtopic: Improve the ja character set per ARIB feedback w3c/imsc#614 01:17:19 github: https://github.com/w3c/imsc/pull/614 01:17:45 pierre: we added a recommend charset based on ARIB input. 01:18:07 .. unfortunately, there is in the liaison some vagueness. We should make sure we get it right. 01:18:23 .. we asked for more details but got no clarifciation. 01:18:51 .. don't want to remove the text but we need clarification. This is informative (should not a shall), it is usefull but not necessary. 01:19:24 nigel: I think that the idiographic selector is not defined where it says it is. 01:19:29 .. translation issue? 01:20:09 atsushi: this is not a stopping issue 01:20:44 nigel: if your colleague comes later, let's ask them 01:21:10 .. is there a choice of terminology and we need to use the correct one? 01:21:24 pierre: this is a complex part with many things falling underneath it. 01:21:41 .. what would be most useful would be an example of what is meant. 01:21:55 .. I find it a complex part of the unicode spec. 01:22:15 .. as atsushi pointed out, terms may have changed. Ideally have an example. 01:22:43 .. here is sample tet that uses IVS, and here is what we expect the rendering to be. 01:22:47 s/tet/text/ 01:22:56 .. and we could include a spec action. 01:23:16 s/a spec action/in the spec actually 01:23:21 s/in/it in 01:23:46 nigel: this is unresolved right now. so we are saying we can proceed to CRS without resolving? 01:23:54 atsushi: agrees. 01:24:04 nigel: we merge later. 01:24:17 atsushi: this is not normative, so don't need another crs 01:24:29 nigel: we can put change in and request transition to rec 01:24:45 .. implementation report will be empty. It is a formality. 01:25:08 s/crs/CRS/ 01:26:17 SUMMARY: Hold this PR open pending feedback and hopefully an example, and do not hold up CRS publication 01:28:31 forcedDisplay and visibility="hidden" #484 01:28:40 s/forced/Subtopic: forced 01:28:46 github-bot, end topic 01:28:57 github: https://github.com/w3c/imsc/issues/484 01:29:11 Subtopic: forcedDisplay and visibility="hidden" #484 01:29:13 github: https://github.com/w3c/imsc/issues/484 01:29:41 nigel: Note that in one of the breakouts yesterday, was pointed out there is a new API 01:30:11 .. about selecting or signaling to assisted tech which notification to expose, to allow user filtering? 01:30:20 .. it was news to me yesterday. 01:30:53 .. the scenario was one where two people watch a movie, one of them needs hard of hearing subtitles, the other one is screenreader user 01:31:17 .. and wants to choose whether captions are exposed or not. 01:31:58 james: please do share more about this, it is new to me 01:32:20 nigel: filtering can only be done on data and tags. 01:32:46 james: I don't understand, this seems a side conversation. 01:33:20 nigel: it is closely related actually. This is about not just hiding things but also ensuring that assisting tech does not see things that are hidden 01:34:00 .. need to go back to Matt and find out what the new API is. Propose we defer for IMSC 1.3. Or include as editorial. 01:34:05 pierre: agrees 01:34:52 SUMMARY: @nigelmegitt to check about the new AT notifications API, defer to a later version of IMSC or include in IMSC 1.3 CRS if editorial 01:35:17 Subtopic: CRS Publication 01:35:31 pierre: we need a resolution 01:36:06 PROPOSAL: Request transition of IMSC 1.3 to CRS without being dependent on open pull requests being merged 01:36:53 Nigel: Any thoughts, objections etc? 01:36:55 Gary: Ship it! 01:37:40 Atsushi: If we cannot conclude on w3c/imsc#614 before AC review for entering Rec, 01:37:51 .. we may want to remove some of the new text. 01:38:03 wschildbach0 has joined #tt 01:38:13 Pierre: We could make the pull request cover the entire JA character set so if it does not get merged 01:38:15 .. then it is not there. 01:38:31 Atsushi: Maybe having nothing is better than having it wrong 01:38:32 wschildbach has joined #tt 01:38:36 Nigel: I'm not sure it is wrong 01:38:46 Pierre: The pull request is a tweak to a previously merged PR. 01:39:06 .. The proposal is either to include a JA character set or not, in its entirety, including the PR 01:39:27 .. Instead of playing with the pull request, we can note it - unless it can be agreed to, 01:39:34 .. the entire JA character set might be removed. 01:39:42 Nigel: Works for me. 01:40:04 RESOLUTION: Request transition of IMSC 1.3 to CRS without being dependent on open pull requests being merged 01:40:39 atai has joined #tt 01:41:38 james: not sure how it is relevant to TT 01:42:30 .. ariaNotify is a first version for a better version. rules out accidental notifications. 01:42:48 .. a webauthor might accidentally put role=status ... 01:43:27 s/webauthor/web author/ 01:43:58 jernoble has joined #tt 01:44:16 i/james/Gary: is the api aria notify? https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/AriaNotify/explainer.md 01:44:33 Topic: Regulatory changes and new API proposal (Apple) 01:44:57 Dana: [shares slides] 01:45:03 FYI Explainer Link: https://github.com/WebKit/explainers/tree/main/CaptionDisplaySettings 01:45:24 Dana: I'll present a new API that Webkit is proposing to meet new requirements from FCC 01:45:52 .. Goal of the FCC regulation is to make system level caption style settings "readily accessible" to users 01:45:58 .. Begins August 2026 01:46:16 The FCC document in question: https://docs.fcc.gov/public/attachments/FCC-24-79A1.pdf 01:46:17 .. 4-part test: Proximity, Discoverability, Previewability, Consistency and Persistence 01:46:29 .. Scope of API 01:46:45 .. Proximity: asks that the settings be accessible via something like a button within the app 01:46:59 .. or page, without forcing a switch of application or a lengthy process to access caption 01:47:01 .. display settings. 01:47:12 .. Web app responsible for displaying settings 01:47:26 .. Discoverability: requires user testing of the web app to ensure discoverability 01:47:41 .. Previewability: user to be able to see a preview of their selected style on the video 01:47:59 .. Consistency and Persistence: user settings to persist across apps 01:48:38 .. User agent proposal for Webkit is: 01:48:46 pal has joined #tt 01:48:55 .. for Previewability, UA would hide current captions, and provide an example text cue 01:49:10 .. and style it to match the user's current profile choice 01:49:46 jcraig: To clarify this is how Webkit proposes to implement a compliant solution that 01:49:52 .. meets the new requirements 01:50:49 Nigel: Why hide the current caption, isn't a real caption the best example you could have? 01:51:09 Jer: There might not be a current caption 01:51:26 jcraig: The tech stack might only be able to preview a predefined caption 01:51:39 hober: The example caption would stress the different styles 01:51:43 gkatsev: Would the video pause? 01:52:06 jernoble: If the application wants to pause, that would be up to the app 01:52:36 Dana: Consistency and Persistence: 01:52:43 .. UA will read the system Media Accessibility settings 01:52:44 Cyril has joined #tt 01:52:50 .. Convert those settings to CSS styles 01:52:57 RRSAgent, pointer 01:52:57 See https://www.w3.org/2025/11/11-tt-irc#T01-52-57 01:52:59 .. Apply those styles to cues rendered by the ideo element 01:53:02 s/ideo/video 01:53:06 .. Webkit already implements this 01:53:49 Nigel: What about settings that don't have CSS, like raised edges? 01:54:01 Eric: We can simulate raised edges in CSS 01:54:43 Jer: There is a style that the FCC mandates that you can set in system preferences that 01:54:53 .. is not exposed to the web, which is the block level element that surrounds the cue 01:55:08 .. rather than the inline. There is a PR open on WebVTT specifically to represent that block 01:55:25 .. level element. So that all the styles will be implementable in CSS. 01:55:42 FYI, issue in question is: https://github.com/w3c/webvtt/issues/516 01:55:45 jcraig: Nigel you may remember discussing this in another place about terminology differences 01:55:59 .. like "window" and defining those. 01:56:18 Dana: [shows WebIDL] 01:56:41 .. There would be a new method on the HTMLMediaElement that would return promise 01:56:46 .. to show the caption display settings 01:56:58 .. Once the user has selected a style the menu will close and the promise will resolve. 01:57:12 hober: If the website uses the browser's default media controls this is unnecessary. 01:57:25 .. This is for pages that implement their own media controls, to support a button that allows 01:57:28 .. the user to do this. 01:57:38 Dana: Example use cases 01:57:45 .. [shows sample code] 01:58:03 .. When the user clicks the button, the event handler calls the API, the 01:58:10 .. UA places the menu where the cursor is. 01:58:21 .. More complex case, where an anchor node and position area are provided. 01:58:34 .. In this case WebKit would try to place the menu adjacently to the top right of the caption settings 01:58:44 .. button. If there's no space there's a fallback algorithm. 01:58:54 hober: That fallback algorithm is defined in the CSS anchor spec. 01:59:12 Dana: In this case the anchor is the settings button at the bottom right, and there's no room 01:59:16 .. to the right so we place it to the left. 01:59:29 .. Last example: in the click event listener, the website first hides its own caption menu, 01:59:47 .. then calls the API, and once the promise has resolved, the website restores its caption menu. 02:00:11 s/in the CSS anchor position spec/by CSS Anchor Positioning/ 02:00:13 .. That's the presentation. 02:00:56 Nigel: Let's open up for discussion. 02:01:08 Gary: One question: has this been brought up with other browser vendors? 02:01:13 .. Have they shown interest? 02:01:18 q+ 02:01:23 Dana: First time bringing it up was last week at FOMS 02:01:32 jernoble: I was there and presented this. 02:01:45 .. This is part of the outreach we would like to do to encourage other browsers to be interested 02:01:51 .. and to show this is a good solution. 02:02:08 .. Chrome on Mac already has the second half of this implemented - it already reads system 02:02:17 .. preferences and turns it into CSS that applies to the cues. 02:02:21 q+ 02:02:44 jcraig: Sometimes FCC gives notice and time to reply, but for some reason they didn't do it here 02:02:54 .. with captions. This is a reasonably short timeline. 02:02:57 ack atai 02:03:11 Andreas: Thanks a lot for the presentation. Always good to have a standardised approach on this. 02:03:24 .. I haven't fully understood the webkit part vs the standard part. 02:03:28 q+ 02:03:40 .. As I understand it you have a proposed API to display this. 02:03:53 .. Everything else in terms of presentation is browser implemented? 02:03:58 Dana nods 02:04:22 Andreas: Some web apps might implement with WebVTT, others with other mechanisms like IMSC rendering. 02:04:23 .. They have the same requirements. 02:04:31 .. So every app would need to have this access to media settings. 02:04:40 Jer: None of us here is a lawyer! 02:04:55 .. We can't advise which apps are covered and what the requirements are. 02:05:10 .. We can though provide a solution in the case that a web app decides that they are covered. 02:05:28 .. Above and beyond, to give users access to the system style settings. 02:05:33 Repeat from above: The FCC document in question: https://docs.fcc.gov/public/attachments/FCC-24-79A1.pdf 02:05:35 q+ 02:05:43 .. If you are a writer of a web app and you don't believe you are covered, 02:05:49 .. then this probably isn't relevant to 02:05:58 .. you unless you want to use it. 02:06:15 Gary: It seems like, indirectly, if you fall under the jurisdiction you need to do native rendering 02:06:18 .. of captions on the platform. 02:06:35 jernoble: I think we can get to solutions for IMSC clients, either later today or another time. 02:06:47 .. Short of allowing IMSC to be a full web format. 02:06:53 Pierre: Why not? 02:07:03 jernoble: Because it's not the minimum we can do 02:07:11 Pierre: It would be a solution 02:07:15 q? 02:07:18 q+ 02:11:14 Nigel: There's a huge number of questions in my mind about this! 02:11:28 .. Things like what if the site wants to provide the preview caption? 02:12:00 .. What if the site doesn't use native rendering because it doesn't work properly? 02:12:14 .. What if the user wants their settings to be associated with their profile not their device? 02:12:20 Jer mentioned "multichannel video programming distributors" MVPDs as defined in the R&O 02:12:36 .. What if the actual presentation is some combination of authoring and adjustments, 02:12:37 qv? 02:12:42 q- 02:12:43 .. the UA doesn't know what's authored 02:12:47 ack nig 02:13:00 .. Lots more questions! 02:13:14 jcraig: You can go from the new menu into the system level settings 02:14:38 jernoble: You can choose whether to override the authored styles or not 02:15:09 Nigel: Doesn't cover the middle ground of wanting to manipulate the authored content 02:15:18 .. rather than overriding it, e.g. adjusting the colour palette 02:15:23 q? 02:15:34 q+ 02:15:35 Pierre: Today you have applications that offer caption customisation directly from their player skin. 02:15:41 .. What does this change for them? 02:15:54 jernoble: You should probably read the FCC regulation. That's what I had to do to understand 02:15:58 .. what we're providing here. 02:16:08 .. I don't think there's anything wrong with adding styling on top of the user styles. 02:16:20 .. The regulations say the user must be able to access the system settings 02:16:25 .. and this proposal allows that. 02:16:44 .. An existing caption setting button misses the ability to read/write system settings. 02:16:49 .. The proposal doesn't address that. 02:17:00 Pierre: To avoid fingerprinting apps cannot read or write system preferences. 02:17:14 .. So the system style has to be supplied by the UA. So far UAs have not implemented timed 02:17:23 .. text sufficiently for this to happen. That's been the blocker for the past 8 years. 02:17:27 q? 02:17:30 ack pal 02:19:10 eric-carlson has joined #tt 02:32:05 q? 02:32:27 Present+ Cyril 02:33:12 Present+ Matt Paradis 02:33:33 atai has joined #tt 02:33:39 ack at 02:33:49 Andreas: This whole effort is driven by regulation in the US. 02:34:03 .. All the accessibility and caption settings are also the target of European regulations. 02:34:18 .. The European Accessibility Act also suggests users need to be able to adjust settings 02:34:21 .. like for captions. 02:34:37 .. In general whatever is specified in standards needs to reflect global requirements 02:34:48 .. What you have proposed is only a small part of the problem. 02:35:02 .. How can we broaden the perspective to deal with this issue for different situations, 02:35:09 .. to implement access from applications to the caption settings 02:35:29 .. The question is if we can do that, and also a comment that if something is put now into 02:35:41 .. a global standard we should make sure it does not conflict with other regulations or requirements. 02:35:56 jcraig: The EAA mandates that captions be available in general but is not at this level of 02:36:04 .. prescription for this particular new feature. 02:36:18 Andreas: There would be a longer discussion, but it does mandate user adjustment of 02:36:37 .. settings and then the referring standard EN 301 549 has further settings, not in that 02:36:46 .. detail (of the FCC) but affecting the same area, that some settings at least need to be exposed. 02:36:59 eric-carlson: One of the positive things about this proposal is that its quite generic. 02:37:10 .. It allows a web app to request that the UA displays some caption settings but it doesn't 02:37:17 .. mandate what is in those. 02:37:27 .. It is possible to have different kinds of settings to be available depending on the region 02:37:31 .. that the web app is running in. 02:37:48 hober: To clarify, you said that it would require exposing the settings but I think it requires 02:37:54 .. the honouring of settings, which is a big difference. 02:38:12 Andreas: Can look into the details, but independent of that, if something goes into web 02:38:26 .. standards it should not be specific to FCC requirements but should meet wider requirements. 02:38:49 .. Extending the scope, maybe we need to do more work than that on this topic, 02:39:06 .. defining best practice, because a lot of stakeholders are struggling with this. 02:39:26 hober: What Dana presented is what we think is a reasonable approach to comply with the 02:39:38 .. requirements in the timeframe. That's not the end of the discussion, it's the beginning, 02:39:49 .. because we want the web to continue to be viable for much longer. 02:39:58 Andreas: The European requirements are in place already. 02:39:59 q? 02:40:29 jcraig: I'm familiar with the EAA and EN 301 549. There are other ways to comply to EAA 02:40:39 .. without meeting EN 301 549. It's a "safe harbour" way. 02:40:51 .. Everything related to captions and subtitles in EN 301 549 does not get to this level of 02:40:57 .. prescriptive detail about the UI. 02:41:09 mattp has joined #tt 02:41:22 Dana has joined #tt 02:41:27 .. I don't see this conflicting with any other worldwide standard I'm aware of, but if you know 02:41:38 .. of something specific we should discuss it. 02:41:41 ack gk 02:42:08 Gary: I would agree with the sentiment Andreas raised that web standards work should apply everywhere. 02:42:25 .. I agree that this wouldn't be an issue with other regulations even though the FCC originates it. 02:42:42 .. My main question was: earlier there was the topic round IMSC and how to handle custom rendering 02:42:54 .. and I was wondering if there was more info around it or is the main direction for that 02:43:11 .. the existing direction for captions with TextTrackCue constructor or something else? 02:43:27 eric-carlson: We don't have anything beyond the TextTrackCue constructor that takes a document 02:43:41 .. fragment with appropriate pseudo-classes so the web app can identify the different parts of 02:43:44 .. the fragment. 02:43:53 q? 02:44:28 Nigel: There's a lot more to discuss here but I just want to flag that it's not obvious that this 02:44:32 the TextTrackCue explainer https://github.com/WebKit/explainers/tree/main/texttracks 02:44:41 .. is in scope of the TTWG, which is chartered to look at formats not APIs. 02:44:55 hober: The HTML Media Element API is defined in the HTML spec, and this is a change to that API 02:45:06 .. so I would expect this to be proposed and iterated on in the HTML spec in WHATWG. 02:45:17 .. But this group has the right expertise, and these are the right people to get feedback on it. 02:47:30 .. Chair's decision about scope. 02:47:30 .. These are the right experts to be talking to, regardless of the formalities. 02:47:30 Gary: The charter specifies what documents we produce, not what documents we produce. 02:47:30 atsushi has joined #tt 02:47:30 hober: I hope what goes in the HTML spec will be better for this discussion. 02:47:30 Gary: I agree 02:47:44 s/ not what documents we produce/not what discussions we have 02:49:51 rrsagent, make minutes 02:51:37 I have made the request to generate https://www.w3.org/2025/11/11-tt-minutes.html nigel 02:54:48 Nigel: If WHATWG actually wants my views, they are: support IMSC natively! 02:54:52 Topic: DAPT issues and pull requests 02:54:52 Bernd has joined #tt 02:54:52 Nigel: Firstly, CR must have issues. 02:54:52 .. Filtering the open issues on CR must have label, there are none open. That's good! 02:54:52 .. I also want to look at the two pull requests, and publishing a new CRS. 02:54:52 Subtopic: Expand the security considerations section w3c/dapt#329 02:54:52 github: https://github.com/w3c/dapt/pull/329 02:54:52 scribe+ 02:54:52 nigel: request was from security HR 02:54:52 ... [reading open issue] 02:54:52 nigel: opened PR and reviewer said LGTM, will merge shortly 02:54:52 [review changes by htmldiff] 02:55:00 nigel: in #serialization, there are clarification on BOM 02:55:00 i/#serialization, /nigel: added entire security consideration section 02:56:00 rrsagent, publish minutes 02:57:00 q+ 03:00:00 andreas: WebVTT has nothing about BOM, should we strict here? 03:01:00 nigel: when validating much TTML documents, some has BOM, implementation sometimes re-encodes BOM as text 03:03:00 scribe+ 03:03:00 cyril: pointing XML entity attach description at https://portswigger.net/web-security/xxe 03:04:00 nigel: do we need more time for review this PR? 03:04:00 ... PR has been reviewed and approved by security colleagues 03:04:00 cyril: how about with 2 weeks period 03:04:00 SUMMARY: Continue with usual review and merge process 03:05:00 Subtopic: Clarify requirements for Represents w3c/dapt#328 03:05:00 https://github.com/w3c/dapt/pull/328 03:05:00 nigel: this PR is coming from implementation experience 03:05:00 ... something circular expression 03:06:00 ... we have discussed around this several times 03:07:00 [nigel describe PR overview] 03:09:00 cyril: reading now, and will do review 03:10:00 cyril: for "Add definition wrappers to namespace prefixes", it bother me with invalid representation 03:11:00 nigel: values are in registry, and you can use defined values there 03:11:00 ... but it's not deny to have "invalid" value 03:12:00 nigel: we carefully defined registry definition, on invalid value 03:15:00 cyril: will comment to the PR 03:15:00 SUMMARY: Review to continue 03:16:00 Subtopic: Dealing with at risk features 03:16:00 nigel: number of at-risk in DAPT 03:17:00 [describe options on dealing with at-risk] 03:18:00 Nigel: If we remove an at-risk feature do we need another CRS? 03:18:00 tidoust: If you remove an at risk feature you can move ahead - that's the purpose of them 03:19:00 atsushi: Maybe, but if you get a comment about removing an at-risk feature, for example 03:19:00 .. horizontal review says an at-risk feature is required, you may need to ask for a review. 03:19:00 Gary: The process explicitly allows removal of at-risk features for substantive changes 03:19:00 .. when moving to the next stage of the process without doing a new CRS. 03:20:00 revising a CR section of the process document https://www.w3.org/policies/process/#revising-cr 03:20:00 Nigel: Just for clarity, none of the horizontal reviews have commented about any of the at-risk features. 03:20:00 .. Not sure what our best option is, 03:20:00 .. could just remove the at risk flags, 03:21:00 .. or review on a case by case basis, 03:21:00 .. or wait for more implementation experiences. 03:21:00 .. Maybe I will follow up with implementers who currently take specific approaches that 03:21:00 .. would affect the at risk features. 03:22:00 Subtopic: Progress to next CRS 03:22:00 Nigel: My proposal is to complete the review and merge process on the open pull requests 03:22:00 .. and then request a new CRS. 03:24:00 Cyril: What's stopping us from moving to Rec? 03:24:00 Nigel: We need a new CRS first. 03:24:00 .. I think we have completed HR. 03:24:00 Atsushi: Security has a comment that we have a PR to address. 03:24:00 .. i18n has a comment on language. 03:25:00 .. Only i18n and security remains. 03:25:00 nigel: we've got comment from i18n on langSrc at closed issue 03:25:00 -> https://github.com/w3c/dapt/issues/321 03:26:00 .. This requires a reversion of a pull request we merged, based on seemingly changing advice 03:26:00 .. from i18n, though maybe that's our misunderstanding. 03:27:00 .. The reversion should: 03:27:00 .. * allow an empty daptm:langSrc 03:27:00 .. * make the default value the empty string 03:27:00 .. * Not suggest using the `und` value 03:28:00 .. I can prepare a PR to do that. 03:28:00 .. Then the next thing is to complete the implementation report 03:28:00 Cyril: I think we can do that, we have 2 implementations. 03:29:00 nigel: BBC implementation passes all of existing tests, and will be turned into open shortly 03:30:00 cyril: not everything now, but mostly pass for our implementation 03:33:00 nigel: some of implementator are implementing only audio description, and need to confirm 03:34:00 [cyril review items implemented in their one] 03:35:00 q? 03:35:00 nigel: anything else to be considered in implementation report 03:35:00 [none] 03:36:00 Present+ Hiroki 03:37:00 Present+ Paola 03:37:00 Nigel: In summary, we are in the implementation phase, and need a 2nd implementation for 03:38:00 .. every feature. A new CRS is reachable, then we can request transition to Rec when the 03:38:00 .. Implementation Report is complete. 03:38:00 Topic: WebVTT interop testing 03:38:58 RRSAgent has joined #tt 03:38:59 logging to https://www.w3.org/2025/11/11-tt-irc 03:40:34 eric-carlson has joined #tt 03:41:20 gkatsev: I do have some things for WebVTT but because of time we may not get around to it 03:41:32 .. but I will raise them at our regular meetings and encourage the right people to join,. 03:41:42 Dana: First thing was a PR open. 03:41:48 https://github.com/w3c/webvtt/pull/528 03:42:16 Subtopic: Add support for ::cue-backdrop #528 03:42:21 github: https://github.com/w3c/webvtt/pull/528 03:42:33 Dana: This adds the block level wrapper around inline content. 03:42:39 .. This is required by some CEA standards. 03:42:48 .. Webkit and Chromium already implement it but it isn't in the spec. 03:42:53 .. Jer opened the PR to add it. 03:43:02 .. From the discussion it seems that the name of it was contentious. 03:43:08 .. cue-backdrop was settled on, it seems. 03:43:19 .. Can we merge it or are there any comments or objections. 03:43:36 gkatsev: Also it is the equivalent of the "window" FCC requirement 03:43:39 q+ 03:43:51 gkatsev: It would be good to get the other browsers to comment on that. 03:44:13 Alastor: I will take a look and leave a comment 03:44:27 gkatsev: Do we know anyone at Chrome or is this something we need to chase down separately? 03:44:31 .. Anyone specifically? 03:44:47 eric-carlson: We should ask Philip. He can point us to the right person. 03:45:03 .. He was at MEIG yesterday 03:45:08 Dana: OK 03:45:19 .. I can ask Philip about it. 03:45:39 gkatsev: I don't have any blockers aside from the other vendors. 03:45:44 q? 03:45:52 hiroki has joined #tt 03:45:59 ack atai 03:46:04 ack nigel 03:46:21 nigel: I had proposal to change name to -background 03:47:02 Dana: don't know which one we should use -backdrop or -background 03:47:39 nigel: TTML has concept of region as box to be placed 03:47:55 gary: WebVTT region is inline block element 03:48:01 ... similar name could be confusing? 03:48:23 nigel: positioning is block level and similar? 03:52:23 Dana: So I need to get the answer from whoever is responsible for Chrome if they can accept this. 03:52:36 gkatsev: I can also ping Ted from FOMS/Demuxed and pursue that channel as well. 03:53:14 SUMMARY: Request feedback from other browser vendors on the feature and name of the element before proceeding 03:53:30 https://github.com/w3c/webvtt/issues/531 03:53:49 Subtopic: WebVTT should allow pages to modify the caption display area w3c/dapt#531 03:53:57 github: https://github.com/w3c/webvtt/issues/531 03:54:11 Dana: This issue proposed a new pseudo element that represents where the cue is allowed to 03:54:18 .. be rendered, excluding where top or bottom controls are. 03:54:47 s/dapt#531/webvtt#531 03:55:17 Dana: It's not possible to test the requirement for captions not to overlap controls 03:55:26 .. but this proposal would allow it. Not sure the latest status. 03:55:38 gkatsev: This is another naming issue - I think the current proposal is cuecontainer 03:55:48 .. The idea is to expose what's already there so we can expose styling 03:55:59 Dana: Q: what properties should we allow the website to style? 03:56:12 .. Jer had suggested allowing top, left, bottom and right as well as transition so that 03:56:15 .. changes can animate. 03:56:32 Nigel: Why not position and size? 03:56:55 Dana: I'm not certain, top, left, bottom and right would be sufficient. 03:57:02 .. We know the position that's on top of the video. 03:57:09 .. We just need to allow it to be shortened from either edge. 03:57:53 Nigel: The trend now seems to be to use position and size. 03:58:03 .. For example, what would happen if right is smaller than left? 03:59:22 gkatsev: inline size and block size might make sense in addition to top/bottom/left/right 04:00:33 Nigel: There's discussion in the thread where I've mentioned this is an undercooked solution, 04:00:35 q+ 04:00:41 .. that doesn't work with controls in the centre. 04:00:55 gkatsev: I think there could be a lot of work, and this gives a good baseline. 04:01:07 .. One thing we discussed at FOMS is that you can create a custom track element with 04:01:30 .. custom captions that are positioned to avoid controls, so that's a hack to make sure that 04:01:41 .. your cues don't interact with custom player elements. 04:01:46 ack pal 04:01:59 Pierre: Wasn't it last year that there was a proposal to basically allow a subset of HTML to be 04:02:11 .. used as an overlay and have applications render subtitle tracks to that subset of HTML, 04:02:26 .. so the application would have complete control rather than doing it declaratively. 04:02:30 .. What happened to that proposal. 04:02:40 eric-carlson: 3 or 4 years ago we wrote that explainer and it didn't get any feedback. 04:02:54 pal: It's a much more flexible solution than dealing with all these edge cases. 04:03:05 eric-carlson: It's a good solution for people who want to render their own captions. 04:03:19 .. This is a good solution for custom controls with native caption playback. 04:03:31 Pierre: If someone is using the default player that's one thing. 04:03:44 .. But if you're doing your own thing there are lots of libraries out there. 04:03:59 gkatsev: I've built players with custom controls and native caption rendering. 04:04:17 .. Also this would be helpful for the FCC regulations discussed earlier. 04:04:19 q+ 04:04:27 ack nigel 04:04:53 nigel: If this is a baseline, how could you extend it later to meet the more complex requirements? 04:05:02 gkatsev: This might not be able to meet the central controls requirement. 04:05:30 nigel: A good API design would allow for future extension, and I don't understand the model for this. 04:05:50 gkatsev: This might not be extensible. People do this in the wild by looking in the shadow DOM 04:05:59 .. and inspecting the controls. It would be good to expose that. 04:06:11 .. From the interop perspective it says controls should not overlay captions, but given that 04:06:23 .. each vendor has different controls, it means you can't have a good test for that since 04:06:29 .. everything will move separately. 04:06:41 .. If you can modify the caption display area you can approximate that feature. 04:07:38 Nigel: There's already a comment about using the existing collision avoidance. 04:07:52 .. The idea is to tell the player "here's where are my controls are" and it synthesises a 04:08:00 .. "cue" to avoid collision. 04:08:23 eric-carlson: It wouldn't allow the page to animate collision avoidance of captions. 04:08:30 Nigel: Why? Isn't that a secondary concern anyway? 04:08:43 gkatsev: Two concerns: 1. You shouldn't have captions show up where you have controls 04:08:59 .. or vice versa. 2. In a lot of apps when controls are showing the captions are at the bottom 04:09:11 .. but when controls appear the captions slide up. 04:09:43 Nigel: That's assuming a particular design? 04:09:53 eric-carlson: No, it's flexible design 04:10:09 Nigel: Animation is an orthogonal concern - in both cases you're expressing either in the positive 04:10:20 .. or negative some description of where you can put captions. 04:10:46 gkatsev: [scribe missed a bit] It wouldn't be able to animate 04:10:54 Nigel: I don't understand what the difference is 04:11:09 gkatsev: In the end maybe do both, this codifies an existing common pattern that doesn't 04:11:18 .. work across vendor right now because Firefox doesn't use shadow dom 04:11:42 Dana: Maybe we can look at websites that already hack this and see what properties they use 04:11:48 .. to guide what properties we allow. 04:12:00 q? 04:12:49 gkatsev: We also discussed this in #503, where we considered passing rectangles to the video element. 04:12:53 related discussion https://github.com/w3c/webvtt/issues/503 04:13:18 gkatsev: Next steps are to get other vendor buy in as well 04:13:34 .. I think top/bottom/left/right is the bare minimum. 04:13:47 .. It would be good to look for other minimal properties that might make sense 04:13:52 .. like inset. 04:16:16 SUMMARY: Look for other vendor views 04:16:25 Topic: Lunch 04:23:38 nigel has joined #tt 04:39:36 nigel has joined #tt 04:57:36 nigel has joined #tt 05:13:59 nigel has joined #tt 05:18:54 nigel_ has joined #tt 05:20:29 Topic: Subtitle purpose field in TV-Anytime 05:21:07 Andreas: I'm presenting as chair of the DVB task force on accessibility. 05:21:16 .. I brought up this topic 2 years ago at TPAC in Seville, 05:21:28 Adam_Page has joined #tt 05:21:28 .. and we published. The main question I have for this part is if this group, 05:21:45 .. who is one of the few groups with subtitling experts in a standards organisation 05:21:55 .. wants to contribute and finding a way to align. 05:22:11 .. [shows slides] 05:22:17 .. DVB-I is the context. 05:22:30 .. It is a way to unify TV services over IP with broadcast. 05:22:44 .. DVB-I service discovery and content specification makes use of data models 05:22:52 .. in TV-Anytime, which can also be used for other purposes. 05:23:00 .. It defines metadata for TV content. 05:23:12 .. Last time I detailed what accessibility setting metadata we would like to add to TV-A, 05:23:19 .. and we got feedback and implemented it. 05:23:23 .. Brief detail on one of them. 05:23:34 .. For each accessibility feature of component we have a wrapper element like subtitles, 05:23:35 hiroki has joined #tt 05:23:40 .. audio description attributes, signing and others. 05:23:53 .. For subtitles we have properties, like encoding (TTML, WebVTT etc), how it is carried 05:24:08 .. (ISOBMFF, open, etc) but the point of interest here is what is the purpose, what kind of 05:24:10 .. subtitle is it. 05:24:21 .. Last time people didn't really understand fully, or saw some complexity. 05:24:32 .. Although we know that for some stakeholders it may not be sufficient we made a basic 05:24:43 .. set of values, defined in an XML classification scheme called SubtitlePurposeCS. 05:25:03 .. 5 values: translation, hard of hearing, audio description, content related commentary and forced narrative. 05:25:19 .. 2 questions: 1. Is it something this group would be interested in extending or working on? 05:25:30 atsushi has joined #tt 05:25:30 .. Maybe it is already sufficient and all we need. 05:25:48 s/Maybe/2. Maybe 05:25:58 .. I wanted to bring it back and see if there is interest in this. 05:26:12 .. It's also based a bit on IMF, because of Pierre's proposal. 05:26:27 Pierre: The only difference is karaoke which might not be relevant for the target application. 05:26:35 .. Another one that may not be relevant is chapters. 05:26:41 .. Are there definitions? 05:26:49 Andreas: Yes, but I didn't go into detail here. 05:27:04 .. For example transcription - maybe there is insufficient description. 05:27:14 .. Because it only describes it as translation from one language to another, 05:27:21 .. and not intralingual subtitles. 05:27:27 Cyril: I was going to say: transcription? 05:27:40 Andreas: Yes, but this would not only be same language, but also that it is accurate, 05:27:50 .. verbatim transposition of what is said, right? 05:28:01 .. How would you describe transcription? 05:28:08 Cyril: I was more thinking of DAPT, right 05:28:13 Andreas: yes, that's true. 05:29:03 Nigel: We did a lot of work in DAPT with represents - transcription could be 05:29:20 .. dialogue or text in the video image, say. There's an extra layer of detali. 05:29:34 Andreas: We also thought about transcription, how AI transcription is different from hard of hearing 05:29:38 .. or translation. 05:29:44 Pierre: Looks good to me 05:29:59 Andreas: I was checking the EBU-TT classification scheme metadata. 05:30:11 .. How is this different? That already describes similar things. 05:30:17 s/Andreas/Cyril 05:30:31 Andreas: Yes it's a good point, and other subtitle standards may have this. 05:30:40 .. But it's valid because the EBU-TT metadata is independent of the format. 05:30:55 .. You may be able to use the EBU-TT metadata to classify the types of other formats of subtitles. 05:31:05 Nigel: It's just a classification scheme 05:31:15 Andreas: Yes, okay, we should look at it and align it. 05:31:25 .. You're right, the context was different but I think we have not looked at it. 05:31:34 Cyril: At least having a correspondence between the two schemes. 05:31:38 Andreas: Yes 05:31:52 Cyril: In the US people make the distinction between closed captions and subtitles for the hard of hearing. 05:32:10 .. There is gradually more text describing non-dialogue. 05:32:15 Pierre: That's news to me! 05:32:31 .. It's the first time I am hearing that it's a different kind rather than a different style of authoring. 05:32:40 Cyril: I need to check my source. 05:33:10 Nigel: What is the distinction? Is it that closed captions don't have non-dialogue sounds? 05:33:22 Cyril: What I heard is that subtitles don't have any ambient sound description, then you add 05:33:32 .. some to get closed captions, then add even more for hard of hearing subtitles. 05:33:35 .. More context. 05:33:44 Nigel: It's a first for me as well! 05:33:55 Cyril: Probably safe to ignore it 05:34:05 Pierre: Another place to look for different types is DASH. 05:34:17 .. There was an effort to create a mapping between IMF, DASH and others. 05:34:35 Andreas: We are mapping between DVB specifications - the DVB DASH specification might differ 05:34:48 .. from DASH-IF, if that has its own metadata e.g. for the role attribute. 05:35:05 .. What would be good anyway is if we for example, from the values, cover the spectrum of 05:35:18 .. what we deliver. A mapping document, even an informative one, to map between the different 05:35:23 .. specifications would be useful. 05:35:38 Pierre: I'm 99% sure I've seen that document somewhere. I feel like I've seen a spreadsheet... 05:35:42 Andreas: That would be good. 05:35:54 .. Then it could either be extended or pointed to. 05:36:08 .. It would be good to get at least a common understanding of the purpose and kind of subtiltes, 05:36:16 .. so we are sure we mean the same thing. 05:36:20 s/tilt/titl 05:36:35 .. What I get from your feedback is that it most likely covers what is already used 05:36:42 .. apart from transcription that could be added. 05:36:51 .. But then there could be different understandings of the labels or names. 05:37:00 .. It would be good for us to look at it from the DVB side. 05:37:14 .. I don't know where this could be worked on or published, the mapping between the different specifications. 05:37:24 .. It could be actually some work in the CCSubs group. 05:37:31 .. It doesn't need to be a standard document. 05:37:34 Pierre: Yes. 05:37:45 Andreas: Possibly there is no further need to work on it. 05:38:36 Nigel: Are all the accessibility features in the DVB Accessibility Implementation Guidelines 05:38:45 .. that need a timed text track represented by this list? 05:39:19 Andreas: That cross referencing is something we want to do. 05:39:33 Pierre: There's a difference between what could be used and what is actually used today 05:39:42 Andreas: We tried to focus on what is used today 05:40:03 .. In the liaison we sent to TTWG we include a classification that may not be deployed yet 05:40:05 .. or have a label, so it is more future looking. 05:40:23 Pierre: I can definitely see a super simple web page with a column for each spec, 05:40:27 .. DVB, HTML, IMF etc 05:40:33 Andreas: That would be a good target. 05:40:41 .. It could just be a GitHub Markdown thing 05:40:47 Pierre: We could put that together very quickly. 05:42:12 Topic: Subtitle formats 05:42:18 eric-carlson has joined #tt 05:42:33 Andreas: We reached a kind of status where two formats co-exist, that 05:42:43 .. possibly on both side was a result of a kind of resignation that they are both in the market 05:42:46 .. and will remain. 05:43:03 .. What I hear constantly and from other stakeholders not in standards orgs is that they are 05:43:10 .. really confused about these different formats and profiles. 05:43:23 .. If they are not very involved they would like one format, and they don't mind which one. 05:43:42 .. W3C or TTWG, maintaining both of them, does not deliver a clear answer to why we have 05:43:53 .. this situation and how implementers in the domain should behave on that. 05:44:09 .. It is hard to understand why you have two formats that implement the same kind of requirements. 05:44:25 .. My question is what can we do, or the other way around, we should do something to ease 05:44:34 .. the situation in the market, or find a position or strategy how to deal with this. 05:44:42 .. I think this is our responsibility to do that. 05:44:45 q+ 05:44:49 eric-carlson: To do what exactly? 05:45:00 Andreas: To explain to the market what they should do and why we have two different thigns 05:45:08 .. coming from the same group in the same organisation. 05:45:12 s/thign/thing 05:48:13 Nigel: I presented a very short presentation two weeks ago at Demuxed addressing the 05:48:23 .. same question, "What timed text format should I use?" 05:48:33 .. I told the audience to use IMSC Text for new subtitle and caption applications, and 05:48:42 .. DAPT for new transcription and audio description applications, 05:48:51 atai has joined #tt 05:48:52 .. though I did not have time to explain all my rationale. 05:49:18 .. If you look at CMAF for example, and lots of other video systems, they all point to IMSC, 05:49:23 .. so the web is the outlier here. 05:49:44 eric-carlson: You haven't been able to convince browser vendors to implement [TTML] for over 10 years. 05:49:54 Andreas: Right, but the other spec is still not a recommendation. 05:50:10 Pierre: Javascript, HTML and CSS is too good Eric! 05:50:22 eric-carlson: It works too well up to a point, and then there are issues like user privacy 05:50:26 .. where we run into a wall. 05:50:40 Pierre: This is too casual 05:50:50 eric-carlson: OK, how do we have a real discussion, where are we going to have it, 05:50:59 .. who needs to be in the room and how are we going to have a decision? 05:51:04 q? 05:51:07 ack n 05:51:17 Andreas: What I wanted to aim for is not a certain answer to the question. 05:51:31 .. I just said that it would be good to have a strategy that I would expect for a standards organisation. 05:51:45 .. If we were a company I'm sure we would have a statement or a strategy, but at the moment 05:51:56 .. we don't have anything like that, we just move on, and that is unsatisfying. 05:52:02 .. We all may have our own opinions on that. 05:52:17 .. As a group it would be good to have help or an explainer to the world what they should do. 05:54:08 Nigel: One of the issues I see is that the same companies that are browser vendors have 05:54:35 .. directly contradictory statements for their native frameworks - both Apple and Google, for example. 05:54:54 eric-carlson: You need to make a case for adding support for IMSC to browser implementers. 05:54:58 q+ 05:55:06 .. Browsers are the largest target. Not to disparage any of the other code on the system, 05:55:35 .. but any code that you add to the browser has to be much more robust than ... 05:55:47 .. I think people underestimate how much effort it is to add support for a complicated 05:56:00 .. sophisticated feature to a browser, because of the security considerations. 05:56:18 .. So what we need to do if it is important to add native support for IMSC to the browsers is 05:56:29 .. to convince the browser vendors to spend a serious amount of time and money adding this 05:56:31 .. feature. 05:56:40 q? 05:56:45 ack pal 05:56:54 Pierre: I agree that it's an investment and it's not instantaneous. 05:57:07 .. On the security surface, this is not like implementing a new video decoder or encoder. 05:57:21 .. It can be done entirely with CSS, HTML, JS. There's already an XML parser somewhere in all 05:57:32 .. browsers. It is true that it is effort, and I don't want to minimise that. 05:57:48 .. But compared to a completely fresh video decoder the risk is lower, if anything because there 05:57:56 .. is test content and a reference implementation. 05:58:04 .. I have implemented it now in a couple of languages. 05:58:09 eric-carlson: Including C++? 05:58:26 Pierre: No, in JS + HTML + XML + CSS. I don't think you'd have to write a single line of C, 05:58:35 .. maybe for binding at a super high level in the case of Webkit. 05:58:44 .. Some operators have clients that entirely use polyfills. 05:58:55 .. I'm happy to be proven wrong here, but I think this is true in the case of TTML. 05:59:04 eric-carlson: That's not typically the way that a browser is written. 05:59:18 .. Maybe I'm overstating things but it will be a major piece of work and investment. 05:59:23 Pierre: I totally agree with you on that one. 05:59:39 .. There's already an XML parser in Webkit? 05:59:54 eric-carlson: I assume there is but I don't actually know. 06:00:11 Pierre: Assuming that it exists, then writing in C, assuming the XML Parser is in C or C++ 06:00:26 .. or ObjectiveC then writing something that goes from XML to HTML + CSS then that's 06:00:41 .. not hard. I would assume you do not have to write the layout engine too, and it would be more 06:00:50 .. consistent and faster to use CSS for layout. 06:01:05 .. So you could write the XML to HTML conversion in C and C++, which is not insignificant, 06:01:19 .. but there's at least one very good example of doing that in JS, so writing the equivalent in C 06:01:41 .. or C++ or whatever is pure logic - no layout, font rendering, no Unicode. 06:01:53 .. If you told me that was the main obstacle then I could imagine people collaborating on it. 06:02:06 .. If you said you also have to write the layout engine in C then that is a different business. 06:03:07 Nigel: There's also a reference Java implementation that maps TTML into SVG, which also 06:03:23 .. has browser support, so that's also another approach, I'm not saying it's a good one or the right one. 06:03:47 Pierre: I'd be interested in considering what it takes to implement. 06:04:05 eric-carlson: Every time you add a major feature which is what this is, there are trade-offs, 06:04:26 .. and you have to convince browser implementers. 06:04:47 Pierre: I'm just trying to communicate that this would be worthwhile and not as hard as it might be. 06:04:55 q+ atai 06:05:03 Cyril: I was trying to understand where we're going. 06:05:32 .. If I look at the Netflix experience, I can describe our workflow if it helps. 06:05:38 .. We have two pipelines, live and VOD. 06:05:46 .. In VOD, probably 90% of what we ingest is IMSC today. 06:05:54 .. The rest would be legacy formats, SCC, STL etc. 06:06:01 .. I'm pretty sure none of it is WebVTT. 06:06:14 .. In the VOD space WebVTT is only present when we distribute content to Apple devices. 06:06:29 .. The rest of our consumption on android or web, we deliver IMSC, and we control the players. 06:06:37 .. The TVs have a Netflix SDK that handles TTML. 06:06:47 .. We have very limited use of WebVTT except for iOS devices. 06:06:52 .. For live, it's slightly different. 06:07:13 .. In many workflows we still process 608 or 708 and convert to WebVTT because people 06:07:25 .. think it's easier, but then we have to convert back to TTML to reach other devices. 06:07:35 .. It's a pain to convert to 608 to WebVTT and then to TTML. 06:07:44 .. If we have a way to migrate to one format we would be happy to do that. 06:07:45 q+ 06:07:57 .. It's more likely TTML than WebVTT given our usage of TTML. 06:08:12 .. I'm not even sure that adding a native TTML implementation would make us change our players. 06:08:19 eric-carlson: That was going to be my next question. 06:08:30 .. If a browser had native support for TTML I suspect you guys wouldn't use it because of 06:08:42 .. your requirements for styling, and user profiles across devices. 06:08:50 Cyril: Yes, it would have to be configurable. 06:09:08 .. When we were talking about FCC requirements, you seem to have requirements that 06:09:08 .. are different from ours. 06:09:19 eric-carlson: Sure, and Nigel you have said as much, that native support in browsers then 06:09:26 .. you wouldn't use it for the same reason. 06:10:35 q+ 06:11:55 ack nigel 06:11:58 q+ 06:12:12 Nigel: BBC perspective is similar. We only distribute EBU-TT-D and IMSC Text subtitles, 06:12:29 .. to all devices, and we don't have an issue doing live conversion of Teletext subtitles into 06:12:38 .. IMSC using a commonly used off the shelf cloud based encoder. 06:12:58 .. The blockers to adopting native playback are the ability to provide a good user experience 06:13:05 q- 06:13:13 .. including styling, and the lack of usage data, which is vital for product development, and 06:13:29 .. is maybe a clue as to why browser implementers have generally not been interested in caption 06:13:35 .. playback performance for many years. 06:13:37 q? 06:13:41 ack atai 06:13:54 Andreas: My intention was explicitly not to limit or focus the discussion on native 06:14:11 .. implementation in the browser. You implied that we still have no solution for that. 06:14:18 .. It could be part of the overall discussion and the solution. 06:14:35 .. It would be good to know if W3C and TTWG is willing to make an effort to find an answer 06:14:46 .. - if not, maybe we keep going as we are. 06:15:00 .. But it's not good for the industry. If we would like to find an answer we need the right 06:15:04 q+ 06:15:12 .. people in the room and a good place to discuss it. Usually TPAC is a good place. 06:15:29 .. Only then in the discussion you decide whether to keep going with one format or adopt two formats, 06:15:40 .. with justification of the decision, then there could be a new strategy. 06:15:50 .. The question is if we want to face this and work on it and discuss it. 06:15:57 .. Make some effort to find an answer together on that. 06:16:01 q? 06:16:13 q- 06:16:34 Pierre: Say that this obstacle you raise, that you're not convinced that if native IMSC support 06:16:46 .. were implemented and you're concerned that people would not use it, do you think that is 06:16:52 .. the main objection? 06:16:57 eric-carlson: I don't know that it's the main objection. 06:17:11 .. When anybody evaluates whether it is worth the cost to spend the time and cost to implement 06:17:15 atai has joined #tt 06:17:25 .. a feature you have to weigh all the options, is it better for our customers or would our time be 06:17:40 .. better spent on some other feature - there's always a bottomless list of things to be done. 06:17:47 Pierre: Sure, absolutely. 06:20:04 q+ 06:21:50 ack pal 06:24:42 ack Cyril 06:24:57 Cyril: Take as an analogy the AV1 format. 06:25:10 .. It was adopted by browsers only because there was a library 06:25:18 .. that became a reference implementation and then a few browsers used it. 06:25:27 .. I wonder if we can think of it in a similar way for TTML or WebVTT. 06:25:43 .. What if we have a library like that that converts whatever comes in into HTML with hooks 06:26:08 .. to be able to do application specific styles or OS specific styles like in iOS etc. 06:26:14 .. I wonder if that's a viable thing that would help? 06:26:27 s/AV1 format/AV1 image format/ 06:26:30 Nigel: Feels like a good thought 06:26:36 q- 06:27:51 q+ 06:28:06 Nigel: Thank you for raising this Andreas. It's good to be explicit about it. 06:28:15 .. I don't think we would solve it in one meeting. 06:28:30 .. My view working on this for so many years is that the web platform is failing the audience 06:28:36 .. in ways that other platforms don't. 06:31:15 hiroki: [speaks, scribe unable to follow, requested he post directly into IRC] 06:31:59 hiroki3 has joined #tt 06:32:28 I really welcome discussions around schemas like this. They are important both from an Accessibility perspective and for exploring the technical feasibility of generating and managing such data. 06:33:39 broadcasting will have better alignment with Web Standards 06:34:07 rrsagent, make minutes 06:34:08 I have made the request to generate https://www.w3.org/2025/11/11-tt-minutes.html nigel 06:34:19 However, I would also like to gain a clearer understanding of which group should lead these discussions and what kind of outputs would be most desirable. 06:34:29 Present+ Hiroki 06:35:39 Atsushi: His interest is in how the DVB definition is related to the TTWG work. 06:35:53 .. The schema could be attached to DAPT or audio description files. 06:36:12 .. How could the DVB-I schema be used with TTWG work. The platform should be coordinated. 06:36:31 .. From another perspective what is the place where the DVB-I schema will be applied? 06:37:31 Hiroki: I also know various groups strategy where the group members pointed ... 06:37:52 Atsushi: In reality TTWG participants are from companies as well as SDOs like DVB who use TTML, 06:38:22 like SMPTE or something else, so he is interested in how metadata will be placed within 06:38:48 .. TTWG. TTWG focuses on file formats but in real use cases there should be several metadata schemas, 06:39:12 .. so how does TTWG think such metadata takes a role in TTWG, or how TTWG participants are interested. 06:41:43 Nigel: It depends what the members tell us we need. 06:41:55 .. We allow extensibility in our formats to add arbitrary metadata. 06:42:16 .. For specific cases we add relevant metadata like in DAPT the content-descriptor. 06:42:40 .. For metadata outside the file format, we can consider that. For example there was a request 06:42:58 .. to add an Attributes block to VTT to make it easier to set the attributes on the HTML track element. 06:43:41 Hiroki: [scribe missed] 06:43:55 Atsushi: [scribe missed] 06:44:13 Andreas: What you asked for is how these two specification activities relate to each other, 06:44:29 .. with the definition of file format here in TTWG, and the metadata in DVB and TV-Anytime for 06:44:42 .. example. I understand your question is if TTWG is dealing with how their file formats are 06:44:59 .. used in the workflow. I think TTWG doesn't deal with that, but other organisations define 06:45:11 .. how to use TTML in their workflows. We can discuss more offline. 06:45:36 s/[scribe missed]/[briefly touched about whole pipeline processing using TTML or DAPT documents of video package]/ 06:47:39 rrsagent, make minutes 06:47:41 I have made the request to generate https://www.w3.org/2025/11/11-tt-minutes.html nigel 07:30:05 Siyaman has joined #tt 07:30:16 Present+ Siyaman 07:30:27 Topic: TTML Profile Registry 07:32:00 nigel: This is a WG Note at the moment. 07:32:08 -> https://www.w3.org/TR/ttml-profile-registry/ 07:32:16 Adam_Page has joined #tt 07:32:25 .. It has a registry definition and a registry section, so in principle it meets the core 07:32:29 atsushi has joined #tt 07:32:36 .. requirements of a Registry Track document, aside from maybe some formatting. 07:32:53 .. The discussion point is: should we convert it from a WG Note to a WG Registry document 07:32:59 .. so its status is clearer within W3C. 07:33:36 Andreas: Maybe there are more important things to work on first given the benefit of 07:33:41 .. changing is not so great. 07:33:50 .. It is already quite clear. 07:34:14 Atsushi: I believe some of the Web Codecs registry has a similar shift from Note to Registry. 07:34:24 .. So it should be possible. 07:34:31 .. You need a companion Rec track document which this has. 07:34:45 .. You need a format too, and a description of what the table is for. 07:34:55 .. And how to update and who will be the custodian. 07:35:10 .. Everything in this WG Note meets that so I believe a transition request should be fine. 07:35:25 .. Not sure if we should start from Draft Registry or Registry. 07:35:33 .. If the group wants to then we can issue the transition request. 07:35:46 .. I agree that the benefit of changing track is not great. 07:36:43 .. A WG Note can also have a streamlined publication - just merging to the repo could 07:36:52 .. cause a new publication, so not much changes I suppose. 07:37:36 Nigel: OK, I agree, let's leave this as-is for now, and leave open the possibility of changing 07:37:39 .. it in the future. 07:38:04 Atsushi: Just note, changing the track will not change the URL for /TR documents. 07:38:06 atai has joined #tt 07:38:18 Nigel: Right, if it did change the URL then I would not do it! 07:38:32 Atsushi: So nothing will change - it is purely up to Chairs and Editors. 07:38:52 Topic: Joint meeting follow-ups and planning. 07:39:01 Nigel: Yesterday we had the joint meeting with MEIG. 07:39:45 .. Is there anything to note? 07:40:07 Andreas: We discussed TextTrackCue, use cases for adding a more generic TextTrackCue with a 07:40:26 .. constructor. One of them was also what we discussed today, to have an HTML fragment cue, 07:40:42 .. that could be used with TextTrack. There was no strong result from the discussion. 07:41:05 .. One browser member, Philip Jagenstadt was there - I understood that he delegated the 07:41:14 .. responsibility to the subtitle experts, TTWG, for that. 07:41:48 Nigel: Yes, it was good that he attended and listened - he didn't take particular actions. 07:42:05 Andreas: There's a question about how much TTWG is involved or serves as a place for discussion 07:42:24 .. if browser implementers want to consider subtitle and caption questions. 07:42:48 Nigel: Minutes for that will be published by MEIG. 07:43:14 Andreas: We also had a brief discussion on the European legislation on accessibility, 07:43:20 .. and there are some issues regarding subtitles and captions. 07:43:33 .. The question was if the IG should work on a report that identifies gaps in web standards 07:43:39 .. to satisfy those kinds of issues. 07:43:55 .. There's no particular action for TTWG. 07:44:09 Nigel: I agree. 07:44:33 .. On Thursday we have another joint meeting, with MEIG and APA WG. 07:44:40 .. What do we want on the agenda for that? 07:44:54 .. I'm assuming that we will cover the DVB Accessibility Implementation Guidelines from the 07:45:02 .. incoming liaison that went to APA WG as well as TTWG. 07:45:17 .. We should summarise the discussion we had this afternoon too. 07:45:34 .. (on the subtitle format support) 07:45:59 .. I'd like to provide an update on DAPT and IMSC 1.3 to APA and check if there are any 07:46:20 .. requirements that they are hoping we support - especially the comment on IMSC as part of the 07:46:27 .. wide review should be discussed. 07:47:02 .. Also, coming out of the breakout session yesterday on accessible standards, 07:47:23 .. and Matt Atkinson mentioned a new ARIA Notifications API, which could be relevant for 07:47:43 .. sending subtitles and captions to screen readers, maybe in a standard way. 07:48:26 .. At the moment the BBC puts an aria-live "polite" attribute on subtitles, but it's not obvious that 07:48:31 .. is always the best choice for all users. 07:49:09 .. I'll try to format this in some sensible way and send it before the meeting. 07:50:17 Topic: Process feedback 07:50:33 Nigel: Do we have any feedback now? 07:50:57 Andreas: Possibly we can open this as a topic on a future call, when more people who might have a view will be present. 07:50:59 Nigel: Good idea. 07:51:16 Topic: Wrap up and next steps 07:51:30 Nigel: Thanks everyone for attending today. 07:51:48 .. We have good forward momentum for IMSC 1.3 and DAPT, and some actions to move ahead. 07:52:37 .. I think we need some follow-up with Dana and Gary about the WebVTT tests 07:52:54 .. review work. Dana told us yesterday that they've been meeting every 2 weeks, but that's 07:53:16 .. not been visible to TTWG at all, so we should make that work more visible and transparent to 07:53:33 .. all, rather than keeping it in a "quiet" repository. 07:53:49 .. We made a bit of progress on WebVTT issues but more is needed. 07:54:25 .. We had an interesting API presentation from Apple, but it's not really clear that the API is 07:54:43 .. in scope of TTWG, however we are of course able to discuss it and provide feedback. 07:55:15 .. We got some feedback on the TV-Anytime subtitle purpose field. 07:55:27 Andreas: There were some suggestions for additions and agreement that the mapping 07:55:45 .. between different specifications, and what kind/type/purpose exist, but the document does 07:55:49 .. not need to be prepared by this group. 07:56:05 Nigel: Of course it can be, it could easily be a WG Note. 07:56:09 Andreas: That's true. 07:56:34 Nigel: That could be useful if we want to propose changes to the kind attribute, for example. 07:56:41 Andreas: We can check the different options and choose a lightweight process. 07:57:05 Nigel: And we spent a good amount of time thinking and discussing how we can make the 07:57:21 .. subtitle format landscape easier for users and content providers to navigate. 08:00:29 Nigel: With that, I think we're done for the day. Thanks again everyone. 08:00:33 .. [adjourns meeting] 08:00:42 rrsagent, make minutes 08:00:43 I have made the request to generate https://www.w3.org/2025/11/11-tt-minutes.html nigel 08:26:24 nigel has joined #tt 08:42:33 nigel has joined #tt 08:43:02 nigel has joined #tt 09:01:37 Adam_Page has joined #tt 12:08:55 Adam_Page has joined #tt 13:40:31 Adam_Page has joined #tt