Intent to Implement and Ship: Inline WebVTT Styling

Evan Liu

unread,

Aug 21, 2019, 3:16:48 PM8/21/19

to blink-dev

Contact emails

ev...@google.com

mlam...@google.com

Spec

https://www.w3.org/TR/webvtt1/

Design doc

https://docs.google.com/document/d/1bSCLwCuPkSPbOMh61YNuEsCE1wM9LjNO-DlVmmU2VJ4/edit?usp=sharing

Summary

The W3C WebVTT specification allows the ability to embed CSS style sheets within the STYLE block of a WebVTT file. This feature is supported by several other web browsers and video players including Safari and VLC but not Chrome.

Motivation

To ensure a consistent experience across platforms, Chrome should conform to the WebVTT specification by supporting inline styling. This project is part of a larger effort to improve Accessibility around the Media Experience in Chrome.

Risks

Interoperability and Compatibility

There is no interoperability and compatibility risk for this feature. A detailed W3C WebVTT specification exists and Safari already implemented the feature.

Ergonomics

There are no known risks associated with ergonomics.

Activation

The detailed W3C WebVTT specification as well as several online tutorials and guides make it very easy for content authors to learn how to add inline styling to their WebVTT files.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

The WPT test suite for WebVTT parsing is located here: https://github.com/web-platform-tests/wpt/tree/master/webvtt/parsing

Additional tests specific to the WebVTT STYLE block will be added as tests for the implementation.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5718402851143680

Requesting approval to ship?

Yes.

Simon Pieters

unread,

Aug 22, 2019, 8:53:19 AM8/22/19

to Evan Liu, blink-dev

I'm happy to see movement with this feature!

The design doc isn't public. Can it be made public?

> Interoperability and Compatibility

> There is no interoperability and compatibility risk for this feature. A detailed W3C WebVTT specification exists and Safari already implemented the feature.

A detailed spec and a prior implementation are good signs, but I think it doesn't follow that there is no interop or compat risk.

There is an interop risk if the Safari implementation doesn't conform to the spec, or if Gecko do not implement the feature. In this case, what VLC does is also interesting, since people may author WebVTT files that work as they intend in VLC, and go on to publish it on the web.

> Activation

> The detailed W3C WebVTT specification as well as several online tutorials and guides make it very easy for content authors to learn how to add inline styling to their WebVTT files.

What are the online tutorials that cover this feature?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/61a54ca9-159d-4b3a-8d1a-094cc3e98d8e%40chromium.org.

--

Simon Pieters

https://bocoup.com/

Alex Russell

unread,

Aug 22, 2019, 3:37:51 PM8/22/19

to blink-dev, ev...@google.com

Hey Evan,

Some folks are still having trouble accessing the doc. Any chance you can make a fully public copy?

Regarding shipping, I'd love to see the tests land before approving the intent.

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/61a54ca9-159d-4b3a-8d1a-094cc3e98d8e%40chromium.org.

Evan Liu

unread,

Aug 22, 2019, 3:46:01 PM8/22/19

to blink-dev, ev...@google.com

Hi Alex,

Here's a public link to the design document: https://docs.google.com/document/d/e/2PACX-1vQSt06bpRU1fOREH403DqQlYFW7ISxmKOJPMKWXJwFt3zGyjtWrc9gCy49uULAZl3GDImFconXsBObn/pub

Thanks,

Evan

Evan Liu

unread,

Aug 22, 2019, 6:16:51 PM8/22/19

to blink-dev, ev...@google.com

Correction: try this link instead https://docs.google.com/document/d/1irKaV9iSOdmL6J4T8x7qWCgf9hvrZaZCSpaphxoPr-U/edit?usp=sharing

Thanks,

Evan

On Thursday, August 22, 2019 at 12:46:01 PM UTC-7, Evan Liu wrote:

Hi Alex,

Here's a public link to the design document: https://docs.google.com/document/d/1irKaV9iSOdmL6J4T8x7qWCgf9hvrZaZCSpaphxoPr-U/edit?usp=sharing

Simon Pieters

unread,

Aug 23, 2019, 4:08:34 PM8/23/19

