Can ::cue(selector) match a list of webvtt node objects?

[danae404]

I am curious if I have this css:

::cue(*) {
color: green
}

And this .vtt:

WEBVTT

00:00:00.000 --> 00:00:05.000
This is a test subtitle

Should "This is a test subtitle" be green?

The section of spec that discusses ::cue(selector) says this:

The ::cue(selector) pseudo-element with an argument must have an argument that consists of a CSS selector [SELECTORS4]. It matches any WebVTT Internal Node Object constructed for the matched element that also matches the given CSS selector [...]

Because ::cue(selector) matches any WebVTT Internal Node Object that also matches the selector, and because Lists of WebVTT Node Objects are a subclass of WebVTT Internal Node Object, this seems to indicate that ::cue(*) should match the list/root.

However, later the spec says that type selectors match "WebVTT Internal Node Objects (except the root list of WebVTT Node Objects) with the given name."

This seems like a contradiction to what the spec says earlier. Is one of these statements an error that should be fixed?

[danae404]

@silviapfeiffer

[zcorpan]

I think it's reasonable to make ::cue(*) not match the root.

[gkatsev]

Yeah, I think it's reasonable to remove to simplify things since we also have the alternative of ::cue. If ::cue wasn't available, or it functioned too differently, I'd be more concerned.

While it's technically a breaking change, I think styling is likely not implemented or used widely enough to be an issue. Though, if anyone knows otherwise, worth thinking about it now.

[danae404]

A follow up question: should ::cue(:root) be allowed? We have tests for this selector, but all the browsers fail them

[gkatsev]

My initial thought is that for simplicity we can have ::cue() only allow the explicit VTT tags only, so, :root wouldn't be allowed either. But open for other's thoughts on this.

[zcorpan]

Yeah I think just make the root element never match for :cue(), without listing * or :root or other specifically.

[css-meeting-bot]

The Timed Text Working Group just discussed Can ::cue(selector) match a list of webvtt node objects? w3c/webvtt#533, and agreed to the following:

• SUMMARY: @danae404 and @gkatsev to re-read the spec about nodes, and check the archives for history about the intent.

The full IRC log of that discussion

