Have tags for specifying color and background color

[zcorpan]

See https://github.com/w3c/webvtt/pull/261#issuecomment-158187662

Again I suppose this would be needed on the cue level as well as on the element level, if it should be possible to override the default background color.

I don't particularly like adding new elements for color, it seems like it would be better to be able to set colors on any element, like you can set classes on any element.

We could allow color specifiers at the end of start tags, as annotations. For elements that already require annotations, we could make a "#" switch from annotation to color. (It would be possible to write stylesheets that work in legacy clients using ^= attribute selector, e.g. v[voice^=Roger].)

WEBVTT

00:00:00.000 --> 00:00:10.000.foo.bar align:left #FFF #000
<v.foo.bar Roger #FFF #000>Hello

The cue itself has classes "foo" and "bar", color "#FFF", background color "#000". The v element has the same classes, annotation "Roger", same colors.

To support non-opaque colors, we can use hex annotation with 4 or 8 characters (this is supported in CSS now, per spec at least). e.g. fully transparent black is #0000 or #00000000. https://drafts.csswg.org/css-color/#hex-notation

The colors specified this way would be overridable with CSS, so it's like HTML <font color>, not like style="...".

[andreastai]

That's a reasonable proposal and I would support that (also to have a notation that enables transparency at least for background colors). Do you expect that color and background color would always be specified as pair? Would work for me...

[zcorpan]

I was thinking that you could specify color only, or both.

[dwsinger]

On Nov 19, 2015, at 14:16 , Simon Pieters notifications@github.com wrote:

See #261 (comment)

Again I suppose this would be needed on the cue level as well as on the element level, if it should be possible to override the default background color.

I don't particularly like adding new elements for color, it seems like it would be better to be able to set colors on any element, like you can set classes on any element.

I think I am more comfortable using classes than with changing syntax.

As I said, I think we may be able to achieve what we want by saying that CSS-incapable UAs must nonetheless support a bare minimum of classes that give a bare minimum of functionality, notably coloring.

David Singer Manager, Software Standards, Apple Inc.

[silviapfeiffer]

I think I agree with David: classes are sufficient to capture all use cases. We don't have to also introduce color as an annotation and color as a cue setting. Note also that cue settings and annotations don't have an inherent order, so if you're using order to determine foreground from background color, that will massively complicate your cue settings and cue annotations syntax and parsing.

I'm warming to the idea of setting classes on whole cues - that will help with the ability to format a group of cues in one go, since right now we only have the ID concept on cues. It does look strange with the dot directly following the end time, but I think I can get used to it.

[zcorpan]

It wouldn't massively complicate settings parsing. Settings are parsed one after the other, with a last valid one wins behavior. It wouldn't be hard to make the first color set color and the second one set background color, and ignore further colors.

[zcorpan]

If you could provide reasons for your preferences, that would be helpful. Just saying "I prefer X" doesn't help me understand which is the best technical solution.

I think it is a bad idea to have different default behavior for CSS-incapable UAs and CSS-capable ones, because it makes it harder for a UA to add support for CSS, and it creates two sets of content -- one that assumes CSS-incapable UAs and one that assumes CSS-capable UAs.

[dwsinger]

On Nov 22, 2015, at 5:15 , Simon Pieters notifications@github.com wrote:

If you could provide reasons for your preferences, that would be helpful. Just saying "I prefer X" doesn't help me understand which is the best technical solution.

I think it is a bad idea to have different default behavior for CSS-incapable UAs and CSS-capable ones, because it makes it harder for a UA to add support for CSS, and it creates two sets of content -- one that assumes CSS-incapable UAs and one that assumes CSS-capable UAs.

Exactly. I think that was one reason to prefer the “as if the following stylesheet(s) were available” approach — the authoring doesn’t change.

David Singer Manager, Software Standards, Apple Inc.

[andreastai]

