New ATTRIBUTES block #523
New ATTRIBUTES block #523
Conversation
|
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. |
|
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: |
index.bs
Outdated
| NOTE | ||
| Standard subtitles (unlike CC or SDH captions) typically | ||
| translate spoken dialog or signage, but not audible sounds | ||
| effects like "dogs barking." |
There was a problem hiding this comment.
This example isn't a great place to put definitional content. The WebVTT spec does not currently distinguish between subtitles and captions and that's probably a good thing. If there's an intended linkage between the kind attribute and the HTML track element's kind attribute then that should be explicit in the spec text.
There was a problem hiding this comment.
If there's an intended linkage between the kind attribute and the HTML track element's kind attribute then that should be explicit in the spec text.
I included that in the "WebVTT attributes key/value parsing rules."
<dt>If the key name is "<code>kind</code>"</dt>
<dd>Process the value as <a href="https://html.spec.whatwg.org/multipage/media.html#attr-track-kind">the kind attribute</a> of a track element according to the HTML Standard.</dd>Did you miss the above text, or is there some additional place where you'd like it added? Thanks for clarifying.
There was a problem hiding this comment.
I may have missed it, but I can see why: that's appearing as part of §6.6 "WebVTT rules for extracting the chapter title" - shouldn't it be in its own numbered section?
Aside from that, what does "process the value as ..." mean? Does it mean that it takes precedence over the same attribute on the <track> element? Seems like we need to say something about precedence in this scenario.
There was a problem hiding this comment.
I may have missed it, but I can see why: that's appearing as part of §6.6 "WebVTT rules for extracting the chapter title" - shouldn't it be in its own numbered section?
I agree, it should be a separate section.
Aside from that, what does "process the value as ..." mean? Does it mean that it takes precedence over the same attribute on the
<track>element? Seems like we need to say something about precedence in this scenario.
I was wondering the same. Are these purely metadata or do they interact with the HTML/DOM in any way? And what is the order of precedence if both values are used? The track element wins? That might need a change in HTML?
There was a problem hiding this comment.
Section mismatch was probably due to my unfamiliarty with Bikeshed. I will correct it and look at your other question at the same time.
|
|
||
| <div class="example"> | ||
|
|
||
| <p>In this example, an optional WebVTT attributes object is used to differentiate captions from standard subtitles.</p> |
There was a problem hiding this comment.
My feeling here is that the number of examples enumerating different values of kind is unnecessary given that this specification is not defining that attribute's value set. Better to have one example and, somewhere, link the value set to its canonical definition.
There was a problem hiding this comment.
I'm not sure I understand... Are you suggesting the value parsing algo cross reference the HTML Infra values in track[kind]?
There was a problem hiding this comment.
Oh, upon re-reading, it sounds like you're suggesting the examples be removed.
FWIW, as a reader of the spec (this was my first PR to VTT), I found the pre-existing examples helpful. Perhaps others will too? The ATTRIBUTES block is defined here, so seeing how it's used with different key/value pairs seems useful to me, even if those values are defined by HTML.
There was a problem hiding this comment.
There is one of each:
- subtitle example
- caption example
- description example
- metadata example
I'd prefer to leave all 4 examples, but perhaps we can compromise on just removing the subtitle example?
There was a problem hiding this comment.
I still think there are too many but it's not a major complaint; as you say, many folk find examples an easy way into understanding the specification.
Also I just noticed that Example 14 is appearing in the Chapters section, but its about descriptions, so it seems to be misplaced.
There was a problem hiding this comment.
I tend to like a lot of examples.
Given how similar the subtitles and captions examples are, maybe we only keep one?
| <li> | ||
| The following components, in the given order: | ||
| <ol> | ||
| <li>A <a>WebVTT line terminator</a>.</li> |
There was a problem hiding this comment.
I am not sure, but this item seems to be out from this <ol>, since it divides the ATTRIBUTES line but not in key/value pairs
There was a problem hiding this comment.
I intended that as the line termination char on the same line as ATTRIBUTES
ATTRIBUTES
^
But I'd be happy to combine it with the previous line, or specify some other way at the editors' direction.
There was a problem hiding this comment.
I think we can remove a level here. So, at the top say "attributes block consists of the following components, in the given order:"
- string ATTRIBUTES
- Zero or more U+0020 SPACE characters or U+0009 CHARACTER TABULATION (tab) characters
- line terminator
- attributes block body
- line terminator
This would match the webvtt region block definition too: https://pr-preview.s3.amazonaws.com/cookiecrook/webvtt/pull/523.html#webvtt-region-definition-block https://github.com/w3c/webvtt/blob/main/index.bs#L1500-L1511
The "attributes block body" (current lines 1774-1797) could either be inline or could move into its own subsection.
|
Needs a review from the Editor, @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. 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. |
There was a problem hiding this comment.
Thanks for the work on this @cookiecrook and for your patience!
| @@ -658,6 +714,32 @@ CSS comment (e.g. <code>/**/</code>).</p> | |||
|
|
|||
| </div> | |||
|
|
|||
|
|
|||
|
|
|||
| <div class="example"> | |||
There was a problem hiding this comment.
we probably want this in a separate section on descriptions, alternatively, should move to section 1.4 Other caption and subtitling features rather than being in the chapters section.
| <li> | ||
| The following components, in the given order: | ||
| <ol> | ||
| <li>A <a>WebVTT line terminator</a>.</li> |
There was a problem hiding this comment.
I think we can remove a level here. So, at the top say "attributes block consists of the following components, in the given order:"
- string ATTRIBUTES
- Zero or more U+0020 SPACE characters or U+0009 CHARACTER TABULATION (tab) characters
- line terminator
- attributes block body
- line terminator
This would match the webvtt region block definition too: https://pr-preview.s3.amazonaws.com/cookiecrook/webvtt/pull/523.html#webvtt-region-definition-block https://github.com/w3c/webvtt/blob/main/index.bs#L1500-L1511
The "attributes block body" (current lines 1774-1797) could either be inline or could move into its own subsection.
| @@ -4130,6 +4283,30 @@ follows:</p> | |||
| </ol> | |||
|
|
|||
|
|
|||
| <p>The <dfn>WebVTT attributes key/value parsing rules</dfn> consist of the following algorithm.</p> | |||
There was a problem hiding this comment.
| <p>The <dfn>WebVTT attributes key/value parsing rules</dfn> consist of the following algorithm.</p> | |
| <h3 id=rules-for-parsing-attr-key-values algorithm>WebVTT Attributes key/value parsing rules</h3> | |
| <p>The <dfn>WebVTT attributes key/value parsing rules</dfn> consist of the following algorithm.</p> |
|
|
||
| <div class="example"> | ||
|
|
||
| <p>In this example, an optional WebVTT attributes object is used to differentiate captions from standard subtitles.</p> |
There was a problem hiding this comment.
I tend to like a lot of examples.
Given how similar the subtitles and captions examples are, maybe we only keep one?
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.
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 |
|
@gkatsev wrote:
Yes, I have taken that as an action. |
|
The Timed Text Working Group just discussed
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 |
|
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. |
|
From @eric-carlson:
All examples use the following, identical headers. Of note, WEBVTT
Styling=CEA608
Kind=Caption
Channel=CC1
00:00:00.333 --> 00:00:03.000 line:11
White text on black |
Closes #511
Add new ATTRIBUTES block parsing rules and examples as discussed in #511.
Preview | Diff