Add support for ::cue-backdrop

[jernoble]

Fixes #516

In order to align the capabilities of WebVTT with CEA standards like 708, add the concept of a "WebVTT block background box", which is defined as a block-level wrapper around the WebVTT cue's contents.

To allow authors to specify styles that apply to this block background object, add a new selector ::cue-container that matches it. UAs which provide FCC required styling information for "window background & opacity" can do so via this new selector in UA-provided style sheets.

---

Preview | Diff

[jernoble]

Pinging @gkatsev for a review of this PR.

[gkatsev]

This change seems reasonable to me. Though, we'd want to resolve naming issues between this one and #531. Maybe this should be ::cue-backdrop and #531 the ::cue-container?

[jernoble]

Updated the PR to use ::cue-backdrop.

[nigelmegitt]

I think ::cue-backdrop is not a great name since it creates an ambiguity: does it apply at the block level or the inline level. Maybe ::cue-block would work better, allowing for a potential ::cue-inline if ever needed later?

[jernoble]

Our accessibility and CSS experts internally suggest "block background" and "inline background" as naming conventions. So this would imply ::cue-block-background and (in the future) ::cue-inline-background.

(Other terms suggested were "box" and "container", which lead me to the initial ::cue-container proposal.)

[nigelmegitt]

That makes sense @jernoble , except... isn't the ::cue-thing part of a selector, to target a particular stylable thing, and if you want to style the background, you'd apply the CSS background-color property?

If we ever wanted to allow other styling properties to apply, it might look rather odd to have background be part of the selector; putting something that looks like a property name into a selector is probably not ideal, even if it might be unavoidable sometimes.

[jernoble]

If we ever wanted to allow other styling properties to apply, it might look rather odd to have background be part of the selector...

Well yes, which is why I originally proposed "container" or "backdrop", which are both descriptive of the thing itself, and not the property. I don't actually think "block" or "inline" alone are appropriate either for the same reason: those are both CSS display: values (in addition to being CSS concepts). Besides, the "block" object is actually display:inline-block.

[nigelmegitt]

Aargh, naming is hard! Yes, I agree with those concerns too, though I feel that overlap with a permitted property value is less bad than overlap with a property name.

[jernoble]

If you wanted to disambiguate the terms from their CSS property values, one option would be to use inline box and block container, both of which are terms defined by CSS, but are not themselves CSS property values.

[jernoble]

Or, we could roll all the way back to ::cue-container (since "block container" has a defined meaning in CSS), and use ::cue-root (since "root element" also has a defined meaning in CSS) to represent the cue display area, and the use of those two terms shouldn't be ambiguous (in CSS terms).

[gkatsev]

I guess ::cue-block-box could be an option, but maybe ::cue-container with ::cue-root might be best/easiest. I don't really have other ideas.
Do we know folks from Firefox or Chrome who might have thoughts?

[fantasai]

+1 to Nigel's comments wrt incorporating -background in the name. :)

What is the box-tree you're working with here? If I set color on this pseudo-element, will it inherit to ::cue elements inside it? If I size it, will that affect the content inside it?

If no, then backdrop is fairly reasonable as a name. But if it does function as a container, then ::cue-block might work.

[jernoble]

If I set color on this pseudo-element, will it inherit to ::cue elements inside it?

You cannot set color: on it, because color: isn't an allowed property on this selector.

If I size it, will that affect the content inside it?

The only allowed properties would be background:, padding: and border:; setting those would affect the layout of its contents, but not their size.

[jernoble]

Per @gkatsev 's comment in issue 531, updating this PR to use :cue-backdrop.

[css-meeting-bot]

The Timed Text Working Group just discussed Add support for ::cue-backdrop #528, and agreed to the following:

• SUMMARY: Request feedback from other browser vendors on the feature and name of the element before proceeding

The full IRC log of that discussion

