Bug 15023 - WebVTT: Add inline style support
WebVTT: 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
v1
:
: 18530 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-01 00:02 UTC by Ian 'Hixie' Hickson
Modified: 2015-04-17 08:07 UTC (History)
14 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.
Comment 22 Silvia Pfeiffer 2015-03-08 06:49:32 UTC
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.
Comment 23 Philip Jägenstedt 2015-03-09 08:24:44 UTC
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.
Comment 24 Simon Pieters 2015-03-09 09:12:21 UTC
SGTM
Comment 25 Silvia Pfeiffer 2015-03-09 11:14:53 UTC
(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.
Comment 26 Eric Carlson 2015-03-09 15:00:55 UTC
(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.
Comment 27 David Singer 2015-03-09 16:14:10 UTC
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?
Comment 28 Loretta Guarino Reid 2015-03-09 21:23:59 UTC
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?
Comment 29 Silvia Pfeiffer 2015-03-09 21:39:08 UTC
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.
Comment 30 Loretta Guarino Reid 2015-03-09 21:41:54 UTC
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.
Comment 31 Simon Pieters 2015-03-10 10:15:20 UTC
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?
Comment 32 Simon Pieters 2015-03-10 11:08:13 UTC
(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.
Comment 33 David Singer 2015-03-10 17:26:50 UTC
(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 34 Simon Pieters 2015-03-10 18:54:42 UTC
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.
Comment 35 Philip Jägenstedt 2015-03-11 09:26:11 UTC
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.
Comment 36 Simon Pieters 2015-03-11 10:20:35 UTC
(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?
Comment 37 Philip Jägenstedt 2015-03-12 06:37:23 UTC
(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?
Comment 38 Philip Jägenstedt 2015-03-12 06:42:39 UTC
(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?
Comment 39 Simon Pieters 2015-03-12 07:27:00 UTC
(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.
Comment 40 Simon Pieters 2015-03-12 07:55:47 UTC
(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.
Comment 41 Philip Jägenstedt 2015-03-12 09:11:39 UTC
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.
Comment 42 Philip Jägenstedt 2015-03-12 09:14:27 UTC
fs, do you have any good hunches about what would be easiest to implement regarding comment #39?
Comment 43 Fredrik S 2015-03-12 10:23:55 UTC
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.
Comment 44 Cyril Concolato 2015-03-12 14:45:29 UTC
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.
Comment 45 Philip Jägenstedt 2015-03-12 16:38:49 UTC
(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.
Comment 46 Philip Jägenstedt 2015-03-12 16:41:58 UTC
(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.
Comment 47 Fredrik S 2015-03-12 17:02:21 UTC
(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.
Comment 48 Silvia Pfeiffer 2015-03-13 11:35:04 UTC
(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).
Comment 49 David Singer 2015-03-13 15:09:06 UTC
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).
Comment 50 Simon Pieters 2015-03-15 08:41:02 UTC
(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.
Comment 51 Simon Pieters 2015-04-09 08:49:23 UTC
(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
Comment 52 Loretta Guarino Reid 2015-04-17 00:10:59 UTC
Have we reached consensus on this proposal?
Comment 53 Philip Jägenstedt 2015-04-17 08:07:26 UTC
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.