New ATTRIBUTES block

[cookiecrook]

Closes #511

Add new ATTRIBUTES block parsing rules and examples as discussed in #511.

This is also a prerequisite for:

• VTT Type Proposal for time-coded general-flash metadata  #512

…and its duplicate in the WHATWG repo:
whatwg/html#11333

---

Preview | Diff

[cookiecrook]

Marking as Ready for Review despite there being some TODOs remaining in the diff. Feedback requested from @gkatsev, @silviapfeiffer, @nigelmegitt, @eric-carlson, @chrisn, @bdougherty, et al.

[cookiecrook]

I think this PR is merge-ready now once a TTWG reviewer approves. The previously included TODO comments are now removed from this PR in favor of addressing that follow-on work in:

• Add a kind sub-type differentiator to new WebVTT ATTRIBUTES block #525

[nigelmegitt]

I think this would benefit from more clarity (i.e. more text) about the intended use of ATTRIBUTES and its relationship to attributes on the HTML <track> element, and any other potential usage context.

[nigelmegitt]

Needs a review from the Editor, @gkatsev .

[nigelmegitt]

See also another operational practice described for doing this at #485 (comment) in which YouTube is doing it in the Header section. We should probably make sure that whatever we specify here aligns with practice, or if not, that folk using that alternative approach are happy to change.

Update: @gkatsev had the action to draft a PR to resolve #485, and that looks to me as though it would overlap strongly with this PR.

[gkatsev]

Thanks for the work on this @cookiecrook and for your patience!

[gkatsev]

See also another operational practice described for doing this at #485 (comment) in which YouTube is doing it in the Header section. We should probably make sure that whatever we specify here aligns with practice, or if not, that folk using that alternative approach are happy to change.

What YouTube has definitely seems to align with it. Would be great if we can find someone from there to comment on this, if they could potentially move to the new block when it exists.

Update: @gkatsev had the action to draft a PR to resolve #485, and that looks to me as though it would overlap strongly with this PR.

I think ultimately, particularly, with HLS's usage of the header, we do still want the header as "point of extensibility" there. But, we may want to discourage new uses of it, since the majority of these use cases could use the ATTRIBUTES block. As an example, the ECMAScript spec added the __proto__ to the spec to get it documented but marked it as legacy: https://262.ecma-international.org/15.0/index.html#sec-object.prototype.__proto__ (I'm not aware of something specific like that in HTML or w3c specs, but I'm also not sure that there's anything against doing so).

[cookiecrook]

@gkatsev wrote:

What YouTube has definitely seems to align with it. Would be great if we can find someone from there to comment on this, if they could potentially move to the new block when it exists.

Yes, I have taken that as an action.

[css-meeting-bot]

The Timed Text Working Group just discussed New ATTRIBUTES block w3c/webvtt#523, and agreed to the following:

• SUMMARY: @cookiecrook to raise issue on HTML about track attribute precedence

The full IRC log of that discussion

<nigel> Subtopic: New ATTRIBUTES block #523
<nigel> github: https://github.com//pull/523
<nigel> jcraig: Need to assess, if there's a mismatch, which one wins.
<nigel> .. I don't have a strong opinion.
<nigel> .. Main reason we want it in the VTT is sometimes there's no HTML as an intermediary,
<nigel> .. so the track information is missing.
<nigel> gkatsev: That makes sense, my question would be would this also allow a change in HTML
<nigel> .. if we're adding precedence to those attributes.
<nigel> jcraig: I would expect that whatever we land on, we could have the same thing reflected on the track element
<nigel> eric_carlson: We also would want to add some text to the spec describing the rules of precedence,
<nigel> .. whichever way we go.
<nigel> Nigel: How are you going to work out which way to go?
<nigel> eric_carlson: We'll put a stick in the ground and we'll be right.
<nigel> gkatsev: My assumption is the track element takes precedence
<nigel> eric_carlson: That would be right, it would override what's in the file.
<nigel> gkatsev: Can still have the precedence rules in the VTT spec but would also need them in HTML
<nigel> eric_carlson: HTML doesn't say anything about how to process the contents of the VTT file,
<nigel> .. so maybe no change needed.
<nigel> jcraig: The other editorial suggestions seem fine to me.
<nigel> .. There was a section question, was just my unfamiliarity with bikeshed.
<nigel> gkatsev: Should we open an HTML issue now around this to get the conversation going.
<nigel> jcraig: I'll take that as an action and write it into PR 523 so I don't forget it.
<nigel> pal: On that last point, if you run into any issues, I can help, please don't hesitate to ask.
<nigel> jcraig: You mean pushback on HTML?
<nigel> pal: Sure, ultimately the question is who writes those tests.
<nigel> .. As Nigel pointed out there's a large body of tests to port to WPT.
<nigel> .. With reference renderers once we've overcome the issue of should we have that at all in WPT,
<nigel> .. I'm confident that we'll have the resources to make that happen.
<nigel> group confusion caused because Pierre misheard!
<nigel> gkatsev: With that we can, unless there's anything specific to WebVTT right now we can end
<nigel> SUMMARY: @cookiecrook to raise issue on HTML about track attribute precedence

