Suggestions to refine the STYLE block

[xiaochengh]

(This issue was originally posted as w3c/csswg-drafts#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 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 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 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).

[gkatsev]

For 1, I'm not sure that video#id::cue in the HTML shouldn't override ::cue in the WebVTT file. If we make STYLE blocks bind the same way as the style attribute, it would make it much harder to be able to override the styles, should that be needed. Though, I guess it's possible that !important would still settle that specificity battle?
My reading and the example in the spec seems to imply that given rules of the same specificity, the ones in the STYLE block should win.
For 2, seems like @import is already disallowed. I'm not terribly familiar with @layer yet, but it seems reasonable to exclude it right now, since it's easier to allow it later on if needed rather than removing it later on. It likely makes sense to limit the other rules, as you mention. Though, may be hard to do if already supported in existing implementations.

[xiaochengh]

For 1, I'm not sure that video#id::cue in the HTML shouldn't override ::cue in the WebVTT file. If we make STYLE blocks bind the same way as the style attribute, it would make it much harder to be able to override the styles, should that be needed. Though, I guess it's possible that !important would still settle that specificity battle?

While the current spec text allows video#id::cue in the HTML to override ::cue in the WebVTT file, I'm not sure if that matches the intention of the spec. It would be great if a spec editor could clarify on this.

Also since CSS Cascade Level 5, Element Attached Styles have become an independent sorting criterion in deciding the priority. Since STYLE is directly attached to the <track> element, for consistency, it also should belong to this category and hence has the same priority as the style attribute.

And HTML authors can always try to override non-important styles in the WebVTT file with !important. This is also consistent with the style attribute.

---

For 2, ... Though, may be hard to do if already supported in existing implementations.

@layer is a newly specified feature that is still under implementation by current browsers, and the spec is also under actively revisions. It's very easy to change at this stage.

[gkatsev]

While the current spec text allows video#id::cue in the HTML to override ::cue in the WebVTT file, I'm not sure if that matches the intention of the spec. It would be great if a spec editor could clarify on this.

I'm the current editor but don't have knowledge of when this was implemented. Would love it if @silviapfeiffer could chime in if she remembers anything related to it.

Ultimately, as long as changes don't break existing usage (not that I've seen a lot of webvtt styling, let alone STYLE block usage), better alignment with CSS makes sense.

For 2, ... Though, may be hard to do if already supported in existing implementations.

@layer is a newly specified feature that is still under implementation by current browsers, and the spec is also under actively revisions. It's very easy to change at this stage.

Definitely makes sense for @layer, I was more specifically referring to turning off things like @font-face and others that you mentioned.

[xiaochengh]

Ultimately, as long as changes don't break existing usage (not that I've seen a lot of webvtt styling, let alone STYLE block usage), better alignment with CSS makes sense.

I can confirm that the proposed change aligns with what Chromium currently does. Chromium currently treats STYLE as having the same precedence as the style attribute, and ignores any global-name-defining at-rules (@font-face and etc).

@eric-carlson What do you think about the proposed change? I saw you reviewed the implementation in WebKit, which treats STYLE blocks as child stylesheets of the UA shadow tree, so the exact behavior might differ (example).

Firefox doesn't seem to support STYLE blocks, according to this issue.

[zcorpan]

I wrote the STYLE spec originally.

I think the intent is conveyed in this example in the spec: https://www.w3.org/TR/webvtt/#example-01d14f75

That is, act as if the rules from the outer document appear first and then the embedded STYLE blocks, and no other special casing for specificity. So the specified ordering of stylesheets are only relevant to determine winning rule when the specificity is the same.

HTH.