to Evan Liu, blink-dev

Thanks! I only have permission to view the doc, not comment, but I can comment here.

> Because these blocks must appear before any cues in the WebVTT file, the CSS strings can be aggregated and parsed into a single style sheet when the first cue is encountered.

This would not be conforming. Consider:

WEBVTT

STYLE

::cue {

STYLE

color: red }

00:00:00.000 --> 00:00:10.000

Test

The cue should not be red, since each stylesheet is incomplete/bogus. (There are other cases as well, like handling of @namespace rules that are per-stylesheet.)

I don't see any plan for handling of URLs. The spec states:

> For the purpose of resolving URLs in STYLE blocks of a WebVTT file, or any URLs in resources referenced from STYLE blocks of a WebVTT file, if the URL’s scheme is not "data", then the user agent must act as if the URL failed to resolve.

>
> Supporting external resources with @import or background-image would be a new ability for media elements and track elements to issue network requests as the user watches the video, which could be a privacy issue.

https://w3c.github.io/webvtt/#obtaining-css-boxes

> Such style sheets cannot fetch any external resources, and it is important for privacy that user agents do not allow this. Otherwise, WebVTT files could be authored such that a third party is notified when the user watches a particular video, and even the current time in that video.

https://w3c.github.io/webvtt/#styling-security

I think it would be good to have a plan for this, and tests to verify.

cheers

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b50e7eaf-e01d-4ad7-994b-a7cc91acbc19%40chromium.org.

Simon Pieters

unread,

Aug 23, 2019, 4:25:11 PM8/23/19

to Evan Liu, blink-dev

- blink-dev

I just found out that webkit doesn't follow the spec on the URL issue. https://bugs.webkit.org/show_bug.cgi?id=201086

Evan Liu

unread,

Aug 26, 2019, 4:48:08 PM8/26/19

to blink-dev, ev...@google.com

Hi Simon,

I've made a few changes to the design document and addressed the two issues you brought up in the latest iteration.

Thanks,

Evan

Simon Pieters

unread,

Aug 27, 2019, 3:47:22 AM8/27/19

to Evan Liu, blink-dev

Thank you.

@import and background-image are two cases that can fetch something from CSS, but this is not an exhaustive list of such features. For example, I assume @font-face doesn't go through the ConsumeImage code path.

How do you make sure that everything is covered (ideally also when a new CSS feature is added, e.g. @color-profile)?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b597ad87-6123-4e8f-b1e8-c0b49d93ff0e%40chromium.org.

Daniel Bratell

unread,

Sep 12, 2019, 9:52:05 AM9/12/19

to Evan Liu, Simon Pieters, blink-dev

I approve this work, but it seems like the spec/test situation is not yet great. Would it make sense to work on implementation/spec and land tests to learn more about this before deciding on shipping?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHWN20Un-95KxwT2kj2S%2BVakdA1NBFCO1Etptxz3qXNd1%2BR8Gg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Alex Russell

unread,

Sep 26, 2019, 1:32:10 PM9/26/19

to blink-dev, ev...@google.com, zco...@gmail.com

Any update on the tests?

On Thursday, September 12, 2019 at 2:52:05 PM UTC+1, Daniel Bratell wrote:

I approve this work, but it seems like the spec/test situation is not yet great. Would it make sense to work on implementation/spec and land tests to learn more about this before deciding on shipping?

/Daniel

On Tue, 27 Aug 2019 09:46:39 +0200, Simon Pieters <zco...@gmail.com> wrote:

Thank you.

@import and background-image are two cases that can fetch something from CSS, but this is not an exhaustive list of such features. For example, I assume @font-face doesn't go through the ConsumeImage code path.

How do you make sure that everything is covered (ideally also when a new CSS feature is added, e.g. @color-profile)?

Den mån 26 aug. 2019 kl 22:48 skrev 'Evan Liu' via blink-dev <blin...@chromium.org>:

Hi Simon,

I've made a few changes to the design document and addressed the two issues you brought up in the latest iteration.

Thanks,
Evan

On Friday, August 23, 2019 at 1:25:11 PM UTC-7, Simon Pieters wrote:
- blink-dev

