Basically :past styles all the nodes except for the :future nodes. We could use the combination of ::cue() and ::cue(:future) to style WebVTT nodes that are in the past, though it may be good to have a designated selector for that. http://dev.w3.org/html5/webvtt/#the-'::cue'-pseudo-element
<rdar://problem/12914642>
Created attachment 184101 [details] Proposed fix 0.1
Comment on attachment 184101 [details] Proposed fix 0.1 View in context: https://bugs.webkit.org/attachment.cgi?id=184101&action=review r+ but I would prefer to have a bit more logging to help someone looking at the test results figure out what is happening. > LayoutTests/media/track/track-css-matching-timestamps-expected.txt:32 > +RUN(video.currentTime = 0.7) > +EVENT(seeked) > +EXPECTED (getComputedStyle(cueNode).color == 'rgb(0, 255, 0)') OK > +EXPECTED (getComputedStyle(cueNode).color == 'rgb(0, 255, 0)') OK > +EXPECTED (getComputedStyle(cueNode).color == 'rgb(0, 255, 0)') OK > +EXPECTED (getComputedStyle(cueNode).color == 'rgb(128, 128, 128)') OK > +EXPECTED (getComputedStyle(cueNode).color == 'rgb(0, 255, 0)') OK I thought these results were wrong at first, and really had to scratch my head before I understood the tree structure created by the <c>s in the cue. I think it would be worth also logging the text of each cue node to make it more obvious what is going on.
Comment on attachment 184101 [details] Proposed fix 0.1 Clearing flags on attachment: 184101 Committed r140707: <http://trac.webkit.org/changeset/140707>
All reviewed patches have been landed. Closing bug.