- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 11 Sep 2025 16:17:46 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <3B08E178-8957-41AC-A223-1365BF998682@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2025/09/11-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
11 September 2025
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2025/08/28-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/315
[4] https://www.w3.org/2025/09/11-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
Chris_Needham
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]DAPT
1. [7]CR Snapshot publication
2. [8]Issues and pull requests for discussion
3. [9]Use xref to resolve TTML2 and w3c-process links
w3c/dapt#313
4. [10]Use of src on embedded content entities appears to
conflict with TTML2 w3c/dapt#312
3. [11]IMSC 1.3
1. [12]Incoming liaison from ARIB
2. [13]ARIB liaison 2025-09-05: Table 1. Base Character
Set w3c/imsc#616
3. [14]The reference to the Unicode Standard should be
undated w3c/imsc#617
4. [15]Can ::cue(selector) match a list of webvtt node
objects? w3c/webvtt#533
5. [16]TPAC 2025 planning
6. [17]Meeting close
Meeting minutes
This meeting
Nigel: Today we have a busy agenda.
… DAPT bits and pieces, IMSC 1.3 - the ARIB incoming liaison
and consequences,
… a couple of WebVTT issues and TPAC 2025 planning
… Any other business or points to make sure we cover?
… I have something small about our group wiki page.
no other business
DAPT
CR Snapshot publication
Nigel: I don't think we've had any HR responses yet, as tracked
in [18]w3c/dapt#307
[18] https://github.com/w3c/dapt/issues/307
Atsushi: I don't see any comments yet
… Some of the HR groups had August vacations.
Issues and pull requests for discussion
Nigel: Some issues were raised since the last call.
… I fixed the typo/editorial type issues directly.
Use xref to resolve TTML2 and w3c-process links [19]w3c/dapt#313
[19] https://github.com/w3c/dapt/issues/313
Nigel: This addresses that some links to TTML2 went to the
current Rec
… and others to the most recent CR snapshot.
… I requested review.
… The pull request changes all the hrefs to TTML2 to point to
the latest CR snapshot.
… It needs a review approval before it can be merged.
Atsushi: I have not commented yet.
… My concern is that for TTML2 we make /TR/ttml2 point to the
latest Rec even though
… we have some CR publications.
… We should be consistent but I haven't had time to check.
… Let me have some time to look.
SUMMARY: @himorin to check this
github: [20]w3c/dapt#313
[20] https://github.com/w3c/dapt/pull/313
Use of src on embedded content entities appears to conflict with
TTML2 [21]w3c/dapt#312
[21] https://github.com/w3c/dapt/issues/312
github: [22]w3c/dapt#312
[22] https://github.com/w3c/dapt/issues/312
Nigel: Raising this here for visibility.
… It needs a fix I think, preferably before CRS.
… It's a spec bug by the looks of it.
… I don't think it's too hard to fix; my plan is to raise a PR.
… If when I raise it we can review it reasonably speedily and
get it merged that would help
… us avoid needing another CRS after the one we're working
towards now.
SUMMARY: @nigelmegitt to open a PR to fix.
IMSC 1.3
Incoming liaison from ARIB
Nigel: We received an incoming liaison from ARIB
… Pierre I think you've already taken some action based on
this.
Pierre: Yes, let's start with [23]w3c/imsc#616.
[23] https://github.com/w3c/imsc/issues/616
ARIB liaison 2025-09-05: Table 1. Base Character Set
[24]w3c/imsc#616
[24] https://github.com/w3c/imsc/issues/616
github: [25]w3c/imsc#616
[25] https://github.com/w3c/imsc/issues/616
Pierre: My understanding of the issue is that IMSC recommends
that authors use certain
… characters depending on language.
… There's a base set that can always be used, and all
implementations should support it
… regardless of language.
… That base set has been in IMSC since time immemorial, and if
I'm not mistaken it was derived
… from Blu-ray and home video titles.
… My understanding of the ARIB comment is that for their
application the base set should not
… contain some characters, because they don't consider them as
being universally needed.
Cyril: Those that they suggest are not universal - I assume
they're not Japanese?
Pierre: They're things like horizontal bar, trademark sign,
vulgar fraction 2/5, punctuation,
… graphic signs, service mark sign.
… I think some of those are not uncommon.
… My take on this is that's exactly why support for the base
character set is a SHOULD not a SHALL
… specifically for that reason, that those characters are not
necessarily completely universally
… applicable.
… My recommendation is that we do nothing and point out that
it's a SHOULD and that in general
… people are encouraged to support as many Unicode characters
as possible.
… Internationalisation was surprised we even had [sub]sets.
Nigel: That makes sense to me.
Pierre: I've labelled it as Won't Fix and provided a rationale.
… We should probably include that in our disposition in a
liaison back to ARIB.
Nigel: Any other views or comments?
Cyril: You're suggesting Won't Fix. What would be the
alternative, the next best solution?
Pierre: The real issue is that this table, the base set, has
been in IMSC forever.
… Trying to edit it partially would be a very significant
undertaking and maybe pointless at the end.
Cyril: I was thinking of other options. We could completely
remove the base set.
… It's a SHOULD, if nobody implements it, what's the point?
Pierre: It's been there for people who maybe don't know.
… Maybe things are different from in 2008 or 2012.
… If somebody creates a renderer and needs to know which
characters amongst all of Unicode
… they need to support, the base set plus language specific
sets are a good place to start.
… If you're a specialist who knows better for local needs, then
you can do what works for you.
… For a renderer on an embedded device it makes sense to use
those tables to subset the
… characters supported, and those tables are incredibly useful.
Gary: There's already a note that it's not intended to limit
processors from deciding what to render.
Pierre: I think it was a reasonable compromise between "all of
Unicode" and "what's in 608".
<Zakim> atsushi, you wanted to discuss agree with SHOULD, if we
left as wontfix, we may need to weaken it somehow...
Atsushi: Reading the spec strictly, instances should be using
the character sets in Appendix B too,
… a SHOULD, and there's a note in B saying it's not intended to
limit the set of possible characters
… the processor understands. Reading it strictly, it's a
processor minimum (that SHOULD be supported)
… We first added to the ja table in 1.3 draft.
… There is inconsistency between ARIB one and what we have
here.
… There may be inconsistency between the IMSC 1.3 definition
and the ARIB one.
… I propose to add a note about the ja set that some characters
could be omitted from the base
… set to weaken the minimum requirement for the processor for
ja specifically.
… If not, there's an inconsistency at the SHOULD level compared
to ARIB that could cause some
… issues in the future.
Andreas: I don't have a strong view. Question: is there any
indication that those base characters
… are actually used? Do we have feedback about which characters
are used?
… Otherwise we could remove it because it is nearly impossible
for us to review if the base set
… is the correct one.
Pierre: I will quadruple check, but these characters came from
the original member submission.
… [checks]
… Yes, that came from the initial member submission - it
definitely had a character set.
… That was the result of actual study of home video material.
… And the intersection with 608 and 708.
… There's a basis for those tables, they're not random.
… Since then they've been updated.
… To the question of usage, unfortunately like all voluntary
standards with no licensing we have
… no idea who uses IMSC. If the criteria depend on knowing
about usage we would have no spec!
… I'm not excited to remove text that is only a recommendation.
… This would be a very different conversation if we were
talking about convergence with ARIB
… and ultimately ARIB referencing IMSC and not ARIB-TT then it
would be different.
… It would be reasonable at least to have a note. We might not
want to create a ja set that
… conflicts with past ARIB-TT practice. As far as I can tell
ARIB-TT will continue being a separate
… specification managed separately.
… So I do not want to impose additional constraints on IMSC at
this time.
Nigel: For a local usage it is reasonable to impose additional
constraints on IMSC if they make
… sense. So an adopter could say "IMSC but with SHALL support
for some specific set of characters"
… that they define, and that wouldn't be non-conformant with
IMSC at all as it stands.
… I think that's an argument in favour of Won't Fix.
Pierre: Again, it's not clear from the liaison but if ARIB is
interested in discussing convergence
… this might be a different discussion.
… Maybe we ought to ask about that when we get back to ARIB.
Nigel: Does anyone think Won't Fix is not what we should be
doing here?
… Hearing nothing, that's the summary then.
SUMMARY: TTWG discussed 2025-09-11 and no proposal other than
Won't Fix was made. A possibility was raised to add a
ja-specific note.
The reference to the Unicode Standard should be undated
[26]w3c/imsc#617
[26] https://github.com/w3c/imsc/issues/617
github: [27]w3c/imsc#617
[27] https://github.com/w3c/imsc/issues/617
Nigel: This is related to [28]w3c/imsc#615.
[28] https://github.com/w3c/imsc/issues/615
Pierre: There are many layers to this. At a high level, Unicode
is a living standard that
… is evolving regularly, with new languages being added,
corrections being made etc.
… I don't think it ever makes sense to take a single dated
snapshot and be done.
… The way to convey that is to reference the undated, i.e.
latest, version of Unicode.
… That's my general recommendation with Unicode.
… Today in the current draft it is the 2020 version.
… I think we should remove that and always point to latest.
… Added to that, ISO has withdrawn older versions of some
standards,
… so pointers to old versions will stop working.
… I don't see any reason not to point to the undated latest
version.
Nigel: That makes sense.
… The general counter-argument is that it means that point in
time implementations
… that are valid or conformant when created can suddenly stop
being conformant later,
… even though they point to a specific dated version of say
IMSC in this case.
… For a Consumer Electronics device where some claim of
conformance might be made,
… it leaves the manufacturer in an open-ended situation.
… The reason for not worrying about that too hard here is that
Unicode doesn't tend to
… do unpleasant things like reassigning code points. It's more
an additive process.
Cyril: I was about to make a similar comment. It depends on the
standard you're referring to.
… If the standard is adding features, not to mention making
non-backward compatible changes, you
… don't want an undated version.
… Is Unicode "adding features" whatever that means?
Pierre: Typically the most common one is adding new languages
and characters for those languages.
… Unicode is not only code points but also a large library of
localisation information.
… They have the CLDR language recommendations that typically
get updated.
… I'm not aware of them ever removing characters or changing
the way code points work.
Atsushi: Maybe there are two possible links - the ISO version
or the Unicode one.
… The ISO one is updated every 2-3 years I understand.
… Then if we refer to the Unicode-consortium published one, it
has an additional set
… of information called UCS features, such as things
implemented in CLDR or other libraries.
… For glyphs and their code points, once it is added to a
Unicode code point it is never deleted.
… Sometimes a foreign feature, like a double exclamation mark,
has been marked as an emoji
… and changed from a black and white glyph to a colourful one -
Unicode can make that change.
… I totally agree that we are better to refer to the non-dated
version but I am not sure which
… one to use, ISO or Unicode.
Nigel: Do you have to pay for the ISO standard?
Pierre: Not that one. I have a pull request that points to the
undated ISO one.
… It's an update to what was there before.
Nigel: On the basis that that's the smallest change it's
probably the right thing to do.
Pierre: Also that's what ARIB references.
Atsushi: The WHATWG references the Unicode one, just for
information.
[29]WHATWG Infra spec Unicode reference
[29] https://infra.spec.whatwg.org/#biblio-unicode
SUMMARY: Group to review [30]w3c/imsc#618 pull request to
resolve this.
[30] https://github.com/w3c/imsc/issues/618
Can ::cue(selector) match a list of webvtt node objects?
[31]w3c/webvtt#533
[31] https://github.com/w3c/webvtt/issues/533
github: [32]w3c/webvtt#533
[32] https://github.com/w3c/webvtt/issues/533
Gary: We discussed this in the WebVTT Interop meeting yesterday
SUMMARY: @gkatsev to summarise the WebVTT Interop meeting
conclusion about this
Gary: Example 22 needs updating and the styling under the cue
text parsing rules needs fixing for clarity.
TPAC 2025 planning
Nigel: I created a wiki page for our f2f at TPAC
[33]TTWG TPAC2025 wiki page
[33] https://www.w3.org/wiki/TimedText/tpac2025
Nigel: It needs populating, there are some draft topics in
there.
… We also need to think about timing, if some times of day are
better for some topics than others.
… There is a link to the people in this WG who have registered
for TPAC.
… In passing I noticed that our TTWG wiki pages were quite out
of date
… so I spent some time fixing them and adding in historic face
to face meetings that were absent.
[34]TTWG wiki home page
[34] https://www.w3.org/wiki/TimedText
Nigel: We probably have too many home pages!
… If you are going to TPAC please add yourself.
Gary: Would be useful to have a session for remote attendees
and their timezones so that
… we can try to schedule relevant topics appropriately.
Nigel: Great idea.
… I'll try to do that unless someone else gets there first.
Meeting close
Nigel: We're at time, so let's adjourn.
… Next meeting is 2025-09-25
[35]Meeting issue and agenda for 2025-09-25 call
[35] https://github.com/w3c/ttwg/issues/316
Nigel: Thank you everyone. [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[36]scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).
[36] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 11 September 2025 16:18:15 UTC