<nigel> Subtopic: Add support for ::cue-backdrop #528
<nigel> github: https://github.com//pull/528
<nigel> Dana: This adds the block level wrapper around inline content.
<nigel> .. This is required by some CEA standards.
<nigel> .. Webkit and Chromium already implement it but it isn't in the spec.
<nigel> .. Jer opened the PR to add it.
<nigel> .. From the discussion it seems that the name of it was contentious.
<nigel> .. cue-backdrop was settled on, it seems.
<nigel> .. Can we merge it or are there any comments or objections.
<nigel> gkatsev: Also it is the equivalent of the "window" FCC requirement
<nigel> q+
<nigel> gkatsev: It would be good to get the other browsers to comment on that.
<nigel> Alastor: I will take a look and leave a comment
<nigel> gkatsev: Do we know anyone at Chrome or is this something we need to chase down separately?
<nigel> .. Anyone specifically?
<nigel> eric-carlson: We should ask Philip. He can point us to the right person.
<nigel> .. He was at MEIG yesterday
<nigel> Dana: OK
<nigel> .. I can ask Philip about it.
<nigel> gkatsev: I don't have any blockers aside from the other vendors.
<nigel> q?
<nigel> ack atai
<nigel> ack nigel
<atsushi> nigel: I had proposal to change name to -background
<atsushi> Dana: don't know which one we should use -backdrop or -background
<atsushi> nigel: TTML has concept of region as box to be placed
<atsushi> gary: WebVTT region is inline block element
<atsushi> ... similar name could be confusing?
<atsushi> nigel: positioning is block level and similar?
<nigel> Dana: So I need to get the answer from whoever is responsible for Chrome if they can accept this.
<nigel> gkatsev: I can also ping Ted from FOMS/Demuxed and pursue that channel as well.
<nigel> SUMMARY: Request feedback from other browser vendors on the feature and name of the element before proceeding
<Dana> https://github.com//issues/531

[alastor0325]

I've reviewed this issue and #516. Adding a new pseudo-element for the block cue window, as well as its proposed naming, both sound reasonable to us (Mozilla).

However, we have a concern regarding how this proposal involves applying system accessibility settings for closed captions. It seems possible for websites to infer user-specific system styles from the computed cue styles, which could lead to fingerprinting risks. How should we address this potential privacy issue?

Additionally, if system settings are applied to cue rendering and a website explicitly sets cue colors that happen to match those from the system settings (for example, both text and background being white), it could result in even worse accessibility for users. How should cases like this be handled?

[emilio]

Yeah two issues that immediately came to mind. For the example, let's say system a11y settings have effectively background-color: white and color: black.

Issue number 1 is causing unreadable backdrops on existing content. Let's say I have a dark video, so as an author unaware of these settings, I write:

video::cue {
  color: white;
}

This works if the backdrop is transparent, but a user with such settings would get white on white and unreadable text.

The other issue is that if you just apply the OS setting to the container you can trivially use getComputedStyle(video, "::cue-backdrop").backgroundColor to extract the OS setting values, right? That would be a fingerprinting concern.

[jernoble]

There is no way to extract style information from inside the shadowDOM of the media element, or that privacy risk would already exist, since both chrome and Safari both already apply system accessibility preferences to browser rendered subtitles.

[jernoble]

...getComputedStyle(video, "::cue-backdrop").backgroundColor to extract the OS setting values, right?

That won't do anything interesting; ::cue-backdrop isn't something that can be querySelector'd.

[emilio]

@jernoble that's generally not right?

I mean, we can decide to not expose ::cue-backdrop to getComputedStyle, but getComputedStyle(.., "::before") and so on work and they can't be querySelector'd

[jernoble]

@jernoble that's generally not right?

This may just be a result of WebKit's implementation of Text Track rendering taking place in the media element Shadow DOM. Styles defined inside the closed Shadow DOM are generally not accessible from the outside.

I mean, we can decide to not expose ::cue-backdrop to getComputedStyle, but getComputedStyle(.., "::before") and so on work and they can't be querySelector'd

It seems like we have an interop problem; Chrome and Safari both do not expose resolved styles of ::cue pseudos, and both do apply system accessibility settings to rendered cues; Firefox does expose those resolved styles, and does not apply system accessibility settings. I suggest we take that up in a different issue.

[jernoble]

@alastor0325 said:

Additionally, if system settings are applied to cue rendering and a website explicitly sets cue colors that happen to match those from the system settings (for example, both text and background being white), it could result in even worse accessibility for users. How should cases like this be handled?

Lets continue this conversation in a separate issue that's narrowly about applying system accessibility preferences to subtitle rendering.

[jernoble]

I filed Issue #536 to track the interop and accessibility discussion.

[gkatsev]

@alastor0325 @emilio I guess my question is do you consider these interop issues a blocker for this PR or is this PR otherwise good to go, and we can continue discussing the interop issues in #537?

[alastor0325]

I think the interop issue in #537 should not block this PR—we can address that separately. This PR looks good to us.