<nigel> Subtopic: Can ::cue(selector) match a list of webvtt node objects? #533
<nigel> github: https://github.com//issues/533
<nigel> Dana: This is about ::cue pseudo element.
<nigel> .. You can add a selector to that as an argument.
<nigel> .. We're finding that all of the browsers are failing the tests where the selector is * or :root
<nigel> .. When we consult the WebVTT specification we find that it's ambiguous.
<nigel> .. It's not spelled out if those selectors are supposed to be supported.
<nigel> .. One idea that I think I agree is to have the only allowed type selectors be the explicit VTT classes
<nigel> .. like bold, underline, voice, language, ruby text, so we have a concrete list of type selectors,
<nigel> .. and the universal or root selector wouldn't be supported.
<nigel> Gary: The issue is that the spec implies that bare text nodes should be selected, but it's not clear.
<nigel> .. Should the * match those as well as the explicit tags.
<nigel> .. No browser implements selection of the explicit tags without the text nodes ("internal node objects")
<nigel> .. But whether it should is unclear.
<nigel> Nigel: What are the use cases?
<nigel> Dana: It's for styling the internal nodes within the cues, e.g. make all bold elements green.
<nigel> .. The use case for the * selector is covered by the pseudo element without the selector argument,
<nigel> .. because that already matches to the cues.
<nigel> Andreas: Thanks for bringing this up.
<nigel> .. For confirmation, if you have cue text and you want to apply CSS styles to all of them,
<nigel> .. then you can already do that by using ::cue without a selector?
<nigel> nods
<nigel> Andreas: And the * selector most likely is supposed to do the same thing?
<nigel> .. But it's ambiguous if it includes text enclosed by tags.
<nigel> .. It's questionable why you should exclude it.
<nigel> .. Why should the * selector give the same results as no selector?
<nigel> Gary: Given that it's covered, unclear in the spec and not implemented, we can remove it
<nigel> .. from the spec and call it a day.
<nigel> Dana: Would the spec change be to say that the 8 or so type selectors are the only allowed ones?
<nigel> Gary: I think that might be the best course of action, to be as explicit as possible.
<nigel> Nigel: Are you saying that * selector applies to tagged text only, or to remove *?
<nigel> Gary: The first, that it applies to tagged text only.
<nigel> Nigel: What's the relationship between that and Dana's suggestion of limiting the set of tags?
<nigel> .. Sounds like an orthogonal issue.
<nigel> Gary: The spec lists the node objects, which are the untagged text objects.
<nigel> .. Simon suggested the root element never match. I guess that would be an alternative,
<nigel> .. to say that internal node objects don't match the * selector.
<atai> q+
<nigel> ack atai
<nigel> Andreas: I'm also a bit confused. I thought that your approach would be to remove the * completely,
<nigel> .. but you're now saying to keep it but make the semantics only apply to text inside tags?
<nigel> Gary: Yes, I don't know if we can remove it completely.
<nigel> Andreas: If it's ambiguous and not properly implemented then this way is also not properly implemented, right?
<nigel> .. Why are you using this kind of solution?
<nigel> Nigel: you mean what is the * for at all?
<nigel> Andreas: Yes, if it's ambiguous and not properly implemented, why target a specific different meaning?
<nigel> .. What points you to this solution?
<nigel> .. If it's used already and people have a different interpretation, then some existing WebVTT
<nigel> .. files might then have a different presentation, and users would not be happy.
<nigel> Dana: That's a good point. I'm not sure which solution I like best.
<nigel> .. I'm thinking, in terms of ease of implementation, there could be a potential problem to have
<nigel> .. the * only apply to internal text and not the root, because then we have other selectors
<nigel> .. like the id selector that would need to match the root.
<nigel> Gary: One of the ambiguities is that it says, maybe we used the terms incorrectly,
<nigel> .. that it matches any internal node object and that includes both tags with existing names
<nigel> .. and those without explicit names, like times.
<nigel> .. and then it says leaf nodes are not matched, and those include text or fragments of text.
<nigel> .. There's that ambiguity that fragments seem to be listed as matchable but then later on it says
<nigel> .. leaf node objects cannot be matched.
<nigel> Dana: Are you talking about how the spec says in one place that leaf node objects are separate
<nigel> .. from internal node objects and then later on it says they are a subset of internal node objects?
<nigel> Gary: Yeah, I guess this isn't straightforward.
<nigel> .. I think the main question is that in the cue selector it has a table of things it should be able
<atai> q+
<nigel> .. to match and the question is what it means by "other elements".
<nigel> .. I think we need to review the spec again because it's very likely that we still need a clarification
<nigel> .. but maybe the spec is clearer than on first reading, and the tests may not be correct.
<nigel> ack at
<nigel> Andreas: As a suggestion, you might want to consult the meeting archives to find a better hint
<nigel> .. on the intent.
<nigel> Nigel: Good point, why is it written the way it is written?
<nigel> Dana: I'm curious if we say that a selector matches a leaf node object, like a text node object,
<nigel> .. is that referring to the text content within a span, which you cannot style?
<nigel> .. When they said you cannot target the leaf node objects maybe that's what they're talking about.
<nigel> Gary: It could be the same as HTML where you cannot target text but you can target the span that they're in.
<nigel> Dana: If you can't target that then you target the root.
<nigel> Gary: Yes, that would be the ::cue
<nigel> Dana: Another way is to say it matches both the root and any internal nodes.
<nigel> Nigel: Another way is to say the * matches on the tag name, and not on null, so the root would be excluded.
<nigel> Gary: That's what it seems like it wants to do.
<nigel> .. Then :root would not be allowed as a selector, and * would not match against :root
<nigel> Nigel: Why not allow :root?
<nigel> .. From an implementation perspective would you not have the default selector for ::cue be ::cue(:root)?
<nigel> Gary: The options are either * and :root are allowed or explicitly not allowed.
<nigel> .. Since it's also a CSS extension and the implementations are lacking we can decide to simplify it.
<nigel> Nigel: What's the next step?
<nigel> Gary: Immediate next step is to read through the spec again to exactly understand what it means
<nigel> .. by internal node objects and leaf node objects and see if there's any history about the intent.
<nigel> SUMMARY: @danae404 and @gkatsev to re-read the spec about nodes, and check the archives for history about the intent.
<nigel> Dana: Are there publicly available notes about the development of WebVTT spec?
<nigel> Gary: I think they are, and there's discussion on GitHub.
<nigel> Andreas: Some of it will be in the text track community group. There may have been
<nigel> .. some in the WHATWG too so you may have to look at different sources.
<nigel> Gary: Some of the old FOMS websites when WebVTT was first developed have some notes too.

[zcorpan]

The issue is that the spec implies that bare text nodes should be selected, but it's not clear.

Text nodes can never match a selector as defined in Selectors. What part of WebVTT implies that they should?

::cue(*) needs to continue to match elements within the cue, but not text nodes. Changing this would change the semantics of Selectors and seems unacceptable, and disallowing * specifically would be a layering violation which also seems unacceptable.

Whether to match the root element or not is up for debate, but if it doesn't match the root then, for consistency, ::cue(:root) (or any selector that would match the root according to Selectors) should also not match.

The point of ::cue(selector) is just to be able to target and style specific elements within the cue, like b elements.

[css-meeting-bot]

The Timed Text Working Group just discussed Can ::cue(selector) match a list of webvtt node objects? w3c/webvtt#533, and agreed to the following:

• SUMMARY: @gkatsev to summarise the WebVTT Interop meeting conclusion about this

The full IRC log of that discussion

<nigel> Topic: Can ::cue(selector) match a list of webvtt node objects? #533
<nigel> github: https://github.com//issues/533
<nigel> Gary: We discussed this in the WebVTT Interop meeting yesterday
<nigel> SUMMARY: @gkatsev to summarise the WebVTT Interop meeting conclusion about this
<nigel> Gary: Example 22 needs updating and the styling under the cue text parsing rules needs fixing for clarity.

[danae404]

PR addressing this: #534