- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 23 Apr 2026 16:15:29 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <243298D9-D7AB-428E-BD86-889B2868CC43@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2026/04/23-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
23 April 2026
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2026/03/26-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/332
[4] https://www.w3.org/2026/04/23-tt-irc
Attendees
Present
Andreas, Cyril, Dana, Eric_Carlson, Gary, James_Craig,
jcraig, Nigel, Pierre, Simon_Pieters, zcorpan
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]DAPT
3. [7]IMSC 1.3
1. [8]Rec transition AC Review
2. [9]Namespace document
3. [10]TTML Profile Registry
4. [11]WebVTT
1. [12]New ATTRIBUTES block
2. [13]Spec ownership and auto-publication status
5. [14]Meeting close
Meeting minutes
This meeting
Nigel: Today we have:
… * DAPT - though that's an empty topic I think
… * IMSC 1.3
… * WebVTT
… * Impact of AI technologies on TTWG's mission
… Is there any other business, or things to make sure we cover?
DAPT
Cyril: I see you added another implementation. Still waiting
for 1 more for the audio parts?
Nigel: Yes that's right, the EBU's Eurovox product generates
DAPT transcripts and translations.
Cyril: That's the only blocker for transition to Rec?
Nigel: Yes, that and final decisions about what to do with the
at risk features.
IMSC 1.3
Rec transition AC Review
Nigel: The AC WBS poll is open, please ask your AC rep to vote,
if you are in a member organisation!
… I can see that several have voted already.
Namespace document
Nigel: There's a PR open on w3/ns to add the IMSC 1.3
namespace, link in the agenda.
Pierre: It's been merged
Nigel: Great, that's this subtopic closed then!
TTML Profile Registry
Nigel: Should we add IMSC 1.3 Text as im4t?
… I can raise a pull request for that.
Cyril: Why 4?
Nigel: Because 3 is taken up by IMSC 1.2. Because of IMSC 1.0.1
I think
… Any objections?
Cyril: No
no other objections
Nigel: OK I'll do that.
WebVTT
New ATTRIBUTES block
Gary: The main topic is the ATTRIBUTES block PR.
… Background is Apple wanting to add a new metadata type for
their Dim Flashing Lights feature.
James: Currently you might see just a warning at the beginning,
… it would be better to take action during the content.
… The metadata issue and PR are pre-requisites for shipping
that feature to other platforms
… and to open up VTT metadata to being a broader more reusable
metadata structure.
… Sounds like we're really close to a resolution here.
Gary: I think we're close. Thanks for providing a summary of
the main open questions.
… The main one is whether to be a new block or part of the
header location.
James: [shares window]
github: [15]w3c/webvtt#523
[15] https://github.com/w3c/webvtt/pull/523
James: If there's no concern of webcompat then I'm not
concerned about not having a new block,
… and just moving the newly proposed data into the header.
Simon: That's my preference, it's what that was intended for.
Gary: I think it would be good to have the = permitted even if
not recommended.
… I don't know if there's any precedence for this in W3C specs,
but in Javascript the __proto property
… was added with a note to tell people not to use it.
Simon: HTML has similar precedent, for various elements that
were never standardised but browsers implemented
… were specified in HTML with the "obsolete" status immediately
applied.
James: Is that a list, or a recommendation against using any
prior non-standard way.
Simon: Here it's using = instead of : as a separator.
James: Use = as a separator but say it's not recommended.
Andreas: For context, is this the same issue that James
presented in TPAC in Seville more than 2 years ago?
James: Yes
Andreas: I liked the proposal at the time but haven't followed
it.
… We made some comments, but in this case will there be a 2
weeks review period so I can check it?
James: I have some time off next week so can't promise 2 weeks.
Nigel: The TTWG working mode is to treat open (non-Draft) PRs
as CfCs, and apply the TTWG Decision policy to them, so if
there's an Approve and no Request Changes after 2 weeks, it can
be merged.
James: I'm planning to summarise the discussion from today and
then add it as a comment to the PR
… So if people want to clarify any details or I've
misunderstood then people can see that.
… I'll leave it as a draft PR until then.
Simon: Case sensitivity: currently WebVTT is mainly case
sensitive, so it would be consistent to
… be case sensitive here as well. Is there a reason not to be?
Gary: For the attribute names?
Simon: Yes
James: Yes there is pre-existing use by YouTube and others who
have capitalised attribute names.
Simon: Are those attribute names the same as the standard ones
we're trying to add?
Gary: It depends on which one - like kind etc.
… The case-insensitive part comes up later in the summary of
bullets.
… The next point is how we want to define parsing of the
attribute names.
… Right now what is implemented is ASCII+, other proposals
include XML Name or HTML attribute name.
… My question is: does it need to be ASCII only?
… In WebVTT we already have IDs like cue and region identifier,
where any character except --> or space
… is permitted. It already specifies that the cue identifier
needs to be unique in the file,
… so the parser would need to do unicode normalisation and
other things to make sure the IDs are unique.
James: The only concerns I brought up are bidi and reverse
chars, look-alike characters, or zero-width joiners, or emoji
variant combinations?
Simon: At the higher level do we need to make it conforming to
use non-standard metadata attributes
… in the first place. If not this is moot, we just list the
permitted attribute names.
James: The reason for this is, depending on the type that is
chosen, I think it is appropriate for the TTWG
… to be the keyholder of what the type is, but once that type
is defined it could be some other standards
… body that defines the keys.
… Maybe we don't need to do that.
… At the same time I put in the concept of a custom metadata
block that is freeform, not standardisable,
… but parsed, so the implementation could use it.
… If that's the case we should allow freeform characters of
whatever character set we define.
Gary: I think it would be helpful to allow custom attributes.
… The reason we had the previous issue is because WebVTT didn't
have an official way to include metadata.
… If there was something official then e.g. HLS could have used
that for the timestamp map.
… Now I wonder if we want to limit the official names, with an
x- prefix, to make it easier for us to add new attributes.
James: Or use the HTML pattern data-
Simon: Or just a - at the beginning, like in HTML.
Gary: In that case would it make sense to point to the HTML
attribute parsing, or do we still
… need to specify the - for custom names.
Simon: It's not so much that, which we may need to define
ourselves, but we can be aligned that
… no dash means it's defined by the standard.
James: For Gary's question, do we want to point it to the HTML
attribute name for parsing?
Simon: I think no.
… We need to ban --> for example, although > is not allowed in
attribute names, but it's a different rule.
Gary: We probably want to be similar to how region identifiers
are implemented.
Simon: I don't think we need to worry about lookalike
characters. These are all possible in identifiers right now
… I think.
Nigel: +1 to aligning with HTML attribute name syntax, because
we want to allow the attributes to be reused in HTML.
Simon: Non-standard attributes would be invalid HTML unless
they begin with data-
Nigel: OK, imagine people want to push WebVTT attributes into
the HTML for their own reasons.
James: Are you proposing some model for tunnelling these
attributes through from VTT to HTML?
Nigel: We haven't discussed that as a processing model, but I
don't think we need to. But we should
… make the path easy in case people do want to do that.
James: Are we saying any Unicode char except bidi and --> ?
Gary: I think so, yes. Just remove the "ASCII only" part.
… Being case-sensitive is probably easiest. The potential
benefit of being case-insensitive is if we were
… to allow language for the lang attribute, because that will
allow the current YouTube metadata to work
… without any further work on their part.
Simon: Making YouTube's content magically do something should
be a non-goal.
… They can update that in an afternoon. We shouldn't complicate
the language for that.
… Maybe that means we should not care about case-insensitive or
the = sign either.
… If we were using the ATTRIBUTES block then the existing
headers would still do nothing in the standard
… implementation, so we can decide that if the syntax doesn't
match then it still does nothing.
… It's not breaking any more than it's broken today if we
ignore it.
James: Follow-on question: if any of these attribute lines is
invalid do we invalidate the whole block or just that line?
Gary: Just that line. Looking at the HLS timestamp map there is
a colon used.
… It wouldn't match exactly, but the attribute name would not
just be the [scribe missed]
… The main reason is that it's so ubiquitous in HLS content
that having it be valid would be helpful.
Simon: HLS compat is more compelling than YouTube compat.
Gary: Yes. If and when we have a follow-up of a GetAttributes()
method then we could decide how to handle
… non-standard attribute names from being returned.
… We could just not worry about them at the moment.
Simon: If the intent is that they should be usable from
Javascript then there needs to be a way for them
… to be usable other than fetching and parsing the file again.
Gary: Yes but that doesn't need to be part of this PR.
James: Sounds like we're aligned on 2, moving on, to the
question of the reserved key name being lang or language.
Nigel: I can't recall my original comment, and I can't find it!
… Matching HTML attributes in the track element makes sense, I
have some recollection that care was needed
… for translation subtitles when indicating the language from
which they were translated.
James: I'll see if I can find that comment, but work on the
basis of `lang` for now.
… Item 4 is about if `kind` is required, or should `kind:
metadata` be required in order to use metadata type.
… I feel that we should require it but if we only require it
with a metadata value then it seems complex,
… and I'd appreciate advice on how to do that, if that is what
we decide.
Gary: It doesn't seem worth requiring it, to me.
… If you have a type then potentially you could assume kind:
metadata but even that seems unnecessary,
… because what if in the feature we decide to have multiple
types of captions, or something like that.
… We could extend it for other kinds as well.
James: Then the parsing rule I will attempt to write will be:
… if there is a type, then we would need a kind as well, in
order to use the type.
… if there is a type but no kind then the implementation
wouldn't be sure how to use it.
… It might be some future type with an unidentified kind.
Simon: Isn't there always a `kind` when sourced from HTML even
if it is the default?
James: Yes, so the implementation can fall back.
Simon: Yes, the UA will have a kind even if it is the default.
James: One of the primary use cases is in Apple's services that
could be used on other non-Apple hardware
… such as the AppleTV app on another brand of TV, or HBO's
content on AppleTV hardware.
… I feel we need to know this outside the context of just the
web.
… I'll try to write it up logically in the PR.
Nigel: Until we define a processing model for all this metadata
then we should not restrict anything.
… We can add the syntax but then add restrictions later if we
define a processing model.
Gary: I was going to say the same thing.
Simon: Just to comment on the processing model, at least for
the standard attributes that we're adding then
… it makes sense to specify the processing model in HTML, then
you can use the file-provided attributes
… as fallback. Then in WebVTT all you need to do is make that
data available so that other specs can look into it.
James: To make sure I understand "the value provided", the kind
attribute in HTML would override the value
… in the WebVTT if provided, otherwise the WebVTT value would
be used?
Simon: Potentially, yes.
James: So there'd be no need for a parser warning?
Gary: I agree
Nigel: I'd be more concerned about errors than warnings. I'd
only expect a warning if there's a SHOULD
… and I don't think there are any here.
James: I'll check that.
Gary: If the line is invalid from a parsing perspective we
would skip it.
Simon: But if --> is present then it would be invalid so we
would expect some parser message
Gary: Even then the parser might just ignore it and move on.
Simon: Sure, sometimes the parser has errors even if it also
ignores.
James: The final point is about the examples, and I'm happy to
concede to consensus.
Gary: You could add subtitles to an existing example.
James: Fair point.
Spec ownership and auto-publication status
Nigel: I think we need Atsushi for this.
… For those who haven't been following there was a question
about TTWG officially taking ownership of WebVTT.
Gary: There was a CfC that had no objections so we need
Atsushi's help to figure out the next steps.
Meeting close
Nigel: Thanks all, we didn't cover the TTWG mission related to
AI, for another time when Atsushi is present.
… See you in 2 weeks. [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[16]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).
[16] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 23 April 2026 16:15:40 UTC