This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider WEBVTT 00:00:00.000 --> 00:00:10.000 foo <00:03.000> bar <00:07.000> baz and video::cue(:past) { color:green } This wouldn't do anything per the current spec, because the cue has only WebVTT Leaf Node Objects, and they cannot be matched by ::cue(). To make it work per spec, you have to do: WEBVTT 00:00:00.000 --> 00:00:10.000 <c>foo</c> <00:03.000> <c>bar</c> <00:07.000> <c>baz</c> This seems pretty horrible. To fix it we could make ::cue() be able to match text leaf nodes (so they basically act like name-less elements to selectors).
(In reply to comment #0) > To fix it we could make ::cue() be able to match text leaf nodes (so they > basically act like name-less elements to selectors). Except that's also kind of horrible. Maybe it would be better if timestamps somehow were elements that wrapped the relevant text.
Something like this: <00:00.000> Hello, <00:01.350> <i>you fool, <00:02.800> I love you becomes: #document-fragment | <00:00.000> | " Hello, " | <00:01.350> | " " | <i> | "you fool, " | <00:02.800> | " I love you" (not trying to reopen the <i> since WebVTT doesn't try to DWIM in general anyway)
I thought it worked like this: ::cue:past { color: yellow; } ::cue:future { text-shadow: black 0 0 1px; } This would make all parts of all active cues before the current time yellow and tive all parts of all active cues after the current time a shadow.
(In reply to comment #3) > I thought it worked like this: > > ::cue:past { > color: yellow; > } > ::cue:future { > text-shadow: black 0 0 1px; > } > > This would make all parts of all active cues before the current time yellow and > tive all parts of all active cues after the current time a shadow. For foo <00:03.000> bar <00:07.000> baz the above style rules do nothing, since there are no elements, so the selectors don't match anything.
Also, ::cue:past and ::cue:future as used in your example would be a pseudo-class on the "List of WebVTT Node Objects" object (i.e. the root element) which never matches :past or :future. It needs to be something like ::cue(*:past) and ::cue(*:future) to match elements (like <c>) in the cue.
Hmm, I see. Is this just a problem with the Leaf text nodes probably need to be wrapped into anonymous <c> elements or something similarly addressable (basically, a <div>). Maybe each cue object is initially inside such an anonymous <c>/<div> element, which is broken up further when more timestamps are present.
oops: s/Is this just a problem with the//
(In reply to comment #6) > Leaf text nodes probably need to be wrapped into anonymous <c> elements or > something similarly addressable (basically, a <div>). Maybe each cue object is > initially inside such an anonymous <c>/<div> element, which is broken up > further when more timestamps are present. That was basically my initial proposal (in comment 0), but it's quite weird and different to HTML and it makes all cues that don't use any timestamps to pay an element in "tax". Making the timestamps themselves be elements (comment 2) seems like a better approach, I think. (We could even make :past and :future only match timestamp elements.)
(In reply to comment #8) > That was basically my initial proposal (in comment 0), but it's quite weird and > different to HTML and it makes all cues that don't use any timestamps to pay an > element in "tax". Making the timestamps themselves be elements (comment 2) > seems like a better approach, I think. (We could even make :past and :future > only match timestamp elements.) The problem is that a time stamp is a time instant and not a time interval, so it would essentially need a wrapping that ends with the next time instant. Thus it creates the same kind of leaf node wrapping as your initial proposal. I don't really see the advantage.
(In reply to comment #9) > The problem is that a time stamp is a time instant and not a time interval, I don't see why that is a problem. > so > it would essentially need a wrapping that ends with the next time instant. That's the proposal in comment 2. > Thus > it creates the same kind of leaf node wrapping as your initial proposal. Well, it creates the same kind of wrapping as normal elements (except there's no end tag, it's implied by the next timestamp). > I > don't really see the advantage. The advantage is that you only get elements where they are needed. With the initial proposal, you get elements all over the place, which has all kinds of implications with how CSS applies to it, even for cues that don't use timestamps. Consider this cue text foo <b>bar</b> With the current spec, with HTML, and with the proposal in comment 2, the tree would be #document-fragment | "foo " | <b> | "bar" With the proposal in comment 0, the tree would be (as seen from CSS anyway) #document-fragment | <> | "foo " | <b> | <> | "bar" Now consider for instance a trivial style rule like ::cue(*) { outline:solid }. This would create an outline for the <b> element *and* the child <> element, and since they take up the same space, they cancel each other out. It would also outline the "foo" even though that doesn't happen in HTML. This is clearly just wrong. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1567
(In reply to comment #10) > #document-fragment > | "foo " > | <b> > | "bar" I meant: #document-fragment | "foo " | <b> | "bar"
(In reply to comment #2) > Something like this: > > <00:00.000> Hello, <00:01.350> <i>you fool, <00:02.800> I love you > > becomes: > > #document-fragment > | <00:00.000> > | " Hello, " > | <00:01.350> > | " " > | <i> > | "you fool, " > | <00:02.800> > | " I love you" > > (not trying to reopen the <i> since WebVTT doesn't try to DWIM in general > anyway) How would this actually fit in the fact that the DocumentFragment has timestamps as ProcessingInstructions? I'm pretty new to this, but it would still mean to change the timestamp from a ProcessingInstruction to an element accepting style. Why not dynamically wrap past elements and future and element in just two different styled containers, to which further we apply the CSS rules?
(In reply to comment #12) > How would this actually fit in the fact that the DocumentFragment has > timestamps as ProcessingInstructions? I'm pretty new to this, but it would > still mean to change the timestamp from a ProcessingInstruction to an element > accepting style. Yes, we can change that as well. > Why not dynamically wrap past elements and future and element in just two > different styled containers, to which further we apply the CSS rules? I'm not sure I follow what you mean. What do you do with this? A <00:03.000> B <c> C <00:07.000> D </c> E
(In reply to comment #13) > > Why not dynamically wrap past elements and future and element in just two > > different styled containers, to which further we apply the CSS rules? > > I'm not sure I follow what you mean. What do you do with this? > > A <00:03.000> B <c> C <00:07.000> D </c> E I think my suggestion isn't correct, as I might have oversimplified things; so allow me to step back a bit just to make sure I understood correctly the spec. Given the current playback time of 00:05.000 do we obtain the following sets (considering leaf nodes as well)? Past: A [ because <00:03.000> < 00:05.000 is "entirely after" ] Future: D E [ because <00:07.000> > 00:05.000 is "entirely before" ] So "B" and "<c> C <00:07.000> D </c>" wouldn't match neither :past, nor :future.
Making the timestamps into elements doesn't solve the leading text problem. I think it makes sense to just have implied elements at the innermost level, but I'll have to think about this some more.
Ok so how about if we just make :before and :after match implied elements that wrap the "text node"-like objects? Kind of like pseudo-elements, except that you're matching the pseudo-class against them, rather than selecting them directly.
Those pseudo-elements would be dynamic and dependent on the current video playback time. I think that would work.
(In reply to comment #16) > Ok so how about if we just make :before and :after match implied elements that > wrap the "text node"-like objects? Kind of like pseudo-elements, except that > you're matching the pseudo-class against them, rather than selecting them > directly. s/before/past/ s/after/future/ AFAICT that is the comment 0 proposal. I explained in comment 10 why I think it's a bad idea.
I really meant more like pseudo-elements than that; I meant these things wouldn't match "*". They'd _only_ match selectors that contained :past and :future and no explicit element type selector (other than the universal selector). I think essentially requiring timestamps to only occur at the top level is really ugly. It means taking an existing well-marked-up cue and adding timings would be a really invasive procedure. Maybe we should in fact make :past and :future really be only pseudo-elements. Are there many effects you couldn't do if we did that, that you'd plausibly want to do? Since they can only change things like colour anyway...
Ok my new plan is to make ::past and ::future be pseudo-elements that wrap innermost as if they were elements in the tree at the leaf level, and to disallow ::first-letter and ::first-line to match anything in cues. Any objections?
Hmm... ::first-line could be useful, but really, :nth-child would be even more useful for line-based styling if each line was a selectable child.
Real pseudo-elements sounds OK to me.
This might become somewhat moot if http://lists.w3.org/Archives/Public/www-style/2013Jul/0547.html gets adopted.
Hmm... how does that deal with the element selection problem?
What problem do you mean? The original example in comment 0 would be video::cue(::text:past) { ... }
(In reply to Simon Pieters from comment #23) > This might become somewhat moot if > http://lists.w3.org/Archives/Public/www-style/2013Jul/0547.html gets adopted. I see that thread ended at http://lists.w3.org/Archives/Public/www-style/2013Jul/0588.html . Has there been any progress with a ::text pseudo-element?
No. Feel free to bring it up again.
Note to self: analyse how Chrome, Safari and Opera are supporting :past in http://src.chromium.org/blink/trunk/LayoutTests/media/track/track-css-matching-timestamps.html
(In reply to Silvia Pfeiffer from comment #28) > Note to self: analyse how Chrome, Safari and Opera are supporting :past in > http://src.chromium.org/blink/trunk/LayoutTests/media/track/track-css- > matching-timestamps.html Maybe bug 28237 can answer this. In Blink/WebKit, every node is :past unless it is :future. Spec says otherwise.
Some kind of fix for this would be nice, Loretta has stumbled on this as well: https://code.google.com/p/chromium/issues/detail?id=342592
I can't access that bug.
(In reply to Simon Pieters from comment #31) > I can't access that bug. "WebVTT: paint-on captions are not supported" is the title of the bug... rest is obvious ;-)