Meeting minutes
This meeting
Nigel: Today we have one DAPT issue and pull request to consider,
… a possible consequence for the TTML Media Type and Profile Registry
… Two issues on WebVTT
… TPAC planning
… AI impacts
… and WebVTT Interop
… Anything else for the agenda?
no other agenda items
DAPT
Profile identifier and TTML registry w3c/dapt#248 and w3c/dapt#337
github: w3c/
Nigel: [summarises most recent comment on the issue]
Nigel: The Content Profile and the Processor Profile have different designators. Why?
… I've been looking into it. The reason for having two profiles, is because we have two dispositions in DAPT, they're not supported in TTML for inferring a processor profile from a content profile on a feature-by-feature basis
… The only safe way I found, back in Dec 2022, to express what we wanted is to have two separate profiles
… We introduced the designators in March 2023. We gave them different designators as there's text in TTML that says the designator URIs may be any URI that references a profile document
… Those are in the profile and in the spec
… So you if try that in the browser, the server returns an HTML document, but it's not presented properly as its header says text/plain
… All that the documents do is point you to the bit of the spec that defines them. They're in the ns space in w3.org
… I think we have a couple of options
… One is to ignore what the PR says: keep two designators. We wouldn't need a new CR snapshot, but we should fix the content type that's served
… Find a way to add a note to say that there's a different content profile designator if you're looking at a DAPT document
… The second option is to merge the PR that makes it a single designator, then change the PR on the TTML Type Definition and Profile Registry to point to the single value, and make it so the new URI dereferences to a sensible page
… At the moment it's just a 403
… We'd meet the TTML requirement for it to feasibly dereference by serving a page
… There'd be a double dereference
… In DAPT we'd need to determine which class of change it is and whether that needs a new CR snapshot
… It's a class 3 change, which are considered substantive, so needs a CR snapshot to be published because it would affect the conformance of content.
… Does that all make sense? Any views?
Cyril: So one solution needs a new CR snapshot, and one doesn't?
Nigel: That's right
Cyril: So we update the page served by the designator
Nigel: The type profile registry would need an extra note about the existence of the profile, and the two pages served by the designator URIs need fixing
… That might be just fixing the content-type used to be text/html
Cyril: If we don't change anything, the document that defines the profile registry can be changed and there's no publication process to follow?
Nigel: Yes
Cyril: It seems there's a choice between doing things in a clean way, and doing something quickly
… I think I favour publishing faster, so prefer avoiding a new CR
Nigel: Makes sense. I'm not fully decided on which is the cleaner way. Any other views?
Andreas: Cyril's proposal makes sense
Nigel: That's fine for me as well
Nigel: Issue 248 is about differentiating different document types. I think we can close that too
Cyril: Yes
SUMMARY: Close this issue with no change, close the related pull request without merging
SUMMARY: Update the related TTML Type Definition and Profile Registry pull request
SUMMARY: An action is needed to fix up the pages served at the profile designator URIs
Atsushi: If we made that minor change, the process shouldn't be heavy. Any strong concern about doing another CRS?
Nigel: The time it takes, and any implementation that generates valid documents would have to be updated to change the designator they use
… I'll open an action item for you to fix the pages
… Any other thoughts on this, or DAPT?
(Nothing)
WebVTT
Add WebVTT header metadata to disambiguate metadata cues (#511) w3c/dapt#548
github: w3c/
Gary: The new PR is out, in good shape but needs more reviews
Nigel: You had a comment about something being too restrictive without benefit?
Gary: It says that if you see a type that you don't recognise, you must not display it too the user. Is that necessary, as the expectation for metadata is that you don't display it
… But if the user forces metadata to be visible this would conflict with that. It seems unnecessary
Nigel: Does this assumes a new type value means a new form of metadata. But it could parse as VTT cues and be presented?
Gary: I think it's associated with kind metadata, but that may be an unnecessary restriction as well
Nigel: I don't have a view right now, but something to think about
Gary: You also made a clarification request, on the parsing steps
Nigel: The rule is that a given rule key must not appear more than once in a WebVTT file. The first will be used. But what happens if it does appear more than once, is there an error state?
Gary: Makes sense
… The parsing rules say there isn't an error generator
Chris: Is the "must" guidance to authors?
Gary: It's a lower-case "must" rather than an upper-case MUST
Chris: If that's the case maybe it should explain that.
Chris: Suggest rephrasing it to say "Authors should ... " as it's actually guidance to authors
Gary: Yes
… We'll probably need WPTs for this
Nigel: Having tests along with PRs is helpful
Gary: I think that's everything on this PR
Nigel: There are a few actions to take, based on the comments. One thing is subtle, about an unordered list. James said he'd modify that.
Gary: So I don't think there's anything major left
SUMMARY: Review and edits to continue; group reminded to check this PR.
Add properties of Fill and Stroke spec plus paint-order to properties that apply to ::cue and ::cue() w3c/dapt#545
github: w3c/
Gary: This is a request to add a couple more CSS properties to the cue
… It seems reasonable to me, but want others' opinions on it
… Specifically, the paint order related properties, and the fill and stroke properties
Nigel: Why bring in a property from SVG?
… Does anyone expect WebVTT to be rendered as SVG?
… [Reads the spec] Ah, it applies to text too, so makes sense
Gary: That paint-order property does apply to text, as it's referred to in the fill stroke spec
Nigel: Is that needed, to do something different from the default?
Gary: I think it sounds reasonable if we're expanding it to allow for all relevant related properties
Nigel: That might make sense. [Shows example in the spec]. The default behaviour is to paint the fill then paint the stroke
… The one on the right looks much nicer
Andreas: The spec is an Editor's Draft, so it's not yet a stable version?
Nigel: The latest FIll and Stroke is a Working Draft
… The SVG spec is CR. It's a good point, though, because I think W3C allows CRs and Recs to normatively reference CRs but having a normative reference to something only in WD should block publication as Rec
Gary: So technically we couldn't add it anyway
Nigel: We could defer this and ask them to come back when Fill and Stroke is in CR
Gary: Sounds reasonable
… Is it possible for WebVTT to specify more broadly, to allow any class of properties that might be available rather than have an explicit allow list?
… How to make it specific enough while allowing new properties? Or maybe that opens many new issues?
Nigel: I remember vaguely that part of the intent of the restricted set of style properties was to make it more feasible and straightforward to implement WebVTT outside a web environment
Gary: WebVTT does say if you're outside a web context, you don't need to worry about the CSS styling, Maybe that came after when the restricted set was made?
… I think there's a potential benefit to restricting the CSS, but that means whenever there's a new property we have to add it, or we can't reference that CSS spec if we want to progress our spec if it's in WD
Andreas: Go back to the browser vendors to ask the reason?
… I remember about making an HTML version of the cue, which restricted everything by a wildcard
Gary: Yes, I'd like to get their opinion
… We probably don't want to allow all CSS, so difficult to specify a subset of CSS we'd be OK with that's generic enough to add new CSS that we do want
Andreas: I remember that Nigel brought an idea to apply CSS to TTML
Nigel: It's something I wondered about, no specific proposal
… There is no class attribute in TTML. You could imagine a variant of TTML that allows a class attribute, and style with CSS instead of using TTML's applicative styling vocabulary
… The other possibility is to come up with a document that more normatively defines the mapping from the current style attributes (in IMSC) to CSS
… What we do now is point to related CSS things from TTML and leave the mapping to implementers
Andreas: As a general question, how to bring the power of CSS rendering to TTML and WebVTT
Nigel: There are missing things in CSS that we need, e.g., how backgrounds are drawn on line areas, somewhere between inline and block
SUMMARY: These properties sound like a good idea but we cannot reference a WD - please come back when this is in CR
Interop update
Dana: There's a meeting on Wednesday, for anyone with interest improving the WebVTT test suite
Andreas: Share on the group's public mailing list
Nigel: public-tt@w3.org
Dana: I'll do that, thank you
Meeting close
Nigel: Thank you all, we're over time, let's adjourn.
… Next meeting is in two weeks, 2026-07-02 w3c/
… [adjourns meeting]