This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Feedback by the CSS WG, see http://lists.w3.org/Archives/Public/public-tt/2015Apr/0007.html Section 6.2.3.3: It looks like cue regions are basically blocks that get filled with cues. Why not just make those an element selectable by ::cue()? You're limited to the same styles that apply to ::cue anyway. http://dev.w3.org/html5/webvtt/#the-cue-region-pseudo-element
related to 28474
asked for clarification in email: We’re not entirely sure we understand this comment. Are you suggesting we view regions as if they were divs, that contain cues, that are effectively divs? The syntax of WebVTT doesn’t really have the concept of nesting here; it’s line-based, not tag-based. Can you clarify your suggestion?
Bert replies: Hmm, it's a long time ago and it wasn't me who wrote the comment. I think the suggestions was to add '::cue(region)' and drop '::cue-region'. In other words: let '::cue' apply to regions (in addition to the other cues it already applies to) and then allow '::cue(region)' analogous to '::cue(v)' and '::cue(i)' for more specific selectors.
(In reply to David Singer from comment #3) > Bert replies: > > Hmm, it's a long time ago and it wasn't me who wrote the comment. I think > the suggestions was to add '::cue(region)' and drop '::cue-region'. In > other words: let '::cue' apply to regions (in addition to the other cues > it already applies to) and then allow '::cue(region)' analogous to > '::cue(v)' and '::cue(i)' for more specific selectors. A region is not a WebVTT Node Object, since it doesn't live inside a cue. Therefore, ::cue(region) doesn't seem to make sense. The region is a cue-like object that exists a level above the cue, so needs a separate selector, e.g. to address all regions with ::cue-region - that would not be possible with a ::cue(region-id).