I am not sure how to read Simon's comment. For me to have CSS classes as they were defined for CSS-incapable UA leads to inconsistencies. Even if the CSS capable UA would behave the same they would still have to check first if a predefined class name is overwritten by in-document styles or a style sheet in a HTML page where VTT is embedded. This use of CSS seems to me like a CSS hack and I haven´t seen it in another standard.

A solution like this can have two consequences (especially if a content provider wants to reach also CSS-incapable User Agents): either you make two different VTT files (as Simon mentioned) or you prepare one VTT file that uses only the colors of the "pre-defined" stylesheet.

Apart from the benefit to not change authoring: are there any other reasons to limit the color range?

[zcorpan]

Even if the CSS capable UA would behave the same they would still have to check first if a predefined class name is overwritten by in-document styles or a style sheet in a HTML page where VTT is embedded. This use of CSS seems to me like a CSS hack and I haven´t seen it in another standard.

It's technically no different from the UA default stylesheet that both HTML and WebVTT already have for their elements. For example, <i> has the default style font-style: italic. Author-level CSS can override it.

[silviapfeiffer]

@tairt Adding CSS classes doesn't mean that we limit the color range. It just provides defaults and settings to choose.

[foolip]

Is it a premise here that we care about making it easier for CSS-incapable UAs to implement the spec? If it adds no burden at all for browser engines that's fine, but I'm quite skeptical of adding things that only benefit CSS-incapable UAs, unless the problem is severe and these UAs represent a significant part of the WebVTT ecosystem.

[lorettaguarino]

I would like WebVTT to be the only caption format an author needs to provide. Videos will be shown on non-browser devices like televisions where full CSS support will be a heavy burden. So I think it important that we have a solution to providing at least the accessibility-critical styling for those UAs.

On Mon, Nov 23, 2015 at 7:11 AM, Philip Jägenstedt <notifications@github.com

wrote:

Is it a premise here that we care about making it easier for CSS-incapable UAs to implement the spec? If it adds no burden at all for browser engines that's fine, but I'm quite skeptical of adding things that only benefit CSS-incapable UAs, unless the problem is severe and these UAs represent a significant part of the WebVTT ecosystem.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webvtt/issues/272#issuecomment-158963954.

[foolip]

Are those non-browser devices using independent implementations of WebVTT, and are their implementors participating in WebVTT standardization? All I know of is Chromecast and Apple TV, and at least Chromecast is based on Chromium, and I'm guessing that Apple TV uses WebKit for its WebVTT support.

[lorettaguarino]

There are devices with their own implementations. I doubt that their implementors are participating in WebVTT standardization. Let me see whether I can get in touch with any of them.

On Mon, Nov 23, 2015 at 7:53 AM, Philip Jägenstedt <notifications@github.com

wrote:

Are those non-browser devices using independent implementations of WebVTT, and are their implementors participating in WebVTT standardization? All I know of is Chromecast and Apple TV, and at least Chromecast is based on Chromium, and I'm guessing that Apple TV uses WebKit for its WebVTT support.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webvtt/issues/272#issuecomment-158976252.

[nigelmegitt]

I would like WebVTT to be the only caption format an author needs to provide. Videos will be shown on non-browser devices like televisions where full CSS support will be a heavy burden.

@lorettaguarino There's no realistic prospect of this ever happening. In the past year or two there have been several ratified TV standards (e.g. DVB DASH profile, HbbTV 2.0, Freeview Play, ARD Mediathek Portals...) that don't include WebVTT. Any authors needing to target platforms that adopt them will have to create something other than WebVTT.

Having said that, I agree that the same WebVTT subtitle/caption resource should work equally well on WebVTT supporting platforms that do support CSS as those that do not.

[zcorpan]

Since WebVTT limits what can be done, a WebVTT UA would not need to have "full" CSS support. It would need to implement css-syntax, css-cascade, selectors, and the properties mentioned in the WebVTT spec (or only those that the UA wishes to support).

I am slightly worried that, even if we add colors as proposed here, it's not going to be enough (is font-size needed? font-family? text-shadow?), which seems like a slippery slope towards reinventing CSS.

