This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Add the following as something that can be added to the top of WebVTT files: STYLE S::cue(v[voice=Bob]) { color: green; } S::cue(c.narration) { font-style: italic; } S::cue(c.narration i) { font-style: normal; } (Within STYLE blocks the escapes would need to be supported, so that you can include --> without triggering the cue timings line detection.) The primarily use case is non-browser players.
Moving to the TextTracks CG bug tracker, since this is mostly WebVTT specific. I also wanted to mention that we may need styling not just at the top of a WebVTT file as a default styling setting, but also some time throughout the file to change default stylings; possibly even scoped for individual cues.
We already support per-cue styling via cue IDs.
(In reply to comment #2) > We already support per-cue styling via cue IDs. That only works if you're using CSS for a WebVTT file that is referenced through a HTML page with the ::cue() selector. This bug talks about non-browser players. We don't currently have a means to provide styling for non-browser players. Inline styling as proposed would satisfy that need. Web browsers would also parse inline styling as a default styling that the author of a WebVTT file has set, but that can be overruled by the Web page.
Comment 1 and comment 3 seem like a separate issue that should be filed separately, but for what it's worth, I think that given inline styles (comment 0) and per-cue styling via cue IDs, there's not really any need for yet another styling method, even for non-browser players. (That's even assuming that non-browser players need styling, which isn't clear.)
I think we're talking past each other. I support what you want to introduce in comment0. Let's add it.
I agree with the use case, but not the syntax. The header syntax discussed on the list can be used for this, so we have a single syntax for headers going forward. Once supported, it also allows editors to round-trip future headers without having to know what they are, since the decoded header block is simply a list of key/value pairs. They can have a single code path for parsing and writing headers (instead of a special case for style), can make sure text round-trips (without warts like possibly needing to strip blank lines from stylesheets), etc.
#18530 is related.
Note that with the discussions in bug 15851 and the thread ending at http://lists.w3.org/Archives/Public/public-texttracks/2012Apr/0093.html the proposed format of this would be: Style: | ::cue(v[voice=Bob]) { color: green; } ::cue(c.narration) { font-style: italic; } ::cue(c.narration i) { font-style: normal; }
Rather, Style: | ::cue(v[voice=Bob]) { color: green; } ::cue(c.narration) { font-style: italic; } ::cue(c.narration i) { font-style: normal; } . with "." terminating the block (and some other escaping details that probably don't need to be duplicated here). (Just clarifying since in your example it looked like an RFC-822 prefix-spaces-to-continue-the-header syntax.)
Thanks, you're absolutely correct.
In converting from other formats into WebVTT, inline styles are needed to ensure that the styles needed for the cue classes will be defined in the rendering environment.
*** Bug 18530 has been marked as a duplicate of this bug. ***
http://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html proposes another way to provide styles: Style: @import(cea608.css) ## or Style: ::cue(v[voice=Bob]) { color: green; } ::cue(c.narration) { font-style: italic; } ::cue(c.narration i) { font-style: normal; } ##
Here's a new idea for dealing with newlines: convert them all to . Then we can deal with multi-line in-line styles as a metadata header.
I now think that STYLE declarations should be their own block in a VTT file - similar to how comments are their own NOTE block. That would immediately allow multi-line styles and it would allow adding them in diverse locations in VTT files. Backwards compatibility comes from the STYLE block being ignored as a broken cue.
Also, it seems easy enough to specify, so if people find it important for V1, we can move that forward.
Any plan for newlines inside the blocks? Just don't allow them?
Use something like on an otherwise empty line? It does create some weirdness, because you can't see it in an editor, but it needs to be there. But it's possible.
I think we should not support a WebVTT-layer escaping mechanism here. For including --> in CSS, there are two cases you would want to do that. First, the stylesheet might be wrapped in <!-- --> which is a no-op legacy syntax construct. Usually the --> is on its own line at the end, which means no harm done. But there might be some other CSS before --> on the same line, which would drop that line and break part of the stylesheet. The fix is to remove the --> or put it on a separate line, not to escape it. The other reason is to use --> in a CSS string. There is no reason to prefer WebVTT-layer escaping over CSS-layer escaping for this, so just use CSS's escaping mechanism, --\>. I don't see what solves. It seems to just complicate things without fixing anything. It doesn't let you paste a stylesheet with blank lines without modification. If you think modification is OK, why is it not OK to remove the blank lines or fill them with a space or /**/? Having something special represent a newline means you also have to introduce an escaping mechanism if you want to use that sequence of characters literally, which means you require another round of modification to make sure things are escaped properly. Since CSS has an escaping mechanism of its own, this seems like it would be quite a headache to maintain. I think we should either (1) not allow blank lines at all, or (2) come up with something that lets you paste a stylesheet with blank lines without modification. In either case I think supporting an escaping mechanism is bad. As for (2), I would be OK with making "-->" denote multiline start and end. This makes it robust against forgetting the end marker, since we already start a new cue when seeing it. STYLE --> S::cue(v[voice=Bob]) { color: green; } S::cue(c.narration) { font-style: italic; } S::cue(c.narration i) { font-style: normal; } --> Possibly we could use --> for single-line metadata as well, so that they can break out of an unclosed multiline block also. STYLE --> @import url(foo); STYLE --> @import url(bar);
(In reply to Silvia Pfeiffer from comment #15) > I now think that STYLE declarations should be their own block in a VTT file > - similar to how comments are their own NOTE block. That would immediately > allow multi-line styles and it would allow adding them in diverse locations > in VTT files. Backwards compatibility comes from the STYLE block being > ignored as a broken cue. I really don't. Currently VTT files are random-accessible; having styles at arbitrary places that can persist to the end would badly impact that.
Thanks Simon, I think I agree with you about not introducing new escape syntax. I would be quite content with not allowing blank lines at all, although the STYLE --> ... --> syntax is an interesting idea.
I think we should just not allow blank lines in STYLE blocks. Also, I think we should simply disallow "-->" in a STYLE block, just like we have excluded it in a NOTE block. If somebody needs those in the VTT file, they can always create an external stylesheet and use @import(sheet.css) within a STYLE block.
That would work for me, as long as it's invalid to have no blank line between a style block and a cue so that --> in style reliably results in a warning in a validator.
SGTM
(In reply to Philip Jägenstedt from comment #23) > That would work for me, as long as it's invalid to have no blank line > between a style block and a cue so that --> in style reliably results in a > warning in a validator. WFM.
(In reply to Philip Jägenstedt from comment #23) > That would work for me, as long as it's invalid to have no blank line > between a style block and a cue so that --> in style reliably results in a > warning in a validator. This sounds fine to me as well.
sgtm too. summary, as I understand: styke block(s) after the header and before the first cue; no blank lines in them; somewhere I assume we'll have a place to optionally identify the style type (text/css if not specified), following HTML; must be a blank line before the next block (this is true of all blocks, does it need saying?); note external style sheets can be used by using an import rule here; note that styling is formally optional for the player... anything else?
SGTM (In reply to David Singer from comment #27) > sgtm too. > > summary, as I understand: styke block(s) after the header and before the > first cue; no blank lines in them; somewhere I assume we'll have a place to > optionally identify the style type (text/css if not specified), following > HTML; must be a blank line before the next block (this is true of all > blocks, does it need saying?); note external style sheets can be used by > using an import rule here; note that styling is formally optional for the > player... > > anything else?
I'd allow only CSS for now. Also: if you are keen to have this in v1, please speak up now, since we want to move to CR in the TTWG asap.
I'm keen to have this in v1. (In reply to Silvia Pfeiffer from comment #29) > I'd allow only CSS for now. > > Also: if you are keen to have this in v1, please speak up now, since we want > to move to CR in the TTWG asap.
Concrete proposal for spec text. Example: WEBVTT STYLE ::cue(#hello) { color:lime } /* Style blocks cannot use blank lines nor "dash dash greater than" */ NOTE comment blocks can be used between style blocks. Style blocks can have an optional type:text/css setting. STYLE type:text/css @import url(foo.css); hello 00:00:00.000 --> 00:00:10.000 Hello world. NOTE style blocks cannot appear after the first cue. Syntax: A *WebVTT file body* consists of the following components, in the following order: (before the cue blocks) 7. Zero or more WebVTT style blocks and WebVTT comment blocks separated from each other by one or more WebVTT line terminators. 8. Zero or more WebVTT line terminators. A *WebVTT style block* consists of the following components, in the given order: 1. The string "STYLE". 2. Optionally, one or more U+0020 SPACE characters or U+0009 CHARACTER TABULATION (tab) characters, followed by a WebVTT style block settings list. 3. A WebVTT line terminator. 4. Any sequence of zero or more characters other than U+000A LINE FEED (LF) characters and U+000D CARRIAGE RETURN (CR) characters, each optionally separated from the next by a WebVTT line terminator, except that the entire resulting string must not contain the substring "-->" (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN), and must also be valid a CSS stylesheet. [CSS] 5. A WebVTT line terminator. A WebVTT style block settings list consist of a sequence of zero or more WebVTT cue settings in any order, separated from each other by one or more U+0020 SPACE characters or U+0009 CHARACTER TABULATION (tab) characters. Each setting consists of the following components, in the order given: 1. A WebVTT style block setting name. 2. Optionally: 1. A U+003A COLON (colon) character. 2. A WebVTT style block setting value. A WebVTT style block setting name and a WebVTT style block setting value each consist of any sequence of zero or more characters other than U+000A LINE FEED (LF) characters and U+000D CARRIAGE RETURN (CR) characters except that the entire resulting string must not contain the substring "-->" (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN). A WebVTT style block settings list consists of zero or more of the following settings. Each setting must not be included more than once per WebVTT style block. * A WebVTT type style block setting. A WebVTT type style block setting is a WebVTT style block setting that consists of the following components, in the givne order: 1. The string "type" as the WebVTT style block setting name. 2. A U+003A COLON character (:). 3. A string that is an ASCII-case insensitive match for the string "text/css" as the WebVTT style block setting value. Parsing: (right before /Cue loop/) 17. /Style block loop/: _Collect a sequence of characters_ that are U+000A LINE FEED (LF) characters. 18. _Collect a sequence of characters_ that are not U+000A LINE FEED (LF) characters. Let /line/ be those characters, if any. 19. If /line/ is the empty string, then jump to the step labeled /end/. (In such a case, /position/ is also forcibly past the end of /input/.) 20. If /line/ contains the three-character substring "-->" (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN), then set the /already collected line/ flag and jump to the step labeled /cue loop/. 21. _Collect a WebVTT style block settings_ from line. If that fails, jump to the step labeled /bad style block/. 22. Let /stylesheet/ be the result of _creating a CSS style sheet_, with the following properties: [CSSOM] location null parent CSS style sheet null owner node null owner CSS rule null media The empty string title The empty string alternate flag Unset. origin-clean flag Set. 23. Let /style data/ be the empty string. 24. /Style block data loop/: If /position/ is past the end of /input/, then jump to the step labeled /style block data processing/. 25. If the character indicated by position is a U+000A LINE FEED (LF) character, advance /position/ to the next character in /input/. 26. Collect a sequence of characters that are not U+000A LINE FEED (LF) characters. Let /line/ be those characters, if any. 27. If /line/ is the empty string, then jump to the step labeled /style block data processing/. 28. If /line/ contains the three-character substring "-->" (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN), then set the /already collected line/ flag and jump to the step labeled /style block data processing/. 29. If /style block data/ is not empty, append a U+000A LINE FEED (LF) character to /style block data/. 30. Let /style block data/ be the concatenation of /style block data/ and /line/. 31. Return to the step labeled /style block data loop/. 32. Style block data processing: Let /stylesheet/'s _CSS rules_ be the result of invoking _parse a stylesheet_ of /style block data/. [CSSOM] [CSS3SYN] 33. Jump back to the step labeled /style block loop/. 34. /Bad style block/: Discard /stylesheet/. 35. /Bad style block loop/: If /position/ is past the end of /input/, then jump to the step labeled /end/. 36. If the character indicated by /position/ is a U+000A LINE FEED (LF) character, advance /position/ to the next character in /input/. 37. _Collect a sequence of characters_ that are not U+000A LINE FEED (LF) characters. Let /line/ be those characters, if any. 38. If /line/ contains the three-character substring "-->" (U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN), then set the /already collected line/ flag and jump to the step labeled /cue loop/. 39. If /line/ is the empty string, then jump to the step labeled /style block loop/. 40. Otherwise, jump to the step labeled /bad style block loop/. To *collect a WebVTT style block settings* from a string /input/, the user agent must run the following algorithm: 1. Let /input/ be the string being parsed. 2. Let /position/ be a pointer into /input/, initially pointing at the start of the string. 3. _Collect a sequence of characters_ that are not U+0020 SPACE characters or U+0009 TABULATION CHARACTER (tab) characters, and let /block name/ be those characters, if any. 4. If /block name/ is not the string "STYLE", abort these steps and return failure. 5. If /position/ is past the end of /input/, abort these steps. 6. _Skip whitespace_. 7. Let /remainder/ be the trailing substring of /input/ starting at /position/. 8. Let /settings/ be the result of _splitting /remainder/ on spaces_. 9. For each token /setting/ in the list /settings/, run the following substeps: 1. If /setting/ does not contain a U+003A COLON character (:), or if the first U+003A COLON character (:) in /setting/ is either the first or last character of /setting/, then jump to the step labeled /next setting/. 2. Let /name/ be the leading substring of /setting/ up to and excluding the first U+003A COLON character (:) in that string. 3. Let /value/ be the trailing substring of /setting/ starting from the character immediately after the first U+003A COLON character (:) in that string. 4. Run the appropriate substeps that apply for the value of /name/, as follows: If /name/ is a case-sensitive match for "type" 1. If /value/ is not an _ASCII case-insensitive_ match for the string "text/css", abort these steps and return failure. 10. /Next setting/: Continue to the next token, if any. Processing model: For the purpose of selectors in STYLE blocks of a WebVTT file, the style sheet must apply to a hypothetical document that contains a single empty element with no explicit name, no namespace, no attributes, no classes, no IDs, and unknown primary language, that acts like the _media element_ for the _text tracks_ that were sourced from the given WebVTT file. The selectors must not match other _text tracks_ for the same _media element_. For the purpose of resolving URLs in the style sheet, the style sheet must act as if its base URL is the same as the WebVTT file that contains it. (For out-of-band text tracks, this is the _track URL_. For in-band text tracks, this is the URL of the containing _media resource_. Text tracks created with addTextTrack() cannot have style sheets.) Issue: Should the style sheet's critical subresources (e.g. @import) block the <track> load event? What about in-band text tracks? Issue: Should we expose the CSSOM API? Issue: Do we want these styles to be before or after the containing page's styles in the cascade?
(In reply to Simon Pieters from comment #31) > For the purpose of resolving URLs in the style sheet, the style sheet must > act as if its base URL is the same as the WebVTT file that contains it. (For > out-of-band text tracks, this is the _track URL_. For in-band text tracks, > this is the URL of the containing _media resource_. Text tracks created with > addTextTrack() cannot have style sheets.) Actually _track URL_ is before redirects. I suppose we want the base URL to be after any redirects.
(In reply to Silvia Pfeiffer from comment #29) > I'd allow only CSS for now. > I agree, but I think we should document that the type follows the STYLE tag and must be either explicitly text/css or be that by default. > Also: if you are keen to have this in v1, please speak up now, since we want > to move to CR in the TTWG asap. I think this is good to have.
Comment 31 supports only CSS but allows specifying type:text/css and any other type makes the block be ignored so it is possible to support new types in the future without having legacy client try to parse it as CSS.
Thank you Simon, I have turned comment #31 into spec text: https://github.com/w3c/webvtt/pull/185 There are a few things I think should change: 1. I don't think we should have a type setting either in the syntax or in the parser, this adds a lot of boilerplate for no real gain that I can tell. 2. The integration with CSS parsing seems wrong: http://dev.w3.org/csswg/css-syntax/#parse-a-stylesheet returns a stylesheet, not rules to attach to an existing stylesheet. Did I find the wrong thing? 3. I can't find a definition of what a valid CSS style sheet is. HTML extracts some bits of ABNF for the <style> element definition :/ 4. The processing model seems difficult to implement. All cues from all tracks end up in the same container (since they must avoid overlapping each other) and it would be nice if this could internally be implemented by inserting a <style> element with the relevant style into the shadow DOM that contains all the cues. I don't know how to isolate the style to individual tracks, maybe one container per track but that makes the overlap avoidance slightly uglier.
(In reply to Philip Jägenstedt from comment #35) > Thank you Simon, I have turned comment #31 into spec text: > https://github.com/w3c/webvtt/pull/185 > > There are a few things I think should change: > > 1. I don't think we should have a type setting either in the syntax or in > the parser, this adds a lot of boilerplate for no real gain that I can tell. I'm happy to drop it. It would just mean that, if we ever want to support a different styling language in the future, then either we introduce a new block type or we let legacy clients try to parse it as CSS. Alternatively we could require that the line matches /^STYLE\s*$/, so that if we introduce settings in the future, legacy clients will drop the block. > 2. The integration with CSS parsing seems wrong: > http://dev.w3.org/csswg/css-syntax/#parse-a-stylesheet returns a stylesheet, > not rules to attach to an existing stylesheet. Did I find the wrong thing? You're right. This is a bit messy at the moment and <style> just glosses over it completely. I'll need to fix this in CSSOM to say what you're supposed to do. For now, have an issue saying "Magic happens here". > 3. I can't find a definition of what a valid CSS style sheet is. HTML > extracts some bits of ABNF for the <style> element definition :/ The ABNF for <style> is for a different purpose, not relevant for us. As far as I can tell, HTML doesn't require the content of <style> to be valid CSS. I think we can say that the string represents a CSS stylesheet, and so the requirements in the CSS specs apply. > 4. The processing model seems difficult to implement. All cues from all > tracks end up in the same container (since they must avoid overlapping each > other) and it would be nice if this could internally be implemented by > inserting a <style> element with the relevant style into the shadow DOM that > contains all the cues. I don't know how to isolate the style to individual > tracks, maybe one container per track but that makes the overlap avoidance > slightly uglier. OK. I assumed that it was desireable that styles in one file did not leak into another, should two tracks be enabled for one media element. Is leaking styles between tracks OK?
(In reply to Simon Pieters from comment #36) > OK. I assumed that it was desireable that styles in one file did not leak > into another, should two tracks be enabled for one media element. > > Is leaking styles between tracks OK? No, I don't think it is OK, but I'm not sure how to spec or implement it. I can see two models: 1. Every cue in a track and the style rules for that track get some internal unique ID so that the rules cannot match anything else. Your spec text could presumably be implemented like this. 2. Every track gets has a separate container and style, something equivalent to a shadow DOM with a <style> inserted since that seems easy to implement. This would make the overlap handling slightly more complicated as you would have to check for overlap in sibling containers. Other ideas?
(In reply to Simon Pieters from comment #36) > (In reply to Philip Jägenstedt from comment #35) > > Thank you Simon, I have turned comment #31 into spec text: > > https://github.com/w3c/webvtt/pull/185 > > > > There are a few things I think should change: > > > > 1. I don't think we should have a type setting either in the syntax or in > > the parser, this adds a lot of boilerplate for no real gain that I can tell. > > I'm happy to drop it. It would just mean that, if we ever want to support a > different styling language in the future, then either we introduce a new > block type or we let legacy clients try to parse it as CSS. How seriously should we take the possibility of a new styling language? If the odds are very low, simply accepting the possibility of a NEWSTYLE block seems OK to me. > Alternatively we could require that the line matches /^STYLE\s*$/, so that > if we introduce settings in the future, legacy clients will drop the block. I think that would be acceptable, even though it means we cannot add any settings that can safely be ignored by existing parsers. Alternatively, I think it would be somewhat neat if one-line style like STYLE ::cue { color: red; } is allowed, like the NOTE syntax. Bad idea?
(In reply to Philip Jägenstedt from comment #37) > No, I don't think it is OK, Yeah, so we'll have to bite the bullet. :-) > but I'm not sure how to spec or implement it. I > can see two models: > > 1. Every cue in a track and the style rules for that track get some internal > unique ID so that the rules cannot match anything else. Your spec text could > presumably be implemented like this. Something like this was what I had in mind. It means more memory, but you only have to do it when two or more tracks are enabled at the same time, which probably doesn't happen very often. > 2. Every track gets has a separate container and style, something equivalent > to a shadow DOM with a <style> inserted since that seems easy to implement. > This would make the overlap handling slightly more complicated as you would > have to check for overlap in sibling containers. I suppose this could work also. Note that the processing model in my proposal means that e.g. the following selector should match: :root::cue { ... } but not this: video::cue { ... } > Other ideas? Not right now at least.
(In reply to Philip Jägenstedt from comment #38) > How seriously should we take the possibility of a new styling language? If > the odds are very low, simply accepting the possibility of a NEWSTYLE block > seems OK to me. It hasn't happened so far. It seems more likely to me that something replaces WebVTT than CSS, but it is possible of course. I think we don't have to complicate the parsing to optimize for only this. If we add settings for other reasons in the future, we can add a type setting at that time. > > Alternatively we could require that the line matches /^STYLE\s*$/, so that > > if we introduce settings in the future, legacy clients will drop the block. > > I think that would be acceptable, even though it means we cannot add any > settings that can safely be ignored by existing parsers. Let's consider existing features for <style> and see what is the desired behavior for legacy clients (drop or apply): type: drop title (alternative stylesheet): drop media: drop scoped: N/A It seems to me it is better to drop the block. > Alternatively, I think it would be somewhat neat if one-line style like > > STYLE ::cue { color: red; } > > is allowed, like the NOTE syntax. Bad idea? I think it is more useful to reserve the space for future settings.
Thanks Simon, (In reply to Simon Pieters from comment #40) > I think it is more useful to reserve the space for future settings. OK, that seems reasonable and not much of a sacrifice.
fs, do you have any good hunches about what would be easiest to implement regarding comment #39?
Not sure I have any great hunches. 1.) Seems to imply more complications with RuleSet-handling/setup and matching 2.) Will need more work to get the "cue ordering" (cues interspersed between different subtrees structurally) right, and hence more complications during layout. If we manage to come up with a good formulation for (1), that sounds like it would be less work. Spontaneously.
I think for streaming use cases, we want to be able to define styles at the cue level, and as David said, only valid for that cue (for easy Random Access) . I'm not sure about the syntax/parsing constraints. It could be done as new WebVTT cue settings: 00:00:00.000 --> 00:00:10.000 color:yellow Hello world.
(In reply to Fredrik S from comment #43) > 2.) Will need more work to get the "cue ordering" (cues interspersed between > different subtrees structurally) right, and hence more complications during > layout. Do you think it would help at all if during layout the cues are grouped by track first and not simply sorted by start and end time? This is a change in behavior, but it ought to make it easier to handle one group at a time and build up a list of "other rects" to avoid overlap with. Not exactly elegant of course.
(In reply to Cyril Concolato from comment #44) > I think for streaming use cases, we want to be able to define styles at the > cue level, and as David said, only valid for that cue (for easy Random > Access) . I'm not sure about the syntax/parsing constraints. It could be > done as new WebVTT cue settings: > > 00:00:00.000 --> 00:00:10.000 color:yellow > Hello world. Would it be sufficient to allow new STYLE blocks at any point? Then you can target any cue you want by ID. Note that we haven't spec'd or implemented streaming WebVTT yet, but we should avoid creating a situation where we can't do it sensibly in the future.
(In reply to Philip Jägenstedt from comment #45) > (In reply to Fredrik S from comment #43) > > 2.) Will need more work to get the "cue ordering" (cues interspersed between > > different subtrees structurally) right, and hence more complications during > > layout. > > Do you think it would help at all if during layout the cues are grouped by > track first and not simply sorted by start and end time? This is a change in > behavior, but it ought to make it easier to handle one group at a time and > build up a list of "other rects" to avoid overlap with. Not exactly elegant > of course. That would probably help, yes.
(In reply to Philip Jägenstedt from comment #46) > (In reply to Cyril Concolato from comment #44) > > I think for streaming use cases, we want to be able to define styles at the > > cue level, and as David said, only valid for that cue (for easy Random > > Access) . I'm not sure about the syntax/parsing constraints. It could be > > done as new WebVTT cue settings: > > > > 00:00:00.000 --> 00:00:10.000 color:yellow > > Hello world. > > Would it be sufficient to allow new STYLE blocks at any point? Then you can > target any cue you want by ID. David / Apple have explicitly asked to avoid this, because then you remove the ability for random access in a non-live file. Instead, he suggested that for the live case (as is e.g. the case with HLS) you get complete WebVTT files associated with blocks of media and thus you would just have the STYLE block for the cues in that file in it. That is how live streaming with WebVTT is currently done and wouldn't break it. > Note that we haven't spec'd or implemented streaming WebVTT yet, but we > should avoid creating a situation where we can't do it sensibly in the > future. We haven't but it has been used in live streaming scenarios using HTTP adaptive streaming (HLS or DASH).
On Mar 12, 2015, at 9:41 , bugzilla@jessica.w3.org wrote: --- Comment #46 from Philip Jägenstedt <philipj@opera.com> --- Would it be sufficient to allow new STYLE blocks at any point? Then you can target any cue you want by ID. only if a STYLE block inline is scoped only to the next cue. But that’s error-prone. I think Cyril’s idea is better, if it can be worked. On Mar 11, 2015, at 23:42 , bugzilla@jessica.w3.org wrote: --- Comment #38 from Philip Jägenstedt <philipj@opera.com> --- (In reply to Simon Pieters from comment #36) (In reply to Philip Jägenstedt from comment #35) There are a few things I think should change: 1. I don't think we should have a type setting either in the syntax or in the parser, this adds a lot of boilerplate for no real gain that I can tell. I'm happy to drop it. It would just mean that, if we ever want to support a different styling language in the future, then either we introduce a new block type or we let legacy clients try to parse it as CSS. How seriously should we take the possibility of a new styling language? If the odds are very low, simply accepting the possibility of a NEWSTYLE block seems OK to me. well, how hard is it to default to text/css or parse type:text/css as the only permitted option for now? we could also say that the type: attribute may be defined in future, with value text/css, and parsers should notice it then, but mandate it not be present when the type is text/css, but that seems asking for trouble (parsers don’t get training wheels).
(In reply to David Singer from comment #49) > well, how hard is it to default to text/css or parse type:text/css as the > only permitted option for now? See comment 31. > we could also say that the type: attribute may be defined in future, with > value text/css, and parsers should notice it then, but mandate it not be > present when the type is text/css, but that seems asking for trouble > (parsers don’t get training wheels). I'm not sure I follow what you are saying. But the suggestion in comment 36 gives us both simplicity now and ability to extend in the future: (In reply to Simon Pieters from comment #36) > Alternatively we could require that the line matches /^STYLE\s*$/, so that > if we introduce settings in the future, legacy clients will drop the block.
(In reply to Simon Pieters from comment #31) > For the purpose of selectors in STYLE blocks of a WebVTT file, the style > sheet must apply to a hypothetical document that contains a single empty > element with no explicit name, no namespace, no attributes, no classes, no > IDs, and unknown primary language, that acts like the _media element_ for > the _text tracks_ that were sourced from the given WebVTT file. The > selectors must not match other _text tracks_ for the same _media element_. This element can now be described as "featureless" that can only be matched when using ::cue, ::cue() and ::cue-region. http://dev.w3.org/csswg/selectors-4/#featureless
Have we reached consensus on this proposal?
There are still plenty of details to iron out, and anything we spec would likely need to be changed in response to further implementor feedback, but the broad strokes of the proposal don't seem controversial.
To move forward, I've tried to summarize the discussion. I gather we agree to add the following to the patch prepared at https://github.com/w3c/webvtt/pull/185 : * remove the type setting on STYLE blocks and mention that STYLE is only for text/css styles * disallow anything after the "STYLE" string, i.e. drop the STYLE block if there's anything behind it * s/must also be a <a>valid CSS stylesheet</a>./represents a CSS stylesheet./ (?) * Every cue in a track and the style rules for that track get some internal unique ID so that the rules can only match for the specific track. * introduce reference to "featureless element" in patch, second-last paragraph
(In reply to Silvia Pfeiffer from comment #54) > To move forward, I've tried to summarize the discussion. > I gather we agree to add the following to the patch prepared at > https://github.com/w3c/webvtt/pull/185 : > > * remove the type setting on STYLE blocks and mention that STYLE is only for > text/css styles > > * disallow anything after the "STYLE" string, i.e. drop the STYLE block if > there's anything behind it > > * s/must also be a <a>valid CSS stylesheet</a>./represents a CSS > stylesheet./ (?) Sounds good. > * Every cue in a track and the style rules for that track get some internal > unique ID so that the rules can only match for the specific track. > > * introduce reference to "featureless element" in patch, second-last > paragraph Something like this, yeah. I suspect we won't know what really works here until someone tries to implement it. I think adding an invisible ID to every rule sourced from a STYLE block could be tricky to implement or amount to a WebVTT-specific hack inside of the CSS code, but I'm not sure. If this doesn't work out, having separate containers for separate tracks is an alternative, it just complicates overlap avoidance somewhat. Finally, I don't think it should be the parsers job to ensure that STYLE is ignored after any cue. I would prefer to write the spec in such a way that this restriction is an artificial-looking one-liner in the shape of |if (track.cues.length > 0) return;| in the code that's invoked when a STYLE block is encountered. This will make it easier to remove this restriction, which I think we'll want to.
Works for me. I'll review whichever solution you thinks is best. Also, I highly doubt it will be ready for CR, so likely will be in v2, but it's worth giving it a shot.
(In reply to Philip Jägenstedt from comment #55) > > * remove the type setting on STYLE blocks and mention that STYLE is only for > > text/css styles I guess this is taste. My temptation would be to say that the default and only allowed value now is text/css (but you should notice anything else there). > Finally, I don't think it should be the parsers job to ensure that STYLE is > ignored after any cue. I would prefer to write the spec in such a way that > this restriction is an artificial-looking one-liner in the shape of |if > (track.cues.length > 0) return;| in the code that's invoked when a STYLE > block is encountered. This will make it easier to remove this restriction, > which I think we'll want to. I guess I hope we don't, but we're good for now. :-) The big question is: do we put it in the CR and mark as at-risk (since wide review comments asked for it, but it's not implemented) or not put it in, and go for a V2 soon? Putting it in means re-asking for review from at least accessibility and CSS.
(In reply to David Singer from comment #57) > The big question is: do we put it in the CR and mark as at-risk (since wide > review comments asked for it, but it's not implemented) or not put it in, > and go for a V2 soon? Putting it in means re-asking for review from at least > accessibility and CSS. I have no position on this, as v1 or v2 doesn't make any difference to implementors. Whatever is the least work in the Rec. process, I'd say.
(In reply to David Singer from comment #57) > The big question is: do we put it in the CR and mark as at-risk (since wide > review comments asked for it, but it's not implemented) or not put it in, > and go for a V2 soon? Putting it in means re-asking for review from at least > accessibility and CSS. Loretta wanted to see it in. I think there's some argument about that making it higher priority for implementation. Also, I think you'll find that with all the changes that we've made, we'll have to do another WD anyway - that's how I interpreted Thierry's feedback.
The PR has now moved to https://github.com/w3c/webvtt/pull/219 I have addressed the comments in this bug. Please review.