WebVTT should expose an inline-block backdrop element for cues

[jernoble]

Safari and WebKit on macOS and iOS have a long-standing default treatment of text track cues that incorporates an inline-block wrapper around the cues, so as to provide the same rendering of cues as is available to native applications using system media frameworks. The styles for this inline-block wrapper are configurable through system defaults, allowing the user to choose between an inline-block style highlight, and a inline highlight. (See attached images for examples.)

Because this block is not exposed through WebVTT, it is very difficult (if not impossible) for inline- or page-provided styles to override this rendering.

[jernoble]

Strawman solution 1: Add an additional wrapper anonymous block with a display: inline-block style, and add a specific selector for ::cue(selector) that applies to the block.

Strawman solution 2: Allow the display: property to apply to the ::cue and ::cue(selector) pseudo element, with the allowed values of inline and inline-block.

[jernoble]

The macOS System Preferences allow users to specify cue treatments that have separate properties for the cue "window" (i.e., the inline-block wrapper) and the cue "background" (i.e., the "WebVTT background box"). See the settings for "background color / opacity" and "window color / opacity" below:

This may mean that "straw man solution 2" is untenable on macOS and iOS, since they allow the user to override styles of the inline-box and inline wrappers separately.

[jernoble]

As an internal implementation detail, WebKit uses the pseudo-element ::-webkit-media-text-track-display-backdrop to refer to the inline-block element which wraps each ::cue. While that's an unreasonably verbose pesudo name, something like ::cue-backdrop would be sufficiently succinct. The ::cue-backdrop pseudo-element could be restricted to a short list of CSS properties; such as background, border-radius, and padding.

[nigelmegitt]

How does this map semantically to e.g. region, div or p in TTML? Is it definitely equivalent to an HTML div or could it be equivalent to a p being a different block element?

I ask because if there is an opportunity to close the semantic gap, we should probably take it. It's unclear how the FCC "window" concept maps too, in the sense that there is more than one possible option for mapping, and I suspect (only by reading between the lines) that FCC does not consider it appropriate for them to go into this level of format-dependent detail.

[jernoble]

No idea how this maps to TTML. For HTML, it's definitely equivalent to a div insofar as a p is just a div with style.

[jernoble]

Pinging this thread. Strawman proposal would be that the "window" of a WebVTT cue should be selectable by a ::cue-window selector.

[nigelmegitt]

@jernoble can you define "window"?

[jernoble]

What definition are you looking for? CEA-708 already defines "caption windows", as well as defines display properties of those windows, including background color, border effects, and transparency. But in the context of WebVTT, I would define a "cue window" as an "inline-block element wrapping the WebVTT Internal Objects generated by the cue".

[jernoble]

Ping on this issue. The ability for web pages to override system-provided styling of "caption windows" is critical for interoperability and use of WebVTT in web pages generally.

[silviapfeiffer]

I like the idea of ::cue-window for dealing with the background. Can I suggest preparing a pull request? That makes the life of the current maintainer a bit easier...

[gkatsev]

I would be in support of exposing ::cue-window. It would basically be an alias for the existing ::-webkit-media-text-track-display-backdrop element in safari?

It would be nice to figure out the TTML mapping, but that can be done separately.