[foolip]

I share that concern. The less that WebVTT adds on top of the existing web platform, the better, IMHO.

[dwsinger]

On Nov 23, 2015, at 7:53 , Philip Jägenstedt notifications@github.com wrote:

Are those non-browser devices using independent implementations of WebVTT, and are their implementors participating in WebVTT standardization? All I know of is Chromecast and Apple TV, and at least Chromecast is based on Chromium, and I'm guessing that Apple TV uses WebKit for its WebVTT support.

we have two implementations of VTT, one for the browser environment (webkit based) and one ‘standalone’ as part of our media stack (and used by HTTP Live Streaming).

David Singer Manager, Software Standards, Apple Inc.

[dwsinger]

On Nov 30, 2015, at 7:23 , Simon Pieters notifications@github.com wrote:

Since WebVTT limits what can be done, a WebVTT UA would not need to have "full" CSS support. It would need to implement css-syntax, css-cascade, selectors, and the properties mentioned in the WebVTT spec (or only those that the UA wishes to support).

I am slightly worried that, even if we add colors as proposed here, it's not going to be enough (is font-size needed? font-family? text-shadow?), which seems like a slippery slope towards reinventing CSS.

I really fear that saying “you only have to implement a subset of CSS” is very hard to keep contained, or even well-defined. As I said before, I suspect it’s pulling on one strand of spaghetti, and you end up with the entire plateful in your lap.

I’m not sure we even need to say very much. Perhaps all we need is to say that user-agents adopting the non-CSS conformance point are strongly encouraged to be required to behave as if certain basic styling were nonetheless available, especially being able to use a set of colors, and that such user-agents should behave as if some basic style-sheets were ‘built in’ to the user-agent (e.g. the style-sheet that support 608/708)?

It’s not realyl a VTT-spec. problem here, it’s a problem for adopters of this conformance point.

David Singer Manager, Software Standards, Apple Inc.

[andreastai]

@tairt Adding CSS classes doesn't mean that we limit the color range. It just provides defaults and settings to choose.

@silviapfeiffer Apologies, I have not been precise. I meant the limitation on a predefined set of colors (which could of course be in any color range)

[andreastai]

Since WebVTT limits what can be done, a WebVTT UA would not need to have "full" CSS support. It would need to implement css-syntax, css-cascade, selectors, and the properties mentioned in the WebVTT spec (or only those that the UA wishes to support).

I am slightly worried that, even if we add colors as proposed here, it's not going to be enough (is font-size needed? font-family? text-shadow?), which seems like a slippery slope towards reinventing CSS.

@zcorpan I can see this as a consequence. But while the missing support for font-size, font-family may be debatable (because you normally use just one value which may be preset by the user agent) the missing support of colors are not because you apply different values to your subtitle content.

[andreastai]

I’m not sure we even need to say very much. Perhaps all we need is to say that user-agents adopting the non-CSS conformance point are strongly encouraged to be required to behave as if certain basic styling were nonetheless available, especially being able to use a set of colors, and that such user-agents should behave as if some basic style-sheets were ‘built in’ to the user-agent (e.g. the style-sheet that support 608/708)?

It’s not realyl a VTT-spec. problem here, it’s a problem for adopters of this conformance point.

The VTT architecture was bound at the beginning to the HTML5 enviroment and browsers as UA. Here CSS support could be assumed and the delegation of certain features (color as one of them) to CSS have not been critical. But VTT is now used outside of the web platform from UA that do not process and support HTML/CSS. These UA have a not ingorable market share (e.g. native video renderers on iOS devices) and therefore this gap in specification becomes critical. Therefore from my point of view this is indeed a situation that needs to be solved by VTT because the usage scenario has changed.

I can therefore see a justification to add important features like color as VTT core feature or to have no conformance class for user agent that do not support the defined VTT CSS subset.

To have predefined CSS classes and let UA behave "as if" seems to me like intermediate fix that does not solve the core problem.

In any case a solution needs not be only recommended but needs to be made mandatory.

