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.

(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 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.

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 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 &#10; 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.