{Minutes} TTWG Teleconference 2025-12-04

Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2025/12/04-tt-minutes.html


In plain text:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

04 December 2025

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2025/11/11-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/318

      [4] https://www.w3.org/2025/12/04-tt-irc


Attendees

   Present
          Andreas, Atsushi, Eric, Gary, Jer, Matt, Nigel

   Regrets
          Chris_Needham, Cyril

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Publication of a CR Snapshot
         2. [8]Test suite and implementation report
         3. [9]MAY contain zero or one ... objects should be MUST
            w3c/dapt#324
    3. [10]DAPT and IMSC compatibility (editorial)
    4. [11]IMSC 1.3
    5. [12]WebVTT open issues
         1. [13]WebVTT should allow pages to modify the caption
            display area w3c/dapt#531
         2. [14]Interop: Applying system accessibility preferences
            to WebVTT cues w3c/dapt#537
    6. [15]Meeting close

Meeting minutes

  This meeting

   Nigel: Today, we have some admin tasks to rattle through, for
   DAPT and IMSC,
   … it may be that we don't have the full set of people to
   discuss DAPT and IMSC issues.
   … We do have a couple of WebVTT issues as well.
   … Any other business, or points to make sure we cover within
   the agenda?

   no other business

  DAPT

    Publication of a CR Snapshot

   Nigel: I believe we have resolved all open HR issues.

   Atsushi: Not back from travels yet, I will check that.

   Nigel: We already have a resolution to publish 2nd CRS.
   … The last pull request (#331) was merged yesterday.
   … So I think the next step is to request the transition.

   Atsushi: Yes, I will check and do that.

    Test suite and implementation report

   Nigel: Cyril sent his regrets but I was in contact with him
   earlier in the week
   … and he intends to add the Netflix implementation to the
   implementation report.
   … I checked the test suite has been updated to reflect the most
   recent spec changes.
   … And the tests listed in the implementation report match the
   test suite.

    MAY contain zero or one ... objects should be MUST [16]w3c/dapt#324

     [16] https://github.com/w3c/dapt/issues/324


   github: [17]w3c/dapt#324

     [17] https://github.com/w3c/dapt/issues/324


   Nigel: Pop quiz.
   … When you see the wording "A DAPT Script MAY contain zero or
   one ... objects"
   … do you think that means MUST instead of MAY?

   Gary: MAY means optional, if there needs to be exactly zero or
   one it should be MUST.
   … The MAY sounds too optional.

   Andreas: I agree, the multiplicity is 0..1 so if there's a need
   for at least one object it needs to be MUST

   Nigel: This is zero or one, maximum

   Gary: I think it should be MUST, it's easier to make things
   less strict than more strict after the fact.

   Nigel: Any other views?

   SUMMARY: Change the MAY to a MUST.

   Nigel: I think this is actually an editorial change, it is
   clear that was intended.

   Gary: I would agree.

  DAPT and IMSC compatibility (editorial)

   Nigel: I raised two issues, one on DAPT and the other on IMSC.
   … IMSC already has sections about compatibility with other TTML
   based specifications.
   … So helpful to add one for DAPT.
   … And to mirror that in DAPT with a section on IMSC
   compatibility.
   … I opened a PR on IMSC a short time ago, one to follow on
   DAPT.
   … The most interesting thing is that in DAPT you can have audio
   but in IMSC you cannot.
   … I think that's fine.
   … The other interesting informative proposal is a description
   of how to use DAPT metadata to
   … drive or improve the production or presentation of subtitles
   and captions.

  IMSC 1.3

   Nigel: There is a CRS transition request open.
   … Is there anything holding that up?

   Atsushi: I created the request with a strategy review.
   Everything is under hand for review.
   … There are conversations around accessibility review, but it's
   just a no-reply from them so I described the situation
   … and left the decision to higher management.

   Nigel: Thank you, so you think it's okay?

   Atsushi: I believe so.
   … We may need some update after entering CRS, on their comment,
   but in any case that should be a minor point.

   Nigel: Yes they only wanted an informative change.
   … Any other points or questions about IMSC 1.3?

  WebVTT open issues

   Gary: One VTT thing we didn't list is the cue backdrop issue,
   … which seems like we have consensus from Firefox and Apple.
   … I've been trying to get input from Chrome but it's
   complicated.
   … I don't know how we want to handle it, maybe wait to see if
   we can get feedback, otherwise move forward.

   Eric: We might as well move forward. They have known about it
   for a long time,
   … and they can speak up if they object.

   Gary: Yes, I want to wait a little longer since it was
   Thanksgiving last week.
   … We may hear in the next week or two, if not we can move on.

    WebVTT should allow pages to modify the caption display area
    [18]w3c/dapt#531

     [18] https://github.com/w3c/dapt/issues/531


   github: [19]w3c/webvtt#531

     [19] https://github.com/w3c/webvtt/issues/531


   Gary: One of the last questions was if the cue backdrop alone
   is sufficient.
   … I think it is not, because users who would want to modify it
   would need to do extra work.
   … If you have cues positioned at the top you would need to
   handle those differently to cues at the bottom,
   … not just changing the size of the display area.

   Jer: Can you say more about why shrinking the cue area isn't
   sufficient?

   Gary: I think it is good. There was a question about adjusting
   the cue backdrop positions up and down.

   Jer: You would have to select cues by their layout, which would
   be a recursive algorithm.

   Gary: You couldn't have a solution that pushes cues outside the
   display area.

   Jer: I've looked at websites that try to do this using webkit-
   CSS properties.
   … They've tried to target the backdrop object and transform it
   upwards.
   … They don't do something different on a per cue basis.
   … Transforming the cue display area, shrinking it or moving it,
   would be simpler.
   … It would be worth calling out a tracking issue that you would
   not be able to dodge controls in the middle of the screen,
   … but those would be symbiotic APIs.

   Gary: Yes I don't think this would preclude having that as an
   additional API.
   … I did try to change the line property, but had to work around
   bugs.
   … In Safari if you replayed a changed cue then Safari would
   make a new cue, with HLS subtitles.

   Eric: With inband captions, if you seek back and play a section
   already played they deliver the captions again.
   … So webkit compares the caption delivered inband by the media
   engine to the ones it already knows about.
   … If they're different it assumes that it's new.
   … The OS cue doesn't have any kind of a unique identifier so we
   just have to go based on the data.
   … We've long asked...

   Jer: Please file a bug!
   … Our deduplication logic should probably take into account the
   original cue not the modified one.

   Gary: You could have in the original source file the same cue
   text at the same time but on a different line.
   … There isn't a good subset of properties to compare.

   Eric: no

   Gary: If you can keep track of what was modified in javascript
   that would be helpful.
   … The reason I did that is there was no way to target the
   display area.
   … In Safari and Chrome we have the exposed pseudo elements, but
   not in Firefox.
   … So I ended up backing the changes out except in Firefox.

   Jer: That's the point of the proposal, so we can get interop on
   a single way to do this.

   Gary: We would need to confirm with the Firefox folk but it
   seems like something we should move forward to.
   … Next question is which properties do we want to allow it on?
   … Basic top/bottom/left/right.
   … Also transition I think.
   … Probably also the helper properties like inset and block
   level ones, that entire family of properties.

   Jer: I've noticed people using transform to move things around.
   … We probably don't want to expose any of the properties that
   move things around.
   … It's a big footgun to set the background colour of the
   caption area and then hide the video.
   … Padding on the edges would be useful to shrink the display
   area.
   … All the font and text layout CSS properties are covered by
   the cue pseudo element so we don't need those.

   Gary: And hopefully the cue backdrop as well.

   Jer: It doesn't necessarily make sense to include font styling
   in the backdrop because you can't render text there,
   … that's the job of the cue itself.
   … What I have seen is that moving the cue area is used both for
   dodging controls
   … and also transferred outside the screen to hide them, to use
   inband cues for their contents but not their rendering.
   … Hopefully won't be necessary if we can get a high level of
   interop.

   Gary: I wonder why they don't just use mode: hidden
   … I think some folk just don't know about it.

   Jer: Another issue though - what if you transform cues out of
   the video viewport itself?
   … Webkit applies overflow: hidden to the media element's shadow
   DOM
   … You can't transform cues outside the video area.
   … We will need to resolve if that's okay or not.

   Gary: If you transform the cue -1000, -1000 is it displayed or
   clipped or forced back into the display area?

   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.
   … What does that mean?
   … I don't think those unresolved edge cases should prevent us
   from moving forward on this.
   … There's already an interop problem we should solve.

   Nigel: There's a use case for presenting captions outside the
   video, it would be bad to prevent that.

   Jer: I'm talking about the video element area not the video
   content area.
   … If you want you can do that by playing around with object fit
   etc.
   … In the currently specified WebVTT.
   … 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.

   Gary: yes

   Jer: The ability to change the object fit should probably not
   affect the cue location.
   … It might be nice to clarify that in a separate issue, that
   the viewport is not necessarily the video area.

   Gary: But then you get issues like the cue height being related
   to the viewport, the text might get absurdly large.

   Jer: The viewport is only defined by the height now, would be
   nice to define by the minimum dimension.

   Gary: You could still have a huge element area with a small
   video area.

   Jer: If you have a dramatically mismatched aspect ratio and you
   want to restrict the layout of the cues to just the video area,
   … a property you could apply to this proposed new area is the
   aspect ratio itself.
   … We should make sure that we lay out the cues within the
   content area of this new area object.

   Nigel: Likewise could you deliberately move them outside that?

   Jer: I think you already can.

   Nigel: I recall an issue some years ago where there were
   arguments about the rendering area height.

   Gary: Maybe this cue display area is the viewport.

   Jer: Viewport is a confusing concept in CSS, which has, after
   WebVTT, introduced the "container" concept.
   … This is familiar to clients of CSS and implementers, so it
   would make sense
   … to define the container area for cues, rather than viewports,
   which for CSS is the whole rendering area including scrolling.
   … I've referenced that as a future change, in a different
   issue, about using the minimum width/height as the basis for
   font size.

   SUMMARY: We want to move forward with cue container and create
   a new issue regarding the viewport/containing area for
   follow-up discussion

    Interop: Applying system accessibility preferences to WebVTT cues
    [20]w3c/dapt#537

     [20] https://github.com/w3c/dapt/issues/537


   github: [21]https://github.com/w3c/webvtt/discussions/537


     [21] https://github.com/w3c/webvtt/discussions/537


   [22]discussion

     [22] https://github.com/w3c/webvtt/discussions/537


   Gary: This is several issues hiding under a trenchcoat!
   … What if the subtitle author specifies a style and the user
   modifies it to make a terrible user experience.
   … One of the questions was around if getComputedStyle() should
   expose the data about the cues inside the video element.
   … From my reading and from when it was created it was not
   possible to get computed style of pseudo elements except
   ::before and ::after.
   … Looking at the privacy and security considerations it talks
   about being private by default
   … so my reading is that the expectation is they should not be
   available,
   … in which case how Firefox handles it would not be applicable,
   … but it should be explicitly called out in the spec,
   … assuming it's okay to say that these pseudo elements should
   not be exposed via getComputedStyle().

   Jer: I don't think there will be a lot of pushback from clients
   because it is already that way for Safari and Chrome.
   … It does make things harder to test, because layout WPT tests
   would be easier if we could query the style.
   … It's not a sufficient concern in comparison with the privacy
   issues.
   … I don't think Firefox has that issue now because they don't
   expose user preferences.
   … I also don't know if any websites rely on Firefox's
   behaviour. It's possible, hence the interop question.

   Gary: It could also, in privacy considerations, say that if you
   are applying OS level styling you must not expose that data.

   Jer: This is tied in with the FCC regulation changes, which I
   need to file an issue for.
   … The regulation depending on your legal staff's understanding
   may require exposing system settings to websites, where
   possible.
   … I will raise the issue explaining the choices we made in that
   explainer we talked about [at TPAC].
   … It might be a requirement soon to expose system preferences
   to web apps.
   … I will file an issue so we can get commentary from other
   implementers.

   Eric: On that issue, if we want to say in the spec that
   computed style is not accessible we might just
   … want to say that the captions are in a closed shadow node
   which means nothing in it is accessible from javascript.
   … That's actually how our implementation works, so we don't
   have to do anything special to silo it from javascript.

   Gary: Wouldn't that imply a specific implementation method,
   which would require Firefox to change?

   Eric: Sure, that's true, so we might want to say, instead, that
   nothing should be available, not just getComputedStyle().

   Gary: mm hmm.
   … I guess we shouldn't make any changes here until we hear the
   fallout from the FCC stuff.
   … 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
   … and the user ends up with white on white cues. Can we
   mitigate that? I'm not sure we can.

   Eric: I don't think there is anything we can do.
   … It is possible for a user, per the FCC regulations, to be
   able to control the display,
   … and essentially mark any of the properties of the caption as
   not changeable.

   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.

   Gary: Potentially the best we can do is note that it is
   possible but users should be able to change it.
   … Also the new FCC regulations talk about previewability as
   well. If when you're modifying captions in the first place you
   see that
   … then you would not fall into that trap.

   Nigel: That doesn't work if the preview is a UA-provided
   standard caption, because that won't take into account
   … if the page provides black on white or white on black
   captions, for example.

   Jer: [offers demo]

  Meeting close

   Nigel: Thanks all, let's adjourn the meeting, next call is on
   18th Dec, last of the year. [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [23]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

     [23] https://w3c.github.io/scribe2/scribedoc.html