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