[cookiecrook]

I've also taken an action to file an issue to HTML to propose any reflected attributes from the VTT to HTML Track content attributes.

[cookiecrook]

Open Question

@nigelmegitt wrote:

Alternatively a definition coincident with the WHATWG definition of attribute name could be used, but is a little less clear in my view.

Both XML Name and HTML attribute name can be hyphenated... such as data-foo which conflicts with variable names in some programming contexts due to the hyphen (minus) character. But given the choice between XML Name, and HTML attribute name, I'd go with HTML.

Regardless, I'm happy to take the working group's decision on this point, whatever that is. I'm collating a list of "Open Questions" here for an in-person discussion. Once we wrap up as much as we can in the thread, I'll research and summarize the remaining opens before scheduling more time with the WG.

[nigelmegitt]

Both XML Name and HTML attribute name can be hyphenated... such as data-foo which conflicts with variable names in some programming contexts due to the hyphen (minus) character.

Not sure how big a deal this is? People generally work around this kind of pattern in their chosen programming language. For example there are many CSS properties including a hyphen, such as font-weight that people seem able to work around in ES just fine.

[zcorpan]

I still think this should be in the header instead of a new block (see #523 (review) ).

[zcorpan]

Open Question: I changed the lang key to language based on review feedback here and precedent for YouTube's usage of Language: en... However, this now conflicts with WebVTT's <lang en> element, as well as HTML's lang and srclang attributes. I don't personally care which the WebVTT spec uses for the new ATTRIBUTES block key, so I'd like the Timed Text Working Group to make the decision.

lang is certainly more consistent, and looks nicer with kind and type also being 4 characters long. I suppose Youtube should be able to change to conform.

[zcorpan]

I would suggest aligning with XML Name as closely as possible for the keys - this is what XML permits for attribute names. That goes beyond ASCII while still being a restricted set. I have not checked if there are any permitted code points that would cause parsing difficulties in WebVTT.

Alternatively a definition coincident with the WHATWG definition of attribute name could be used, but is a little less clear in my view.

I think we should not use XML Name. WebVTT already borrows HTML syntax and parsing for named character references; it would be inconsistent and unnecessary to use XML syntax for something else in WebVTT.

HTML attribute name syntax prevents > (good because we shouldn't allow "-->") and = but doesn't prevent :. I guess we could say HTML attribute name minus : for which characters are allowed, or define the syntax in WebVTT without referencing HTML.

[cookiecrook]

@zcorpan wrote:

I still think this should be in the header instead of a new block (see #523 (review) ).

There are several existing in-the-wild use cases that would become non-conforming if this wasn't a new block. Those existing ambiguous, loosely defined or entirely undefined uses of VTT metadata will continue to persist in perpetuity.

I recall a a core TTWG member (@gkatsev IIRC) suggested the ATTRIBUTES block as a way to ease that transition from the ambiguous legacy processing to more structured processing model, while maintaining webcompat.

[Update: @gkatsev proposed METADATA (# or #:~:text), but either @eric-carlson or I renamed it to ATTRIBUTES to avoid redundancy, since it's primary use will be for kind: metadata.]

[nigelmegitt]

I think we should not use XML Name. WebVTT already borrows HTML syntax and parsing for named character references; it would be inconsistent and unnecessary to use XML syntax for something else in WebVTT.

It's true, the design choices made historically for WebVTT have been extremely XML-unfriendly, so maintaining separation from XML would be consistent. However, since we are primarily talking about metadata, and there may be use cases where folk want to transfer keys and values to/from other syntaxes, it would be good to be as open as possible within those existing constraints to minimise the need to rename keys.

HTML attribute name syntax prevents > (good because we shouldn't allow "-->") and = but doesn't prevent :. I guess we could say HTML attribute name minus : for which characters are allowed, or define the syntax in WebVTT without referencing HTML.

Or remove the requirement for the : after the key name - since the attribute name syntax prevents white space, it's not really needed. We could just have a syntax that looks like:

key [white space]+ value [line terminator]

e.g.

ATTRIBUTES
type  captions
lang  en
label English language hard of hearing subtitles

[zcorpan]

There are several existing in-the-wild use cases that would become non-conforming if this wasn't a new block. Those existing ambiguous, loosely defined or entirely undefined uses of VTT metadata will continue to persist in perpetuity.

They will not become non-conforming, they are already non-conforming.

The space for headers in the spec was reserved for the standards' own future use, it was not intended for private use (hence it is currently non-conforming to have anything there).

In fact, the opposite is true: if we start allowing custom headers, then existing content that has custom headers, assuming the syntax matches what we allow, such content can go from non-conforming to conforming. I think this shouldn't be a goal, though, only that we shouldn't shy away from using the spec's intended space for future extensibility because users of the spec have broken the contract and are using invalid WebVTT.

I recall a a core TTWG member (@gkatsev IIRC) suggested the ATTRIBUTES block as a way to ease that transition from the ambiguous legacy processing to more structured processing model, while maintaining webcompat.

Yeah the interesting question is whether it would break any existing usage if we add some standardized attributes in the header. If they keys used in the wild are different from the ones we're standardizing, then nothing will break, as far as I can tell. Even if the key is the same, so long as the value is different, still nothing would break. What is the web compat issue?

[zcorpan]

Or remove the requirement for the : after the key name - since the attribute name syntax prevents white space, it's not really needed. We could just have a syntax that looks like:

key [white space]+ value [line terminator]

e.g.

ATTRIBUTES
type  captions
lang  en
label English language hard of hearing subtitles

IMO this makes it less clear that they are key/value pairs, and it's inconsistent with WebVTT cue settings.

[nigelmegitt]

IMO this makes it less clear that they are key/value pairs, and it's inconsistent with WebVTT cue settings.

The : is optional in WebVTT cue settings so it isn't really inconsistent.

I also just remembered that some classification schemas etc for metadata use URNs for keys, which often include : so add that on the plus side for permitting colons.

[zcorpan]

That looks like a spec bug. The syntax for each individual cue setting requires the :, and without the colon the name and the value would run together which is not possible to parse.

Edit: filed #541

[cookiecrook]

Open Questions for TTWG Meeting Discussion (Date TBD)

1. Should this use the new ATTRIBUTES block as proposed vs. putting the key/value pairs in the existing header.

   • @zcorpan thinks it should be in the header
   • I’m strongly for I previously was for the ATTRIBUTES block for transitional ease wrt existing, non-conforming use of header parsing. (Note: @zcorpan objected to my use of “webcompat” above since the existing header usage, although widespread, is already non-conforming and therefore not technically a webcompat concern.)
   • Other TTWG members (including but not limited to @gkatsev) have expressed interest in the ATTRIBUTES, but I don’t know how strongly this belief is held or by whom.

2. Key name parsing, including character: define here, reference HTML, or use another name definition?

   • ASCII+ (as in PR), XML Name, or HTML attribute name?
   • Some characters need exclusion.
     • Bidi and reverse chars excluded.
     • Are we concerned with look-alike character like those comparable in ASCII and Cyrillic?
     • What about zero-width joiners used in emoji variant combinations?

3. Should the reserved key name be lang or language?

   • Previously lang, changed to language at @nigelmegitt’s review request (Note: my PR misses that change in at least one place)
   • @zcorpan prefers lang... I have a mild pref for lang, too.
   • No one has voted for srclang the other existing precedent.
   • Not sure about others.

4. Should kind be required, or should kind: metadata be required in order to use (metadata) type?

   • Sounds like no, but I’d like to discuss anyway.
   • See follow-on goal for metadata type in New ATTRIBUTES block #523 (comment)
   • See also 5 below.

5. Should there be any parser warning, or should it be left to a validator, rather than the parser?

   • Sounds like there is mild agreement that there is no need for a parser warning.
   • Depending on outcome of 4 above, this may be moot.

6. Remove the subtitles example since it is so similar to the captions example.

   • The TTWG feels the difference between subtitle (for those who can hear but need translation of the primary language) vs captions (which includes sensory needs like Deaf and Hard-of-Hearing groups, as well as those with translation needs) is not relevant to call out in VTT spec examples.
   • I have a mild pref to keep both, but will concede to the TTWG consensus after discussion.

[cookiecrook]

@nigelmegitt @gkatsev @zcorpan Please help if I missed anything in summary of open questions above. Thanks.

I know that @eric-carlson would like to attend said meeting, and is out this week. My next availability at the normal TTWG meeting time (8am Pacific) is April 9th or April 23rd.

[gkatsev]

My next availability is also April 9th.

I still need to review the new discussion but should note that I'm leaning towards using the headers space assuming that we allow non-conforming usage like mentioned here #523 (comment)

[nigelmegitt]

Agenda for TTWG 2026-04-09 is w3c/ttwg#331, which I'm unable to attend, but have added this as a possible agenda item. 23rd April would work for me, alternatively.

[zcorpan]

• (Note: @zcorpan objected to my use of “webcompat” above since the existing header usage, although widespread, is already non-conforming and therefore not technically a webcompat concern.)

To clarify, I objected to the claim that existing WebVTT content would go from being conforming to being non-conforming, as it's currently invalid WebVTT to use non-blank lines immediately after the WEBVTT file signature.

There could be a webcompat concern, but it's separate from whether existing content is conforming or non-conforming. I asked for examples where the new processing of headers would break existing content. The fact that existing content is using headers doesn't mean that that content will break if browsers start to process some known headers with some known values. I think there's only a potential issue if the standardized key and value are exactly the same as what already exists in the wild, but the semantics are different.

[zcorpan]

ASCII+ (as in PR), XML Name, or HTML attribute name?

If we don't need to allow characters outside of ASCII, an option is to align with HTML PI target: whatwg/html#12118

Right now it's [a-zA-Z][a-zA-Z0-9-]* but I added a review comment asking if _ should also be allowed.

[nigelmegitt]

If we don't need to allow characters outside of ASCII

Since the metadata keys may originate or relate to schemas external to WebVTT and to HTML, my view is that only allowing ASCII characters is likely to be overly restrictive. It's also unnecessary to be so limiting.

[cookiecrook]

Since Nigel can't make it on April 9th, can everyone make it on April 23rd?

If not, let's go ahead with April 9th.

[gkatsev]

Yeah, I think the 23rd works a bit better for me as well. We're going to cancel the April 9th meeting and have the agenda item be on the 23rd.

[gkatsev]

Some comments on this ahead of the meeting.

Open Questions for TTWG Meeting Discussion (Date TBD)

1. **Should this use the new `ATTRIBUTES` block as proposed vs. putting the key/value pairs in the existing header.**
   
   * @zcorpan thinks it should be in the header
   * I’m strongly for the ATTRIBUTES block for transitional ease wrt existing, non-conforming use of header parsing. (Note: @zcorpan objected to my use of “webcompat” above since the existing header usage, although widespread, is already non-conforming and therefore not technically a webcompat concern.)
   * Other TTWG members (including but not limited to @gkatsev) have expressed interest in the ATTRIBUTES, but I don’t know how strongly this belief is held or by whom.

Originally, I thought a new block would be better to minimize issues, but if we can support both the syntax we want while making existing non-conforming usage conforming (albeit a non-standard usage) , I think that would be best. I'm not sure if there's precedent for this type of thing in the W3C, but for JavaScript, there's some precedent when they standardized the previously non-standard __proto__ property.

2. **Key name parsing, including character: define here, reference HTML, or use another name definition?**
   
   * ASCII+ (as in PR), XML Name, or HTML attribute name?
   * Some characters need exclusion.
     
     * Bidi and reverse chars excluded.
     * Are we concerned with look-alike character like those comparable in ASCII and Cyrillic?
     * What about zero-width joiners used in emoji variant combinations?

Is there a need to limit it to ASCII+ specifically? For example, the cue identifier says it's anything except --> and it also specifies that it must be unique, so, theoretically, unicode normalization and what not should already be happening.

A WebVTT cue identifier is any sequence of one or more characters not containing the substring "-->" (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN), nor containing any U+000A LINE FEED (LF) characters or U+000D CARRIAGE RETURN (CR) characters.

A [WebVTT cue identifier](https://w3c.github.io/webvtt/#webvtt-cue-identifier) must be unique amongst all the [WebVTT cue identifiers](https://w3c.github.io/webvtt/#webvtt-cue-identifier) of all [WebVTT cues](https://w3c.github.io/webvtt/#webvtt-cue) of a [WebVTT file](https://w3c.github.io/webvtt/#webvtt-file).

webvtt/index.bs

Lines 1547 to 1553 in 9966609

	<p>A <dfn>WebVTT cue identifier</dfn> is any sequence of one or more characters not containing the
	substring "<code>--></code>" (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN),
	nor containing any U+000A LINE FEED (LF) characters or U+000D CARRIAGE RETURN (CR) characters.</p>
	<p>A <a>WebVTT cue identifier</a> must be unique amongst all the <a lt="WebVTT cue
	identifier">WebVTT cue identifiers</a> of all <a lt="WebVTT cue">WebVTT cues</a> of a <a>WebVTT
	file</a>.</p>

Also, the VTT Region identifier is similar and disallows spaces.

Also, should this be case-insensitive?

3. **Should the reserved key name be lang or language?**
   
   * Previously `lang`, changed to `language` at @nigelmegitt’s review request (Note: my PR misses that change in at least one place)
   * @zcorpan prefers lang... I have a mild pref for lang, too.
   * No one has voted for `srclang` the other existing precedent.
   * Not sure about others.

I do prefer lang as well. Is there a case to support both and have it normalized internally? Being case-insensitive and supporting both would allow supporting the YT attr without work on their side.

4. **Should `kind` be required, or should `kind: metadata` be required in order to use (metadata) `type`?**
   
   * Sounds like no, but I’d like to discuss anyway.
   * See follow-on goal for metadata type in [New ATTRIBUTES block #523 (comment)](https://github.com/w3c/webvtt/pull/523#discussion_r2921729393)
   * See also 5 below.

Having a type could imply a metadata type, though, probably not worth adding. If we'd want to extend type for other kinds, it might make it a bit harder.

5. **Should there be any parser warning, or should it be left to a validator, rather than the parser?**
   
   * Sounds like there is mild agreement that there is no need for a parser warning.
   * Depending on outcome of 4 above, this may be moot.

Yeah, I think I would prefer to err on the permissive side to have less requirements and less parser errors, if it doesn't cause any major issues.

6. **Remove the `subtitles` example since it is so similar to the `captions` example.**
   
   * The TTWG feels the difference between subtitle (for those who can hear but need translation of the primary language) vs captions (which includes sensory needs like Deaf and Hard-of-Hearing groups, as well as those with translation needs) is not relevant to call out in VTT spec examples.
   * I have a mild pref to keep both, but will concede to the TTWG consensus after discussion.

could alternate kinds across different examples instead, maybe? Like, update some of the existing examples with the new attrs.

[css-meeting-bot]

The Timed Text Working Group just discussed WebVTT.

The full IRC log of that discussion

<nigel> Topic: WebVTT
<nigel> Gary: The main topic is the ATTRIBUTES block PR.
<nigel> .. Background is Apple wanting to add a new metadata type for their Dim Flashing Lights feature.
<nigel> James: Currently you might see just a warning at the beginning,
<nigel> .. it would be better to take action during the content.
<nigel> .. The metadata issue and PR are pre-requisites for shipping that feature to other platforms
<nigel> .. and to open up VTT metadata to being a broader more reusable metadata structure.
<nigel> .. Sounds like we're really close to a resolution here.
<nigel> Gary: I think we're close. Thanks for providing a summary of the main open questions.
<nigel> .. The main one is whether to be a new block or part of the header location.
<nigel> James: [shares window]
<nigel> i/Gary: The main/Subtopic: New ATTRIBUTES block
<nigel> github: https://github.com//pull/523
<nigel> James: If there's no concern of webcompat then I'm not concerned about not having a new block,
<nigel> .. and just moving the newly proposed data into the header.
<nigel> Simon: That's my preference, it's what that was intended for.
<nigel> Gary: I think it would be good to have the = permitted even if not recommended.
<nigel> .. I don't know if there's any precedence for this in W3C specs, but in Javascript the __proto property
<nigel> .. was added with a note to tell people not to use it.
<nigel> Simon: HTML has similar precedent, for various elements that were never standardised but browsers implemented
<nigel> .. were specified in HTML with the "obsolete" status immediately applied.
<atai> q+
<nigel> James: Is that a list, or a recommendation against using any prior non-standard way.
<nigel> Simon: Here it's using = instead of : as a separator.
<nigel> James: Use = as a separator but say it's not recommended.
<nigel> ack at
<nigel> Andreas: For context, is this the same issue that James presented in TPAC in Seville more than 2 years ago?
<nigel> James: Yes
<nigel> Andreas: I liked the proposal at the time but haven't followed it.
<nigel> .. We made some comments, but in this case will there be a 2 weeks review period so I can check it?
<nigel> q+
<zcorpan> q+
<nigel> James: I have some time off next week so can't promise 2 weeks.
<nigel> Nigel: [explains TTWG working mode]
<nigel> James: I'm planning to summarise the discussion from today and then add it as a comment to the PR
<nigel> .. So if people want to clarify any details or I've misunderstood then people can see that.
<nigel> .. I'll leave it as a draft PR until then.
<nigel> q?
<nigel> ack n
<nigel> ack zcorpan
<nigel> Simon: Case sensitivity: currently WebVTT is mainly case sensitive, so it would be consistent to
<nigel> .. be case sensitive here as well. Is there a reason not to be?
<nigel> Gary: For the attribute names?
<nigel> Simon: Yes
<nigel> James: Yes there is pre-existing use by YouTube and others who have capitalised attribute names.
<nigel> Simon: Are those attribute names the same as the standard ones we're trying to add?
<nigel> Gary: It depends on which one - like kind etc.
<nigel> .. The case-insensitive part comes up later in the summary of bullets.
<nigel> .. The next point is how we want to define parsing of the attribute names.
<nigel> .. Right now what is implemented is ASCII+, other proposals include XML Name or HTML attribute name.
<nigel> .. My question is: does it need to be ASCII only?
<nigel> .. In WebVTT we already have IDs like cue and region identifier, where any character except --> or space
<nigel> .. is permitted. It already specifies that the cue identifier needs to be unique in the file,
<nigel> .. so the parser would need to do unicode normalisation and other things to make sure the IDs are unique.
<nigel> q?
<nigel> James: The only concerns I brought up are bidi and reverse chars, look-alike characters, or zero-width joiners, or emoji variant combinations?
<nigel> Simon: At the higher level do we need to make it conforming to use non-standard metadata attributes
<nigel> .. in the first place. If not this is moot, we just list the permitted attribute names.
<nigel> James: The reason for this is, depending on the type that is chosen, I think it is appropriate for the TTWG
<nigel> .. to be the keyholder of what the type is, but once that type is defined it could be some other standards
<nigel> .. body that defines the keys.
<nigel> .. Maybe we don't need to do that.
<nigel> .. At the same time I put in the concept of a custom metadata block that is freeform, not standardisable,
<nigel> .. but parsed, so the implementation could use it.
<nigel> .. If that's the case we should allow freeform characters of whatever character set we define.
<nigel> Gary: I think it would be helpful to allow custom attributes.
<nigel> .. The reason we had the previous issue is because WebVTT didn't have an official way to include metadata.
<nigel> .. If there was something official then e.g. HLS could have used that for the timestamp map.
<nigel> .. 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.
<nigel> James: Or use the HTML pattern data-
<nigel> Simon: Or just a - at the beginning, like in HTML.
<nigel> Gary: In that case would it make sense to point to the HTML attribute parsing, or do we still
<nigel> .. need to specify the - for custom names.
<nigel> Simon: It's not so much that, which we may need to define ourselves, but we can be aligned that
<nigel> .. no dash means it's defined by the standard.
<nigel> James: For Gary's question, do we want to point it to the HTML attribute name for parsing?
<nigel> Simon: I think no.
<nigel> .. We need to ban --> for example, although > is not allowed in attribute names, but it's a different rule.
<nigel> Gary: We probably want to be similar to how region identifiers are implemented.
<nigel> q+
<nigel> Simon: I don't think we need to worry about lookalike characters. These are all possible in identifiers right now
<nigel> .. I think.
<nigel> Nigel: +1 to aligning with HTML attribute name syntax, because we want to allow the attributes to be reused in HTML.
<gkatsev_cloud> q+
<nigel> ack n
<nigel> Simon: Non-standard attributes would be invalid HTML unless they begin with data-
<nigel> Nigel: OK, imagine people want to push WebVTT attributes into the HTML for their own reasons.
<nigel> James: Are you proposing some model for tunnelling these attributes through from VTT to HTML?
<nigel> Nigel: We haven't discussed that as a processing model, but I don't think we need to. But we should
<nigel> .. make the path easy in case people do want to do that.
<nigel> q?
<nigel> James: Are we saying any Unicode char except bidi and --> ?
<nigel> Gary: I think so, yes. Just remove the "ASCII only" part.
<nigel> ack gk
<nigel> .. Being case-sensitive is probably easiest. The potential benefit of being case-insensitive is if we were
<nigel> .. to allow language for the lang attribute, because that will allow the current YouTube metadata to work
<nigel> .. without any further work on their part.
<nigel> Simon: Making YouTube's content magically do something should be a non-goal.
<nigel> .. They can update that in an afternoon. We shouldn't complicate the language for that.
<nigel> .. Maybe that means we should not care about case-insensitive or the = sign either.
<nigel> .. If we were using the ATTRIBUTES block then the existing headers would still do nothing in the standard
<nigel> .. implementation, so we can decide that if the syntax doesn't match then it still does nothing.
<nigel> .. It's not breaking any more than it's broken today if we ignore it.
<nigel> James: Follow-on question: if any of these attribute lines is invalid do we invalidate the whole block or just that line?
<nigel> Gary: Just that line. Looking at the HLS timestamp map there is a colon used.
<nigel> .. It wouldn't match exactly, but the attribute name would not just be the [scribe missed]
<nigel> .. The main reason is that it's so ubiquitous in HLS content that having it be valid would be helpful.
<nigel> Simon: HLS compat is more compelling than YouTube compat.
<nigel> Gary: Yes. If and when we have a follow-up of a GetAttributes() method then we could decide how to handle
<nigel> .. non-standard attribute names from being returned.
<nigel> .. We could just not worry about them at the moment.
<nigel> Simon: If the intent is that they should be usable from Javascript then there needs to be a way for them
<nigel> .. to be usable other than fetching and parsing the file again.
<nigel> Gary: Yes but that doesn't need to be part of this PR.
<nigel> James: Sounds like we're aligned on 2, moving on, to the question of the reserved kay name being lang or language.
<nigel> Nigel: I can't recall my original comment, and I can't find it!
<nigel> .. Matching HTML attributes in the track element makes sense, I have some recollection that care was needed
<nigel> .. for translation subtitles when indicating the language from which they were translated.
<nigel> James: I'll see if I can find that comment, but work on the basis of `lang` for now.
<nigel> .. Item 4 is about if `kind` is required, or should `kind: metadata` be required in order to use metadata type.
<nigel> .. I feel that we should require it but if we only require it with a metadata value then it seems complex,
<nigel> .. and I'd appreciate advice on how to do that, if that is what we decide.
<nigel> Gary: It doesn't seem worth requiring it, to me.
<nigel> .. If you have a type then potentially you could assume kind: metadata but even that seems unnecessary,
<nigel> .. because what if in the feature we decide to have multiple types of captions, or something like that.
<nigel> .. We could extend it for other kinds as well.
<zcorpan> q+
<nigel> James: Then the parsing rule I will attempt to write will be:
<nigel> .. if there is a type, then we would need a kind as well, in order to use the type.
<nigel> .. if there is a type but no kind then the implementation wouldn't be sure how to use it.
<nigel> q+
<nigel> .. It might be some future type with an unidentified kind.
<nigel> Simon: Isn't there always a `kind` when sourced from HTML even if it is the default?
<nigel> James: Yes, so the implementation can fall back.
<nigel> Simon: Yes, the UA will have a kind even if it is the default.
<nigel> James: One of the primary use cases is in Apple's services that could be used on other non-Apple hardware
<nigel> .. such as the AppleTV app on another brand of TV, or HBO's content on AppleTV hardware.
<nigel> .. I feel we need to know this outside the context of just the web.
<gkatsev_cloud> q+
<nigel> .. I'll try to write it up logically in the PR.
<gkatsev_cloud> ack z
<gkatsev_cloud> ack n
<zcorpan> q+
<gkatsev_cloud> ack g
<nigel> Nigel: Until we define a processing model for all this metadata then we should not restrict anything.
<nigel> .. We can add the syntax but then add restrictions later if we define a processing model.
<nigel> Gary: I was going to say the same thing.
<nigel> Simon: Just to comment on the processing model, at least for the standard attributes that we're adding then
<nigel> .. it makes sense to specify the processing model in HTML, then you can use the file-provided attributes
<nigel> .. as fallback. Then in WebVTT all you need to do is make that data available so that other specs can look into it.
<nigel> James: To make sure I understand "the value provided", the kind attribute in HTML would override the value
<nigel> .. in the WebVTT if provided, otherwise the WebVTT value would be used?
<nigel> Simon: Potentially, yes.
<nigel> James: So there'd be no need for a parser warning?
<nigel> Gary: I agree
<nigel> Nigel: I'd be more concerned about errors than warnings. I'd only expect a warning if there's a SHOULD
<nigel> .. and I don't think there are any here.
<nigel> James: I'll check that.
<nigel> Gary: If the line is invalid from a parsing perspective we would skip it.
<nigel> Simon: But if --> is present then it would be invalid so we would expect some parser message
<nigel> Gary: Even then the parser might just ignore it and move on.
<nigel> Simon: Sure, sometimes the parser has errors even if it also ignores.
<nigel> James: The final point is about the examples, and I'm happy to concede to consensus.
<nigel> Gary: You could add subtitles to an existing example.
<nigel> James: Fair point.

[cookiecrook]

Consensus from today's meeting as I understand it.

1. key/value pairs should immediately follow the WEBVTT file header, not a new ATTRIBUTES block.
2. Allowed key name characters will match the value: any unicode char minus exclusions such as bidi or reverse chars, -->, etc.
3. language key should be lang to match HTML <track lang>
4. Neither kind nor (metadata) type should be required at this stage.
5. No parser warnings needed.
6. I already removed the subtitles example due to its similarity to the captions example.

Consensus of other items discussed:

7. Make key names case-sensitive; existing implementations can update.
8. In addition to colon (:) for key/value delineation, allow equals (=) for webcompat related to HLS VTT's pervasive use of X-TIMESTAMP-MAP=, but mark equals as not recommended for other use.
9. In the case of a mismatch between a standardized attribute from HTML (E.g. <track lang> vs the file's lang value), the value from HTML will prevail as source of truth. (Follow-up: We did not discuss inherited values vs explicit values though. Would an inherited :lang(en) from the document count as an override, or only a non-empty lang value on <track>?)
10. Any invalid key/value lines are ignored, but an invalid pair will not invalidate the whole block.
11. Custom keys (those not defined by the VTT spec or a registry kind->type extension spec) MUST include a hypen (-) in the name such as x-foo: bar (or data-bop: baz to match HTML)... (Follow-up: We did not discuss if a leading hyphen -foo would be okay.)

Please fill in if I've missed anything. Thanks everyone for your time today.

[cookiecrook]

I also plan to close this PR and create a new one with the rewrite because the thread is getting unmanageably long.

[gkatsev]

Thanks for the summary! Seems accurate to what was discussed.

For item 9, there's probably nothing needed on the WebVTT spec side as it'll be part of HTML or related specs.

For item 11 follow-up, might be fine to not worry if it starts with a -. The only reason I can think of requiring text at the beginning is if we wanted getAttributes() to return an object and handle it similarly to CSS where we set the keys of that object to be camelCased versions of the attribute name in the file. But, that's probably unneeded as we can return the name as a string.