16875 2012-04-27 15:28:11 +0000 WebVTT :past and :future don't work if you just have text between the timestamps 2015-11-04 23:26:28 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All NEW v1 P2 normal --- 19126 1 zcorpan zcorpan ian lorettaguarino mike philipj public-texttracks silviapfeiffer1 victor.carbune dave.null oldest_to_newest 67144 0 zcorpan 2012-04-27 15:28:11 +0000 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). 68484 1 zcorpan 2012-06-01 08:47:28 +0000 (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. 68485 2 zcorpan 2012-06-01 09:03:09 +0000 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) 68496 3 silviapfeiffer1 2012-06-01 11:20:12 +0000 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. 68508 4 zcorpan 2012-06-01 12:45:44 +0000 (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. 68509 5 zcorpan 2012-06-01 12:48:03 +0000 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. 68511 6 silviapfeiffer1 2012-06-01 13:14:18 +0000 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. 68512 7 silviapfeiffer1 2012-06-01 13:15:07 +0000 oops: s/Is this just a problem with the// 68768 8 zcorpan 2012-06-06 19:03:53 +0000 (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.) 68801 9 silviapfeiffer1 2012-06-07 14:06:46 +0000 (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. 68906 10 zcorpan 2012-06-11 06:58:35 +0000 (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 68907 11 zcorpan 2012-06-11 07:00:24 +0000 (In reply to comment #10) > #document-fragment > | "foo " > | <b> > | "bar" I meant: #document-fragment | "foo " | <b> | "bar" 69170 12 victor.carbune 2012-06-17 20:14:52 +0000 (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? 69186 13 zcorpan 2012-06-18 06:09:55 +0000 (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 69212 14 victor.carbune 2012-06-18 22:51:13 +0000 (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. 71401 15 ian 2012-07-24 16:11:16 +0000 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. 71917 16 ian 2012-08-07 23:29:49 +0000 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. 71919 17 silviapfeiffer1 2012-08-07 23:58:52 +0000 Those pseudo-elements would be dynamic and dependent on the current video playback time. I think that would work. 72191 18 zcorpan 2012-08-15 09:19:00 +0000 (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. 76746 19 ian 2012-10-19 19:54:35 +0000 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... 78584 20 ian 2012-11-21 19:11:26 +0000 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? 78602 21 silviapfeiffer1 2012-11-21 20:22:17 +0000 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. 78640 22 zcorpan 2012-11-22 09:31:24 +0000 Real pseudo-elements sounds OK to me. 91683 23 zcorpan 2013-08-06 11:49:14 +0000 This might become somewhat moot if http://lists.w3.org/Archives/Public/www-style/2013Jul/0547.html gets adopted. 91685 24 silviapfeiffer1 2013-08-06 12:28:54 +0000 Hmm... how does that deal with the element selection problem? 91779 25 zcorpan 2013-08-08 08:26:34 +0000 What problem do you mean? The original example in comment 0 would be video::cue(::text:past) { ... } 110793 26 silviapfeiffer1 2014-08-30 03:17:10 +0000 (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? 110816 27 zcorpan 2014-09-01 08:24:32 +0000 No. Feel free to bring it up again. 111118 28 silviapfeiffer1 2014-09-06 03:25:02 +0000 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 118680 29 philipj 2015-03-19 12:13:45 +0000 (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. 124050 30 philipj 2015-11-03 09:18:24 +0000 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 124079 31 zcorpan 2015-11-04 15:14:43 +0000 I can't access that bug. 124084 32 silviapfeiffer1 2015-11-04 23:26:28 +0000 (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 ;-)