[webvtt] Suggestions to refine the STYLE block (#498)

xiaochengh has just created a new issue for https://github.com/w3c/webvtt:

== Suggestions to refine the STYLE block ==
(This issue was originally posted as https://github.com/w3c/csswg-drafts/issues/6735)

I'm requesting the following changes regarding the `STYLE` block:

1. Change the cascade precedence of STYLE blocks to be the same as the `style` attribute.

The [current spec](https://www.w3.org/TR/webvtt/#obtaining-css-boxes) only says:

> For the purpose of determining the cascade of the declarations in STYLE blocks of a WebVTT file, the relative order of appearance of the style sheets must be the same order as they were added to the collection, and the order of appearance of the collection must be after any style sheets that apply to the associated video element’s document.

If I understand correct, the intention is to make sure `STYLE` blocks should override regular stylesheets in the document. However, the current spec text doesn't take, e.g., [specificity](https://www.w3.org/TR/css-cascade/#cascade-specificity) into consider, so a regular author style rule with selector `video#id::cue` would override a `::cue` rule in the `STYLE` block. To match the intention, we should make `STYLE` blocks in the author origin, in the same tree scope as the `<track>` element and has the same precedence as a `style` attribute attached to the element.

2. Disallow `@layer` rules and layered `@import` rules in `STYLE` blocks, or even specify an allowlist of what rules are valid

Since `STYLE` blocks apply to only one element, it doesn't make sense to define global structures like [cascade layers](https://www.w3.org/TR/css-cascade-5/#layering) there, in the same way defining layers in the `style` attribute doesn't make sense. So we shouldn't allow that.

To make things more systemic, we may even be more restrictive by specifying an allowlist. My suggestion would be only regular style rules and conditional rules (`@media`, `@support` and `@container`) are valid. Other rules either don't make sense, or require registering something global (like `@font-face`, `@keyframes`, `@property` etc), which is not well-specified and very hard to support (and at least not supported in Chromium AFAICT).

Please view or discuss this issue at https://github.com/w3c/webvtt/issues/498 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 15 October 2021 22:59:04 UTC