Bug 15023 - WebVTT v2: Add inline style support
WebVTT v2: Add inline style support
Status: NEW
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT
unspecified
PC Windows 3.1
: P1 enhancement
: ---
Assigned To: Silvia Pfeiffer
This bug has no owner yet - up for the taking
v2
:
: 18530 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-01 00:02 UTC by Ian 'Hixie' Hickson
Modified: 2015-02-25 04:39 UTC (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian 'Hixie' Hickson 2011-12-01 00:02:51 UTC
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.
Comment 1 Silvia Pfeiffer 2012-01-20 02:27:01 UTC
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.
Comment 2 Ian 'Hixie' Hickson 2012-01-25 23:27:19 UTC
We already support per-cue styling via cue IDs.
Comment 3 Silvia Pfeiffer 2012-01-26 05:24:35 UTC
(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 4 Ian 'Hixie' Hickson 2012-07-24 04:38:50 UTC
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.)
Comment 5 Silvia Pfeiffer 2012-07-25 04:11:17 UTC
I think we're talking past each other. I support what you want to introduce in comment0. Let's add it.
Comment 6 Glenn Maynard 2012-08-10 14:11:00 UTC
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.
Comment 7 Glenn Maynard 2012-08-10 18:36:24 UTC
#18530 is related.
Comment 8 Silvia Pfeiffer 2012-08-28 00:03:59 UTC
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; }
Comment 9 Glenn Maynard 2012-08-28 00:28:34 UTC
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.)
Comment 10 Silvia Pfeiffer 2012-08-28 03:56:58 UTC
Thanks, you're absolutely correct.
Comment 11 Loretta Guarino Reid 2012-08-30 01:31:36 UTC
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.
Comment 12 Ian 'Hixie' Hickson 2012-08-30 17:02:31 UTC
*** Bug 18530 has been marked as a duplicate of this bug. ***
Comment 13 Silvia Pfeiffer 2012-10-24 03:01:42 UTC
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; }
##
Comment 14 Silvia Pfeiffer 2013-09-16 07:38:40 UTC
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.
Comment 15 Silvia Pfeiffer 2015-02-22 06:55:03 UTC
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.
Comment 16 Silvia Pfeiffer 2015-02-22 06:58:16 UTC
Also, it seems easy enough to specify, so if people find it important for V1, we can move that forward.
Comment 17 Philip Jägenstedt 2015-02-23 02:55:41 UTC
Any plan for newlines inside the blocks? Just don't allow them?
Comment 18 Silvia Pfeiffer 2015-02-23 04:19:50 UTC
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.
Comment 19 Simon Pieters 2015-02-23 13:45:27 UTC
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);
Comment 20 David Singer 2015-02-23 19:39:24 UTC
(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.
Comment 21 Philip Jägenstedt 2015-02-25 04:39:40 UTC
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.