[andreastai]

I got more feedback from different European broadcaster on this issue and will summarize it this week.

[zcorpan]

@dwsinger

I really fear that saying “you only have to implement a subset of CSS” is very hard to keep contained, or even well-defined. As I said before, I suspect it’s pulling on one strand of spaghetti, and you end up with the entire plateful in your lap.

I'm not convinced that is really the case.

• css-syntax is pretty self-contained, both spec-wise and in implementations, I believe. https://github.com/tabatkins/parse-css is an impl in JS.
• css-cascade is not so self-contained in browser implementations due to optimizations, I think, so it might not be practical to steal this from a browser engine, but it does not appear to be super-difficult to implement from scratch, assuming it doesn't need the same performance as a browser engine.
• selectors is self-contained; there's a DOM API for it and people implemented it in JS before the DOM API existed.
• The color and background-color properties are presumably not much of a problem.

[andreastai]

In the context of the HBB4ALL project (a project funded by the European Commission which works on Access Services for connected devices) I tried to gather more feedback on some important questions discussed thread. I got responses from four partners in the project (three broadcaster from Portugal, Spain and Germany + consultant who works on access services in France). I asked them 3 questions highlighted below.

How important is it that a technical solution supports colour and background colour for subtitle text?

Germany

"From my experience in providing captions I know that colors are very helpful for the deaf and hard of hearing. Therefore I am absolutely in favour to keep the possibility to assign colors."

Spain

"Deaf people are grateful that the main characters have assigned colors. It’s an easy way to know who is speaking. An alternative is to indicate in brackets the name of the speaker, when no color is assigned to characters, but color identification is much better. We consider really relevant that the subtitle format supports text colors and black background."

Portugal

"I agree [with the comment from Spain]. The only way to identify who is speaking is using colors. For instance, in Portugal we only use three colors: white (off camera speech), yellow (on camera speech) and cyan (for other information, such as music, when someone knocks in a door or a bell rings, etc.) on a black background. We also identify the characters with their names in cyan."

France

"In France are specifications in a “Charter on the quality of subtitling for deaf and hard-of hearing” signed in December 2011 by all concerned stakeholders (Chartesoustitrage122011.pdf attached and can also be downloaded from the website of the Conseil Supérieur L'Audiovisuel),

Among others, it stipulates 6 colours:

• White, when a person speaks on the screen
• Yellow, when a person speaks off-screen
• Red, for noise directions
• Magenta, for musical indications
• Cyan, for internal reflections or voice overs ( les commentaires en voix off)
• Green, for transcriptions of foreign languages

It seems that people appreciate colored subtitles"

How important is the author's control over which colour to be chosen?

Germany

"It is debatable if the author or the enduser assign the color. From my side I think it is better if the author assigns the color because through work on it he knows much better the movie and the subtitles. He has therefore more knowledge to assign the color so they give sense and also keep continuity.

Spain

"No problem if you want to change the colors which are determined. Important is that the colors are easy to read. The colors agreed that read better are white, yellow, cyan and green. People with vision restrictions read better if there is a black background to the text. The background color option is dispensable."

Portugal

"For us it is important to be in control of the use of colors when we are subtitling. We use only the three colors mentioned above. There are some colors that are aggressive to the users, as red for instance."

Are the support for some basic, pre-defined colours sufficient or should the author have control over the complete range of colours that are supported by a user agent?

Germany

"For sure the author does not need all possible colors. Four or five colors are enough, to do the 'coloring' properly."

[zcorpan]

Thanks @tairt! Very helpful.

I suggest we close this issue in favor of https://github.com/w3c/webvtt/issues/270

[andreastai]

I would prefer to leave it open for now so we can summarize the conclusion from the above feedback.

[andreastai]

I gathered and posted this feedback from experts that work with captions because it is so important that standards meet the requirements that come directly from daily operation. Therefore this feedback stands for it's own and I would like to clearly mark the following summary and conclusions as my personal view and understanding.