I just found out that webkit doesn't follow the spec on the URL issue. https://bugs.webkit.org/show_bug.cgi?id=201086

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b597ad87-6123-4e8f-b1e8-c0b49d93ff0e%40chromium.org.

--
Simon Pieters
https://bocoup.com/
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHWN20Un-95KxwT2kj2S%2BVakdA1NBFCO1Etptxz3qXNd1%2BR8Gg%40mail.gmail.com.

Evan Liu

unread,

Sep 26, 2019, 6:30:30 PM9/26/19

to Alex Russell, blink-dev, zco...@gmail.com

Hi Alex,

I've updated the test cases in the document. You can view the WPT test cases I've implemented here: https://chromium-review.googlesource.com/c/chromium/src/+/1685677

Thanks!

Evan

Evan Liu

unread,

Oct 9, 2019, 7:30:09 PM10/9/19

to blink-dev, zco...@gmail.com

Hi all,

Have people gotten a chance to review the test cases that will be accompanying this change: https://chromium-review.googlesource.com/c/chromium/src/+/1685677 Please let me know if there are any gaps in coverage or if there are any other issues preventing you from approving this intent to ship.

Thanks,

Evan

Philip Jägenstedt

unread,

Oct 10, 2019, 2:14:04 PM10/10/19

to Evan Liu, blink-dev, Simon Pieters

I believe the remaining work is on the test and implementation side and that this intent need not be blocked on that. The spec change was made 4 years ago now <https://github.com/w3c/webvtt/pull/219> and was discussed in depth then.

LGTM1 assuming detailed test coverage is added together with the implementation. Code review is the best place to work through that.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e23b5c28-3015-457e-b5d9-4958624a7594%40chromium.org.

Chris Harrelson

unread,

Oct 10, 2019, 2:52:27 PM10/10/19

to Philip Jägenstedt, Evan Liu, blink-dev, Simon Pieters

Simon: since you raised various concerns about the spec and interop: do you think your concerns you raised have been adequately addressed?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfpQZOxkQ2qXGk8HX9D7XPe3Enw8DRnnwdgbY4LNWmO-w%40mail.gmail.com.

Simon Pieters

unread,

Oct 11, 2019, 5:31:41 AM10/11/19

to Chris Harrelson, Philip Jägenstedt, Evan Liu, blink-dev, eric.c...@apple.com

+cc eric.c...@apple.com - FYI about Safari test results below.

These were my concerns:

## Concatenating STYLE blocks into one style sheet is wrong

This is addressed in the implementation and tested.

## Interop situation for VLC is unclear.

I don't think this is addressed, but shouldn't block shipping.

## Interop situation for Safari is unclear

Looking at the tests, it seems they have good coverage of the interesting cases. Nice!

The test results can be viewed at https://wpt.fyi/results/?label=pr_head&max-count=1&pr=19097 but note that Safari fails most rendering WebVTT tests due to how they display subtitles (which doesn't conform to the spec), so need to manually check the screenshots. I've done that now, here are the results:

