This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16875 - WebVTT :past and :future don't work if you just have text between the timestamps
Summary: WebVTT :past and :future don't work if you just have text between the timestamps
Status: NEW
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard: v1
Keywords:
Depends on:
Blocks: 19126
  Show dependency treegraph
 
Reported: 2012-04-27 15:28 UTC by Simon Pieters
Modified: 2015-11-04 23:26 UTC (History)
7 users (show)

See Also:


Attachments

Description Simon Pieters 2012-04-27 15:28:11 UTC
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).
Comment 1 Simon Pieters 2012-06-01 08:47:28 UTC
(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.
Comment 2 Simon Pieters 2012-06-01 09:03:09 UTC
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)
Comment 3 Silvia Pfeiffer 2012-06-01 11:20:12 UTC
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.
Comment 4 Simon Pieters 2012-06-01 12:45:44 UTC
(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.
Comment 5 Simon Pieters 2012-06-01 12:48:03 UTC
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.
Comment 6 Silvia Pfeiffer 2012-06-01 13:14:18 UTC
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.
Comment 7 Silvia Pfeiffer 2012-06-01 13:15:07 UTC
oops: s/Is this just a problem with the//
Comment 8 Simon Pieters 2012-06-06 19:03:53 UTC
(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.)
Comment 9 Silvia Pfeiffer 2012-06-07 14:06:46 UTC
(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.
Comment 10 Simon Pieters 2012-06-11 06:58:35 UTC
(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
Comment 11 Simon Pieters 2012-06-11 07:00:24 UTC
(In reply to comment #10)
> #document-fragment
> | "foo "
> |   <b>
> |     "bar"

I meant:

#document-fragment
| "foo "
| <b>
|   "bar"
Comment 12 vcarbune 2012-06-17 20:14:52 UTC
(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?
Comment 13 Simon Pieters 2012-06-18 06:09:55 UTC
(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
Comment 14 vcarbune 2012-06-18 22:51:13 UTC
(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.
Comment 15 Ian 'Hixie' Hickson 2012-07-24 16:11:16 UTC
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.
Comment 16 Ian 'Hixie' Hickson 2012-08-07 23:29:49 UTC
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.
Comment 17 Silvia Pfeiffer 2012-08-07 23:58:52 UTC
Those pseudo-elements would be dynamic and dependent on the current video playback time. I think that would work.
Comment 18 Simon Pieters 2012-08-15 09:19:00 UTC
(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.
Comment 19 Ian 'Hixie' Hickson 2012-10-19 19:54:35 UTC
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...
Comment 20 Ian 'Hixie' Hickson 2012-11-21 19:11:26 UTC
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?
Comment 21 Silvia Pfeiffer 2012-11-21 20:22:17 UTC
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.
Comment 22 Simon Pieters 2012-11-22 09:31:24 UTC
Real pseudo-elements sounds OK to me.
Comment 23 Simon Pieters 2013-08-06 11:49:14 UTC
This might become somewhat moot if http://lists.w3.org/Archives/Public/www-style/2013Jul/0547.html gets adopted.
Comment 24 Silvia Pfeiffer 2013-08-06 12:28:54 UTC
Hmm... how does that deal with the element selection problem?
Comment 25 Simon Pieters 2013-08-08 08:26:34 UTC
What problem do you mean?

The original example in comment 0 would be video::cue(::text:past) { ... }
Comment 26 Silvia Pfeiffer 2014-08-30 03:17:10 UTC
(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?
Comment 27 Simon Pieters 2014-09-01 08:24:32 UTC
No. Feel free to bring it up again.
Comment 28 Silvia Pfeiffer 2014-09-06 03:25:02 UTC
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
Comment 29 Philip J├Ągenstedt 2015-03-19 12:13:45 UTC
(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.
Comment 30 Philip J├Ągenstedt 2015-11-03 09:18:24 UTC
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
Comment 31 Simon Pieters 2015-11-04 15:14:43 UTC
I can't access that bug.
Comment 32 Silvia Pfeiffer 2015-11-04 23:26:28 UTC
(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 ;-)