The feedback from the first two questions clearly undermines the argument that assignment of colors to text through the author is an indispensable feature for a format that is used for captions. As I read pull request/commit 72560f7d3f3ccfb5c2fa988c8f988046f2925696 this addition would make the support for basic colors mandatory through "predefined" classes and therefore solves this issue.

Therefore it this commit is a far better solution then to have conformant VTT clients that do not support color at all.

For the question if a handful of fixed color values would do the job, you may tend to say "yes" after reading the feedback. I think it is important to be more cautious. To understand this we should look in the broadcast domain and how captions are produced nowadays in this domain. In North America CEA 608 is widely used and in Europe technologies that refer to features of European teletext predominate. These two legacy technology limit the applicable colors to a very small number of color values. Because the captions used for internet distribution are very often derived from broadcast captions a matching limitation of color values for some VTT devices seems not be a problem.

On the other side for over a decade standard organizations have been trying to overcome the limitation of CEA 608 and teletext with new formats. As it turned out this is much harder to bring them into operation than assumed because you cannot replace just one system in the production chain. You have to change nearly all system relevant for the caption workflow. Therefore the progress is slow. Even for internet distribution you cannot use new features because the base material are still produced using legacy technology.

But the goal to replace legacy technologies stays. It is just a question of time when this will happen. Once they are replaced you can use all features in the base format because end devices as systems in between will support these new features already. One example: A broadcaster in Germany currently statically maps the colors for DVB Bitmap Subtitling from teletext color values to "less aggressive" color values (e.g. for cyan from "#00FFFF" to "#a8fafa"). This could happen then directly in the production format because all systems including end devices have a broader range of supported color values.

I am therefore very worried to limit now again the feature spectrum for User Agents that do not want or can support CSS. This will push the date for a possible change to beyond the time when CEA 608 and teletext are not used anymore. It seems like an irony that this limitation may apply to non-browser based user agents that run on the most high end devices currently available. Compared to the days when days when CEA 608 or teletext were invented this limitation is now less driven by technical capabilities. The reasons are more format inherent; backwards compatibility with existing VTT implementation may also play a role. I understand the arguments in this thread. But I also see a big gap between predefined CSS classes and full support of the CSS subset. One reason that it is difficult to find a moderate solution in between may be found in the general design of WebVTT which cannot be changed anymore.

So can we make the solution of predefined classes at least a bit better? In the feedback from the broadcaster but also from discussion with other experts in the accessibility domain the questions of customization of presentation features through the user is a high priority feature. If there will be a conformance class for non CSS clients then the support for customizing the predefined color values shall be mandated or at least strongly recommended with a "should". The same should apply for font size.

[zcorpan]

A broadcaster in Germany currently statically maps the colors for DVB Bitmap Subtitling from teletext color values to "less aggressive" color values (e.g. for cyan from "#00FFFF" to "#a8fafa"). This could happen then directly in the production format because all systems including end devices have a broader range of supported color values.

Why should the broadcaster do that, as opposed to the UA?

In the feedback from the broadcaster but also from discussion with other experts in the accessibility domain the questions of customization of presentation features through the user is a high priority feature.

So the user should be able to customize the colors? (That seems to argue against having the broadcaster tweak the colors.)

I think that makes sense. We could also allow some variation for UA defaults for these colors.

Technically, the user is already in control over any CSS styling, because CSS requires user agents to support user stylesheets where the user can tweak the UA defaults and also override author-specified styles.

[andreastai]

A broadcaster in Germany currently statically maps the colors for DVB Bitmap Subtitling from teletext color values to "less aggressive" color values (e.g. for cyan from "#00FFFF" to "#a8fafa"). This could happen then directly in the production format because all systems including end devices have a broader range of supported color values.

Why should the broadcaster do that, as opposed to the UA?

One reason is technical and the other editorial.

a) DVB Bitmapsubtiles are rendered as bitmaps at the server side. The client has no influence in changing the color.

