16:01:55 RRSAgent has joined #tt 16:01:59 logging to https://www.w3.org/2025/12/04-tt-irc 16:02:00 RRSAgent, make logs Public 16:02:01 Meeting: Timed Text Working Group Teleconference 16:02:02 Agenda: https://github.com/w3c/ttwg/issues/318 16:02:06 scribe: nigel 16:02:13 Present: Eric, Nigel, Andreas 16:02:30 Previous meeting: https://www.w3.org/2025/11/11-tt-minutes.html 16:02:37 Regrets: Chris_Needham, Cyril 16:02:53 Present+ Gary, Jer 16:02:58 Chair: Gary, Nigel 16:03:44 Topic: This meeting 16:03:52 atai has joined #tt 16:04:36 Nigel: Today, we have some admin tasks to rattle through, for DAPT and IMSC, 16:04:51 .. it may be that we don't have the full set of people to discuss DAPT and IMSC issues. 16:05:02 .. We do have a couple of WebVTT issues as well. 16:05:22 .. Any other business, or points to make sure we cover within the agenda? 16:05:46 Present+ Matt 16:05:51 no other business 16:06:10 Present+ Atsushi 16:07:01 Topic: DAPT 16:07:13 Subtopic: Publication of a CR Snapshot 16:07:37 Nigel: I believe we have resolved all open HR issues. 16:08:43 Atsushi: Not back from travels yet, I will check that. 16:08:59 Nigel: We already have a resolution to publish 2nd CRS. 16:09:13 .. The last pull request (#331) was merged yesterday. 16:09:28 .. So I think the next step is to request the transition. 16:09:52 Atsushi: Yes, I will check and do that. 16:10:25 Subtopic: Test suite and implementation report 16:10:38 Nigel: Cyril sent his regrets but I was in contact with him earlier in the week 16:10:51 .. and he intends to add the Netflix implementation to the implementation report. 16:11:09 .. I checked the test suite has been updated to reflect the most recent spec changes. 16:11:23 .. And the tests listed in the implementation report match the test suite. 16:12:29 Subtopic: MAY contain zero or one ... objects should be MUST w3c/dapt#324 16:12:34 github: https://github.com/w3c/dapt/issues/324 16:12:58 Nigel: Pop quiz. 16:13:10 .. When you see the wording "A DAPT Script MAY contain zero or one ... objects" 16:13:23 .. do you think that means MUST instead of MAY? 16:14:44 Gary: MAY means optional, if there needs to be exactly zero or one it should be MUST. 16:14:53 .. The MAY sounds too optional. 16:15:41 Andreas: I agree, the multiplicity is 0..1 so if there's a need for at least one object it needs to be MUST 16:15:54 Nigel: This is zero or one, maximum 16:16:07 Gary: I think it should be MUST, it's easier to make things less strict than more strict after the fact. 16:16:18 Nigel: Any other views 16:16:28 SUMMARY: Change the MAY to a MUST. 16:16:43 Nigel: I think this is actually an editorial change, it is clear that was intended. 16:16:46 Gary: I would agree. 16:17:05 Topic: DAPT and IMSC compatibility (editorial) 16:17:37 Nigel: I raised two issues, one on DAPT and the other on IMSC. 16:17:47 .. IMSC already has sections about compatibility with other TTML based specifications. 16:17:53 .. So helpful to add one for DAPT. 16:18:06 .. And to mirror that in DAPT with a section on IMSC compatibility. 16:18:20 .. I opened a PR on IMSC a short time ago, one to follow on IMSC. 16:18:51 .. The most interesting thing is that in DAPT you can have audio but in IMSC you cannot. 16:18:53 .. I think that's fine. 16:19:27 .. The other interesting informative proposal is a description of how to use DAPT metadata to 16:19:41 .. drive or improve the production or presentation of subtitles and captions. 16:20:56 Topic: IMSC 1.3 16:21:11 Nigel: There is a CRS transition request open. 16:21:21 .. Is there anything holding that up? 16:21:48 Atsushi: I created the request with a strategy review. Everything is under hand for review. 16:22:57 .. There are conversations around accessibility review, but it's just a no-reply from them so I described the situation 16:23:10 .. and left the decision to higher management. 16:23:27 Nigel: Thank you, so you think it's okay? 16:23:31 Atsushi: I believe so. 16:23:47 .. We may need some update after entering CRS, on their comment, but in any case that should be a minor point. 16:23:56 Nigel: Yes they only wanted an informative change. 16:24:13 .. Any other points or questions about IMSC 1.3? 16:25:08 Topic: WebVTT open issues 16:25:26 Gary: One VTT thing we didn't list is the cue backdrop issue, 16:25:34 .. which seems like we have consensus from Firefox and Apple. 16:25:45 .. I've been trying to get input from Chrome but it's complicated. 16:26:35 .. I don't know how we want to handle it, maybe wait to see if we can get feedback, otherwise move forward. 16:26:51 Eric: We might as well move forward. They have known about it for a long time, 16:26:56 .. and they can speak up if they object. 16:27:07 Gary: Yes, I want to wait a little longer since it was Thanksgiving last week. 16:27:20 .. We may hear in the next week or two, if not we can move on. 16:27:49 Subtopic: WebVTT should allow pages to modify the caption display area w3c/dapt#531 16:27:55 github: https://github.com/w3c/webvtt/issues/531 16:28:09 Gary: One of the last questions was if the cue backdrop alone is sufficient. 16:28:19 .. I think it is not, because users who would want to modify it would need to do extra work. 16:28:35 .. If you have cues positioned at the top you would need to handle those differently to cues at the bottom, 16:28:42 .. not just changing the size of the display area. 16:28:57 Jer: Can you say more about why shrinking the cue area isn't sufficient? 16:29:21 Gary: I think it is good. There was a question about adjusting the cue backdrop positions up and down. 16:29:37 Jer: You would have to select cues by their layout, which would be a recursive algorithm. 16:29:51 Gary: You couldn't have a solution that pushes cues outside the display area. 16:30:07 Jer: I've looked at websites that try to do this using webkit- CSS properties. 16:30:22 .. They've tried to target the backdrop object and transform it upwards. 16:30:29 .. They don't do something different on a per cue basis. 16:30:44 .. Transforming the cue display area, shrinking it or moving it, would be simpler. 16:31:02 .. It would be worth calling out a tracking issue that you would not be able to dodge controls in the middle of the screen, 16:31:12 .. but those would be symbiotic APIs. 16:31:28 Gary: Yes I don't think this would preclude having that as an additional API. 16:31:46 .. I did try to change the line property, but had to work around bugs. 16:32:08 .. In Safari if you replayed a changed cue then Safari would make a new cue, with HLS subtitles. 16:32:22 Eric: With inband captions, if you seek back and play a section already played they deliver the captions again. 16:32:43 .. So webkit compares the caption delivered inband by the media engine to the ones it already knows about. 16:32:54 .. If they're different it assumes that it's new. 16:33:07 .. The OS cue doesn't have any kind of a unique identifier so we just have to go based on the data. 16:33:11 .. We've long asked... 16:33:17 Jer: Please file a bug! 16:33:34 .. Our deduplication logic should probably take into account the original cue not the modified one. 16:33:54 Gary: You could have in the original source file the same cue text at the same time but on a different line. 16:34:00 .. There isn't a good subset of properties to compare. 16:34:01 Eric: no 16:34:17 Gary: If you can keep track of what was modified in javascript that would be helpful. 16:34:27 .. The reason I did that is there was no way to target the display area. 16:34:39 .. In Safari and Chrome we have the exposed pseudo elements, but not in Firefox. 16:34:50 .. So I ended up backing the changes out except in Firefox. 16:35:04 Jer: That's the point of the proposal, so we can get interop on a single way to do this. 16:35:19 Gary: We would need to confirm with the Firefox folk but it seems like something we should move forward to. 16:35:29 .. Next question is which properties do we want to allow it on? 16:35:34 .. Basic top/bottom/left/right. 16:35:39 .. Also transition I think. 16:36:05 .. Probably also the helper properties like inset and block level ones, that entire family of properties. 16:36:17 Jer: I've noticed people using transform to move things around. 16:36:28 .. We probably don't want to expose any of the properties that move things around. 16:36:46 .. It's a big footgun to set the background colour of the caption area and then hide the video. 16:36:56 .. Padding on the edges would be useful to shrink the display ara. 16:36:59 s/ara/area 16:37:42 .. All the font and text layout CSS properties are covered by the cue pseudo element so we don't need those. 16:37:49 Gary: And hopefully the cue backdrop as well. 16:38:12 Jer: It doesn't necessarily make sense to include font styling in the backdrop because you can't render text there, 16:38:19 .. that's the job of the cue itself. 16:38:31 .. What I have seen is that moving the cue area is used both for dodging controls 16:38:55 .. and also transferred outside the screen to hide them, to use inband cues for their contents but not their rendering. 16:39:06 .. Hopefully won't be necessary if we can get a high level of interop. 16:39:16 Gary: I wonder why they don't just use display: hidden 16:39:24 .. I think some folk just don't know about it. 16:39:27 s/display/mode 16:39:53 Jer: Another issue though - what if you transform cues out of the video viewport itself? 16:40:05 .. Webkit applies overflow: hidden to the media element's shadow DOM 16:40:17 .. You can't transform cues outside the video area. 16:40:25 .. We will need to resolve if that's okay or not. 16:40:50 Gary: If you transform the cue -1000, -1000 is it displayed or clipped or forced back into the display area? 16:41:18 Jer: There's a lot of text in WebVTT about how to move cues around, and one option is to move them outside the video display area. 16:41:24 .. What does that mean? 16:41:29 q+ 16:41:53 .. I don't think those unresolved edge cases should prevent us from moving forward on this. 16:41:59 .. There's already an interop problem we should solve. 16:42:02 ack nigel 16:42:57 Nigel: There's a use case for presenting captions outside the video, it would be bad to prevent that. 16:43:07 Jer: I'm talking about the video element area not the video content area. 16:43:18 .. If you want you can do that by playing around with object fit etc. 16:43:24 .. In the currently specified WebVTT. 16:43:46 .. There is a bit of ambiguity about what the viewport means when the video aspect ratio doesn't match the aspect ratio of its containing element. 16:43:50 Gary: yes 16:44:16 Jer: The ability to change the object fit should probably not affect the cue location. 16:44:31 .. It might be nice to clarify that in a separate issue, that the viewport is not necessarily the video area. 16:44:52 Gary: But then you get issues like the cue height being related to the viewport, the text might get absurdly large. 16:45:13 Jer: The viewport is only defined by the height now, would be nice to define by the minimum dimension. 16:45:25 Gary: You could still have a huge element area with a small video area. 16:45:54 Jer: If you have a dramatically mismatched aspect ratio and you want to restrict the layout of the cues to just the video area, 16:46:11 .. a property you could apply to this proposed new area is the aspect ratio itself. 16:46:30 .. We should make sure that we lay out the cues within the content area of this new area object. 16:46:49 Nigel: Likewise could you deliberately move them outside that? 16:46:52 Jer: I think you already can. 16:47:25 Nigel: I recall an issue some years ago where there were arguments about the rendering area height. 16:47:33 Gary: Maybe this cue display area is the viewport. 16:47:57 Jer: Viewport is a confusing concept in CSS, which has, after WebVTT, introduced the "container" concept. 16:48:10 .. This is familiar to clients of CSS and implementers, so it would make sense 16:48:31 .. to define the container area for cues, rather than viewports, which for CSS is the whole rendering area including scrolling. 16:48:54 .. I've referenced that as a future change, in a different issue, about using the minimum width/height as the basis for font size. 16:49:38 SUMMARY: We want to move forward with cue container and create a new issue regarding the viewport/containing area for follow-up discussion 16:49:58 Subtopic: Interop: Applying system accessibility preferences to WebVTT cues w3c/dapt#537 16:50:10 github: https://github.com/w3c/webvtt/discussions/537 16:50:19 -> https://github.com/w3c/webvtt/discussions/537 discussion 16:50:30 Gary: This is several issues hiding under a trenchcoat! 16:50:51 .. What if the subtitle author specifies a style and the user modifies it to make a terrible user experience. 16:51:09 .. One of the questions was around if getComputedStyle() should expose the data about the cues inside the video element. 16:51:33 .. From my reading and from when it was created it was not possible to get computed style of pseudo elements except ::before and ::after. 16:51:46 .. Looking at the privacy and security considerations it talks about being private by default 16:51:55 .. so my reading is that the expectation is they should not be available, 16:52:05 .. in which case how Firefox handles it would not be applicable, 16:52:15 .. but it should be explicitly called out in the spec, 16:52:34 .. assuming it's okay to say that these pseudo elements should not be exposed via getComputedStyle(). 16:52:54 Jer: I don't think there will be a lot of pushback from clients because it is already that way for Safari and Chrome. 16:53:14 .. It does make things harder to test, because layout WPT tests would be easier if we could query the style. 16:53:35 .. It's not a sufficient concern in comparison with the privacy issues. 16:53:49 .. I don't think Firefox has that issue now because they don't expose user preferences. 16:54:06 .. I also don't know if any websites rely on Firefox's behaviour. It's possible, hence the interop question. 16:54:25 Gary: It could also, in privacy considerations, say that if you are applying OS level styling you must not expose that data. 16:54:40 Jer: This is tied in with the FCC regulation changes, which I need to file an issue for. 16:55:08 .. The regulation depending on your legal staff's understanding may require exposing system settings to websites, where possible. 16:55:27 .. I will raise the issue explaining the choices we made in that explainer we talked about [at TPAC]. 16:55:38 .. It might be a requirement soon to expose system preferences to web apps. 16:55:49 .. I will file an issue so we can get commentary from other implementers. 16:56:04 Eric: On that issue, if we want to say in the spec that computed style is not accessible we might just 16:56:19 .. want to say that the captions are in a closed shadow node which means nothing in it is accessible from javascript. 16:56:34 .. That's actually how our implementation works, so we don't have to do anything special to silo it from javascript. 16:56:53 Gary: Wouldn't that imply a specific implementation method, which would require Firefox to change? 16:57:15 Eric: Sure, that's true, so we might want to say, instead, that nothing should be available, not just getComputedStyle(). 16:57:20 Gary: mm hmm. 16:57:50 .. I guess we shouldn't make any changes here until we hear the fallout from the FCC stuff. 16:58:16 .. The other big issue was around what if a user decides to set the text color to white and the content makes the background white 16:58:28 .. and the user ends up with white on white cues. Can we mitigate that? I'm not sure we can. 16:58:35 Eric: I don't think there is anything we can do. 16:58:51 .. It is possible for a user, per the FCC regulations, to be able to control the display, 16:59:01 .. and essentially mark any of the properties of the caption as not changeable. 16:59:23 Jer: If the user sets color to white and ends up with illegible captions, the user can resolve it to override the background color as well. 16:59:41 Gary: Potentially the best we can do is note that it is possible but users should be able to change it. 17:00:11 .. Also the new FCC regulations talk about previewability as well. If when you're modifying captions in the first place you see that 17:00:16 .. then you would not fall into that trap. 17:01:28 Nigel: That doesn't work if the preview is a UA-provided standard caption, because that won't take into account 17:01:41 .. if the page provides black on white or white on black captions, for example. 17:02:18 Jer: [offers demo] 17:02:26 Chairs: We're out of time 17:02:29 Topic: Meeting close 17:03:01 Nigel: Thanks all, let's adjourn the meeting, next call is on 18th Dec, last of the year. [adjourns meeting] 17:03:06 rrsagent, make minutes 17:03:07 I have made the request to generate https://www.w3.org/2025/12/04-tt-minutes.html nigel 17:03:41 Chair: Nigel, Gary 17:10:14 rrsagent, make minutes 17:10:15 I have made the request to generate https://www.w3.org/2025/12/04-tt-minutes.html nigel 17:11:08 s/Nigel: Any other views/Nigel: Any other views? 17:13:55 c/one to follow on IMSC/one to follow on DAPT 17:20:34 rrsagent, make minutes 17:20:35 I have made the request to generate https://www.w3.org/2025/12/04-tt-minutes.html nigel 17:21:49 s|c/one to follow on IMSC/one to follow on DAPT|| 17:21:53 s/one to follow on IMSC/one to follow on DAPT 17:21:55 rrsagent, make minutes 17:21:56 I have made the request to generate https://www.w3.org/2025/12/04-tt-minutes.html nigel 17:22:49 scribeOptions: -final, -noEmbedDiagnostics 17:22:50 rrsagent, make minutes 17:22:52 I have made the request to generate https://www.w3.org/2025/12/04-tt-minutes.html nigel 17:23:15 scribeOptions: -final -noEmbedDiagnostics 17:23:18 rrsagent, make minutes 17:23:20 I have made the request to generate https://www.w3.org/2025/12/04-tt-minutes.html nigel 17:24:06 zakim, end meeting 17:24:06 As of this point the attendees have been Eric, Nigel, Andreas, Gary, Jer, Matt, Atsushi 17:24:08 RRSAgent, please draft minutes v2 17:24:10 I have made the request to generate https://www.w3.org/2025/12/04-tt-minutes.html Zakim 17:24:15 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 17:24:16 Zakim has left #tt 17:24:21 rrsagent, excuse us 17:24:21 I see no action items