embedded_style_cascade_priority.html FAIL
embedded_style_imports_blocked.html PASS
embedded_style_invalid_format.html FAIL
embedded_style_media_queries.html FAIL
embedded_style_media_queries_resized.html FAIL
embedded_style_multiple_tracks.html FAIL (it only renders one track, but correctly applies the CSS to that track)
embedded_style_selectors.html FAIL
embedded_style_urls.html FAIL (it applies both background images - bug https://bugs.webkit.org/show_bug.cgi?id=201086 )

This makes the interop situation clearer: it's not interoperable. I don't think this needs to block shipping in chromium, but we can acknowledge that there is a real interop problem and at least report a webkit bug so they can fix their implementation to pass the tests.

## Should centralize blocking of URLs in CSS to cover all CSS features that can fetch things

It looks like the implementation now deals with any URL in CSS (in third_party/blink/renderer/core/css/parser/css_property_parser_helpers.cc), which is good.

The implementation still disallows any @import (including data url), which is different from the spec. But I don't see any use case for it. Shouldn't block shipping, but may want to follow up with either aligning the implementation with the spec or vice versa.

## Reference to "several online tutorials and guides"

No links to such tutorials or guides have been given. I found that MDN says something about STYLE at https://developer.mozilla.org/en-US/docs/Web/API/WebVTT_API#Styling_WebTT_cues but it's pretty brief.

Maybe there's room for a new tutorial? Or update https://www.html5rocks.com/en/tutorials/track/basics/ ?

In summary, I think the important concerns are addressed, and I would be happy to see this feature ship.

Yoav Weiss

unread,

Oct 11, 2019, 5:43:14 AM10/11/19

to Simon Pieters, Chris Harrelson, Philip Jägenstedt, Evan Liu, blink-dev, eric.c...@apple.com

Thanks Simon!!

Reading your detailed report, it seems like there are real interoperability problems here with both Safari and VLC. Are those around edge cases? If this ships, can developers write WebVTT styles that would generally work for all three? Or do they need different styles for each?

If it's the latter, it would seem we need to clarify the situation further before shipping.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHWN20VQqGKjx4P%2BLiV8oJGm%2BzN9FzZ%2BFKOkG9qMH6PvPnfHoQ%40mail.gmail.com.

Simon Pieters

unread,

Oct 11, 2019, 8:32:25 AM10/11/19

to Yoav Weiss, Chris Harrelson, Philip Jägenstedt, Evan Liu, blink-dev, eric.c...@apple.com

I don't know what the situation is with VLC. I have not tested VLC.

> Are those around edge cases?

Several of the tests do target edge cases, as a good test suite does.

> If this ships, can developers write WebVTT styles that would generally work for all three? Or do they need different styles for each?

This probably has more to do with how well the ::cue and ::cue(selector) pseudo-classes work and which properties work, than the details of STYLE. It's worth noting that the ::cue pseudo-class only allows a small subset of CSS properties, and styling WebVTT with CSS *from `<style>` or `<link rel=stylesheet>` in HTML* is already shipping in Safari, Chrome, and Firefox.

https://w3c.github.io/webvtt/#the-cue-pseudo-element

As for STYLE, for general use cases, I think stuff ought to work as well as ::cue / ::cue(selector) styles already do outside the WebVTT syntax. The most concerning issue may be that WebKit allows fetching background images, which web content could end up expecting to work (but shouldn't work in STYLE blocks).

I have a webvtt playground here https://zcorpan.github.io/live-webvtt-viewer/ where you can try things on-the-fly. The "CSS" textarea applies the styles using a <style> element, but you can test STYLE block in the "VTT" textarea.

Simple test for ::cue and color: https://zcorpan.github.io/live-webvtt-viewer/#style=%3A%3Acue+%7B%0A++color%3A+lime%0A%7D

* Chrome, Safari, Firefox: works.

The link below tests the allowed CSS properties.

* Chrome stable: all seem to work as I expect they should per spec.

* Chrome canary: the cue boxes now look more like they do in Safari. The right-aligned cues are invisible. What happened? (This might be a bit off-topic for this thread, though.)

* Safari: They all seem to work except for line-height. What's more different is the size of each cue, how the background color, the border-radius, and there seems to be a bug in the cue overlap avoidance. Not tested in this link but I also found that Safari doesn't allow changing the background-color of `::cue`.

* Firefox doesn't seem to support ::cue(selector).

Chris Harrelson

unread,

Oct 11, 2019, 11:32:52 AM10/11/19

to Yoav Weiss, Simon Pieters, Philip Jägenstedt, Evan Liu, blink-dev, eric.c...@apple.com

On Fri, Oct 11, 2019 at 2:43 AM Yoav Weiss <yo...@yoav.ws> wrote:

Thanks Simon!!

+1, this is excellent feedback! Thanks.

Reading your detailed report, it seems like there are real interoperability problems here with both Safari and VLC. Are those around edge cases? If this ships, can developers write WebVTT styles that would generally work for all three? Or do they need different styles for each?

If it's the latter, it would seem we need to clarify the situation further before shipping.

This is the last point that might block shipping. Evan, do you know the answer?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjm%2BMuHutTr9%2BWdmLOTuQtbwHQp-uYboii%3DGKokoNmoFA%40mail.gmail.com.

Evan Liu

unread,

Oct 11, 2019, 1:43:13 PM10/11/19

to Chris Harrelson, Yoav Weiss, Simon Pieters, Philip Jägenstedt, blink-dev, eric.c...@apple.com

Thanks, Simon for the in-depth analysis!

Regarding the interoperability issues between Safari and Chromium, this is definitely a risk as the implementations between the two differ. The WebKit implementation essentially parses the CSS in the STYLE block and inserts it into a <style> tag in the shadow DOM. This causes several issues and behaviors that differ from the spec including the following:

Evan Liu

unread,

Oct 11, 2019, 1:52:02 PM10/11/19

to Chris Harrelson, Yoav Weiss, Simon Pieters, Philip Jägenstedt, blink-dev, eric.c...@apple.com

- CSS from one track applies to the entire shadow tree scope, including tracks sourced from a different VTT file.

- @import rules are allowed.

- The cascade order of the styles is incorrect.

Despite these differences, developers can still write WebVTT styles that would generally apply to both browsers as these differences only appear in the edge cases. The vast majority of the use cases will probably be simple ::cue and ::cue(selector) tags to customize the color, size, font, etc. of a single text track file. I haven't run all of the test cases through VLC, but in my prior testing it looks like VLC's implementation is closer to Chromium's and the VTT specifications.

Regarding the guides and tutorials, it looks like there aren't as many as I had thought since most of the guides are for styling cues via CSS in author stylesheets and not specifically for style embedded in VTT files.

Thanks,

Evan

Chris Harrelson

unread,

Oct 11, 2019, 2:11:55 PM10/11/19

to Evan Liu, Yoav Weiss, Simon Pieters, Philip Jägenstedt, blink-dev, eric.c...@apple.com

Ok.

LGTM2 then!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOVsCZ%3DmLWhDR2Uwjq07n5-fN%3DzMSzT1JEAGmojdFQ8Fbmg%3DFg%40mail.gmail.com.

Philip Jägenstedt

unread,

Oct 11, 2019, 2:53:55 PM10/11/19

to Chris Harrelson, Evan Liu, Yoav Weiss, Simon Pieters, blink-dev, Eric Carlson

Wow, thanks Simon for that deep dive in interop. Stellar work.

Evan, can you see to it that WebKit issues are filed for any differences between Chromium and WebKit that Simon's analysis reveals?

Evan Liu

unread,

Oct 11, 2019, 3:12:22 PM10/11/19

to Philip Jägenstedt, Chris Harrelson, Yoav Weiss, Simon Pieters, blink-dev, Eric Carlson

I've filed a bug for WebKit to track these interoperability issues: https://bugs.webkit.org/show_bug.cgi?id=202860

I've included the path to the tests that will hopefully be checked in soon.

Thanks,

Evan

Evan Liu

unread,

Oct 11, 2019, 4:38:42 PM10/11/19

to Philip Jägenstedt, Mounir Lamouri, Chris Harrelson, Yoav Weiss, Simon Pieters, blink-dev, Eric Carlson

+Mounir Lamouri

Mounir Lamouri

unread,

Oct 11, 2019, 5:16:49 PM10/11/19

to Evan Liu, Philip Jägenstedt, Chris Harrelson, Yoav Weiss, Simon Pieters, blink-dev, Eric Carlson

For what it's worth, Evan and Eric (Apple) will both be at FOMS in ten days where I'm sure they will discuss these compatibility issues. I also mentioned them to Eric during TPAC. Hopefully WebKit will find a way to solve those.

-- Mounir

Yoav Weiss

unread,

Oct 11, 2019, 5:22:09 PM10/11/19

to Mounir Lamouri, Evan Liu, Philip Jägenstedt, Chris Harrelson, Simon Pieters, blink-dev, Eric Carlson

LGTM3

Thanks Simon for the amazing analysis, and thanks Evan and Mounir for pushing through the questions. Let's hope Safari will align with the spec.

Reply all

Reply to author

Forward