b) The editor may want to choose the right color values based on the regional/channel presets. How does the User Agent know the right color values of a content channel which could be different between a German broadcaster and a Swedish broacaster ? See also: https://github.com/w3c/webvtt/pull/261#issuecomment-158182550

In the feedback from the broadcaster but also from discussion with other experts in the accessibility domain the questions of customization of presentation features through the user is a high priority feature.

So the user should be able to customize the colors? (That seems to argue against having the broadcaster tweak the colors.)

What is missing is the first part of my statement so the meaning get's reversed:

So can we make the solution of predefined classes at least a bit better?

The intent was to give at least the user control when the author does not have control over it in the case of user agents that do not support CSS. It is not "author control or user control". It is author control, user control when possible or when author control is not available.

I think that makes sense. We could also allow some variation for UA defaults for these colors.

I do not agree. If you fix the classes you can use but then again give the client the freedom to change the "default" colors without interaction, for the author there is no prediction at all. It is to allow an explicit override by the user and not a default override by the user agent!

Technically, the user is already in control over any CSS styling, because CSS requires user agents to support user stylesheets where the user can tweak the UA defaults and also override author-specified styles.

The discussion focus mainly on user agent that do not support CSS. How this would work here?

[zcorpan]

a) DVB Bitmapsubtiles are rendered as bitmaps at the server side. The client has no influence in changing the color.

Ah yeah OK.

b) The editor may want to choose the right color values based on the regional/channel presets. How does the User Agent know the right color values of a content channel which could be different between a German broadcaster and a Swedish broacaster ? See also: https://github.com/w3c/webvtt/pull/261#issuecomment-158182550

I mean that the broadcaster can specify a "cyan" class, but the user can decide which shade of cyan that will be ("#00FFFF" or "#a8fafa" or something else). If the user needs e.g. really-bright cyan, he or she would want the same cyan regardless of the broadcaster, no?

If the broadcaster can use "any" color, that seems like it makes it more difficult for users to override while maintaining a color scheme. But maybe not? I suppose the UA could have a minimum/maximum contrast range for colors, and some algorithm to adjust author-specified colors until the contrast is satisfied, or some such.

The intent was to give at least the user control when the author does not have control over it in the case of user agents that do not support CSS. It is not "author control or user control". It is author control, user control when possible or when author control is not available.

I suspect we are in agreement here but I'm not really sure.

I do not agree. If you fix the classes you can use but then again give the client the freedom to change the "default" colors without interaction, for the author there is no prediction at all. It is to allow an explicit override by the user and not a default override by the user agent!

OK.

The discussion focus mainly on user agent that do not support CSS. How this would work here?

We repeat the requirement in WebVTT spec for non-CSS UAs.

[andreastai]

b) The editor may want to choose the right color values based on the regional/channel presets. How does the User Agent know the right color values of a content channel which could be different between a German broadcaster and a Swedish broacaster ? See also: #261 (comment)

I mean that the broadcaster can specify a "cyan" class, but the user can decide which shade of cyan that will be ("#00FFFF" or "#a8fafa" or something else). If the user needs e.g. really-bright cyan, he or she would want the same cyan regardless of the broadcaster, no?

This would only work for broadband distribution, not for broadcast distribution using DVB Bitmap Subtitling or teletext. The broadcast standards do not provide that option.

If the broadcaster can use "any" color, that seems like it makes it more difficult for users to override while maintaining a color scheme. But maybe not? I suppose the UA could have a minimum/maximum contrast range for colors, and some algorithm to adjust author-specified colors until the contrast is satisfied, or some such.

Yes, you are right in that point. As said for DVB Bitmap and teletext subs you do not have that choice. But for "Broadband" Subtitles this is makes customization of colors indeed more difficult. One reason maybe that broadcaster did tests which color is best to apply. There has also been tests for customization of subtitles and I think the biggest need was to customize font-size and position. I am not sure if the need of customizing colors was also tested but in the end this didn't make it in some subtitle apps I know.

[zcorpan]

Closing per https://github.com/w3c/webvtt/pull/279#issuecomment-273751072